Problemas durante autenticação 802.1x para redes sem fio

Por: Yuri Diógenes

1. Introdução

A tecnologia rede redes sem fio (Wireless) vem crescendo cada dia que passa e tornando-se cada vez mais realidade para os usuários de computadores pois tal tecnologia não está mais privada para uso em empresas, pois de fato está tornando-se cada vez mas difundido para usuários caseiros. Com está tecnologia extremamente difundida a gama de fornecedores de soluções wireless que temos no mercado torna-se normal problemas de compatibilidade, configuração e protocolo de comunicação.

O cenário a seguir é baseado em um incidente de suporte onde o administrador da rede estava tendo problemas para autenticar alguns usuários. A autenticação funcionava para todos outros usuários da rede, porém para estes 6 usuários em particular estávamos tendo problema.

2. Detalhamento do Ambiente

No que diz respeito a topologia de rede o cenário era o mostrado abaixo:

Figura 1 – Topologia de rede Wireless com clientes Windows XP.

Conforme mostrado na figura 1, a presença do domínio Windows NT (que não é mais suportado) neste cenário representa em parte a heterogeneidade do ambiente. No lado de infra-estrutura de rede Wireless 802.11 tínhamos equipamentos Cisco e no servidor membro tínhamos também o software Cisco Secure ACS para Windows.

Os usuários pertenciam ao domínio Windows Server 2003, todos localizados em uma única OU, a qual também tinham outros usuários que funcionavam corretamente.

Para adicionar mais segurança ao ambiente, o cliente implementou o método de autenticação 802.1X para redes Wireless. Este método tem como base a tecnologia 802.1X para redes com fio, ou seja, redes com cabeamento. A tecnologia 802.1X do IEEE é utilizada para garantir autenticação no nível de switch ethernet (camada 2), com isso a porta ethernet na switch, a qual o computador está conectado, ficará bloqueada até que a autenticação seja feita com sucesso e o acesso seja garantido. Esta tecnologia foi portada para redes sem fio para garantir esta camada de segurança durante a conexão de um novo computador que usa o padrão 802.11.

O método de autenticação em uso pelo cliente era o EAP-TLS, que exige um certificado válido para autenticação. O cliente tinha no ambiente uma entidade certificadora (CA) privada que emitiu os certificados para os computadores, devido ao cliente ter optado por fazer uma autenticação via conta de computador.

Para maiores informações sobre a tecnologia 802.1X veja o artigo “Understanding 802.1X authentication for wireless networks” no Microsoft Technet.

3. Coletando Dados

Como tínhamos apenas seis usuários com problema o primeiro passo foi obter um dump usando o LDIFDE de uma conta de usuário que funciona para o usuário que não funciona para verificar se os atributos estavam corretos. Para fazer isso é usado o comando:

ldifde -f C:\User.ldf -d "DN" -p base

O nome DN significa “Distinguished Name” de onde o usuário está localizado no AD. Para identificar isso você pode usuar a ferramenta ADSIEdit, navegar até chegar a conta do usuário, clicar nas propriedades do mesmo e verificar o valor do atributo “Distinguished Name”. Para maiores informações ver o artigo “Using LDIFDE to import and export directory objects to Active Directory” no Microsoft Help and Support.

Após comparado os dois objetos não foi possível encontrar nenhuma discrepância de valores nos atributos essenciais para este tipo de autenticação.

Foi então a hora de iniciar o processo de captura dos dados, para isso o seguinte plano de ação foi executado:

1. Instalamos o network monitor no Windows XP (cliente), no servidor Windows Server 2003 e no servidor Membro Windows 2000;

2. Habilitamos o log detalhado de eventos relacionados a este tipo de autenticação no Windows XP através da execução do comando: netsh ras set tracing * enable. Este comando vai habilitar o log detalhado de eventos e todos os arquivos ficaram localizados na pasta %systemroot%\tracing.

3. Configuramos a switch a qual estava conectada o “Access Point” para fazer um “Port Mirror” para uma outra estação, de forma que pudéssemos também fazer a captura dos dados.

4. O usuário (CTEST\Bob) fez o logon a partir da máquina Windows XP para simular o problema.

Para fins comparativos a coleta foi realizada com um usuário que conseguia fazer o logon correto e outro que não conseguia.

3.1. Análise do Tráfego de Rede

Vejamos primeiramente o tráfego de rede esperado para um usuário que funciona, vejamos a seqüência:

1. CiscoAP WindowsXPMAC EAP Request, Identity

2. WindowsXPMAC CiscoAP EAP Response, Identity

3. CiscoAP WindowsXPMAC EAP Request, PEAP

4. WindowsXPMAC CiscoAP TLS Client Hello

5. CiscoAP WindowsXPMAC TLS Server Hello

6. WindowsXPMAC CiscoAP TLS Change Cipher Spec

7. CiscoAP WindowsXPMAC EAP Success

8. CiscoAP WindowsXPMAC TLS Application Data

Abrindo o cabeçalho EAP do pacote número 2 podemos verificar o usuário enviar as credenciais de logon:

802.1X Authentication

Version: 1

Type: EAP Packet (0)

Length: 22

Extensible Authentication Protocol

Code: Response (2)

Id: 1

Length: 22

Type: Identity [RFC3748] (1)

Identity (17 bytes): CTEST\Will

No cabeçalho EAP do pacote 7 temos o finalização da negociação com sucesso:

802.1X Authentication

Version: 1

Type: EAP Packet (0)

Length: 4

Extensible Authentication Protocol

Code: Success (3)

Id: 233

Length: 4

Agora que temos um parâmetro de comparação podemos verificar a negociação durante o problema de autenticação do usuário CTEST\Bob:

1. CiscoAP WindowsXPMAC EAP Request, Identity

