Direkt zum Hauptbereich

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! :-)
Labels:

Kommentare

Anonym hat gesagt…
To sum up, just change the secuuid?
8. April 2015 um 17:47
Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

How to delete WebSEAL servers which have not been configured correctly.

Problem: The WebSEAL server list in the pdadmin: pdadmin> server list shows the server, but it does not exist anymore, i.e. because the host has been disassembled without unconfiguring the WebSEAL instance. Solution: 1.) Delete the instance in the LDAP under: SecAuthority=Default - cn=securitygroup - cn=webseal-servers - cn=secmgrd-servers 2.) Configure the instance again, which will lead to an error, because it seems to be installed already. Configuring WebSEAL instance 'DO-06'...HPDMG0453E A server with the same name already exists.DPWCF0473E The WebSEAL instance 'DO-06' failed to configure. 3.) Unconfigure the instance, which will show errors, but remove the instance totally. # amwebcfg -action unconfig -inst_name DO-06 -admin_id sec_master -admin_pwd ********* Unconfiguring WebSEAL instance 'DO-06'... 2008-10-28-15:30:10.158+01:00I----- 0x389D51F2 amwebcfg ERROR wcf Error WebCfgAdminApi.cpp 84 0x002198d0 DPWCF0498E The user 'DO-06-webseald/srv1252'
Kommentar veröffentlichen
Mehr anzeigen

GSK_KEYRING_OPEN_ERROR-Keyring file did not open

2011-01-18-10:06:22.760+01:00I----- 0x389D0389 webseald WARNING wca revpwd revpwdchk_gskit_sock.c 130 0x0403ab90 DPWCA0905W   Function call, gsk_environment_init, failed error: 000000ca GSK_KEYRING_OPEN_ERROR-Keyring file did not open. 2011-01-18-10:06:22.760+01:00I----- 0x13212064 webseald WARNING ias general pdauthn.cpp 1740 0x0403ab90 HPDIA0100E   An internal error has occurred. Function call, func, failed error: error code error text. Explanation: The specified GSKit function failed while setting up for SSL connections to junctions or from browsers. Or perhaps the initial handshake failed due to invalid certificates or the browser simply closed the connection abruptly. Action: Examine the error text for details. Typical problems might be that the PKCS#11 library is incorrectly specified, or the PKCS#11 token or token password is incorrect, or the PKCS#11 token is not set up. Name: revpwd_s_ssl_status_function_ failed Number: 0x389d0389 (949814153) Severity: W
Kommentar veröffentlichen
Mehr anzeigen

DPWWA1203E Permission denied // DPWAD0312E Object list failed: Forbidden

cmd> server task cnt-1a-webseald-hst7127 create -f -t tcp -h -v hst7105 -p 80 -w /ICB DPWWA1203E Permission denied pdadmin sec_master> object list /WebSEAL/hst7127-cnt-1a DPWAD0312E Object list failed: Forbidden The reason for this behaviour was that somehow my container /WebSEAL in the object space got the ACL default-root instead of default-webseal by the installation. pdadmin sec_master> object listandshow /WebSEAL Name: /WebSEAL/hst7127-cnt-1a Description: WebSEAL Server Object Type: 5 (Junction) Is Policy Attachable: Yes Extended Attributes: Attached ACL: Attached POP: Attached AuthzRule: Effective Extended Attributes: Effective ACL: default-root Effective POP: Effective AuthzRule: Name: /WebSEAL/hst7127-mas-01 Description: WebSEAL Server Object Type: 5 (Junction) Is Policy Attachable: Yes Extended Attributes: Attached ACL:
Kommentar veröffentlichen
Mehr anzeigen