PQ43439: CHANGING LDAP SERVER HOSTNAME DOESN'T PROPAGATE CHANGES TO SECURITY PERMISSIONS


APAR

APAR status
Closed as suggestion for future release.

Error description
Refer to PMR 45944,7TD,000.
Environment:
   WebSphere Application Server 3.5
Description:Environment:WebSphere Application Server 3.5
In any version of WAS 3.5 on any platform, when WAS security is enabled with an LDAP server and security permissions have been assigned to method groups, changing the LDAP server hostname doesn't propagate the LDAP hostname change to the security permissions. This is proven by doing an XMLConfig export after changing the LDAP server hostname. The security permissions can clearly be seen with the hostname of the old LDAP server even though the LDAP server hostname has been changed in the global security settings.
Description:In any version of WAS 3.5 on any platform, when WAS securityis enabled with an LDAP server and security permissions havebeen assigned to method groups, changing the LDAP serverhostname doesn't propagate the LDAP hostname change to thesecurity permissions. This is proven by doing an XMLConfigexport after changing the LDAP server hostname. The securitypermissions can clearly be seen with the hostname of the oldLDAP server even though the LDAP server hostname has beenchanged in the global security settings.
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
This APAR is being closed as a suggestion, since Websphere
doesn't currently support LDAP fail-over.  A feature has been
opened in CMVC to address this, the number is 89280.  This
requirement has already been discussed, as other customers have
expressed interest in this function.
.
Here are some work arounds that the customer can try -- some of
these suggestions are as-is, no implied support, guarantee, or
warrany of any kind -- use at their own risk.
.
1. Assuming they have a mirror or replica of the LDAP directory
   on another machine AND it contains exactly the same contents
   (at least from a user/group registry point of view), then
   why can't they change the hostname of the backup LDAP server
   to that of the primary LDAP server that failed?  This change
   is external to Websphere -- as long as the backup LDAP
   server's hostname and port are the same, Websphere won't
   know or care that it is a different server.
.
2. They could use XMLConfig to export the application security
   permissions, change the access-IDs to contain the new LDAP
   hostname/port, import the new defintions in.  The downside
   is that the "old" access-IDS would still be in the
   repository because the XML tags for the application security
   permissions only support add & remove -- no update/replace.
   They can effectively do the same as a replace by first
   removing the old and adding the new.  Unfortunately, I have
   minimal experience with XMLConfig can't provide much in the
   way of concrete steps to follow.
.
3. Use JDBC, or the rdbms command line to swizzle the LDAP
   server name to the new name directly in the repository.
   This could be captured in a script or jdbc program to help
   automate.  They should back up their WAS repository database
   before trying this.  The table that contains the permissions
   is the REL_INSTANCE_TABLE.
.
   For instance, I am using DB2, after connecting to the WAS
   database from the db2 command line, I can issue the
   following command to see all the permissions:
.
 select * from EJSADMIN.REL_INSTANCE_TABLE
.
   The access-ID will look something like the following (this
   is from the LINK_NAME column).
.
  user:cmason1.austin.ibm.com:389/uid=bob,ou=People, o=
  austin.ibm.com
.
   Notice that the LDAP server hostname & port form a portion
   of the access-ID.  I can use a SQL expression to change the
   LDAP portion like so:following command to see all the permissions:.select * from EJSADMIN.REL_INSTANCE_TABLE.The access-ID will look something like the following (thisis from the LINK_NAME column)..user:cmason1.austin.ibm.com:389/uid=bob,ou=People, o=austin.ibm.com., Notice that the LDAP server hostname & port form a portionof the access-ID.  I can use a SQL expression to change the
. update ejsadmin.REL_INSTANCE_TABLE set LINK_NAME = replace(LINK_NAME,'cmason1.austin.ibm.com:389','areddy. austin.ibm.com:389') . This will change my LDAP server to areddy.austin.ibm.com:389 This bit of SQL acts like a string search and replace. This is what the same entry would look like after the SQL was run . user:areddy.austin.ibm.com:389/uid=bob,ou=People, o= austin.ibm.com . Note they would still have to change the LDAP hostname in the User Registry panel in the WAS admin console, and they would have to stop & restart all WAS server processes.
LDAP portion like so:.update ejsadmin.REL_INSTANCE_TABLE set LINK_NAME =replace(LINK_NAME,'cmason1.austin.ibm.com:389','areddy.austin.ibm.com:389').This will change my LDAP server to areddy.austin.ibm.com:389This bit of SQL acts like a string search and replace. Thisis what the same entry would look like after the SQL was run.user:areddy.austin.ibm.com:389/uid=bob,ou=People, o=austin.ibm.com.Note they would still have to change the LDAP hostname inthe User Registry panel in the WAS admin console, and they, would have to stop & restart all WAS server processes.
APAR information
APAR numberPQ43439
Reported component nameWAS ADVANCED SU
Reported component ID5648C8402
Reported release350
StatusCLOSED SUG
PENoPE
HIPERNoHIPER
Submitted date2000-11-14
Closed date2000-11-21
Last modified date2000-11-21

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:APAR is sysrouted FROM one or more of the following:


Modules/Macros

Fix information
APAR is sysrouted TO one or more of the following:Modules/Macros

Applicable component levels











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, General
Software version: 350
Reference #: PQ43439
IBM Group: Software Group
Modified date: 2000-11-21