Occasionally you will have to install appliances and applications, which will not utilize Kerberos, SASL or NTLM to communicate with Active Directory Domain Services. They will rather use simple BIND, which exposes the users’ credentials in clear text. So anyone with malicious intent, can use network monitoring or packet sniffing tools to capture packets of the communication between the Domain Controller and the client, to view the username and password information in clear text.
Obviously any such appliance or application will not be a member of the Active Directory Domain, in that case it would primarily use Kerberos to authenticate with Active Directory DS. An example of such an appliance is Citrix Netscaler. In other words its mostly non-Microsoft clients which might use LDAP simple bind to communicate with AD Domain Controllers.
To make the connection between such a client and the Domain Controllers secure/encrypted, you will have to enable LDAP over SSL (LDAPS) on one or more Domain Controllers.
There are three methods of enabling LDAPS on a Domain Controller.
- Install an Enterprise Root CA on a Domain Controller. This will automatically enable LDAPS on all DCs in the forest. This is, for obvious reasons, not a recommended practice by Microsoft.
- Install an internal Public Key Infrastructure. But to create a PKI, just for the purpose of enabling LDAPS, is quite an overkill.
- Install a SSL/TLS certificate from a public CA on a Domain Controller.
In this blog post we’ll look at method number 3.
1. Purchasing the SSL certificate
You can purcahce the certificate from any public CA of your choice. Such as Thawte, DigiCert or Comodo.
1.1 Decide on whether you want to enable LDAPS only on a single DC or multiple DCs.
If you want to enable LDAPS only on a single DC, which is the most cost effective solution, you can buy a regular SSL certificate. Most probably you don’t have many clients who use simple BIND to authenticate with DCs, so I would also say its the most viable option.
If you want to enable LDAPS on multiple DCs, you will have to purchase a wildcard certificate, which is a certificate you can install on more than one computer.
1.2 Once you have decided on which type of certificate you want to purchase, you will have to provide information about the server platform you are going to utilize the certificate on. For Windows Server 2008/2008 R2 DCs, that would be Microsoft IIS 7. For Windows Server 20012/2012 R2 DCs, you must choose Microsoft IIS 8.
1.3 Next you will have to either upload the Certificate Signing Request (CSR) file, or copy and paste the content of that file. Which brings us to our next step, what is a CSR file, and how do you create it.
2. Creating the Certificate Signing Request (CSR)
The CSR is an encoded file that enables you to send the public key of your DC, to the public CA. It also includes information that identifies your company and what you are going to utilize the certificate for. You can use any utility or application that creates a valid PKCS #10 request to generate the CSR file. Such as the Certreq.exe command line utility.
Certreq.exe requires an INF file, which includes the following information, to generate an appropriate X.509 certificate request for a Domain Controller.
- The Enhanced Key Usage extension includes the Server Authentication (18.104.22.168.22.214.171.124.1) object identifier (also known as OID).
- The Active Directory fully qualified domain name of the domain controller (for example, DC01.DOMAIN.COM) must appear in one of the following places:
- The Common Name (CN) in the Subject field.
- DNS entry in the Subject Alternative Name extension.
- You must use the Schannel cryptographic service provider (CSP) to generate the key.
Below is the content of an example .inf file,
;----------------- request.inf ----------------- [Version] Signature="$Windows NT$" [NewRequest] Subject = "C=NO, S=Oslo, L=Oslo, O=ShabazTech, CN=DC01.shabaztech.com" KeySpec = 1 KeyLength = 2048 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=126.96.36.199.188.8.131.52.1 ; this is for Server Authentication ;-----------------------------------------------
You can find more information on the different sections and values used in the .inf file above, in this Technet article
2.1 Copy and paste the content of the example .inf file in an empty text document. Then alter the values in the Subject = line, so it corresponds with your environment. You do not need to alter any other sections or values.
2.2 Save that text document as Request.inf
2.3 Run the following command at an administrative command prompt
certreq -new request.inf request.req
2.4 This will create a file called request.req , which includes information you provided in the request.inf, but the information is now in base64-encoded format.
2.5 You can now submit the CSR file when purchasing the SSL certificate
3. Accepting and installing the issued certificate
The public CA will send you the certificate in either base64-encoded text in an e-mail message, or they will send you the certificate with .crt or .cer extension. If you receive the certificate in text format, you can copy and paste that text in an empty text file, and save the file with .cer or .crt extension. They might even send you the certificate in PKCS#7 format, in which case you will not be able to use that certificate to enable LDAPS. If you receive the certificate in PKCS#7 format, you can ask them to send you the certificate in X.509 format.
Or you can change the file extension of the PKCS#7 certificate file from .cer to .p7b
Then you will be able to open the file and view the different certificates the single PKCS#7 certificate file contains. You can also export these certificates one by one, to have them available in X.509 format. You will know that the certificate is in PKCS#7 format, if you get the following error when you try to open the certificate file.
In any case, next step is to install the root and intermediate certificates in the certificate chain which the X.509 certificate you purchased belongs. Unless these certificates are already present in the certificate store of your Domain Controller.
3.1 Install root and intermediate certificates
The certificate I purchased belongs to Comodo. Keep in mind, root and Intermediate certificates are freely available and can be downloaded at any time. For Comodo you can download them here.
These 4 certificates belongs to the chain of the certificate I purchased. Obviously the top most certificate in the picture is the one I purchased.
I had to install the root and intermediate certificates as such
3.1.1 Start mmc.exe , then click File -> Add/Remove Snap-in
3.1.2 Choose Certificates, then click Add
3.1.3 Choose Computer account, click Next -> Finish -> OK
3.1.4 Certificates console will be added for the Local Computer
3.1.5 Browse to Trusted Root Certification Authorities -> Certificates. Right-click -> All Tasks -> Import
3.1.6 Click Next on the first page of the Wizard
3.1.7 Click Browse
3.1.8 Browse to the folder where you have saved the certificates, select the root certificate, then click Open
3.1.9 Click Next
3.1.10 Verify the certificate store, click Next again, and finally click Finish. The root certificate will be imported.
3.1.11 Browse to Intermediate Certification Authorities -> Certificates. Right-click -> All Tasks -> Import
3.1.12 Import any Intermediate Certificates in the certificate chain, by following steps 3.1.6 to 3.1.10
You can check the Certificate request you created in step 2.3, by checking the Certificate Enrollment Requests Folder
If you double-click it, you can see that there is a private key that corresponds to this certificate
3.2 Accept and install the issued certificate
3.2.1 Save the certificate you received in the same folder as the request you created in step 2.4
3.2.2 Run the following command at an administrative command prompt
certreq -accept NameOfCertificate.cer
3.2.3 Verify that the certificate is installed in the computer’s Personal store.
3.2.4 Double-click the certificate, to view the information associated with it
3.2.5 Restart the Domain Controller
3.3 Optional: Install the certificate in the NTDS Service’s Personal certificate store
This step is completely optional. AD DS preferentially looks for certificates in this store over the Local Machine’s store. This makes it easier to configure AD DS to use the certificate that you want it to use. This is because there might be multiple certificates in the Local Machines Personal store, and it can be difficult to predict which one is selected.
3.3.1 You will have to start by exporting the certificate you installed in the Local Machines Personal store.
3.3.2 Right-click the certificate → All Tasks → Export
3.3.3 Click Next on the first page of the wizard
3.3.4 Choose to export the private key
3.3.5 Make these choices, then click Next
3.3.6 Type and confirm a password
3.3.7 Specify the name of the file, then click Next
3.3.8 Click Finish
3.3.9 You will be told that the export was successful
3.3.10 Now add the certificates snap-in again, but this time select Service Account
3.3.11 Select Local Computer, and click Next
3.3.12 Select Active Directory Domain Services, then click Finish
3.3.13 In the MMC Console, in the console tree, expand Certificates – Service (Active Directory Domain Services), right-click on NTDS/Personal, and select Import.
3.3.14 Click Next on the Welcome page
3.3.15 Browse to the file you saved in step 3.3.7
3.3.16 Type the password you set earlier, make the choices in the screenshot below, then click Next
3.3.17 Verify the certificate store, click Next
3.3.18 Click Finish, and the certificate will be imported
4. Verifying an LDAPS connection
4.1 Start Ldp.exe
4.2 Click Connection → Connect
4.3 Type the name of the server, type 636 as Port, and select SSL. Finally, click OK.
4.4 RootDSE information should print in the right pane, indicating a successful connection.
As a final note, LDAP uses port 389, while LDAPS uses port 636.
I like and appreciate the how to portion of this posting as MS does not spell this out in TechNet that I found.
However I would have to disagree with saying that doing an internal CA is overkill. For example if you already have win server licensing and a virtualized server environment I think it makes perfect sense to use an internal CA. If however you have a physical server environment then maybe we agree 🙂
Great post… just one question in regards to the clients/current members of these domain controllers, will there be any impact when it comes to login into the domain or authentication for File Server / Exchange etc etc servers ?
If have what I hope is not a unique situation and there is an easy answer. Because we had to do a rename of our college and educause will only allow 1 registered domain name per institution, we are domain1.edu internally but externally we are domain2.edu. I need a 3rd party Cert for sldap. I got one from incommon for dc1.domain2.edu. When a vendor tries to establish a sldap connection, it cannot because it doesn’t see a cert.
Do you know of a way that I can accomplish what I’m trying to do?
Very good! I had many questions and you helped.
But I am in doubt: I already have an Internal CA installs and my DCs servers longer respond on port 636.
I have an application that is in the cloud, outside my local network.
Basically I have I can use that same export the certificate generated by the Internal CA from my local network from my DC and import the application server that is in the cloud?
Or necessarily need to use a third-party certificate?
I have an internal application that will make integration with active directory which is outside the company.
I will have to establish a LDAP over SSL connection, but I am in doubt about what kind of certificate should I use.
As both servers are in locations and different networks (the Internet communication), I’ll have to buy a third-party public certificate to establish that CONNECTION?