Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers.

README.md

Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers

Tip

Microsoft active directory servers by default provide LDAP connections over unencrypted connections (boo!).

The steps below will create a new self signed certificate appropriate for use with and thus enabling LDAPS for an AD server. Of course the "self-signed" portion of this guide can be swapped out with a real vendor purchased certificate if required.

Steps have been tested successfully with Windows Server 2012R2, but should work with Windows Server 2008 without modification. Requires a working OpenSSL install (ideally Linux/OSX) and (obviously) a Windows Active Directory server.

• Create root certificate
• Import root certificate into trusted store of domain controller
• Create client certificate
• Accept and import certificate
• Reload active directory SSL certificate
• Test LDAPS using ldp.exe utility
• Reference

Create root certificate

Using OpenSSL, create new private key and root certificate. Answer country/state/org questions as suitable:

$ openssl genrsa -aes256 -out ca.key 4096
$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Hold onto the resulting ca.key and ca.crt.

Import root certificate into trusted store of domain controller

• From the active directory server, open Manage computer certificates.
• Add the generated ca.crt to the certificate path Trusted Root Certification Authorities\Certificates.
• Done.

Create client certificate

We will now create a client certificate to be used for LDAPS, signed against our generated root certificate.

From the active directory server:

• Create a new request.inf definition with the following contents - replacing ACTIVE_DIRECTORY_FQDN with the qualified domain name of your active directory server:

   [Version]
   Signature="$Windows NT$"
  
   [NewRequest]
   Subject = "CN=ACTIVE_DIRECTORY_FQDN"
   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 = 1.3.6.1.5.5.7.3.1 ; Server Authentication
  