2. WindowsXPMAC CiscoAP EAP Response, Identity

3. CiscoAP WindowsXPMAC EAP Request, PEAP

4. WindowsXPMAC CiscoAP TLS Client Hello

5. CiscoAP WindowsXPMAC TLS Server Hello

6. WindowsXPMAC CiscoAP TLS Change Cipher Spec

7. CiscoAP WindowsXPMAC EAP Request, Identity

8. WindowsXPMAC CiscoAP EAP Response, Identity

9. CiscoAP WindowsXPMAC EAP Request, PEAP

10. WindowsXPMAC CiscoAP TLS Client Hello

11. CiscoAP WindowsXPMAC TLS Server Hello

Note que o processo fica continuamente tentando autenticar o usuário sem sucesso. Porém no momento do teste o cliente revelou que: se nada for feito a conta do usuário é bloqueada no AD devido a existência de múltiplas tentativas sem sucesso de autenticação.

Isso é uma informação muito valiosa, pois significa dizer que a infra-estrutura está permitindo que o pacote cheque até o controlador de domínio para fazer a validação do usuário, porém por algum motivo as credenciais estão incorretas.

3.2. Análise dos Logs do Windows XP

Para entender melhor porque a autenticação não estava ocorrendo corretamente foi necessário revisar alguns artigos essenciais que fornecem informações detalhadas sobre o problema durante o logon na rede sem fio.

Os seguintes arquivos foram revisados: Wzctrace.log, Eapol.log, Netman.log e RASTLS.LOG. Para maiores informações sobre a funcionalidade destes arquivos ver o artigo “A Support Guide for Wireless Diagnostics and Troubleshooting” no Microsoft TechNet.

O arquivo RASTLS.LOG foi essencial obtenção dos dados necessários para entender onde o processo estava falhando, vejamos a diferença do arquivo para o usuário que funciona e para o que não funciona:

- Cenário que funciona:

[1244] 17:04:57:801: EapTlsBegin(CTEST\Will)

[1244] 17:04:57:801: State change to Initial

[1244] 17:04:57:801: EapTlsBegin: Detected 8021X authentication

[1244] 17:04:57:801: EapTlsBegin: Detected PEAP authentication

[1244] 17:04:57:801: MaxTLSMessageLength is now 16384

[1244] 17:04:57:801: EapPeapBegin done

[1244] 17:04:57:801: EapPeapMakeMessage

[1244] 17:04:57:801: EapPeapCMakeMessage

[1244] 17:04:57:801: PEAP:PEAP_STATE_INITIAL

[1244] 17:04:57:801: EapTlsCMakeMessage

[1244] 17:04:57:801: EapTlsReset

[1244] 17:04:57:801: State change to Initial

[1244] 17:04:57:801: GetCredentials

[1244] 17:04:57:801: Flag is Client and Store is Current User

[1244] 17:04:57:801: GetCachedCredentials

[1244] 17:04:57:801: PEAP GetCachedCredentials: Using cached credentials.

[1244] 17:04:57:801: MakeReplyMessage

[1244] 17:04:57:801: SecurityContextFunction

[1244] 17:04:57:801: InitializeSecurityContext returned 0x90312

[1244] 17:04:57:801: State change to SentHello

- Cenário que não funciona:

[2688] 16:58:02:568: EapTlsBegin(CTEST\Bob)

[2688] 16:58:02:568: State change to Initial

[2688] 16:58:02:568: EapTlsBegin: Detected 8021X authentication

[2688] 16:58:02:568: EapTlsBegin: Detected PEAP authentication

[2688] 16:58:02:568: MaxTLSMessageLength is now 16384

[2688] 16:58:02:568: EapPeapBegin done

[2688] 16:58:02:568: EapPeapMakeMessage

[2688] 16:58:02:568: EapPeapCMakeMessage

[2688] 16:58:02:568: PEAP:PEAP_STATE_INITIAL

[2688] 16:58:02:568: EapTlsCMakeMessage

[2688] 16:58:02:568: EapTlsReset

[2688] 16:58:02:568: State change to Initial

[2688] 16:58:02:568: GetCredentials

[2688] 16:58:02:568: Flag is Client and Store is Current User

[2688] 16:58:02:568: GetCachedCredentials

[2688] 16:58:02:568: FreeCachedCredentials

[2688] 16:58:02:568: No Cert Store. Guest Access requested

[2688] 16:58:02:568: No Cert Name. Guest access requested

[2688] 16:58:02:568: Will NOT validate server cert

[2688] 16:58:02:568: MakeReplyMessage

[2688] 16:58:02:568: SecurityContextFunction

[2688] 16:58:02:568: InitializeSecurityContext returned 0x90312

[2688] 16:58:02:568: State change to SentHello

[2688] 16:58:02:568: BuildPacket

Observer que o usuário é autenticado como Guest (Visitante). Uma vez isolado o problema seguimos para a fase final que foi a implementação e validação da solução.

4. Conclusão

Conforme descrito pelo cliente, eles não faziam uso de certificado de usuário, apenas de certificado de computador. Então forçamos o notebook a qual o usuário efetuava o logon para usar apenas autenticação de computador. Para isso a chave abaixo foi alterada:

HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global

Tipo: REGDWORD

Nome: AuthMode

Valor "2"

Os valores para esta chave são:

Referência da Tabela: Wireless LAN Support in Windows: Frequently Asked Questions

O valor AuthMode estava configurado para 1 (devido ao cliente ter XP SP2 na estação), com isso a autenticação de usuário era realizada e os certificados de usuários para estes seis usuários não estava correto. Porém, para o cliente o importante era autenticar o computador, assim a alteração desta chave foi mais otimizada que o endereçamento do problema do certificado do usuário.