In each column, The WebSphere® Contrarian answers questions, provides guidance, and otherwise discusses fundamental topics related to the use of WebSphere products, often dispensing field-proven advice that contradicts prevailing wisdom.
Changing how you feel about change
We often think of "change" as being "difficult,' and with a quick search of the Internet using your favorite search engine, you can find a number of articles titled Why Change is Hard or Reasons Change is Difficult, plus even a song or two on this theme.
That said, while I too can find change daunting I wouldn’t always characterize change as being difficult -- which probably isn’t totally unexpected given my contrarian nature. In past installments of this column, in fact, I have discussed change in WebSphere Application Server and the precautions to take when making changes in WebSphere Application Server. I would like to take this opportunity, then, to return to the subject of change in the context of WebSphere Application Server administration, specifically a common security change task: changing LDAP passwords without downtime.
LDAP password changes
The solution for making changes to passwords entails a pattern, one that isn’t specific to WebSphere Application Server or LDAP, but one that relies on the use of two user IDs and passwords and has been used since antiquity -- well, computer antiquity at least -- to change passwords that are in use between one server and another. And because this pattern isn’t specific to WebSphere Application Server or LDAP, it can be used for other resources as well, like databases.
The pattern is this:
- Create two user IDs on LDAP and give them the same permissions. To keep this simple, let’s call the two user IDs userA and userB.
- When you first configure WebSphere Application Server to use LDAP, use userA and the password for userA as the LDAP bind distinguished name and bind password.
- When it’s time to change passwords -- say, in 60 days because that’s how often your corporate security policy requires passwords to be changed -- log in to LDAP and change the password for userB, at which point userB now has a new password.
- After saving the new password for userB in LDAP, go into WebSphere Application Server and update it to use userB and the password for userB as the LDAP bind distinguished name and bind password.
- Save the configuration.
At this point, any servers already running are using userA and will continue to work, and any servers that are either started or restarted will use userB; both user IDs will work.
If you don’t want to restart all your servers, you can choose to dynamically update the LDAP binding information, thus avoiding the need to incur a service interruption outage when updating the LDAP password.
Remember that dynamically updating the LDAP binding information in WebSphere Application Server does NOT eliminate the need for two IDs or the need to update the WebSphere Application Server configuration; it just avoids the need to restart the WebSphere Application Server processes (deployment manager, node agent, application server). If you only employ one user ID, then the instant you change a password in LDAP, any WebSphere Application Server still using the old password will potentially be unable to contact LDAP, which will result in an authentication failure. You must use two user IDs to employ this pattern.
By following these simple steps, you can change passwords used by WebSphere Application Server to access external resources, like LDAP, without a complete service outage.
Change is easy!
Thanks to Keys Botzum for his suggestions which led to devoting this column to this topic.
- The WebSphere Contrarian
- Information Center: Updating LDAP binding information
- Book: IBM WebSphere: Deployment and Advanced Configuration by Roland Barcia, Bill Hines, Tom Alcott and Keys Botzum, IBM Press, 2004
- IBM developerWorks WebSphere