Esse erro de senha LDAP pode não ser a senha do usuário
Uma falha de bind pode vir da conta de serviço ou do escopo de pesquisa, não do usuário. Separe os bind antes de redefinir a senha de alguém.
Redefinir a senha de um usuário é o primeiro passo errado quando o log apenas diz que um bind foi recusado. Com um plugin de diretório há mais de um bind em um único login, e a recusa pode pertencer à conta de serviço que realiza a pesquisa. Redefinir as credenciais do usuário nesse caso não muda nada. Também bloqueia alguém que nunca foi o problema.
Um login, vários bind
Uma configuração com uma conta de diretório dedicada costuma executar quatro etapas em ordem, e qualquer uma delas pode encerrar o login.
connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groups
O plugin constrói sua conexão de autenticação do usuário pelo mesmo auxiliar que trata a primeira conexão, então esse auxiliar pode falhar ao conectar, ao negociar TLS ou ao fazer bind como a conta de serviço. A mensagem de alto nível sobre uma senha é gerada depois e não indica qual identidade estava envolvida. Por isso o texto do erro sozinho não pode dizer se o usuário ou a conta de serviço foi recusado.
Leia as linhas antes da mensagem e anote o momento em que a falha ocorreu. Uma recusa na inicialização, antes de qualquer usuário chegar, aponta para a conta configurada ou para o endpoint. Uma recusa que aparece só para uma pessoa, após uma pesquisa bem-sucedida, aponta para a entrada ou o estado da conta dessa pessoa.
Associe o erro a uma identidade
A regra prática é registrar três coisas juntas: quando falhou, qual operação estava em execução e qual identidade foi apresentada. Sem esse trio, duas falhas muito diferentes parecem iguais em um log que guarda apenas a frase final.
| What the log shows | Identity likely refused | First thing to check |
|---|---|---|
| Failure at start-up, no user yet | Service account | DN, password, expiry, lockout |
| Search returns nothing | None, the search scope is wrong | Search base and filter |
| Failure only for one user | That user's entry | Entry state, bind DN, group rules |
Se a conta configurada falhar, inspecione essa conta e a conexão antes de tocar em qualquer registro de usuário. Se o bind do usuário falhar após uma pesquisa bem-sucedida, examine a entrada que a pesquisa retornou, não a que você supôs que retornaria. Os dois caminhos compartilham uma mensagem e nada mais. Anote qual você descartou, porque a próxima pessoa vai perguntar exatamente isso.
O nome distinto é um dado, não uma suposição
Mudar um componente do nome porque ele parece pouco familiar é uma forma comum de quebrar uma configuração que funciona. O local padrão dos objetos de usuário no Active Directory é um contêiner chamado Users, e um contêiner não é o mesmo tipo de objeto que uma unidade organizacional com nome semelhante.
Peça ao administrador do diretório o nome distinto real da conta, ou leia-o do próprio objeto. Ambos os seguintes podem estar corretos em seu próprio diretório, por isso nenhum deles deve ser digitado de memória.
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example
Uma movimentação ou renomeação muda esse valor enquanto a conta e a senha continuam válidas, então uma configuração que funcionava no trimestre passado pode falhar neste sem que ninguém toque em uma credencial. Compare a string configurada com o atributo atual do diretório após qualquer reorganização. Faça isso também após uma migração silenciosa, não apenas depois de uma indisponibilidade relatada.
Uma base de pesquisa não é uma conta de serviço
A identidade do bind e a base de pesquisa respondem a perguntas diferentes: como quem o plugin se autentica e onde procura pessoas. Um bind bem-sucedido seguido de nenhum usuário correspondente é um problema de escopo, filtro ou permissão de leitura, e substituir o nome distinto da conta pela base dos usuários não muda nada nisso.
Confirme que o serviço carregou a configuração que você editou e que o seu endpoint, a confiança em TLS e o modo de autenticação correspondem a um teste administrativo que funcione. Uma consulta manual com outra conta, ou contra outro controlador de domínio, não é um experimento equivalente.
Verifique o segredo armazenado e verifique se a conta está habilitada, expirada ou bloqueada, sem imprimir a senha em lugar nenhum. A expiração é fácil de passar despercebida porque a conta continua funcionando até o dia em que deixa de funcionar. Um bloqueio herdado de um serviço não relacionado é igualmente silencioso. Nenhuma das duas condições produz uma mensagem que nomeie a conta de serviço.
As regras de grupo vêm por último
A autorização é executada depois que os bind têm sucesso, então uma verificação de grupo não pode ser a causa de uma falha de bind, e remover o requisito de grupo não pode repará-la. Se o login agora chega à etapa de grupo, o problema restante é a associação, não as credenciais.
Conceder à conta de serviço amplos direitos de diretório para fazer o erro desaparecer muda a política de acesso de toda a implantação. Trate isso como uma decisão de segurança com sua própria revisão, não como uma correção para uma mensagem que você ainda não atribuiu a uma identidade.