LDAP bind errors in Active Directory: error 49 data codes (52e, 525, 775) and LDAP results

When an application, appliance or script can't bind to Active Directory, the LDAP client usually reports a short result code (49, 8, 81…) and, for error 49, a hex data value buried in the server message. That data value is the real reason. This quick reference decodes the error 49 data codes, the other LDAP results domain controllers return, and the signing, channel binding and LDAPS failures that show up after hardening, each with the usual cause and the first thing to check.

How to read these codes#

A failed bind in ldp.exe looks like this. The DSID and the trailing v… value change between builds; ignore them.

Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: 8009030C: LdapErr: DSID-0C0906F9, comment: AcceptSecurityContext error, data 52e, v4f7c
Error 0x8009030C The logon attempt failed

• The LDAP result code (49) is the category: invalid credentials. Java, Linux and appliance logs wrap the same server string in their own message, so search their logs for AcceptSecurityContext.
• The data value (52e) is a Win32 error code in hex: 0x52E is 1326, ERROR_LOGON_FAILURE. Decode any value on a Windows machine with certutil -error 0x52e or net helpmsg 1326.
• ADSI, .NET and PowerShell surface the same failure as an HRESULT that ends in the Win32 code, for example 0x8007052E.
• The domain controller's side of an authentication failure is in its Security log (events 4625, 4771 and 4776). Decode those with the logon failure codes reference and the Kerberos error codes reference.

Error 49: AcceptSecurityContext data codes#

# Account state behind most data codes (badPwdCount isn't replicated, so ask the PDC emulator)
$pdc = (Get-ADDomain).PDCEmulator
Get-ADUser svc-ldap -Server $pdc -Properties Enabled, LockedOut, badPwdCount, PasswordExpired, PasswordLastSet, AccountExpirationDate |
  Select-Object Enabled, LockedOut, badPwdCount, PasswordExpired, PasswordLastSet, AccountExpirationDate
# Data 568: how many group SIDs end up in the token
(Get-ADUser svc-ldap -Properties tokenGroups).tokenGroups.Count

Other LDAP result codes from domain controllers#

Through ADSI (PowerShell [adsi], .NET DirectoryEntry) the same results arrive as HRESULTs: 0x8007052E for LDAP_INVALID_CREDENTIALS, 0x8007203A for LDAP_SERVER_DOWN ("Cannot contact the LDAP server"), 0x80072030 for LDAP_NO_SUCH_OBJECT, 0x80072035 for LDAP_UNWILLING_TO_PERFORM, 0x80070005 for LDAP_INSUFFICIENT_RIGHTS and 0x80071392 for LDAP_ALREADY_EXISTS.

Signing, channel binding and LDAPS failures#

Strong Authentication Required (LDAP 8)#

Once Domain controller: LDAP server signing requirements is set to Require signing (registry LDAPServerIntegrity = 2 under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters; 1 means None), clear-text simple binds and unsigned SASL binds fail. Microsoft's own test is a simple bind on port 389 in ldp.exe; on a hardened DC it returns:

ldap_simple_bind_s() failed: Strong Authentication Required

Fix the client, not the DC: point it at LDAPS (636, or 3269 for the global catalog), use StartTLS, or use a SASL bind that requests signing. Windows clients follow Network security: LDAP client signing requirements. To find every client still binding insecurely before you enforce, use the DC's LDAP interface events 2887 and 2889, covered in the AD DS, Netlogon and DNS events reference.

Channel binding#

Domain controller: LDAP server channel binding token requirements maps to LdapEnforceChannelBinding in the same registry key: 0 Never, 1 When Supported, 2 Always. Channel binding applies to SASL binds (NTLM, Negotiate, Kerberos) over TLS. It doesn't apply to simple binds over TLS, certificate binds or SASL sessions without TLS. With Always, an older client or library that does a SASL bind over LDAPS without a channel binding token fails as an authentication error even with the right password. Test When Supported first, find and update the clients that fail, then move to Always.

LDAPS (636) fails while 389 works#

The DC needs a certificate in its Local Computer › Personal store with the Server Authentication enhanced key usage, the DC's FQDN in the subject or subject alternative name, an accessible private key, and a chain the client trusts. Without one, the TLS handshake fails and ldp.exe and most libraries report error 81, which looks like a network fault. Connecting by IP address or by an alias that isn't in the certificate fails the name check on the client.

# On the DC: candidate LDAPS certificates
Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains 'Server Authentication' } |
  Select-Object Subject, DnsNameList, NotAfter, HasPrivateKey
# From the app server: is the port even open?
Test-NetConnection dc01.contoso.com -Port 636

Test a bind the way the app does#

Reproduce the failure from the app server with the same account, port and bind type, and print the result code plus the server message:

Add-Type -AssemblyName System.DirectoryServices.Protocols
$id   = New-Object System.DirectoryServices.Protocols.LdapDirectoryIdentifier('dc01.contoso.com', 636)
$conn = New-Object System.DirectoryServices.Protocols.LdapConnection($id)
$conn.SessionOptions.SecureSocketLayer = $true            # $false for port 389
$conn.AuthType = [System.DirectoryServices.Protocols.AuthType]::Basic
$cred = Get-Credential                                    # e.g. svc-ldap@contoso.com
try   { $conn.Bind($cred.GetNetworkCredential()); 'Bind OK' }
catch { $e = $_.Exception.GetBaseException(); "{0} {1}" -f $e.ErrorCode, $e.ServerErrorMessage }

A wrong password prints 49 followed by the AcceptSecurityContext … data 52e string; a TLS or network problem prints 81 with no server message.

How to verify a fix#

1. Run the same bind test from the app server: you want Bind OK, or an authenticated session in ldp.exe.
2. Check the account on the PDC emulator: badPwdCount back to 0 after a successful bind, LockedOut False, no new 4625 or 4771 events for it.
3. For signing work, the DC's daily summary of insecure binds should stop counting the app; for LDAPS, the app should connect with certificate validation turned on, not with checks disabled.
4. Restart the app or its connector service and watch one full sync or login cycle, because many apps cache a failed connection.

References#

• System Error Codes (1300-1699) and System Error Codes (1700-3999)
• Win32 Error Codes (ADSI)
• How to enable LDAP signing in Windows Server
• LDAP channel binding overview for Active Directory Domain Services