Autenticação do Active Directory rejeitada e a contagem de senha incorreta não é incrementada ou redefinida

5

Há um problema estranho e confuso (para mim e para os usuários) que assola a autenticação. Eu não sei há quanto tempo isso está ocorrendo, mas acredito que seja um bom tempo. Apenas recentemente, com o uso da ferramenta Account Lockout, percebi que esses problemas de autenticação às vezes são causados por uma falha no sistema, e não por erro do usuário.

O que acontece é que um usuário autentica corretamente, mas o sistema rejeita sua senha. Desejo repetir: eles fazem login com o nome de usuário, senha e domínio corretos. Isso não é dedilhado de gordura; não é um problema do cliente; não é erro do usuário; não é uma senha expirada; não é específico para nenhum serviço.

O comportamento quando um usuário autentica corretamente é que o CD redefine a contagem de "falha no login" para zero. Quando eles falham, ele é incrementado e define o tempo da "última falha". Mas quando esta falha ocorre, nenhum dos dois acontece; a tentativa de autenticação é rejeitada, mas a contagem não aumenta em 1, nem é redefinida, e o último tempo de falha não muda.

O problema ocorre em vários dispositivos e serviços. Hoje eu tive um aluno não consegue fazer login em vários computadores, bem como webmail. Eu comparei os logs de eventos do computador e do DC; Eu não vejo diferença entre os eventos quando o usuário foi erroneamente rejeitado (e a contagem de falhas não subiu) e quando ela foi rejeitada corretamente porque eu tinha digitado errado a senha de propósito.

Eu mesmo fiz isso, tentando fazer login na conta recém-criada de um aluno (usando um esquema de senha conhecido). Eu tive que acontecer com os usuários em muitos dos serviços que autenticam através do AD. Isso aconteceu com funcionários, professores e alunos. Tanto quanto eu posso dizer, isso é um problema de autenticação diretamente nos DCs; algo anormal com a conta, mas não um dos culpados típicos da senha expirada, desativada, etc.

A redefinição da senha corrige o problema. O problema simplesmente desaparece. Mas a frequência do problema (cerca de 8-10 casos apenas esta semana, de no máximo 100 redefinições de senha de rede) me leva a acreditar que é um problema sério.

Não sei há quanto tempo esse problema está ocorrendo. Sem usar a ferramenta Account Lockout, eu nunca teria visto que a contagem de erros estava falhando em incrementar e, portanto, supus que o usuário estava errado sobre o conhecimento da senha. Tive muitas ocorrências em que os usuários juraram que sabiam seu login e "funcionaram ontem". Eu não sei quantas dessas vezes era verdade, se é que alguma vez. Mesmo depois de receber a ferramenta, várias ocorrências e vários meses do problema ocorreram antes que eu acreditasse que era um problema real. Até que eu realmente tivesse acontecido comigo, digitando a senha inicial do aluno e vendo a contagem de falhas falhar, eu realmente acreditei.

Nosso ambiente de AD é principalmente no Windows server 2008. Alguns DCs ainda são Server 2003. O ambiente é um único domínio. Se houver outros detalhes técnicos relevantes necessários para solução de problemas, entre em contato.

Editar : como a resposta aceita mostra, foi realmente erro do usuário . O evento que 'provou' para mim que era um problema real foi quando eu entrei em uma conta recém-criada e ela falhou sem incrementar a contagem de senha incorreta. Temos padrões para novas contas e para o qual redefinir senhas. Provavelmente outro administrador ignorou o padrão e redefiniu a senha desse usuário para outra coisa. Quando tentei efetuar login no novo usuário, e a senha incorreta não aumentou (mas fui rejeitado), achei que era uma prova de um problema. Muito do Google não conseguiu encontrar uma página descrevendo as situações em que a contagem de senha incorreta não aumenta ... esperamos que essa resposta ajude outra pessoa no futuro.

    
por Myrddin Emrys 11.01.2013 / 02:42

3 respostas

9

Você tem histórico de senhas ativado? Se a senha inserida corresponder a uma das duas últimas senhas da conta, a autenticação será rejeitada, mas badPwdCount não será incrementado. Estou tentando resumir o restante da sua descrição, mas isso pelo menos explica o incremento de senha incorreta "ausente".

EDITAR

Relendo sua pergunta, parece que a reconfiguração administrativa de senhas sempre tem resultados positivos, correto? Também está se perguntando em qual sistema operacional o seu PDCe está (2003, 2008). Existe algum firewall bloqueando potencialmente o acesso ao PDCe (ou a quaisquer outros DCs)? Tenha em mente que, enquanto as alterações de senha do usuário final são comunicadas do cliente ao DC local por meio do protocolo kpasswd (TCP / 464), a notificação do PDCe das alterações de senha é feita por meio de uma chamada RPC. Os portos de destino terão mudado de 2003 para 2008.

    
por 16.05.2013 / 07:08
4

Isso tem um problema com a replicação ou com o controlador de domínio que tem a função de emulador de PDC.

Você pode executar netdom query fsmo em cada CD e comparar os resultados de cada um deles? Certifique-se de que todos pensam que o mesmo servidor mantém a função Emulador de PDC. Em seguida, dê uma olhada na saída de dcdiag e veja o que ela tem a dizer. Além disso, verifique a replicação com repadmin /showrepl em cada DC.

Se eu tivesse que adivinhar completamente, eu diria que há uma inconsistência em quem os CDs pensam ter a função Emulador de PDC, ou o servidor que uma vez foi mantido descomissionado e a função nunca foi movida.

    
por 11.01.2013 / 03:00
0

Isso não é um problema, isso é um recurso: Os aprimoramentos foram introduzidos para domínios no nível funcional do Windows Server 2003 e acima. Quando a senha incorreta corresponde a uma das duas entradas mais recentes no histórico de senhas, o atributo badPwdCount não é incrementado e o atributo badPasswordTime não é atualizado. Isso significa que usuários normais podem fazer mais tentativas antes de serem bloqueados. Suas tentativas de senha incorreta são mais passíveis de serem senhas usadas recentemente.

O significado do atributo lockoutObservationWindow é o mesmo. Mas como badPasswordTime não é atualizado para cada tentativa de senha incorreta, isso afeta o número de tentativas permitidas aos usuários em alguns casos. É mais provável que o badPwdCount seja redefinido quando um usuário tenta usar uma senha antiga.

Esse novo recurso às vezes é chamado de histórico de senhas n-2. A senha anterior mais recente é referida como n-1. Os próximos mais recentes são n-2. Nem todos os tipos de autenticação aproveitam esse novo recurso. Os protocolos de autenticação Kerberos e NTLM suportam o histórico de senhas n-2. Esses protocolos são usados quando uma senha ou um cartão inteligente é usado para login interativo. Outros protocolos, como RADIUS e PEAP, podem ou não incrementar badPwdCount quando uma senha incorreta é tentada. Alguns protocolos não encaminham tentativas de senha incorretas para o emulador de PDC. Isso pode explicar por que os usuários de telefone podem ser bloqueados se o telefone tentar repetidamente autenticar com uma senha incorreta.

Além disso, o sistema só pode saber sobre as duas senhas anteriores no histórico se pwdHistoryLength for pelo menos 3. Com essa configuração, o usuário pode rodar três senhas, de modo que as duas anteriores são mantidas no histórico de senhas. Se pwdHistoryLength for 2, o usuário poderá alternar entre duas senhas. A única tentativa de senha que não irá incrementar badPwdCount, nesse caso, é a anterior. O sistema não retém a segunda senha mais recente.

    
por 08.03.2018 / 14:08