Enabling Secure LDAP Sign-In

Ensuring LDAP communication is secure has become a key concern in cybersecurity, particularly in light of how easily unprotected LDAP sessions can be intercepted and manipulated. There’s been plenty of discussion around LDAP signing, but also a fair amount of confusion. This article aims to clarify the concepts and outline practical steps to implement LDAP signing with confidence.

Understanding LDAP Signing and Sealing

LDAP is a protocol commonly used for querying and modifying Active Directory data. Without proper security configurations, LDAP traffic—including credentials—can be transmitted in plain text, making it vulnerable to attacks such as man-in-the-middle (MitM), session hijacking, and data tampering.

Signing ensures data integrity. It verifies that the content of messages has not been altered during transit.
Sealing adds encryption, making the data unreadable to unauthorized observers.

While the concept of signing and sealing might seem complex, think of it as a modern evolution of wax seals on letters. If the seal is intact, the message hasn’t been read or altered. Today, we use cryptographic keys instead of wax, and protocols like Kerberos or NTLM help facilitate this process.

Binding Types in LDAP

Active Directory supports two main types of LDAP binds:

Simple Binds: These are similar to basic authentication over HTTP. The username and password are sent as plain text unless a secure channel (like TLS) is used.
SASL Binds (Simple Authentication and Security Layer): These use stronger mechanisms such as NTLM or Kerberos and can support both signing and encryption, depending on how the session is negotiated.

It’s important to note

TLS doesn’t sign traffic, but it does ensure encryption and integrity.
Windows will accept simple binds over TLS, even if signing is required by policy.

Enforcing LDAP Signing

Both clients and servers must support signing to establish a secure session. On Windows, policy settings allow you to configure signing requirements:

For Clients

None: No signing is offered.
Negotiate: Signing is offered, but not required.
Require: Session fails if the server doesn’t support signing.

Policy changes take effect immediately and are backed by the registry setting: HKLM\System\CurrentControlSet\Services\LDAP\LdapClientIntegrity

For Domain Controllers

None: Signing is optional.
Require Signing: Connections must support signing or are rejected.

The related registry key is: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity

Before enforcing signing, ensure that all clients support it to avoid service disruptions.

Aviod service disruptions

Implementing TLS for Simple Binds

Using LDAPS (port 636) or StartTLS (on port 389) allows simple binds to be encrypted. This requires:

Install a valid certificate on your domain controllers.
Updating applications to connect using LDAPS or StartTLS.

This often involves working closely with application owners, as configuration steps can vary significantly between platforms.

Load Balancing Considerations

Although load balancers are widely used to distribute LDAP traffic, they can introduce security risks:

TLS Offloading: Exposes traffic between the load balancer and the domain controller.
Kerberos Failures: SPNs can't be shared across multiple DCs when using VIPs.
Channel Binding Issues: Can arise if TLS sessions are broken and restarted by the load balancer.

Instead, rely on DNS-based DC locator logic when possible. It's fault-tolerant and doesn’t interfere with Kerberos.

Auditing Unsigned LDAP Sessions

Before enforcing signing, assess how much unsigned traffic exists in your environment:

Event ID 2887: Logged every 24 hours, showing the number of unsigned binds.
Enable Diagnostic Logging: Use this command on all DCs to log Event ID 2889 for each unsigned connection:

reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

Event ID 2889: Shows the client IP, account used, and bind type (0 = SASL w/o signing, 1 = Simple bind w/o TLS).

The PowerShell script provided in the help gathers and export this data for analysis.

# Get the 2889 events from the Directory Service log on the domain controller
$events = Get-WinEvent -FilterHashtable @{LogName=’Directory Service’;Id=2889}
 
# Create an empty array to store the output
$output = @()
 
# Loop through each event
foreach ($event in $events) {
    # Extract the client IP address without port number
    $clientIP = ($event.Properties[0].Value -split ‘:’)[0]
 
    # Extract the user account name
    $userAccount = $event.Properties[1].Value
 
    # Extract the numerical binding type
    $numericalBindingType = $event.Properties[2].Value
 
    # Extract the timestamp of the event
    $timestamp = $event.TimeCreated
 
    # Perform a DNS reverse lookup of the client IP address
    try {
        $dnsName = [System.Net.Dns]::GetHostEntry($clientIP).HostName
    } catch {
        $dnsName = “Unresolved”
    }
 
    # Get additional computer object attributes using Get-ADComputer
    try {
        $computerObject = Get-ADComputer -Filter { DNSHostName -eq $dnsName } -Properties OperatingSystem, DistinguishedName
    } catch {
        $computerObject = @{
            OperatingSystem = “Unknown”
            DistinguishedName = “Unknown”
        }
    }
 
    # Create a custom object with the output fields
    $obj = [PSCustomObject]@{
        ClientIP = $clientIP
        UserAccount = $userAccount
        BindingType = $numericalBindingType
        Timestamp = $timestamp
        DNSName = $dnsName
        OperatingSystem = $computerObject.OperatingSystem
        DistinguishedName = $computerObject.DistinguishedName
    }
 
    # Add the object to the output array
    $output += $obj
}
 
# Write the output to a .csv file in the c:\script folder
$output | Export-Csv -Path ‘c:\script\resolved_ldap_clients.csv’ -NoTypeInformation
Write-Host “Script completed. Output file created.”

Microsoft Defender for Identity (MDI)

If your organization uses MDI, it can generate Secure Score reports highlighting credentials exposed through insecure simple binds. However, it currently does not track unsigned SASL sessions.

Microsoft defender for identity(MDI)

Best Practices for LDAP Signing

Do not enable "Require Signing" on DCs until all unsigned traffic has been remediated.
Do configure clients to support signing.
Do treat SASL without signing and simple binds without TLS as separate remediation efforts.
Don't confuse LDAP signing with LDAPS (port 636); StartTLS and SASL signing over port 389 are secure too.
Do monitor Event ID 2888 for rejected unsigned bind attempts after enabling signing.

Summary

Implementing LDAP signing is a critical step toward securing Active Directory communications. By carefully auditing your environment and gradually enforcing secure settings, you can eliminate vulnerabilities without breaking business-critical systems. Stay vigilant, test thoroughly, and collaborate across teams to ensure a smooth transition