Monday, 1 August 2016

IBM IIS USER AND GROUP ROLE ASSIGNMENTS ARE NOT PRESERVED AFTER CONVERTING FROM STAND-ALONE LDAP TO FEDERATED USER REGISTRY

Information Server security roles assigned to LDAP users and groups, as well as Steward and access permissions configured in Business Glossary, when the system is configured for a stand-alone LDAP user registry, are saved in the Information Server local repository and assigned to the LDAP full distinguished name (DN) of the user or group.

Once the user registry is converted to Federated and this LDAP registry is configured as one of the Federated repositories, by default queries to the Federated registry expect short (RDN) user and group names and return the names as short (RDN) names.

For the existing assigned roles in the Information Server local repository to be properly associated with the LDAP entities, the names must match with what the Federated registry returns.

To continue using the existing role assignments, the Federated configuration must be changed to expect and return long (DN) names.

This is done by changing the Federated User repository attribute mapping configuration in the WebSphere Integrated Solutions Console (WAS Admin Console). 1) login to the WAS Admin Console with valid WAS administrator credentials

2) modify your configured Federated repository settings by Selecting Security > Global security > select Federated repositories in the Available realm definitions under User account repository > click Configure...

3) click "User repository attribute mapping" under Additional Properties

4) select groupSecurityName and userSecurityName and click Edit

5) for groupSecurityName, set Property for Input and Property for Output values to uniqueName

6) for userSecurityName, set Property for Input value to principalName and set Property for Output value to uniqueName

7) click Apply and then Save directly to the master configuration

8) assuming you have already completed the rest of the Federated configuration restart WebSphere for the changes to take affect.

No comments:

Post a Comment