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

-

Error description

  • When converting Information Server from a stand-alone LDAP  configuration to a Federated user registry that includes the  same LDAP registry, the Information Server security roles  previously assigned to LDAP users and groups are no longer seen  by Information Server for the same users and groups. Likewise,  any Business Glossary asset permissions or Steward assignments  no longer work. In addition, errors occur in the Information  Server Web Console when opening Users or Groups. Additional  problems occur if a user or group previously assigned a role no  longer exists in the configured LDAP registry.

Local fix

  • Some of the issues are caused by a known WAS issue and require a  WAS iFix (PM89827) to be installed. This iFix also requires a  configuration change to WAS to enable it.  However, this only  addresses the issues caused when a user or group no longer  exists in the external LDAP registry and only fixes the issue  when attributes are not mapped. So installation of this iFix  alone does little to address the complete list of problems and  thus should wait to be installed along with the complete  solution to this APAR.

Problem summary

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.

Popular posts from this blog

Shrink you container size up to 95%.

-
BLAFS is a bloat-aware filesystem for container debloating. The design principles of BLAFS are effective, efficient, and easy to use. It detects the files used by the container, and then debloats the container by removing the unused files. The debloated containers are still functional and can run the same workload as the original containers, but with a much smaller size and faster deployment. https://github.com/negativa-ai/BLAFS?tab=readme-ov-file
Read more

alma linux: dnf Module yaml error: Unexpected key in data

-
While applying recent updates to a server running Rocky Linux 8, an error presented itself. Module yaml error: Unexpected key in data: static_context [line 9 col 3] Module yaml error: Unexpected key in data: static_context [line 9 col 3] The solution turned out to be a simple one. Update the libmodulemd first to correct the problem then perform the dnf updates as usual. dnf update libmodulemd For a detailed explanation as to the cause of this problem.
Read more