Introdução
Ah, account lockout... configuração que pode ser tanto um anjo da guarda como também uma pedra em seu sapato, se mal configurado.
De um modo geral não há tantos problemas em se descobrir a origem de um account lockout, salvo ocasiões em que ataques de força bruta são observados. Mesmo quando temos Exchange ou outros produtos envolvidos, cada ferramenta possui um log que nos possibilita a identificação de "credenciais ruins" e, o NPS não é uma exceção. Como podemos ver no artigo de Audit Network Policy Server, existe uma boa gama de eventos para monitorar as solicitações de acesso direcionadas a um servidor NPS. Para habilitar estas auditorias, basta aplicar a GPO de Audit Network Policy Server, encontrada em Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationSystem Audit PoliciesLogon/Logoff.
Dentre os eventos que podem ser gerados, para análise de problemas de account lockouts, utilizamos, principalmente, o evento 6273, que nos informa que o servidor NPS negou o acesso a um usuário bem como o motivo da negação.
Antes de seguir falando sobre este evento, é importante, contudo, falar a respeito dos eventos 6279 e 6280, visto que tais eventos são referentes a account lockouts também, no entanto, estes eventos são referentes ao NPS Account Lockout. Embora ambas configurações - NPS Account Lockout
e Active Directory Account Lockout - tenham o mesmo objetivo: prevenir o
ambiente e/ou o usuário contra ataques de força bruta, ambos funcionam de uma maneira um pouco diferente, enquanto o Active Directory Account Lockout tem como consequência de tentativas de logon incorretas o bloqueio completo da conta do usuário no Active Directory, o NPS Account Lockout tem como objetivo impedir novas tentativas de autenticação no NPS, sem afetar a conta do usuário no Active Directory. Este artigo, no entanto, é focado no Active Directory Account Lockout.
Para entender como habilitar e como funciona o NPS Account Lockout, recomendo a leitura do artigo NPS: Account Lockout.
Nota importante: assumimo que antes de chegar nesta análise do servidor NPS, já tenha realizado análises de account lockout nos domain controllers através de logs de auditoria, depuração do netlogon.log, etc. Embora tenham sido liberadas há bastante tempo, as ferramentas de gerenciamento de Account Lockout ainda são muito úteis nesta análise.
De volta ao evento 6273, o seguinte exemplo de evento nos dá uma ideia de como a análise seria feita:
Log
Name: Security
Source:
Microsoft-Windows-Security-Auditing
Date:
16/05/2017 14:33:14
Event
ID: 6273
Task
Category: Network Policy Server
Level:
Information
Keywords:
Audit Failure
User:
N/A
Computer:
NPS01.contoso.local
Description:
Network
Policy Server denied access to a user.
Contact
the Network Policy Server administrator for more information.
User:
Security
ID: S-1-5-21-3927881245-1022922358-2527905271-1117
Account Name: user1
Account Domain: contoso.local
Fully Qualified Account Name: CONTOSOuser1
Client
Machine:
Security
ID: NULL SID
Account
Name: -
Fully
Qualified Account Name: -
OS-Version:
-
Called Station Identifier: 08-cc-68-??-??-??
Calling Station Identifier: e8-50-8b-??-??-??
NAS:
NAS IPv4 Address: 192.168.110.200
NAS IPv6 Address: -
NAS Identifier: CONTOSONAS01
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: 1
RADIUS
Client:
Client
Friendly Name: CONTOSOAP02
Client
IP Address: 192.168.115.12
Authentication
Details:
Proxy
Policy Name: Contoso-Wireless-Connections
Network
Policy Name: Contoso-Wireless-Connections
Authentication
Provider: Windows
Authentication
Server: phcmisad02.PeninsulaAD.local
Authentication
Type: PEAP
EAP
Type: 29
Account
Session Identifier: -
Reason Code: 34
Reason: The user account that is specified in the RADIUS
Access-Request message is disabled.
Se um usuário tem sua tentativa de acesso negada pelo NPS, espera-se que um evento 6273 seja gerado informando o motivo. Na amostra acima, podemos ver que o usuário user1 não conseguiu autenticar-se devido a um
erro cujo código é 34, ou, no caso, a conta do usuário está desabilitada. Atente-se aos campos de Called Station Identifier e Calling Station Identifier. O Called Station Identifier informa o MAC Address do Wireless Controller ou Access Point que recebeu a credencial e a direcionou ao NPS enquanto o Calling Station Identifier informa o MAC Address do dispositivo que realizou a tentativa de autenticação, por exemplo, um laptop, smartphone, tablet, etc.
Nota: na amostra, ocultamos o sufixo dos MAC Addresses, entretanto, em seu ambiente encontrará a informação completa.
Outro log importante seria o evento 4625 (auditoria de Logon) que também é gerado no servidor NPS, conforme exemplo:
Log
Name: Security
Source:
Microsoft-Windows-Security-Auditing
Date:
16/05/2017 14:33:14
Event
ID: 4625
Task
Category: Logon
Level:
Information
Keywords:
Audit Failure
User:
N/A
Computer:
NPS01W.contoso.local
Description:
An
account failed to log on.
Subject:
Security
ID: SYSTEM
Account
Name: NPS01$
Account
Domain: CONTOSO
Logon
ID: 0x3e7
Logon Type: 3
Account
For Which Logon Failed:
Security
ID: NULL SID
Account Name: user1
Account Domain: CONTOSO
Failure
Information:
Failure Reason: Your user account is disabled.
Status: 0xc000006d ---> STATUS_LOGON_FAILURE
Sub Status: 0xc0000072 ---> STATUS_ACCOUNT_DISABLED
Process
Information:
Caller
Process ID: 0x3e4
Caller
Process Name: C:WindowsSystem32svchost.exe
Network
Information:
Workstation Name:
Source
Network Address: -
Source
Port: -
Detailed
Authentication Information:
Logon
Process: CHAP
Authentication
Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Transited
Services: -
Package
Name (NTLM only): -
Key
Length: 0
This event is generated when a logon request fails. It is generated on the computer
where access was attempted.
The Subject fields indicate the account on the local system which requested the
logon. This is most commonly a service such as the Server service, or a local
process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most
common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system
requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this
specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Observe, novamente, os campos destacados. Temos o nome do usuário, seu domínio, o motivo da falha, entre outras informações. Quero comentar dois campos específicos aqui: Logon Type e Workstation Name.
Como podemos ver, o Logon Type nos retorna o valor 3, que equivale a Network Logon e, geralmente, está relacionado a autenticação NTLM. A tabela com
todos os valores possíveis pode ser encontrada no artigo de Auditoria de eventos de logon. Quanto ao campo de Workstation Name, pode estar se perguntando: por que não retornou o nome do dispositivo? E a resposta envolve sistemas operacionais de terceiros. Logs do event viewer e netlogon tendem a não retornar o hostname do dispositivo quando estamos trabalhando com Sistemas Operacionais de terceiros, visto que o campo de hostname do dispositivo não é encontrado da mesma maneira que encontramos no Windows.
Por falar em netlogon.log, é importante dizer que o log em questão é extremamente útil para análises de problema de autenticação (inclusive problemas de account lockout), entretanto, é necessário manter em
mente que o netlogon.log registrará informações referentes a logon de rede (Logon Type 3) e autenticações NTLM. Para outros tipos de logon e autenticação
Kerbero, por exemplo, é necessário focar no Event Viewer.
Por padrão a depuração do netlogon não é habilitada, porém, pode ser facilmente configurada através do comando nltest /dbflag:2080FFFF, ou, para um nível mais detalhado de informações, nltest /dbflag:26FFFFFF. Para quem deseja habilitar a depuração de forma massiva e ainda sim evitar a utilização de scripts, temos uma GPO disponível para isso: Specify log file debug output level, em Computer ConfigurationPoliciesAdministrative TemplatesSystemNet logon, o valor na GPO precisa ser inserido em sua forma decimal, ou seja, para 2080FFFF, deve-se utilizar o valor 545325055 enquanto que para 26FFFFFF, deve-se utilizar 654311423.
Com a depuração habilitada, o netlogon passará a gerar mais informações, em especial, informações referentes a tentativas de logon, sejam elas com sucesso ou não.
Por exemplo, para nosso usuário de testes, user1, as seguintes informações foram geradas no servidor NPS:
05/16 14:33:14 [LOGON] SamLogon: Network logon of CONTOSOuser1 from Returns
0xC0000072
05/16 14:33:18 [LOGON] SamLogon: Network logon of CONTOSOuser1 from Returns
0xC0000072
05/16 14:33:20 [LOGON] SamLogon: Network logon of CONTOSOuser1 from Returns
0xC0000072
05/16 14:33:22 [LOGON] SamLogon: Network logon of CONTOSOuser1 from Returns
0xC0000072
05/16 14:33:29 [LOGON] SamLogon: Network logon of CONTOSOuser1 from Returns
0xC0000072
Novamente, o código 0xC0000072 refere-se ao erro STATUS_ACCOUNT_DISABLED.
A lista de códigos mais comuns pode ser encontrada no artigo de Quick
Reference: Troubleshooting Netlogon Error Codes. Perceba que não é retornado o nome do dispositivo que enviou a credencial, pois trata-se de um dispositivo com sistema operacional de terceiros. Quando tratamos de um dispositivo Windows, o log gera informações como essa:
05/16 14:39:23 [LOGON] SamLogon: Network logon of CONTOSOuser1 from WindowsPhone01 Returns 0xC0000072
Até aqui parece fácil, mas e se o usuário estiver sendo bloqueado e não termos eventos gerados no servidor NPS?
O problema: as autenticações "fantasma"
Recentemente trabalhei em um incidente com um cliente que possuia as auditorias de NPS habilitadas, entretanto, ainda que o evento 4673 fosse gerado, não haviam eventos para o usuário que era afetado. Para preservar a privacidade de nosso cliente, algumas informações da análise serão censurados ou modificados.
Novamente, tínhamos um usuário sendo bloqueado após diversas tentativas de autenticação utilizando uma senha errada (0xC000006A) contra o servidor NPS, entretanto, essas tentativas de autenticação não eram visíveis nos logs do NPS, apenas nos eventos de Logon e no netlogon.log. Logo, optamos por deixar uma captura de rede rodando por algumas horas no servidor NPS, até que o usuário fosse bloqueado, e então avaliar com mais calma de onde essas credenciais partiam.
Para esta captura de rede, utilizamos o netsh, através do comando netsh trace start capture=yes tracefile=C:tempnetsh.etl maxsize=300 scenario=netconnection. Vale ressaltar que esta captura poderia ter sido realizada com outras ferramentas, por exemplo o Network Monitor 3.4
ou o WireShark, entretanto, o netsh trata-se de uma ferramenta nativa a partir do Windows 7 e Windows Server 2008 R2, que não demanda a instalação de qualquer pacote adicional.
Com o resultado da captura em mãos, partimos para a análise.
Inicialmente imaginei que um simples filtro em cima do protocólo RADIUS seria suficiente, visto que me permitiria analisar todo o processo de Accounting realizado pelo NPS:
![]()
Entretanto, não havia qualquer accounting sendo realizado para a conta de nosso usuário, que chamaremos de mydomainms-user. Para fins de conhecimento, a política de Active Directory Account Lockout desde cliente estava configurada para bloquear usuários caso houvessem 5 tentativas de logon incorretas em um intervalo de 1 hora e, no netlogon.log do NPS encontramos o seguinte:
05/16 14:07:09 [LOGON] SamLogon: Network logon of MYDOMAINms-user from Returns
0xC000006A
05/16 14:19:18 [LOGON] SamLogon: Network logon of MYDOMAINms-user from Returns
0xC000006A
05/16 14:29:03 [LOGON] SamLogon: Network logon of MYDOMAINms-user from Returns
0xC000006A
05/16 14:29:17 [LOGON] SamLogon: Network logon of MYDOMAINms-user from Returns
0xC000006A
05/16 14:29:31 [LOGON] SamLogon: Network logon of MYDOMAINms-user from Returns
0xC000006A
Assim, obtivemos 5 tentativas de autenticação com senha incorreta (0xC00006A) em um intervalo de 1 hora.
De volta à captura de rede e confirmado que um filtro em cima do protócolo em questão não seria suficiente, optei por alterar o filtro para procurar especificamente o nome do usuário, visto que todo processo de accounting e autenticação RADIUS realizado pelo NPS deve retornar um nome de usuário no pacote, assim, o filtro utilizado foi RADIUS.Attributes.AttributeUserName.UserName == "username":
![]()
Logo, encontrei todo tráfego que envolvia nosso usuário mydomainuser2,
inclusive, os timestamps das conversas que combinavam com os timestamps
encontrado no netlogon.log. Vale ressaltar que o dispositivo que estava
enviando as credenciais ao NPS era um dos Wireless Controllers do cliente,
entretanto, este Wireless Controller apenas estava fazendo o trabalho de
direcionar a credencial para validação. Expandindo os frames encontrei o
verdadeiro dispositivo que envia as credenciais:
![]()
Todos os pacotes de autenticação enviados ao NPS, estavam sendo solicitados por um dispositivo cujo MAC Address possui o prefixo E8-50-8B, ou seja, um dos prefixos utilizados pela Samsung. Este dispositivo pode ser um tablet ou smartphone, dificilmente um laptop, visto que se fosse e possuísse Windows instalado, provavelmente teriamos seu hostname listado nos logs do netlogon ou mesmo no Event Viewer.
Conclusão
Daqui em diante a análise deve seguir por parte do cliente junto à sua equipe de redes, de modo a analisar informações do lado de seu Wireless Controller ou Access Points em busca do IP de origem da credencial, ou simplesmente filtrar o MAC Address identificado.
Agradecimentos
Gostaria de agradecer ao Renato Pagan e ao Bruno Portela por sua ajuda inestimável ao longo deste incidente. Não só forneceram informações sobre alguns conceitos do NPS, mas também foram importantes ouvintes em momentos em que um brainstorm se fez necessário.
