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.

Back to top

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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!

Back to top

Acknowledgements

Thanks to Keys Botzum for his suggestions which led to devoting this column to this topic.

Resources

• The WebSphere Contrarian
  • Changing host names and migrating profiles in WebSphere Application Server
  • Less might be more when tuning WebSphere Application Server
  
  
• 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
  
  

About the author

Tom Alcott is consulting IT specialist for IBM in the United States. He has been a member of the Worldwide WebSphere Technical Sales Support team since its inception in 1998. In this role, he spends most of his time trying to stay one page ahead of customers in the manual. Before he started working with WebSphere, he was a systems engineer for IBM's Transarc Lab supporting TXSeries. His background includes over 20 years of application design and development on both mainframe-based and distributed systems. He has written and presented extensively on a number of WebSphere run time issues.

Rate this article

Comments

Back to top

Table of contents

• Changing how you feel about change
• LDAP password changes
• Acknowledgements
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers