我看了你的Spring Boot 2.7.2 Security配置，结合你遇到的「账号密码正确但登录弹窗反复出现、无控制台报错」的问题，下面是几个关键排查点和解决办法：

1. 核心遗漏：未将自定义AuthenticationProvider纳入认证流程 #

你已经定义了activeDirectoryLdapAuthenticationProvider这个Bean，但没有把它注册到SecurityFilterChain的认证逻辑中。Spring Security默认不会自动识别并使用自定义的AuthenticationProvider，导致系统一直在用默认认证逻辑，自然无法通过AD验证，最终触发反复弹窗。

修改你的filterChain方法，添加authenticationProvider配置：

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .anyRequest().fullyAuthenticated()
            .and()
            .httpBasic()
            .and()
            // 关键：将自定义的AD认证Provider加入流程
            .authenticationProvider(activeDirectoryLdapAuthenticationProvider()); 
    return http.build();
}

2. 验证AD用户名的格式是否符合要求 #

ActiveDirectoryLdapAuthenticationProvider默认的用户名处理逻辑是：如果输入的用户名不带域名，会自动拼接你配置的company.com，变成username@company.com去AD验证。但部分AD环境可能要求用纯sAMAccountName（即不带域名的用户名）或者DOMAIN\username格式。

你可以先尝试两种登录方式测试：

• 登录时输入完整格式：username@company.com
• 或者修改Provider配置，支持纯用户名验证，比如添加自定义用户信息映射：

provider.setUserDetailsContextMapper(new UserDetailsContextMapper() {
    @Override
    public UserDetails mapUserFromContext(DirContextOperations ctx, String username, Collection<? extends GrantedAuthority> authorities) {
        // 这里可以自定义用户信息的转换逻辑，确保适配你的AD属性
        return new User(username, "", authorities);
    }

    @Override
    public void mapUserToContext(UserDetails user, DirContextAdapter ctx) {
        // 无需实现，除非需要反向写入AD
    }
});

3. 开启调试日志排查隐藏错误 #

既然控制台没有报错，建议开启Spring Security和LDAP的调试日志，查看认证过程中的细节（比如连接失败、权限不足、属性不匹配等隐藏问题）。在application.properties中添加：

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

开启后，你能看到AD连接请求、认证步骤、属性搜索的完整日志，定位问题会更精准。

4. 确认AD服务器的可达性与配置正确性 #

先确认应用服务器能正常访问ldap://ldap-company.com:389，没有防火墙或网络策略拦截。可以在应用服务器上用ldapsearch命令测试连接：

ldapsearch -H ldap://ldap-company.com:389 -D "cn=你的AD管理员账号,dc=company,dc=com" -w "管理员密码" -b "dc=company,dc=com" "(sAMAccountName=你的测试用户名)"

如果这个命令能返回用户的属性信息，说明网络和AD本身的配置是正常的，问题还是出在Spring Security的配置上。

5. 检查SearchFilter是否匹配AD实际属性 #

你的搜索过滤器(&(objectClass=user)(sAMAccountName={0}))是标准配置，但部分AD环境可能objectClass值为person，或者sAMAccountName字段名有差异。可以通过上面的ldapsearch命令确认用户的实际属性，确保过滤条件和AD的属性一致。

优先尝试第一个修改（将自定义Provider加入SecurityFilterChain），这是最常见的遗漏点，大概率能解决你的问题。如果还是不行，再通过调试日志进一步定位。

内容的提问来源于stack exchange，提问作者Ajay Kumar