LDAPS with self-signed certificate

Alex Mags
Page content

Azure badger “Create a picture in the style of a pixar movie of a friendly badger, working in an office IT department, using encryption to secure Microsoft Active Directory” - bing chat

This post describes how to keep user passwords transmitted in LDAP authentication requests safe. Lightweight Directory Access Protocol (LDAP) is an open standard for directories. It underpins Microsoft Active Directory Domain Services (ADDS). Applications need to check in with a central directory to authenticate user sign-ins. Other authentication protocols oAuth,SAML,Kerberos, even NTLM are prefered but still, even today, you’ll need to accomodate self-hosted business applicaitons that only support LDAP for authenticaiton. In my experience these are often JAVA developed apps or apps hosted on Linux. This post has some PowerShell generate encryption certificates (private and public keys) to enable SSL encrypted LDAPS communication with domain controllers.

Generate self-signed certificate

Usually you’d use a public certificate authority (CA) such as digicert,verisign etc to generate SSL certs. If your AD domain us using a non-routable top level domain name such as .local, .corp then public CAs are not available to you. You can’t prove you own the domain. The next option is to setup and manage an internal certificate authority such as Active Directory Certificate Services (ADCS). This includes a web service for automatic enrolement so all your machines and users automatically renew their certs before expirty. Sometimes, such as a lab, manually managed self-signed certs are good enough. This example creats a self-signed certificate. It makes use of the the subject alternative names (SAN) feature of certificates which enable one cert to work with multiple named hosts.

The disadvantages of this approach are:

  • You have manually roll certs before they expire, including distributing to LDAPS clients.
  • You have to add the cert public key into the LDAP clients. It won’t be trusted by default. For AD domain joined clients you can distribute the public key via group policy. For JAVA apps, which don’t reuse Windows certificate store, you have to hack your public key into the Java Runtime Environment keystore. JAVA certstore gets reset each time JRE is deployed/updated.

Use public CAs if you can!

Find more IT Infrastructure tips at blog.alexmags.com