Configure Active Directory with SSL

From Zarafa wiki

(Difference between revisions)
Jump to: navigation, search
Line 2: Line 2:
The Zarafa Server connects with ADS by standard LDAP access over port 389 or 636 (SSL).
The Zarafa Server connects with ADS by standard LDAP access over port 389 or 636 (SSL).
This document has only been tested once on Windows 2003.

Revision as of 15:01, 8 September 2010

When integrating ZCP with a Microsoft's Active Directory Service (ADS) it is possible to administer users, groups and companies directly from ADS. This combines the scalability and low-cost advantages of ZCP on Linux, with the comfort of a well known front-end for administration to those already acquainted with ADS.

The Zarafa Server connects with ADS by standard LDAP access over port 389 or 636 (SSL).

This document has only been tested once on Windows 2003.

Setting up Active Directory for SSL access

Make sure that the Certificate Authority is installed on the DC running your Active Directory. If it is not installed, you can install it as follows:

  1. Click Start -> Control Panel -> Add or Remove Programs
  2. Click Add/Remove Windows Components and select Certificate Services
  3. Follow the procedure provided to install the Certificate Services CA.

After installation, you must reboot your Active Directory server to make sure the Active Directory server is accepting TLS/SSL connections.

Now, you must configure your Linux server to connect to the SSL port of the Active Directory. This must be done in the system-wide configuration file /etc/ldap/ldap.conf with the configuration option TLS_CACERT. This must be configured to point to a CA (Certificate Authority) that can authorize the server certificate on the AD Server. This can be done either by using the AD server itself as a Certificate Authority (CA) or by using an online CA server. The latter is not recommended due to the time it takes to request the certificate on the internet. If you want to use an online CA, you will need a line like

  TLS_CACERTDIR /etc/ssl/certs

This assumes your CA certificates are installed in /etc/ssl/certs. Please refer to your Linux distribution's documentation on where to find the CA certificates or how to install them. (Tip: on debian, you must install the 'ca-certificates' package, while SuSE and RedHat install the certificates together with the 'openssl' package, sometimes in /usr/share/ssl/certs).

Retrieving the CA certificate from ADS

You can also retrieve the CA certificate from your local AD server so that all communication is local during LDAP accesses. To retrieve the certificate from the MS Windows Server:

  1. Click Start -> Control Panel -> Administrative Tools -> Certificate Authority to open the CA Microsoft Management Console (MMC) GUI.
  2. Highlight the CA machine and right-click to select Properties for the CA.
  3. From General menu, click View Certificate.
  4. Select the Details view, and click the Copy to File button on the lower-right corner of the window.
  5. Use the Certificate Export Wizard to save the CA certificate in a file. (Use ASCII mode)

The certificate will be saved as a .CER file, but you can simply rename the file to a .PEM file. The filename of the .PEM file is not important. You can now copy the certificate to your Linux server, for example into /etc/ssl/certs/AD.pem To use this certificate, please specify

 TLS_CACERT /etc/ssl/certs/AD.pem

in your /etc/ldap/ldap.conf file, or use (also in /etc/ldap/ldap.conf)

 TLS_CACERTDIR /etc/ssl/certs

to accept any CA in the /etc/ssl/certs directory. If you use TLS_CACERTDIR, you must also create the hash link in /etc/ssl/certs: In debian, this is accomplished by running 'update-ca-certificates'. In other Linux distributions, you must create the link manually with

 $ ln -s /etc/ssl/certs/AD.pem `openssl x509 -noout -hash -in /etc/ssl/certs/AD.pem` 

You can check whether the SSL connection is working and see what is happening by issuing the command:

 $ openssl s_client -connect <ip>:636 -CApath /etc/ssl/certs

To test whether the SSL connection is working correctly with LDAP, try the following command:

 $ ldapsearch -x -H ldaps:// -b <BASEDN> -D <binddn> -w <password>

If ldapsearch fails, while the s_client test returns with 'Verify return code 0 (ok)', please make sure that the URL you are connecting with after the -H option contains the exact same hostname as is specified behind CN= in the output of s_client (at the very beginning of the output from s_client).

Personal tools