Converting LDAPSYNC from unencrypted to encrypted communication.

A lot of organizations are now making an effort to make sure all their information that flows on the network, weather internal or external is encrypted. This article talks about what it takes to make your LDAPSYNC CRON task secure via certificate based encryption, which is how it is typically done in the windows environment.

There are two parts to this process, one is making sure you have the necessary certificates installed in WebSphere and the second is converting your LDAPSYNC parameters.

One of the basic concepts you need to keep in mind is that the LDAPSYNC runs under a Maximo application engine in WebSphere. The application engine then runs under the direction of the Node Manager. This same node manager manages the connection between LDAPSYNC and active directory. Why do you care, because you will need to install the active directory trust certificates in the node manager’s trust key store in order to get the secure connection to work.

So the first item of business is to make sure your active directory server has a certificate installed for your LDAPSYNC process to talk too. Since the focus of this article is LDAPSYNC I will leave this process for you to work with your active directory server administrator. Note large organizations typically use commercially available certificates for their domain and smaller organizations may use what are called self-signed certificates, created locally on their domain controller.

Fortunately it’s fairly easy to acquire and install the signer part of the active directory domain certificate in WebSphere. Basically what you are going to do is pull the signer certificate from active directory into the correct node trust key store and save it.

Here is an example of the steps:

1. Signon WebSphere console
2. Expand Security > Select the SSL Certificate and key management link
3. Under Related Items, select the Key Stores and certificates link
4. Find the blue link for “NodeDefaultTrustStore” and select
5. Under additional properties, select the “Signer certificates” link.

You are now looking at a list of existing signer certificates for the node. What you want to do is add to this list by using the “Retrieve from port” button.

6. Select the “Retrieve from port button.
7. Enter a value for “Host”, this will be the active directory server name. You should be able to ping this name and get a response, or at a dos prompt try C:…> echo %logonserver% which should show you your domain server.
8. For the port enter either 636 or 3289 either should return the signer you need to install.
9. The “Alias” field can be any name you want to make up that will help you remember why you added this signer certificate.
10. Select the Retrieve signer information button. If the configuration is correct you should be returned information about the signer certificate.
11. Selecting the OK button will then add it to your list of signer certificates.
12. Don’t forget to save your configuration.

You are now done with the first phase of migrating to a secure LDAPSYNC environment. Note this part of the process can be accomplished without impacting your running Maximo environment. Assuming of course it goes according to plan.

There are a number of things that can impact the success of this previous process. If you use custom key stores or SSL configurations in WebSphere the names used in this example will be different or may not apply. If you can’t connect to the domain server then you may need to use a fully qualified name or check that you are using the correct name. It may even be a case where a firewall product on either the domain server or your WebSphere server is preventing connection. You can even have DNS or host name issues on your WebSphere server that prevent connections. If you are in a large Maximo environment you may have multiple node trust key stores, if so this process needs to be repeated for each one. Lastly the certificate you installed may have chain certificates needed to complete the validation process. See Appendix A for a discussion for how to deal with chained signer certificates for the LDAPSYNC process.

Now that the signer certificates are in place it’s relatively easy to update your LDAPSYNC CRON task. What we need to do is update the two parameters on the CRON that have port assignments and then tell it to use SSL and finally reload the CRON task, it’s that easy. An example of the parameter values is below:

LDAPSYNC CRON task parameters example for secure communications:

port = 636

SynchParameter = globalcatalogport=3269

SSLEnabled = TRUE

Once you have updated the parameters and saved them, then reload the CRON task to make it active. Monitor the next run of the CRON and confirm it’s successful via the history tab and the systemout.log.

There are a few things that can make this second phase of the process difficult. One is the global catalog port in active directory not being open. The domain administrator would need to confirm it is actually working. As it does not open up by default and may not be open in server side firewall products. Another issue is you may not be able to get to the CRON management system in Maximo. You would have to get with your Maximo security administrator and get access. The CRON may give certificate chaining errors when it tries to run. See Appendix A regarding chaining issues. You may have accidentally put the certificates in the wrong place, confirm they are in the node default trust store signer section.

Appendix A.  Dealing with chained signer certificates

If you implement the aforementioned process and your systemout.log shows a chaining error then you need to determine the missing certificate in the chain of certificates back to the root signer. The easiest way to do this is to “Extract” the previously loaded signer from active directory to a .cer file on the OS file system. This is accomplished in WebSphere at the node trust key store signer certificates window. Then remote to the console of the server and double click the .cer file created. This should bring up a dialog box about the certificate where you can select the “Certification Path” tab and see the certificate it chains to. Highlight the next higher certificate and select the View Certificate button. You are now looking at the chain certificate and if you go to the “Details” tab you can select the “Copy to File…” button and create a .cer file. Then “Add” this .cer chain certificate into your WebSphere node default trust key store, ie the same place as before. I have seen as many as two chain certificates be required to get the process to work. So just repeat for the next certificate up the chain if required.