Por: Yuri Diógenes

 

1. Introdução

 

Duas semanas atrás escrevi o que foi a parte 1 deste artigo, porém naquele momento nem imaginava que existiria a parte 2. Conforme dito na introdução passada este é um tema que está cada vez mais em uso em grandes empresas.

 

O cenário passado foi baseado em um incidente de suporte, assim como este. Até parecia a seqüência lógica dos fatos, pois tecnicamente falando a forma de acessar o ambiente e iniciar a resolução do problema foi bem parecida, porém o desfecho foi outro.

 

Vejamos então do que se trata tal problema.

 

2. Cenário

 

O cliente queria apenas usar autenticação de computador fazendo uso de certificados digitais. Foi feito uma distribuição de configuração dos parâmetros da rede sem fio através da política do Active Diretctory onde todos os computadores já tinham o certificado digital. Porém mesmo após o certificado ter sido distribuído havia uma falha na autenticação dos computadores. Caso o cliente alterasse o método de autenticação para usuário, então o processo finalizava com sucesso.

 

 

 

Figura 1 – Método de autenticação usado na política.

 

 

3. Coletando Dados

 

Para fins de resolução de problemas isolamos um notebook para ser usado como teste. Em seguida os passos abaixo foram realizados:

 

1.    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 habilita o log detalhado de eventos. Os logs ficam localizados na pasta %systemroot%\tracing.

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

 

 

3.1. Análise dos Logs

 

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.

 

- Dados do RASTLS.LOG:

[1468] 10:02:10:520: EapTlsBegin(host/nbtxp.ctest.com)

[1468] 10:02:10:520: State change to Initial

[1468] 10:02:10:520: EapTlsBegin: Detected 8021X authentication

[1468] 10:02:10:520: MaxTLSMessageLength is now 16384

[1468] 10:02:10:520:

[1468] 10:02:10:520: EapTlsMakeMessage(host/nbtxp.ctest.com)

[1468] 10:02:10:520: >> Received Request (Code: 1) packet: Id: 5, Length: 6, Type:

13, TLS blob length: 0. Flags: S

[1468] 10:02:10:520: EapTlsCMakeMessage

[1468] 10:02:10:520: EapTlsReset

[1468] 10:02:10:520: State change to Initial

[1468] 10:02:10:520: GetCredentials

[1468] 10:02:10:520: Flag is Machine Auth and Store is local Machine

[1468] 10:02:10:520: GetCachedCredentials

[1468] 10:02:10:520: OpenThreadToken Failed with Error 0x3f0

[1468] 10:02:10:520: FreeCachedCredentials

[1468] 10:02:10:520: AssociatePinWithCertificate

[1468] 10:02:10:520: CertGetCertificateContextProperty failed: 0x80092004

 

Se você leu o primeiro artigo observará que quando a autenticação é de usuário o formato é diferente. Como está é uma autenticação de computador, o formato tem o nome HOST antes do nome completo do computador. Ao final recebemos um erro no resultado da chamada da função CertGetCertificateContextProperty. Essa função tem como objetivo obter as informações contidas nas propriedades estendidas do certificado. A função deveria retornar TRUE (Verdadeiro) caso funcione ou FALSE (Falso) caso não funcione. Quando não funciona existe uma lista de possíveis erros e entre temos o erro CRYPT_E_NOT_FOUND.

 

Em suma, quando temos o erro “0x80092004” no log do RASTLS conforme mostrado acima, o que de fato temos é o retorno CRYPT_E_NOT_FOUND, que significa dizer que o certificado não tinha uma determinada propriedade. Baseado nisso já tínhamos ciência que o problema era no certificado de computador.

 

Para maiores informações sobre a função CertGetCertificateContextProperty veja o artigo “CertGetCertificateContextProperty (4 Parameters) function” no Microsoft MSDN.

 

- Resultado do arquivo EAPOL.LOG

[1316] 14:14:50:335: EKU: Autenticação do servidor
[1316] 14:14:50:335: EKU: Autenticação de cliente
[1316] 14:14:50:335: EKUUsage: Autenticação do servidor, Autenticação de cliente
[1316] 14:14:50:335: EAPSTATE_Working
[1316] 14:14:50:335: ElEapDllWork called for EAP Type 13
[1316] 14:14:50:335: EapDLLMakeMessage for type 13 returned -2146885628
[1316] 14:14:50:335: ElEapWork: ElEapMakeMessage returned error -2146885628
[1316] 14:14:50:335: FSMAuthenticating: Error in ElEapWork -2146885628

 

O código de erro retornado no arquivo EAPOL aponta para a mesma causa, ou seja o erro 2146885628 basicamente tem o mesmo significado do erro apresentado no RASTLS.LOG.

 

4. Resolução

 

Revisando as premissas que asseguram um logon de computador correto chegamos a dois requisitos neste tipo de cenário:

·         A estação precisa ter um certificado com propósito de autenticação do cliente (Client Authentication certificate purpose), também conhecido como EKU (Enhanced Key Usage) ou OID 1.3.6.1.5.5.7.3.2

·         E também precisa conter um UPN de uma conta válida ou um FQDN válido de uma conta de computador para ser usado na propriedade “Subject Alternative Name” do certificado.

 

 

Figura 2 – O propósito do certificado criado para autenticação de computador precisa ser do formato mostrado acima (Cliente Authentication / Server Authentication).

 

Após revisão do certificado criado e emitido pelo cliente para as estações, e o mesmo não atendia o segundo requisito citado, no caso dele a opção abaixo estava marcada:

 

 

Figura 3 – Cenário incorreto e cenário correto para criação de um modelo de certificado para autenticação de computador.

 

Criamos um novo certificado para o computador, fizemos a instalação de tal certificado e após isso a autenticação foi realizada com sucesso.

 

Mais informações acerca dos pré-requisitos de certificado de autenticação verificar o artigo “Troubleshooting IEEE 802.11 Wireless Access with Microsoft Windows” no Microsoft Technet.