removing my old ACLs from an obsolete WebSphere Portal Server's external authorization

Problem

I want to delete the old WPS... ACLs from the old WebSphere Portal Server external authorization, which are not needed anymore. (Note: It was no problem to delete the object /WPS.)

But I cannot modify/delete or even show the ACLs in pdadmin or WPM. In pdadmin I cannot see any ACL Entry on the object or on the ACL, but in a pdacld_dump I can see ACL entries for Groups and Users (Principals).

I'm getting always:
Could not perform the administration request
Error: HPDAC1050E Operation is not authorized. (status 0x1005b41a)

pdadmin sec_master> acl show WPS_PORTLET_DEFINITION_MCO-directory-Search_3_0_1O9-User
ACL Name: WPS_PORTLET_DEFINITION_MCO-directory-Search_3_0_1O9-User
Description: ACL for WP rolePORTLET_DEFINITION/MCO directory Search/3_0_1O9@User
Entries:

---------> no ACLEntry can be seen

I did a pdacld_dump on the PD from the PolicyDirector/db/master_authzn.db:

/opt/PolicyDirector/sbin/pdacld_dump -f /var/PolicyDirector/db/master_authzn.db > /opt/install/MigData/INT/master_authzn_20100317dg03.dump

START OBJECT
Object type: 1282
Object size: 12
Object name: /auth/acl-map/WPS_PORTLET_DEFINITION_MCO-directory-Search_3_0_1O9-User
Object seqnum: 0
ACL to Protected object map:
ACL is attached at:
END OBJECT

--------> ACL is not attached to any object

START OBJECT
Object type: 1293
Object size: 232
Object name: /auth/extended-acl/WPS_PORTLET_DEFINITION_MCO-directory-Search_3_0_1O9-User
Object seqnum: 0
ACL:
Sequence number: 0
Description: ACL for WP rolePORTLET_DEFINITION/MCO directory Search/3_0_1O9@User
Entries:
ACLEntry: Principal 79a134ca-1c21-11d9-ae84-00096b3e3f52 [0]0x45fc3
ACLEntry: Group 72022e86-7914-11d9-ae84-00096b3e3f52 [0]0x4c3
ACLEntry: Group 93c4261c-1952-11da-a1b1-00096b3e3f52 [1]0x1
END OBJECT

--------> ACL has ACLEntries! But "Principal 79a134ca-1c21-11d9-ae84-00096b3e3f52" does not exist anymore. (No clue why.)

Solution

I created a new user in the LDAP with exactly this Principal in the SecAuthority=Default part of the LDAP:

ivmgr@SRVab34: /opt/install/MigData/INT $ ldapadd -h localhost -p 389 -x -D "cn=root" -w ******** -f newuser.ldif
adding new entry "principalName=myNewUser,cn=Users,secAuthority=Default"

dn: principalName=myNewUser,cn=Users,secAuthority=Default
objectclass: secUser
objectclass: eUser
objectclass: cimManagedElement
objectclass: top
secAuthority: Default
secLoginType: Default:LDAP
secAcctValid: true
principalName: myNewUser
secUUID: 79a134ca-1c21-11d9-ae84-00096b3e3f52
secHasPolicy: false
secDN: uid=myNewUser,cn=wps,cn=admusr,o=mco
secPwdLastChanged: 20151208214816.0Z
secPwdValid: true

Then I created the very same user in PD with pdadmin, which creates this user in the LDAP under o=mco, too:

pdadmin> user create myNewUser uid=myNewUser,cn=wps,cn=admusr,o=mco myNewUser myNewUser test1234
pdadmin> user modify myNewUser account-valid yes
pdadmin sec_master> group modify iv-admin add myNewUser

Now the secUUID under o=mco and SecAuthority=Default differ:

ivmgr@SRVab34: /opt/install/MigData/INT $ ldapsearch -x -D "cn=root" -w ********* -b "SecAuthority=Default" secUUID=79a134ca-1c21-11d9-ae84-00096b3e3f52
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: secUUID=79a134ca-1c21-11d9-ae84-00096b3e3f52
# requesting: ALL
#

# myNewUser, Users, Default
dn: principalName=myNewUser,cn=Users,secAuthority=Default
objectclass: secUser
objectclass: eUser
objectclass: cimManagedElement
objectclass: top
secAuthority: Default
secLoginType: Default:LDAP
secAcctValid: true
principalName: myNewUser
secUUID: 79a134ca-1c21-11d9-ae84-00096b3e3f52
secHasPolicy: false
secDN: uid=myNewUser,cn=wps,cn=admusr,o=mco
secPwdLastChanged: 20151208214816.0Z
secPwdValid: true

ivmgr@SRVab34: /opt/install/MigData/INT $ ldapsearch -x -D "cn=root" -w ******** -b "o=mco" principalname=myNewUser
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: principalname=myNewUser
# requesting: ALL
#

# Default, myNewUser, wps, admusr, mco
dn: secAuthority=Default,uid=myNewUser,cn=wps,cn=admusr,o=mco
objectclass: secUser
objectclass: eUser
objectclass: cimManagedElement
objectclass: top
secAuthority: Default
secLoginType: Default:LDAP
secAcctValid: FALSE
secPwdValid: TRUE
principalName: myNewUser
secUUID: 9d0cd052-31a3-11df-a2b6-0050569d0d5f
secHasPolicy: FALSE
secDomainId: Default%myNewUser
secPwdLastChanged: 20100317090102.0Z


-----------> secUUID differ!!!

So I changed the entry of this user under o=mco to have the same secUUID. That is to say the principal from above. (Principal 79a134ca-1c21-11d9-ae84-00096b3e3f52)

ivmgr@SRVab34: /opt/install/MigData/INT $ cat moduser.ldif
dn: secAuthority=Default,uid=myNewUser,cn=wps,cn=admusr,o=mco
changetype: modify
secUUID: 79a134ca-1c21-11d9-ae84-00096b3e3f52

ivmgr@SRVab34: /opt/install/MigData/INT $ ldapmodify -h localhost -p 389 -x -D "cn=root" -w ******** -f moduser.ldif
modifying entry "secAuthority=Default,uid=myNewUser,cn=wps,cn=admusr,o=mco"

ivmgr@SRVab34: /opt/install/MigData/INT $ ldapsearch -x -D "cn=root" -w ********* -b "o=mco" principalname=myNewUser
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: principalname=myNewUser
# requesting: ALL
#

# Default, myNewUser, wps, admusr, mco
dn: secAuthority=Default,uid=myNewUser,cn=wps,cn=admusr,o=mco
objectclass: secUser
objectclass: eUser
objectclass: cimManagedElement
objectclass: top
secAuthority: Default
secLoginType: Default:LDAP
secAcctValid: FALSE
secPwdValid: TRUE
principalName: myNewUser
secHasPolicy: FALSE
secDomainId: Default%myNewUser
secPwdLastChanged: 20100317090102.0Z
secUUID: 79a134ca-1c21-11d9-ae84-00096b3e3f52

-----------> secUUID equal!!!

pdadmin myNewUser> acl show WPS_PORTLET_DEFINITION_MCO-directory-Search_3_0_1O9-User
ACL Name: WPS_PORTLET_DEFINITION_MCO-directory-Search_3_0_1O9-User
Description: ACL for WP rolePORTLET_DEFINITION/MCO directory Search/3_0_1O9@User
Entries:
User myNewUser TcmdbsvaBRl

----------> Own ACLEntry can be seen in pdadmin.
----------> ACLs can be deleted logged in with myNewUser

Yeah! :-)