bind fails with invalid credentials when trying to use LDAPS and bind AD server to domain in entra domain services

Question

Followd the tutorial https://learn.microsoft.com/en-us/entra/identity/domain-services/tutorial-configure-ldaps to the letter but bind fails with "invalid credentials" error when using LDAPS to try to bind my local AD server to entra domain services.

I am 100% credentials are correct.

The error I get is:

53 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)

res = ldap_bind_s(ld, NULL, &NtAuthIdentity, DIGEST (16518)); // v.3

{NtAuthIdentity: User='admin'; Pwd=<unavailable>; domain = 'fastweb.local'}

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

Please help.

Answer 1

Hello andres

AAD DS does not support SAMAccountName (e.g., admin) or domain\user format for authentication.

To resolve the issue, - Use UPN format: admin@<tenant>.onmicrosoft.com- Ensure the user reset their password after enabling AAD DS (required for NTLM/Kerberos hash sync)

• Connect using LDAPS (port 636) with simple bind

Bind will fail with 52e unless UPN format + password reset post AAD DS enablement is used.

It looks like you’ve got a classic “52e / invalid credentials” when you try to LDAPS-bind your on‐prem AD account against your Entra Domain Services managed domain. Even if the password was correct on-prem, AAD DS has a few quirks you need to watch out for:

1. Use a UPN, not SAMAccountName or DOMAIN\user
   • Entra Domain Services only accepts the full UPN (e.g. ******@yourtenant.onmicrosoft.com).
2. Make sure the user reset their password after you enabled AAD DS
   • Password-hash sync (NTLM/Kerberos) only kicks in when the user changes their password post-enablement.
3. Connect over LDAPS (TCP 636) with a simple bind
   • Don’t try DIGEST or SSPI binds; just do ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, 3) + ldap_set_option(ld, LDAP_OPT_REFERRALS, 0), then ldap_bind_s(ld, “admin@…”, “password”, LDAP_AUTH_SIMPLE).
4. Validate your certificate and DNS
   • The LDAPS cert’s subject name must match your managed-domain’s DNS name.
   • Ensure the cert chain is trusted by your client.
5. Test with ldp.exe or openssl
   • Quick sanity check: “ldp.exe -s yourdomain.onmicrosoft.com -p 636 -ssl” then a simple bind with the UPN.

If you still hit the 52e, here are a few follow-up questions to zero in on the root cause:

• Are you really using the UPN format for the bind DN?

• Was the user forced to change their password after AAD DS was turned on?

• Which port and bind method (simple vs. SASL/digest) are you using?

• Does your LDAPS certificate subject match the managed domain name, and is it trusted by your client?

• Can you successfully connect and bind using ldp.exe or openssl s_client?

Hope this helps get you past the “invalid credentials” wall!

References

• Configuring Secure LDAP in Microsoft Entra Domain Services

https://docs.microsoft.com/azure/active-directory-domain-services/active-directory-ds-admin-guide-configure-secure-ldap

• Troubleshooting LDAPS configuration

https://docs.microsoft.com/azure/active-directory-domain-services/active-directory-ds-troubleshoot-ldaps

• Entra Domain Services sign-in/domain-join troubleshooting

https://docs.microsoft.com/azure/active-directory-domain-services/active-directory-ds-troubleshooting

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Let me know if any further queries - feel free to reach out!