LDAP通信始终返回Bad Credential问题排查求助

Hey there! Let's tackle this persistent Bad Credential error you're facing. Since your app works fine with embedded LDIF files and public test LDAP servers, the issue is almost certainly in how your Spring Security configuration aligns with your Active Directory (AD) structure. Let's walk through the most common fixes step by step:

1. Double-Check the User Distinguished Name (DN) Format #

AD is strict about the full DN for authentication. If your DC structure looks like dc=yourdomain,dc=com, the Administrator's full DN is likely cn=Administrator,cn=Users,dc=yourdomain,dc=com—not just Administrator.

• To confirm the correct DN, run this command on your Windows Server 2012:

  dsquery user -name Administrator
  

• Make sure your Spring config uses this exact DN (or correctly constructs it via patterns/search filters).

2. Validate LDAP URL & Port Settings #

• Ensure your contextSource URL points to the right AD server and port:
  • Non-SSL: ldap://your-ad-server-ip:389
  • SSL: ldaps://your-ad-server-ip:636 (note: if using SSL, you'll need to import AD's certificate into your Java truststore—missing this can sometimes throw a misleading Bad Credential error instead of a connection failure).

3. Fix User Search Filter & Base DN #

AD uses sAMAccountName (the Windows login name) instead of the standard LDAP uid. Your Spring config needs to reflect this:

Example correct configuration snippet:

@Bean
public DefaultSpringSecurityContextSource contextSource() {
    return new DefaultSpringSecurityContextSource("ldap://your-ad-server:389/dc=yourdomain,dc=com");
}

@Bean
public LdapAuthenticationProvider ldapAuthenticationProvider() {
    BindAuthenticator authenticator = new BindAuthenticator(contextSource());
    // Use sAMAccountName for user search (matches Windows login)
    authenticator.setUserSearchFilter("(sAMAccountName={0})");
    // Point to the OU/CN where your users are stored (e.g., cn=Users)
    authenticator.setUserSearchBase("cn=Users");
    return new LdapAuthenticationProvider(authenticator);
}

If you're using user DN patterns instead of search filters, it should look like:

authenticator.setUserDnPatterns(new String[]{"cn={0},cn=Users"});

4. Eliminate Case Sensitivity & Whitespace Issues #

• AD's sAMAccountName is case-insensitive, but passwords are strictly case-sensitive—double-check that the password in your config/test matches exactly.
• Ensure there are no extra spaces in the username or DN (e.g., "Administrator " with a trailing space will fail authentication).

5. Test Authentication with a Standalone Tool #

Use a tool like ldp.exe (built into Windows) or ldapsearch to test AD authentication outside of your app. For example:

ldapsearch -H ldap://your-ad-server:389 -D "cn=Administrator,cn=Users,dc=yourdomain,dc=com" -W -b "dc=yourdomain,dc=com" "(sAMAccountName=Administrator)"

• If this tool succeeds, the problem is definitely in your Spring config.
• If it fails, verify that the Administrator account isn't locked (though you mentioned it works for Windows login, so this is unlikely).

6. Enable Debug Logging for Detailed Insights #

Turn on debug logging for Spring LDAP to see exactly what's happening during authentication. Add these lines to your application.properties:

logging.level.org.springframework.security.ldap=DEBUG
logging.level.org.springframework.ldap=DEBUG

Look for logs showing the exact DN being used for binding—this will often reveal if your config is constructing an invalid DN.

If you can share your specific Spring Security code snippet and the DC structure screenshot, I can help pinpoint the exact misconfiguration!

内容的提问来源于stack exchange，提问作者KuldeeP ChoudharY