• Run the following to create a client certificate request of client.csr (note: it's critical this is run from the active directory server itself to ensure correct private key -> certificate association):

   C:\> certreq -new request.inf client.csr

Back to our OpenSSL system:

• Create v3ext.txt containing the following:

   keyUsage=digitalSignature,keyEncipherment
   extendedKeyUsage=serverAuth
   subjectKeyIdentifier=hash
  

• Create a certificate client.crt from certificate request client.csr and root certificate (with private key):

   $ openssl x509 \
     -req -days 3650 \
     -in client.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt \
     -set_serial 01 -out client.crt

• Verify generated certificate:

   $ openssl x509 -in client.crt -text

• Ensure the following X509v3 extensions are all present:

  • X509v3 Key Usage: Digital Signature, Key Encipherment
  • X509v3 Extended Key Usage: TLS Web Server Authentication
  • X509v3 Subject Key Identifier

Accept and import certificate

• From the active directory server with client.crt present, run the following:

   C:\> certreq -accept client.crt

• Open Manage computer certificates, the new certificate should now be present under Personal\Certificates. Ensure that:

  • Certificate has a private key association.
  • The "Intended Purposes" is defined as "Server Authentication".
  • Certificate name is the FQDN of the active directory server.

Reload active directory SSL certificate

Alternatively you can just reboot the server, but this method will instruct the active directory server to simply reload a suitable SSL certificate and if found, enable LDAPS:

• Create ldap-renewservercert.txt containing the following:

   dn:
   changetype: modify
   add: renewServerCertificate
   renewServerCertificate: 1
   -
  

• Run the following command:

   C:\> ldifde -i -f ldap-renewservercert.txt

Test LDAPS using ldp.exe utility

• From another domain controller, firstly install our generated root certificate ca.crt to the certificate path Trusted Root Certification Authorities\Certificates.

• Open utility:

   C:\> ldp.exe

• From Connection, select Connect.

• Enter name of target domain controller.

• Enter 636 as port number (this is the LDAPS port).

• Click OK to confirm the connection works.

• You're all done!

Reference

• Enable LDAP over SSL with a third-party certification authority: https://support.microsoft.com/en-us/kb/321051
• LDAP renewServerCertificate: https://msdn.microsoft.com/en-us/library/cc223311.aspx
• How to Enable LDAPS in Active Directory (similar outcome to above): https://www.javaxt.com/tutorials/windows/how_to_enable_ldaps_in_active_directory
• DigiCert LDAPS certificate install guide: https://www.digicert.com/ssl-certificate-installation-microsoft-active-directory-ldap-2012.htm

Worked like a charm. Thanks @dabenavidesd for advise

Create a new request.inf definition with the following contents - replacing ACTIVE_DIRECTORY_FQDN with the qualified domain name of your active directory server

Could you please clarify this sentence? I just made the same mistake that @dabenavidesd made, by using the Active Directory's FQDN, not the FQDN of the server that I was installing the certificate.

Connecting to "master.domain.bigcorporation.com"
Logging in as current user using SSPI
Importing directory from file "ldap-renewservercert.txt"
Loading entries.
Add error on entry starting on line 1: Inappropriate Authentication
The server side error is: 0x8009030e No credentials are available in the security package
The extended server error is:
8009030E: SecErr: DSID-0C02041A, problem 4001 (INAPPROPRIATE_AUTH), data 0

Creating a new certificate with the correct name (master.domain.bigcorporation.com, not domain.bigcorporation.com) resolved this issue.

I'm having the same problem, the file is UTF-8, all it contains is the following.

dn:
changetype: modify
add: renewServerCertificate
renewServerCertificate: 1

Loading entries.
Add error on line 1: Inappropriate Authentication
0 entries modified successfully.
An error has occurred in the program
No log files were written. In order to generate a log file, please
specify the log file path via the -j option.

Trying this on Windows Server 2003, any ideas?

Fixed it, I forgot to do the following.

Accept the issued certificate. To do this, type the following command at the command prompt, and then press ENTER:
certreq -accept certnew.cer

Great guide! In windows, there may have error message with command:
$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
unable to load config info from /usr/local/ssl/openssl.cnf

We can solve the error by specified parameter -config C:\xxxx\openssl.cnf like bellow:
$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -config C:\xxx\openssl.cnf

Just wanted to thank you for this, saved a lot of searching around all over the place and not having to reboot the DC is a plus 👍

FYI, openssl isn't installed in Window Server by default. Nothing about that is included here. Might want to mention steps on installing it. As of right now, it gives a DLL error when installing from binaries provided from the OpenSSL page which requires additional steps to install this DLL, as well.

Hey @methodbox in the opening paragraph.

Steps have been tested successfully with Windows Server 2012R2, but should work with Windows Server 2008 without modification. Will require both a system with OpenSSL (ideally Linux/OSX) and (obviously) a Windows Active Directory server.

Kudos!

You the real MVP

Awesome! Works like a charm! The easiest documentation to enable LDAP over SSL (LDAPS) for an Active Directory.

@magnetikonline
You may want to update the following command...

openssl genrsa -des3 -out ca.key 4096

...to a newer and stronger one:

openssl genrsa -aes256 -out ca.key 4096

des3 (Triple DES or 3DES) is proven as inadequate.

Thanks @Sebi94nbg - haven't touched Microsoft AD in years, but the gist seems to be popular!

Have updated the private key encryption cypher used to aes256.

Thanks @magnetikonline !

Can anyone answer this question?

Every domain does usually have multiple domain controllers (Active Directory servers; two or more).

In this case: Do we need to create a private key and certificate pair for each single domain controller or can we use the same certificate for all domain controllers?

I found this article: https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

There, I could find this:

Each LDAP server will require its own certificate in order to use this option, but it is only necessary to use this option on a server that has multiple certificates with the purpose of Server Authentication in the local certificates store. The best solution is to have only one certificate in the computer's personal certificate.

So... This means, that we need to create a private key + certificate for each single domain controller, right?

You need to create a private key and csr on each domain controller with a subject alternative name field on each csr with the dns name of the load balancer and get it signed by a trusted CA, then install the signed cert and reboot on each domain controller. Then you need to generate a private key / csr for your load balancer and make sure the subject alternative name field contains the dns name for each domain controller. Then install the signed load balancer cert on the load balancer. Like the following for each cert - subject alternative name mapping DC1 - LB DC2 - LB DC3 - LB LB - DC1, DC2, DC3 Hope this helps

…

On Thu, Oct 24, 2019, 2:27 AM TS3tools ***@***.***> wrote: Thanks @magnetikonline <https://github.com/magnetikonline> ! Can anyone answer this question? Every domain does usually have multiple domain controllers (Active Directory servers; two or more). In this case: Do we need to create a private key and certificate pair for each single domain controller or can we use the same certificate for all domain controllers? I found this article: https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx There, I could find this: Each LDAP server will require its own certificate in order to use this option, but it is only necessary to use this option on a server that has multiple certificates with the purpose of Server Authentication in the local certificates store. The best solution is to have only one certificate in the computer's personal certificate. So... This means, that we need to create a private key + certificate for each single domain controller, right? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://gist.github.com/0ccdabfec58eb1929c997d22e7341e45?email_source=notifications&email_token=AGBSNWU4DOZ6ICHKEHQF5YDQQFTA3A5CNFSM4HRGYJK2YY3PNVWWK3TUL52HS4DFVNDWS43UINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAF3BKO#gistcomment-3064487>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBSNWQOFSRTO2LBTPXJTJLQQFTA3ANCNFSM4HRGYJKQ> .

Thanks very much for this guide! +100

Thanks for the guide!

@magnetikonline

There is one line I would add to the [NewRequest] section of the INF file to ensure a stronger HashAlgorithm is being used as SHA1 hashes are technically "broken" since 2017, and I believe MS certreq defaults to a SHA1 hash (info and other supported algorithms are at https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1):

HashAlgorithm = SHA256

Thank you! I had a problem using TLS 1.2 that does not accept our old self signed sha1 certificate, thus the ldap with tls was rejected. Now it works (following @jmeddy comment).

Complementing this guide, if you need to add subject alternative names to the certificate

1. Add to the request.inf the following section

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=*.example.com&"
_continue_ = "dns=example.com&"
_contiinue_=""ipaddress=10.0.1.1&"

2. Add to the v3ext.txt the following section

subjectAltName = @alt_names
#Modify for your details. Must include the commonName in the list below also. 
#The *.example.com will allow all Domain controllers with 
#the hostname somthing.example.com to use the cert.
[alt_names]
DNS.1 = *.example.com
DNS.2 = example.com
IP.1 = 10.0.1.1

3. You should be able to see the extensions with the openssl x509 -in client.crt -text command as:

X509v3 Subject Alternative Name: 
     DNS:*.example.com, DNS:example.com, IP Address:10.0.1.1

This is great, work very good and no problems. Thank you...

Complementing this guide, if you need to add subject alternative names to the certificate

1. Add to the request.inf the following section

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=*.example.com&"
_continue_ = "dns=example.com&"
_contiinue_=""ipaddress=10.0.1.1&"

2. Add to the v3ext.txt the following section

subjectAltName = @alt_names
#Modify for your details. Must include the commonName in the list below also. 
#The *.example.com will allow all Domain controllers with 
#the hostname somthing.example.com to use the cert.
[alt_names]
DNS.1 = *.example.com
DNS.2 = example.com
IP.1 = 10.0.1.1

3. You should be able to see the extensions with the openssl x509 -in client.crt -text command as:

X509v3 Subject Alternative Name: 
     DNS:*.example.com, DNS:example.com, IP Address:10.0.1.1

This is a life-saver! Thank you very much.

Without this alternative name that specifies the IP address, the setup won't work.

Thank you so much!

ldifde -i -f ldap-renewservercert.txt
...

Add error on entry starting on line 1: Inappropriate Authentication
The server side error is: 0x8009030e No credentials are available in the security package

I've got this same error, for the same reason as those above (domain name instead of fqdn of domain controller). I re-did my request with the FQDN of the domain controller, and it shows correctly as DCNAME.DOMAINNAME.COM - but the error remains.

Nice! but - Microsoft servers and other software will accept the 'root' certificate above, but some software (like pfsense! ) will not accept it as a CA without the CA flag in the cert. To actually create a CA root certificate, you need something like this in a conf file when creating the ca.crt above. Note the 'basicConstraints=critical,CA:TRUE'

[ my_extensions ]
keyUsage=critical, digitalSignature, keyEncipherment, keyCertSign
basicConstraints=critical,CA:TRUE
extendedKeyUsage=critical,serverAuth
subjectKeyIdentifier = hash

Hello: it turns out; as I made a first attempt (wrongly, becasue I used just domain name instead of FQDN), and that certificate wrongly issued was on Service Account Store, so I deleted and export it from Computer Account Store the correct one, and got it to work:

C:\Users\AAA\Downloads\certif5>ldifde -i -f ldap-renewservercert.txt Connecting to "XXX.yyy.zzz" Logging in as current user using SSPI Importing directory from file "ldap-renewservercert.txt" Loading entries.. 1 entry modified successfully.

Followed this instructions to export and import in Service Account from: https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx#Exporting_the_LDAPS_Certificate_and_Importing_for_use_with_AD_DS

The command has completed successfully

Thanks very much for your very short and clear tutorial

This saved my day. Thank you!

I went through the process but i'm getting an error on

ldap-renewservercert.txt

Add error on entry starting on line 1: No Such Attribute
The server side error is: 0x57 The parameter is incorrect.
The extended server error is: 000000557: LdapErr: DSID-0C09105D, comment: Error in attribute conversion operation, data 0, v4563

Server 2019

Worked like a charm on Windows Server 2022 hosted on an EC2 Instance in AWS!

Thx for sharing 👍