- 6 minutes to read

Securing LDAP using SSL

Secure your directory integrations by enabling SSL/LDAPS for LDAP communication. This guide shows you how to encrypt and trust connections between Nodinite LDAP products and your LDAP Catalog Service, so you achieve compliance and peace of mind.

✅ Encrypt all LDAP traffic for maximum security
✅ Follow proven certificate management best practices
✅ Achieve compliance with enterprise and regulatory requirements
✅ Use with both BizTalk LDAP Adapter and LDAP Web API

This user guide applies to both Nodinite LDAP products: BizTalk LDAP Adapter and LDAP Web API. It explains how to secure communication between the Nodinite LDAP products and your LDAP Catalog Service.

Understanding LDAPS

LDAPS (LDAP over SSL/TLS) encrypts LDAP communication using SSL/TLS certificates. When properly configured:

  • LDAP traffic uses port 636 (instead of standard LDAP port 389)
  • All communication uses encryption end-to-end
  • Certificate validation ensures you're connecting to the correct domain controller

Two certificate stores take part: the domain controller presents its server certificate from its Personal store, and the server running the LDAP product trusts it through the CA certificates in its Trusted Root (and Intermediate) store.

graph LR subgraph "Certificate Authority" roCA["fa:fa-certificate Enterprise or public CA"] end subgraph "LDAP Client Server" roClient["fa:fa-cloud-arrow-up LDAP Web API or BizTalk LDAP Adapter"] roTrust["fa:fa-shield-halved Trusted Root and Intermediate CA store"] end subgraph "Domain Controller" roDC["fa:fa-address-book Active Directory - NTDS"] roCert["fa:fa-certificate Server certificate
Personal store, FQDN, Server Authentication EKU"] end roCA -->|"issues"| roCert roCA -->|"root and intermediate certificates"| roTrust roCert --> roDC roClient -->|"LDAPS, TCP 636"| roDC roTrust -.->|"validates certificate chain"| roClient

Diagram: the CA issues the domain controller's server certificate and the client server trusts the same CA, so the LDAP product can validate the certificate when it connects on port 636.

Key Components

Component Where Role Requirement
Server certificate Domain controller, Local Computer → Personal Proves the domain controller's identity and encrypts the session Subject or SAN matches the DC's FQDN; EKU includes Server Authentication; private key present
Root and intermediate CA certificates LDAP client server, Trusted Root and Intermediate Certification Authorities Lets the client validate the server certificate's chain The full chain up to a trusted root
NTDS service Domain controller Picks up the certificate and listens for LDAPS on 636 Restart or reboot after installing the certificate
Connection settings LDAP Web API or BizTalk LDAP Adapter Tells the LDAP product to connect over LDAPS DSAServer is the FQDN, DSAServerPort is 636

LDAP vs LDAPS

LDAP LDAPS
Port 389 636
Traffic ❌ Not encrypted (unless signing/sealing is used) ✅ Encrypted with TLS
Certificate needed ❌ No ✅ Yes, on every domain controller you connect to
Server identity check ❌ No ✅ Yes, the certificate name must match DSAServer

Note

This guide focuses on Active Directory. Other LDAP services (ADAM/LDS, DirX, etc.) have similar requirements but may use different certificate stores or configuration methods.

The firewall must allow TCP 636 from the LDAP client server to each domain controller; see the firewall section in the Prerequisites for every port the LDAP products use.

Configuration Steps

Step 1: Install Certificate on Domain Controllers

On each Active Directory Domain Controller that clients will connect to:

  1. Obtain a certificate with the following requirements:

    • Subject or Subject Alternative Name (SAN): Must match the Domain Controller's Fully Qualified Domain Name (FQDN)
    • Enhanced Key Usage (EKU): Must include Server Authentication (OID 1.3.6.1.5.5.7.3.1)
    • Private key: Must be installed with the certificate; make it exportable if you install the same certificate on multiple DCs
    • Certificate Authority: Use your enterprise CA or a trusted public CA

    Warning

    Self-signed certificates work for testing but are not recommended for production. Use certificates from your enterprise Certificate Authority or a trusted public CA for production environments.

  2. Install the certificate:

    • Open certlm.msc (Local Computer Certificates) on the Domain Controller
    • Navigate to Personal → Certificates
    • Import or request the certificate (ensure the private key is imported)
    • Verify the certificate appears in the Personal\Certificates store for the computer account

  3. Restart the NTDS service or reboot the Domain Controller:

    Restart-Service NTDS -Force

  4. Verify LDAPS is enabled:

    • Use ldp.exe (included with Windows Server)
    • Connection → Connect → Server: dc.yourdomain.com, Port: 636, SSL: checked
    • You should successfully connect over LDAPS

Step 2: Install Certificate on LDAP Client Servers

On the server(s) running the BizTalk LDAP Adapter and/or LDAP Web API:

  1. Export the root certificate from your Certificate Authority or Domain Controller

  2. Install on the client server:

    • Open certlm.msc (Local Computer Certificates)
    • Navigate to Trusted Root Certification Authorities → Certificates
    • Right-click → All Tasks → Import
    • Select the root certificate file
    • Complete the import wizard

  3. For certificates with intermediate CAs:

  4. Verify certificate chain:

    • Double-click the imported certificate
    • Check the Certification Path tab
    • Ensure the chain shows "This certificate is OK"

  5. Restart services or reboot if required

Step 3: Configure the Connection for LDAPS

Both LDAP products connect with a server host name and a port. Point the connection at the domain controller's FQDN and port 636:

Product Host name setting Port setting Where
LDAP Web API DSAServer DSAServerPort Per connection in the settings file, see Configuration
BizTalk LDAP Adapter DSAServerName Port Send port Connection Info, SSO Application, or context properties, see BizTalk LDAP Adapter Configuration

The examples below show the LDAP Web API settings file.

Before (Unencrypted LDAP) 

{
  "DSAServer": "WILDWESTAD01",
  "DSAServerPort": 389
}

After (LDAPS) 

{
  "DSAServer": "wildwestad01.wildwest.local",
  "DSAServerPort": 636
}

Tip

When using LDAPS, certificate validation is automatic. Ensure the certificate's Subject Name or SAN matches the host name (DSAServer or DSAServerName) to avoid validation errors. Review the AuthenticationType flags, such as SecureSocketsLayer, in the Configuration guide.

Troubleshooting

LDAPS Connection Fails

  • Check certificate validity: Use certlm.msc to verify the certificate hasn't expired
  • Verify port 636 is open: Use Test-NetConnection -ComputerName dc.yourdomain.com -Port 636 from the client server; see TCP and UDP ports for more port tests
  • Check certificate chain: Ensure all intermediate and root certificates are properly installed
  • Review Event Logs: Check Windows Event Viewer → System and Directory Services logs on the Domain Controller

Certificate Validation Errors

  • Hostname mismatch: The certificate's Subject Name or SAN must match the FQDN in DSAServer
  • Trust chain broken: Verify all intermediate certificates are installed in the correct store
  • Certificate expired: Replace with a new certificate before the expiration date

Certificate Management Best Practices

  • Use enterprise CA: Leverage your organization's Certificate Authority for centralized management
  • Plan for renewal: Set reminders to renew certificates at least 30 days before expiration
  • Monitor certificate health: Use Nodinite Monitoring Agents to alert on expiring certificates
  • Document your configuration: Keep records of which certificates are deployed where
  • Test in non-production: Always validate certificate changes in dev/test environments first

References

Important

Always use certificates to secure communication. Replace certificates before they expire or become obsolete.

Next Steps

Monitor your certificates so you replace them before they expire: