Configuring CUCM with Secure LDAP

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. Open the CUCM OS Administration page, go to Security > Certificate Management, and click the “Upload Certificate” button.
8. 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.
9. 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.
10. If more than one certificate was obtained from more than one DC/GC server, repeat the previous two steps and upload each certificate.
11. 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).
12. 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.
13. 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.
14. 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.
15. 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.