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 fixProblem summaryProblem conclusionTemporary fixComments
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 number | PQ43439 | Reported component name | WAS ADVANCED SU | Reported component ID | 5648C8402 | Reported release | 350 | Status | CLOSED SUG | PE | NoPE | HIPER | NoHIPER | Submitted date | 2000-11-14 | Closed date | 2000-11-21 | Last modified date | 2000-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 APAR is sysrouted TO one or more of the following:Modules/Macros
Applicable component levels |
|