This blog is one of five dealing with the encryption of various Cisco UC devices. This particular piece deals with setting up secure connections to an LDAP server. The other blogs in this series are Configuring Calling Encryption Between Cisco IP Phones, Configuring Calling Encryption Between Cisco IP Phones and Cisco Unity Connection, Configuring Secure Hardware Conferencing, and Configuring a Secure Voice Gateway.
The operations detailed in these blogs may not be the final word on all of the ins and outs of configuring the items. However, we discovered that there are very few, or no, articles dealing with these subjects written by someone who has actually performed the tasks. We, therefore, felt it would be a service to offer information about the steps that worked for us in our specific set of circumstances (particularly since we, apparently, fell into most of the traps).
Comments are certainly welcome, and we will be happy to update these blogs if need be.
This article deals with setting an LDAP connection between an Active Directory (AD) server or cluster of servers and a Cisco Unified Communications Manager (CUCM) system.
- Make sure DNS is configured on the network and that CUCM is set to use DNS to resolve names. If this hasn’t happened, none of the rest of this stuff will work.
- Get an AD administrator to set up a username for the CUCM connection to the LDAP server. It should have Read rights to the directory. When the user is set, make sure to find out the fully distinguished name of the location where it was created; this should include the CN of the name, the OU(s) that the name falls into (if there’s more than one OU, get their correct order) and the DCs (also in the correct order). An example would be something like CN=ucdirsync,OU=Users,OU=Detroit,DC=verybigco,DC=com.
- Get the AD person to explain what OU(s) contain(s) the users that must be imported into CUCM. This is going to define the “LDAP User Search Base”. If Very Big Co. has many employees listed in many OUs, and those OUs are contained in other OUs, it’s possible to set individual search bases for many OUs (up to 5). It’s also possible to set a single search base for a single higher-level OU that will catch all of the ones below it.
Even though it’s possible to set a search base at the domain level (e.g. verybigcorp.com), it’s a good idea to avoid such a thing. Setting the search base up that high in the domain tree will catch all of the employees, but it will also catch all of the administrative and system accounts that are generated automatically by Windows; in other words, a lot of accounts that don’t correspond to actual users. If a search base is set that high, make sure that the user created in the previous step does not have Read rights on the OUs from which it should not pull user information. - Get the AD person to export a Windows certificate from a Domain Controller (preferably one that has a copy of the Global Catalog). The person needs to go into the Certificate Export Wizard and export a DER encoded binary X.509 certificate.
- When the certificate is exported, it will have a .cer extension. That’s OK. When it’s imported into CUCM, it will produce two certificates automatically, a .der and a .pem.
- If the plan is to set up more than one LDAP server, certificates will have to be obtained from all of them. It’s possible to configure up to three LDAP servers. Again, best practice is that all Active Directory servers contain a copy of the Global Catalog.
- Open the CUCM OS Administration page, go to Security > Certificate Management, and click the “Upload Certificate” button.
- In the Certificate Name field hit the drop-down and select “directory-trust” if you\’re using CUCM v7.x and below. If you\’re using v8.x and above, select \”tomcat-trust\”. The second field can remain blank. To fill in the Upload File field, browse to the location where the certificate was saved and hit the “Open” button.
- Hit the “Upload File” button. After the file has been successfully uploaded, select the “Close” button to refresh the screen. It will then be possible to select the “File” button and see the certificate that was just added.
- If more than one certificate was obtained from more than one DC/GC server, repeat the previous two steps and upload each certificate.
- Repeat the previous three steps within the administrative GUIs on each of the Subscriber servers. All certificates from all LDAP servers that will be configured in CUCM must be uploaded to the Publisher and all Subscribers. When the certificates have been uploaded you have to go to Unified Serviceability on the Publisher and restart the DirSync service. THEN on each server you have to go to the CLI and restart the Tomcat service (this is the only place it can be restarted) by typing “utils service restart Cisco Tomcat” (note the case of the letters).
- After all of the certificates have been uploaded on any of the servers, click on the link for either the .pem or .der version of the certificate(s). This will bring up a window that shows the FQDN of the server that issued the certificate. In the part that says “CN=” write down the name just as it’s listed. If the name of the server says “CN=server1” just write down “server1”. If it’s listed as “CN=server1.verybigco.com” write down “server1.verybigco.com”. Don’t bother writing down any of the “OU=”, “O=”, “L=”, “ST=” or “C=” information. Remember that if there will be more than one LDAP server configured, the “CN=” in each certificate will have to be discovered and noted.
- At this point, the CUCM servers should be ready for secure connections to AD. The next steps deal with configuring the LDAP connection within CUCM. These follow the usual, well-documented procedures for this task, including the configuration of the LDAP System, LDAP Directory, and LDAP Authentication. However, there are three “Gotchas”:
– Within the LDAP configuration pages in the CUCM Administration GUI, it’s normally possible to enter either the fully qualified name of the server or the IP address of the server. However, when configuring secure LDAP, the name that goes in the field must be the exact name that was written down in the previous step (e.g. server1, or server1.verybigco.com). The reason for this is that the name of the server must match the name in the certificate exactly. Just because it’s possible for servers to communicate using an IP address, it doesn’t mean certificates will be accepted to complete the handshake. Two servers will only trust each other if they know the other’s exact name (this is the reason why it’s critical to have DNS defined correctly everywhere).
– After the server name is entered, the port number that’s listed after it will probably have to be changed to the secure port. For this it would be wise to consult the person who issued the certificate, but the port is usually 636 for a regular DC or 3269 for a GC.
– After the field in which the port number is defined, there’s an “SSL” check box. This box must be checked. - After the rest of the LDAP configurations are entered, a synchronization should be performed as a final test of the connection. It’s good to remember, however, that this can eat up a lot of bandwidth. If possible, schedule the sync to be performed during off hours.
- Realize that the above information is sufficient in most circumstances. However, if CUPS is going to be installed in the network, and the CUPC client will be used, it is typical to expect that that the CUPC client will be controlling phones. In a situation in which CUPC will be employed, Cisco recommends that the servers mentioned in Step 13 all be Global Catalog servers. Remember, this means the port listed after the servers should be 3269.
Hi Paul
Can you please elaborate more on why the certificates need to be uploaded on all nodes? Since, its only the Pub which does Dirsync with LDAP.
Thank you
AKB,
I added the certificate to the PUB as well as the SUBs with the idea that users would still be able to log into the ccmuser pages when the PUB was down. This works, so I’m stickin’ with my story.
Hi Paul –
Thanks for taking the time to write your post. However, I’ve been unable to find any published documentation stating the specific requirements regarding needing to point to the exact host that generated the certificate uploaded within the directory configuration in CUCM. Do you have a link to the doc or the excerpt you used to come up with these instructions? I’m not challenging the validity of your information, but I have a customer that wants to see it in writing as it’s "different than what he’s had to do in the past for other vendors"… and I must be able to prove it in writing. Any additional information you can provide to assist me in having that customer conversation would be much appreciated.
Randy
Randy,
Unfortunately, I don’t have jack in terms of documentation. All of the security articles I’ve written were generated precisely because of the lack of information that’s out there. As was stated in the article, though, the instructions were for a specific set of circumstances; in this case, one in which no one had a CA that could generate a certificate that would be trusted by everyone. I have also seen this done with a certificate from a Root CA. Get your hands on one of those, pop it into the certificate store in CUCM, and you should be all set. If this is the angle that your customer is going for, you’ll be fine. If this isn’t your customer’s angle, and the person is just being difficult…well..I live on the East Coast and I’ve found that going to the beach and screaming at the ocean helps.
I tried importing the CA certs for the ldap sites we are using. Happen to be AD. I could set up a subscriber to authenticate to those sites via SSL. I could not do so on the publisher. Just trying to configure the publisher to use ldap SSL failed with a java error. Am I missing something?
I’m a little confused about how you managed to configure the subscriber but not the publisher. The configuration is only done on the publisher and those configurations cover the entire cluster. Are you saying that you managed to install the certificate on the subscriber but not the publisher? I’ll be glad to help, but I might be missing something?
I was a little surprised but there was nothing stopping me from going to a subscriber and configuring it to use SSL for authentication. It turns out that was pushed back back to the publisher as well. Doing it this way allowed authentication on the subscriber but it still didn’t work on the publisher. The thing missing for the publisher was that tomcat had to be restarted. Don’t know why that wasn’t necessary on the subscriber.
Hi Paul
the article is very very good
i used in my customer and it was excellent witout any problme
thanks for all the info
Yaniv
Do you have any experience with renewing a certificate used for LDAP communication?
I would guess you could export the updated cert from your DC(s) and import it to all of the servers in your cluster as you described above. After which, I would think you might need to delete the old expired certs from the cluster servers.
Greg
Paul- Is this still valid information and if so is it possible to use a root certificate? I’m new to the certificate game and I do have a presence environment so I’m assuming the domain controllers would all need to be Global Catalog servers.
The best I can say about using only a root certificate is that I’ve seen it work. However, at a site where it worked they discovered that they could get less expensive certs. from another CA. When it came time to change the cert. they got one from this new CA and found that secure LDAP no longer worked with the new root certificate. They had to add the intermediate cert. and a cert. from the server itself.
Awesome doc, thanks guys!!!