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:


 

















Valor


Descrição


0


Autenticação de computador é realizada quando o computador é ligado. Valor padrão para Windows XP sem Service Pack.


1


Faz autenticação de usuário e de computador no logon e faz autenticação de computador quando o usuário faz logoff. Valor padrão para XP SP1, SP2 e Windows Server 2003.


2


Apenas faz autenticação de computador, autenticação de usuário não é feita


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.


 

Comments (2)

  1. Anonymous says:

    Grande Luciano,

    Obrigado pela visita e pelo constante suporte na divulgagação do nosso Blog.

    Grande Abraço,

    Yuri Diógenes

  2. Luciano de Lima - MVP Windows Server says:

    Grande mestre Yuri!!!

    Parabéns pelo artigo ficou muito bom.

    Estarei anunciando no meu blog para que o pessoal venha ler mais esse excelente artigo.

    Um abraço,