Secure Authentication between Zimbra and AD
Secure Authentication between Zimbra and AD (self-signed certificate)
How to configure authentication with Active Directory using SSL.
Before everything else, make sure that the non-ssl (port 389) AD authentication is working, by following that article.
1. Review the following article to familiarize yourself with the authentication with AD from Zimbra side in AdminUI. The only difference from the article, is that in the "Active Directory Settings", we need to check the "Use SSL:" tick box:
2. Convert the zimbra CA to .der, and copy it to the DC:
cd /opt/zimbra/ssl/zimbra/ca openssl x509 -in ca.pem -outform der -out ad.der
- Use tools such as WinScp to copy the /opt/zimbra/ssl/zimbra/ca/ad.der file to the DC.
3. Install the Zimbra certificate authority (CA) (ad.der) on the domain controller:
- Start->Run > Type mmc > Right click on it > "Run as Administrator". This will open the Microsoft Management Console.
- Click "File" > "Add/Remove Snap-In..." to open the "Add Standalone Snap-in" dialog.
- From the Available snap-ins on the left, select "Certificates" and press "Add".
- Select "Computer account" and press "Next".
- Select "Local computer" and press "Finish"
- Click "Ok" to close the "Add/Remove Snap-in" dialog.
Once the "Certificates snap-in" is open, click on the "Certificates" node under "Trusted Root Certification Authorities". Right-click on the "Certificates" node, select "All Tasks" -> "Import...", and import the Certificate Authority (in my case "ad.der") you copied from Zimbra. Accept the default location: Trusted Root Certification Authorities
Leave the Microsoft Management Console open for step 8
4. Create a CSR. For this purpose we will use Microsoft's certreq utility. To generate csr, we need to create a *.inf file. Below is a sample *.inf file you ca use.
- Open a text editor (Notepad) and paste the following text into the file. Make sure no CR/LF character is added to the "Subject =" line when you copy and paste the text. Remove if any.
- Update the Subject attributes with appropriate values. For example: CN=ad.example.com. The FQDN must be the name of the AD server.
;----------------- csr.inf ----------------- [Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=<DC fqdn>, OU=Organizational_Unit, O=Organization, L=City, S=State, C=Country" ; Replace <DC fqdn> with the FQDN of your DC. ; Replace the remaining Subject attributes. KeySpec = 1 KeyLength = 2048 HashAlgorithm = SHA256 Exportable = TRUE MachineKeySet = TRUE SMIME = False PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=188.8.131.52.184.108.40.206.1 ; this is for Server Authentication ;-----------------------------------------------
5. Once you have a inf file, generate a Certificate Signing Request (CSR) using certreq. Open CMD and type:
certreq -new csr.inf ad.csr
6. Create and Sign the certificate. Copy the ad.csr file to the ZCS server (/tmp) and run as root:
openssl x509 -req -days 365 -in /tmp/ad.csr -CA /opt/zimbra/ssl/zimbra/ca/ca.pem -CAkey /opt/zimbra/ssl/zimbra/ca/ca.key -set_serial 01 -out ad.crt
That will create a file ad.crt. Copy the file (ad.crt) back to the AD server.
(If you are purchasing an SSL certificate, send the CSR to your third-party CA and they will generate and sign the certificate for you). Note The saved certificate must be encoded as base64. Some third-party CAs return the issued certificate to the requester as base64-encoded text in an e-mail message.
7. Accept the Certificate. After the ad.crt file has been copied to the AD server, run the following command to accept it, using the "certreq" utility:
certreq -accept ad.crt
This will accept the cert in the Windows certificate store and it will be available to those services and products that make use of the Windows certificate store. These products include but are not limited to: IIS, Exchange, Active Directory (LDAPS), Terminal Services and Microsoft Management Console (MMC).
8. Verify the certificate is installed in the computer's Personal store.
From Step 3, open the "Certificates snap-in", expand the "Certificates" node under "Personal". The certificate should exist there. Make sure In the Certificate Properties dialog box, the intended purpose displayed is Server Authentication.
If the certificate is not listed under Certificates, do the following: Right-click on the "Certificates" node, select "All Tasks" -> "Import...", and import the "ad.crt".
9. Restart the domain controller.
After installing the certificate you must restart the AD server.
1. Go back to that article, and check the SSL tick box (from step 1). Then proceed forward until you reach the window to test the authentication. The authentication should succeed.
2. The next test includes the ldp.exe utility located on the DC. Click Start > Run > type ldp.exe and open it. At top left, click on "Connection" > "Connect...".
Make sure the port is 636, the SSL check box is ticked and you type the FQDN of the AD server.
If the "Connect" is successful, the following output is produced:
Then, you can Bind to AD.
You can choose any of the authentication methods. In my case I authenticated as "aduser" user:
- Start TLS extended request
LDAPS communication occurs over port TCP 636. LDAPS communication to a global catalog server occurs over TCP 3269. When connecting to ports 636 or 3269, SSL/TLS is negotiated before any LDAP traffic is exchanged. Windows 2000 does not support the Start TLS extended-request functionality.
- Multiple SSL certificates
Schannel, the Microsoft SSL provider, selects the first valid certificate that it finds in the local computer store. If there are multiple valid certificates available in the local computer store, Schannel may not select the correct certificate.
- Pre-SP3 SSL certificate caching issue
If an existing LDAPS certificate is replaced with another certificate, either through a renewal process or because the issuing CA has changed, the server must be restarted for Schannel to use the new certificate. The SSL provider in Windows 2000 caches the LDAPS certificate and does not detect the change until the domain controller is restarted. This has been corrected in Service Pack 3 for Windows 2000.