Bloqueio de conta após uma única falha de autenticação

Question

Eu tenho 2 servidores autônomos (não em qualquer domínio / AD) - Windows 2003 e Windows 2008.

Ao se conectar a compartilhamentos neles, usando o caminho UNC do Windows 2000 pro ou Samba (no linux), se eu cometer um erro ao digitar a senha, esses servidores bloquearão a conta na primeira tentativa.

Funciona bem, quando se conecta a partir do Windows 2003, Windows 2008 e Vista.

Em todas as máquinas conectadas, ele informará falha de autenticação e solicitará credenciais novamente. Mas a partir do Windows 2000 e do Samba, ele continuará a falhar na segunda tentativa, mesmo que a senha esteja correta. Tentar registrar-se nessas máquinas relatará a conta bloqueada.

O conjunto de políticas é para bloquear a conta em 10 falhas e se comporta corretamente quando a tentativa de conexão é feita a partir da W2008 ou W2003 - ou seja, mesmo que a primeira tentativa falhe, a próxima será bem-sucedida.

Eu fiz o experimento para desbloquear a conta, a partir do W2000 eu intencionalmente tentei logar com uma senha incorreta, e mesmo sem uma segunda tentativa eu posso ver que a conta está bloqueada.

Alguma idéia do que eu posso mudar, então evito esse problema? Isso geralmente acontece quando eu estou com pressa (claro :)), então lidar com o registro nas máquinas para desbloquear a conta é realmente frustrante.

    

Answer 1

Não sei qual é o seu nível de familiaridade com o Wireshark, então peço desculpas se isso for muito verboso ou conciso. ; -)

Essencialmente, você deseja instalar e iniciar o Wireshark em ambas as extremidades - não importa qual - e começar a capturar na interface apropriada:

1. No Wireshark, clique no menu Capture e, em seguida, em Options…
2. Selecione a interface apropriada.
3. Como você mencionou que não está em um domínio, sugiro inserir um Capture Filter para limitar a quantidade de tráfego capturado, algo como:
   host 169.254.255.127
   O endereço IP deve ser para o host remoto .
4. Start da captura e, em seguida, tente navegar no compartilhamento.
5. Aguarde até que o compartilhamento seja exibido ou você receba uma caixa de nome de usuário / senha inválida e pare a captura.

Posso sugerir que você faça isso duas vezes em cada local; primeiro, com um nome de usuário e senha corretos; e segundo, com um nome de usuário e / ou senha inválidos. Entre cada tentativa, certifique-se de desconectar do compartilhamento remoto (para que ele solicite novamente a autenticação), fazendo:

net use \remoteserver\SharedFolder /delete

O que estamos procurando aqui é SMB data, então a primeira maneira de remover tudo que não está relacionado é aplicar um simples Filtro de exibição no campo Filter: nas barras de ferramentas:

smb

No começo, você deve ver basicamente três tipos de transmissões no campo Info :

• Negotiate Protocol Request/Response
  Estes mostram os protocolos suportados pelo cliente e qual protocolo foi aceito pelo servidor. Você pode expandir isso na seção Packet details para ver se o servidor está usando NTLM, Kerberos, etc.
• Session Setup AndX Request/Response
  Esta é a autenticação, o que, esperamos, está acontecendo em um estilo de desafio / resposta. Você verá vários Response s possíveis do servidor:
  • STATUS_MORE_PROCESSING_REQUIRED : a autenticação está em andamento.
  • STATUS_LOGON_FAILURE : esta é uma falha de logon - você estará mais interessado nelas!
  • (nada), caso em que você pode expandir SMB > SMB Header e procure por NT Status: STATUS_SUCCESS , o que indica uma autenticação bem-sucedida.
• Tree Connect AndX Request/Response
  Este é o cliente pedindo para se conectar a um local específico no servidor; você normalmente verá acessos a IPC$ , bem como o compartilhamento que realmente deseja.

Então, o que você está procurando, são as linhas que dizem STATUS_LOGON_FAILURE . Em seguida, observe uma linha acima para ver qual usuário não conseguiu autenticar.

Agora, é típico ver falhas de login sempre que você navega em um compartilhamento; isso é porque o Windows tenta autenticar usando a conta de usuário com logon primeiro. Portanto, não se surpreenda ao ver, mesmo entre as famílias de sistemas operacionais "modernas" (2k3, Vista, 2k8), falhas de logon.

Quando executei este teste anteriormente, vi três falhas de logon com LOCALCOMPUTER\localuser antes mesmo de tentar usar REMOTECOMPUTER\remoteuser (que, no meu caso, foi bem-sucedido na primeira tentativa). E quando tentei em uma máquina em outro domínio, recebi dez falhas de logon! Isso antes mesmo de me pedir credenciais alternativas.

Se você quiser filtrar tudo, exceto a autenticação, altere o filtro de exibição para:

smb.cmd == 0x73

Para ver uma lista de todas as falhas de logon, altere o filtro de exibição para:

smb.nt_status == 0xc000006d

Lembre-se de que essas falhas de logon podem não ter nenhum impacto, já que normalmente a conta não existe na máquina remota (portanto, não há "contabilidade negativa", por assim dizer, a ser feita para isso). / p>

Editar : talvez você queira fazer uma pausa por alguns segundos quando solicitar credenciais alternativas, para que você tenha uma ideia clara de quais falhas de autenticação pertencem às tentativas "automatizadas" e quais pertencem para você deliberadamente erros nas credenciais.

Deixe-nos saber o que você descobriu!

    

Answer 2

É mais provável que você tenha um problema com a diferença entre o NTLM e o NTLMv2. O padrão do Windows 2000 e do Samba é NTLM, que aparece para um servidor Windows 2003 e Windows 2008 como uma tentativa válida de senha, mas não pode interpretar a senha corretamente enquanto espera o NTLMv2.

Acredito que o Windows 2000 possa agora suportar o NTLMv2 juntamente com os últimos bits do Samba ...

Você pode tentar configurar o seu Windows 2000 e Samba para usar o NTLMv2 ...

Outra estratégia que você pode tentar é fazer o downgrade da versão NTLM em seus servidores Windows 2003/2008 para ver se ainda tem problemas. Eu não deixaria no NTLM, já que o NTLMv2 é muito mais seguro.

    

Answer 3

Isso pode acontecer se você tiver um usuário cujo nome de usuário seja o mesmo em dois domínios (mas a senha for diferente) e tente se conectar de uma máquina em um domínio a uma máquina na outra.

Isso também pode ser devido a vários desafios de autenticação sequencial por tentativa de conexão. Há um artigo da base de conhecimento e uma correção do Win2K no link

Você pode desabilitar os métodos de autenticação que você não está usando de qualquer maneira. :)