Entender o registro do AnyConnect Network Access Manager

Introdução

Este documento descreve como habilitar o registro do AnyConnect Network Access Manager (NAM), bem como coletar e interpretar os registros. Os exemplos incluídos no documento descrevem diferentes cenários de autenticação e os registros que refletem as etapas realizadas pelo Network Access Manager para autenticar o cliente.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Habilitar log do NAM

Se for identificado um problema que possa estar relacionado ao módulo NAM, a primeira etapa é ativar o recurso de registro em log estendido. Isso deve ser feito no endpoint do cliente enquanto o módulo NAM estiver em execução.

Etapa 1. Abra a janela do AnyConnect e verifique se ela está em foco.

Etapa 2. Pressione esta combinação de teclas, Shift Esquerda + Alt Esquerda + L. Não há resposta.

Etapa 3. Clique com o botão direito no ícone do AnyConnect na bandeja do sistema do Windows. Um menu é exibido.

Etapa 4. Selecione Extended Logging para que uma marca de seleção seja exibida. O NAM agora registra mensagens de depuração detalhadas.

Configurar a captura de pacotes NAM

Quando o Registro Estendido está ativado, o NAM também mantém um buffer de captura de pacotes ativo. O buffer é limitado por padrão a cerca de 1MB. Se a captura de pacotes for necessária, talvez seja vantajoso aumentar o tamanho do buffer para capturar mais atividades. Para estender o buffer, um arquivo de configuração XML deve ser modificado manualmente.

Etapa 1. No PC com Windows, navegue até:
C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Network Access Manager\system\

Etapa 2. Abra o arquivo internalConfiguration.xml.

Etapa 3. Localize a marca XML <packetCaptureFileSize>1</packetCaptureFileSize> e ajuste o valor para 10 para um tamanho de buffer de 10 MB e assim por diante.

Etapa 4. Reinicialize o PC cliente para que a alteração tenha efeito.

Coleta de logs

A coleta de registros do NAM é feita por meio da ferramenta de diagnóstico e relatório (DART), que é um módulo do conjunto AnyConnect. No instalador, selecione um módulo e use o ISO de instalação completa do AnyConnect para instalar. O instalador do Cisco Media Services Interface (MSI) também pode ser encontrado dentro do ISO.

Depois de ativar o Registro estendido e executar um teste, basta executar o DART e passar pela caixa de diálogo, o pacote de registro está localizado por padrão na área de trabalho do Windows.

Além do pacote DART, o registro de mensagens do NAM também é útil para localizar os dados relevantes no registro do NAM. Para localizar o registro de mensagens do NAM, navegue até a janela de configurações do AnyConnect > Gerenciador de acesso à rede > Histórico de mensagens. O registro de mensagens contém o carimbo de data/hora de cada evento de conexão de rede, que pode ser usado para localizar os registros relevantes para o evento.

Leitura de registros NAM

Os logs do NAM, especialmente depois que você habilita o Log Estendido, contêm uma grande quantidade de dados, a maioria dos quais é irrelevante e pode ser ignorada. Esta seção lista as linhas de depuração para demonstrar cada etapa que o NAM executa para estabelecer uma conexão de rede. Quando você trabalha em um registro, essas frases-chave podem ser úteis para localizar parte do registro relevante para o problema. 

Resumo de log de uma conexão de rede sem autenticação 802.1x habilitada

2016 17:20:37.974 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network test123: AccessStateMachine current state = ACCESS_STOPPED, received userEvent = START

Explicação: isso indica que o usuário selecionou uma rede no módulo NAM e que o NAM recebeu um userEvent de START.

538: TESTPC: May 16 2016 17:20:37.974 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network test123: AccessStateMachine new state = ACCESS_STARTED
539: TESTPC: May 16 2016 17:20:37.974 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network test123: NetworkStateMachine current state USER_T_DISCONNECTED, received access event ACCESS_STARTED

Explicação: a máquina de estado de acesso e a máquina de estado de rede foram iniciadas.

545: TESTPC: May 16 2016 17:20:37.974 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Ipv4 {EFDAF0F0-CF25-4D88-B125-E748CD539DFF}: received Cancel event [state: COMPLETE]

Explicação: A instância IPv4 foi cancelada para redefinir os estados.

547: TESTPC: May 16 2016 17:20:37.974 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: starting makeMatches...
549: TESTPC: May 16 2016 17:20:37.989 +0600: %NAM-6-INFO_MSG: %[tid=1412]: matching adapter {484E4FEF-392C-436F-97F0-CD7206CD7D48} and network test123 ...

Explicação: O adaptador com a ID 484E4FEF-392C-436F0-CD7206CD7D48 foi selecionado para se conectar à rede test123, que é o nome da conexão de rede configurada no NAM.

551: TESTPC: May 16 2016 17:20:37.989 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network test123: AccessStateMachine new state = ACCESS_ATTACHED
557: TESTPC: May 16 2016 17:20:37.989 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network test123: AccessStateMachine current state = ACCESS_ATTACHED, received userEvent = CONNECT

Explicação: O NAM conectou com êxito o adaptador a esta rede. Agora, o NAM tenta se associar (conectar) a esta rede (que por acaso é sem fio):

561: TESTPC: May 16 2016 17:20:37.989 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: ACE: adapter SM current: state(STATE_DISCONNECTED_LINK_DOWN), event(EVENT_CONNECT)
562: TESTPC: May 16 2016 17:20:37.989 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: ACE: adapter SM state change: STATE_DISCONNECTED_LINK_DOWN -> STATE_ASSOCIATING
567: TESTPC: May 16 2016 17:20:37.989 +0600: %NAM-6-INFO_MSG: %[tid=1412]: Starting wifi connection, trying ssid test123 ...
568: TESTPC: May 16 2016 17:20:37.989 +0600: %NAM-6-INFO_MSG: %[tid=1412]: Connection Association Started(openNoEncryption)

Explicação: openNoEncryption indica que a rede está configurada como aberta. No Wireless Lan Controller, ele usa o MAC Authentication Bypass (MAB) para se autenticar.

234: TESTPC: May 16 2016 17:20:38.020 +0600: %NAMSSO-7-DEBUG_MSG: %[tid=1912]: waiting for cs...

Explicação: cs pode ser visto muito nos registros NAM. Esses registros são irrelevantes e devem ser ignorados.

575: TESTPC: May 16 2016 17:20:38.020 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network test123: NetworkStateMachine new state USER_T_DISCONNECTED 236: TESTPC: May 16 2016 17:20:38.020 +0600: %NAMSSO-7-DEBUG_MSG: %[tid=1912]: Tx CP Msg: <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ssc="http://www.cisco.com/ssc" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <networkStateEvent> <sequenceNumber>16</sequenceNumber> <groupName>Local networks</groupName> <networkName>test123</networkName> <networkState>Associating</networkState> <adapterName>Intel(R) Centrino(R) Ultimate-N 6300 AGN</adapterName> <serverVerifiedName></serverVerifiedName> </networkStateEvent> </SOAP-ENV:Body></SOAP-ENV:Envelope>
 

Explicação: essas são mensagens de Simple Object Access Protocol (SOAP) usadas para dizer ao AnyConnect GUI para exibir a mensagem de status da conexão, como Associating neste caso. Qualquer mensagem de erro exibida na janela NAM pode ser encontrada em uma das mensagens SOAP no registro, que pode ser usada para localizar o problema facilmente.

582: TESTPC: May 16 2016 17:20:38.020 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: {484E4FEF-392C-436F-97F0-CD7206CD7D48} - Received STATE_AUTHENTICATED
583: TESTPC: May 16 2016 17:20:38.020 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: ACE: adapter SM current: state(STATE_ASSOCIATING), event(EVENT_AUTH_SUCCESS)

Explicação: o NAM recebe um evento AUTH_SUCCESS, que induz em erro porque não há autenticação que tenha ocorrido no momento. Você recebe esse evento simplesmente porque se conecta a uma rede aberta, portanto, por padrão, a autenticação é bem-sucedida.

595: TESTPC: May 16 2016 17:20:38.738 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network test123: AccessStateMachine current state = ACCESS_ASSOCIATING, received adapterState = associated

Explicação: a associação ao Service Set Identifier (SSID) foi bem-sucedida; tempo para tratar a autenticação.

603: TESTPC: May 16 2016 17:20:38.754 +0600: %NAM-6-INFO_MSG: %[tid=1412][mac=1,6,3c:a9:f4:33:ab:50]: Authentication not required.
604: TESTPC: May 16 2016 17:20:38.754 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: ACE: adapter SM current: state(STATE_ASSOCIATED), event(EVENT_AUTH_SUCCESS)
605: TESTPC: May 16 2016 17:20:38.754 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: ACE: adapter SM state change: STATE_ASSOCIATED -> STATE_AUTHENTICATED

Explicação: Como esta é uma rede aberta, ela é autenticada por padrão. Neste ponto, o NAM está conectado à rede e agora inicia o processo DHCP:

610: TESTPC: May 16 2016 17:20:38.754 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: {484E4FEF-392C-436F-97F0-CD7206CD7D48} creating a new DHCP work
612: TESTPC: May 16 2016 17:20:38.754 +0600: %NAM-6-INFO_MSG: %[tid=1412][mac=1,6,3c:a9:f4:33:ab:50]: {484E4FEF-392C-436F-97F0-CD7206CD7D48}: DHCP: Sending DHCP request
613: TESTPC: May 16 2016 17:20:38.754 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: queueing DHCP work
642: TESTPC: May 16 2016 17:20:40.830 +0600: %NAM-7-DEBUG_MSG: %[tid=1448]: Ipv4 {484E4FEF-392C-436F-97F0-CD7206CD7D48}: connectivity test[03]: IP:10.201.230.196(255.255.255.224) GW:10.201.230.193 [Success]
643: TESTPC: May 16 2016 17:20:40.830 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Ipv4 {484E4FEF-392C-436F-97F0-CD7206CD7D48}: received Success event [state: WAIT_FOR_CONNECTIVITY]
645: TESTPC: May 16 2016 17:20:40.845 +0600: %NAM-6-INFO_MSG: %[tid=1412][mac=1,6,3c:a9:f4:33:ab:50]: {484E4FEF-392C-436F-97F0-CD7206CD7D48}: IP Address Received: 10.201.230.196
646: TESTPC: May 16 2016 17:20:40.845 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Ipv4 Connectivity Result: SUCCESS

Explicação: o NAM adquire com êxito um endereço IP.

648: TESTPC: May 16 2016 17:20:40.845 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: ACE: adapter SM current: state(STATE_AUTHENTICATED), event(EVENT_IP_CONNECTIVITY)
649: TESTPC: May 16 2016 17:20:40.845 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: ACE: adapter SM state change: STATE_AUTHENTICATED -> STATE_CONNECTED

Explicação: quando um endereço IP é recebido, o NAM enviará uma solicitação ARP (Address Resolution Protocol) ao gateway (Get-Connectivity). Uma vez recebida a resposta ARP, o cliente é conectado.

Registrar resumo de uma conexão de rede usando 802.1x e PEAP em rede com fio

1286: TESTPC: May 16 2016 17:55:17.138 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network WiredPEAP: AccessStateMachine new state = ACCESS_STARTED
 

Explicação: NAM começou a se conectar à rede WiredPEAP.

1300: TESTPC: May 16 2016 17:55:17.138 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Binding adapter Intel(R) 82579LM Gigabit Network Connection and user auth for network WiredPEAP
1303: TESTPC: May 16 2016 17:55:17.138 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network WiredPEAP: AccessStateMachine new state = ACCESS_ATTACHED
 

Explicação: o NAM associou um adaptador a esta rede.

1309: TESTPC: May 16 2016 17:55:17.138 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Network WiredPEAP: AccessStateMachine current state = ACCESS_ATTACHED, received userEvent = CONNECT
1342: TESTPC: May 16 2016 17:55:17.154 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: STATE (4) S_enterStateAux called with state = CONNECTING (dot1x_sm.c 142)
 

Explicação: O NAM começou a se conectar a esta rede com fio.

1351: TESTPC: May 16 2016 17:55:17.154 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: 8021X (4) Sent start frame (dot1x_sm.c 117)
 

Explicação: O cliente envia EAPOL_START.

1388: TESTPC: May 16 2016 17:55:17.154 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: PORT (3) net: RECV (status: UP, AUTO) (portMsg.c 658)
1389: TESTPC: May 16 2016 17:55:17.154 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: 8021X (4) recvd EAP IDENTITY frame (dot1x_util.c 264)
1397: TESTPC: May 16 2016 17:55:17.154 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) EAP State: EAP_STATE_IDENTITY (eap_auth_client.c 940)
 

Explicação: o cliente recebe a solicitação de identidade do switch e agora procura uma credencial para enviar de volta.

1406: TESTPC: May 16 2016 17:55:17.154 +0600: %NAM-7-DEBUG_MSG: %[tid=1464]: EAP-CB: credential requested: sync=8, session-id=1, handle=00AE1FFC, type=AC_CRED_SESSION_START
1426: TESTPC: May 16 2016 17:55:17.169 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: EAP: processing credential request: sync=8, session-id=1, eap-handle=00AE1FFC, eap-level=0, auth-level=0, protected=0, type=CRED_REQ_SESSION_START
1458: TESTPC: May 16 2016 17:55:17.169 +0600: %NAM-6-INFO_MSG: %[tid=1412]: Trying fast reauthentication for unprotected identity anonymous
1464: TESTPC: May 16 2016 17:55:17.169 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: EAP: credential request completed, response sent: sync=9
 

Explicação: Por padrão, o Anyconnect envia anonymous como identidade desprotegida (identidade externa), então aqui ele tenta anonymous e verá se o servidor está OK com ele. O fato de que a identidade é anônima em oposição a host/anônimo indica que é uma autenticação de usuário, em vez de autenticação de máquina.

1492: TESTPC: May 16 2016 17:55:17.185 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: 8021X (4) recvd EAP TLS frame (dot1x_util.c 293)
 

Explicação: o servidor RADIUS envia um quadro EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) sem nenhum conteúdo. Sua finalidade é negociar o protocolo EAP-TLS com o cliente.

1516: TESTPC: May 16 2016 17:55:17.185 +0600: %NAM-6-INFO_MSG: %[tid=1412]: EAP: EAP suggested by server: eapTls
1517: TESTPC: May 16 2016 17:55:17.185 +0600: %NAM-6-INFO_MSG: %[tid=1412]: EAP: EAP requested by client: eapPeap
1518: TESTPC: May 16 2016 17:55:17.185 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: EAP: EAP methods sent: sync=10
1519: TESTPC: May 16 2016 17:55:17.185 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: EAP: credential request 10: state transition: PENDING -> RESPONDED
 

Explicação: o NAM reconhece a solicitação do servidor para usar EAP-TLS, mas o cliente está configurado para usar o PEAP (Protected Extensible Authentication Protocol). Por esse motivo, o NAM envia de volta uma contraoferta para o PEAP.

1520: TESTPC: May 16 2016 17:55:17.185 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Auth[WiredPEAP:user-auth]: Authentication state transition: AUTH_STATE_UNPROTECTED_IDENTITY_SENT_FOR_FAST_REAUTHENTICATION -> AUTH_STATE_UNPROTECTED_IDENTITY_ACCEPTED
 

Explicação: o servidor RADIUS aceita a identidade externa/não protegida.

1551: TESTPC: May 16 2016 17:55:17.200 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: 8021X (4) recvd EAP PEAP frame (dot1x_util.c 305)
1563: TESTPC: May 16 2016 17:55:17.200 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) EAP-PEAP: SSL handshake start (eap_auth_tls_p.c 409)
 

Explicação: a parte protegida do PEAP (para estabelecer um túnel seguro para trocar credenciais internas) é iniciada depois que o cliente recebe uma confirmação do servidor RADIUS para continuar o uso do PEAP.

1565: TESTPC: May 16 2016 17:55:17.200 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) SSL STATE: SSLv3 write client hello A (eap_auth_tls_p.c 394)
1566: TESTPC: May 16 2016 17:55:17.200 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) SSL STATE: SSLv3 read server hello A (eap_auth_tls_p.c 394)
 

Explicação: o NAM envia uma mensagem de saudação de cliente encapsulada em EAP e aguarda a chegada da saudação de servidor. O hello do servidor contém o certificado ISE, portanto, leva algum tempo para concluir a transferência.

1622: TESTPC: May 16 2016 17:55:17.216 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: 8021X (4) recvd EAP PEAP frame (dot1x_util.c 305)
1632: TESTPC: May 16 2016 17:55:17.216 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) SSL STATE: SSLv3 read server hello A (eap_auth_tls_p.c 394)
1633: TESTPC: May 16 2016 17:55:17.216 +0600: %NAM-6-INFO_MSG: %[tid=1468][comp=SAE]: CERT (0) looking up: "/CN=ISE20-1.kurmai.com" (lookup.c 100)
1634: TESTPC: May 16 2016 17:55:17.232 +0600: %NAM-6-INFO_MSG: %[tid=1468][comp=SAE]: CERT (0) Certificate not found: "/CN=ISE20-1.kurmai.com" (lookup.c 133)
1646: TESTPC: May 16 2016 17:55:17.232 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) SSL_ERROR_WANT_X509_LOOKUP (eap_auth_tls_p.c 193)
 

Explicação: o NAM extraiu o nome da entidade do servidor ISE do certificado do servidor. Como ele não tem um certificado de servidor instalado no repositório de confiança, você não o encontra lá.

1649: TESTPC: May 16 2016 17:55:17.232 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (5) EAP_EVENT_CRED_REQUEST queued (eapCredProcess.c 496)
1650: TESTPC: May 16 2016 17:55:17.232 +0600: %NAM-7-DEBUG_MSG: %[tid=1464][comp=SAE]: EAP (5) EAP: CRED_REQUEST (eapMessage.c 355)
1662: TESTPC: May 16 2016 17:55:17.232 +0600: %NAM-6-INFO_MSG: %[tid=1412]: Getting credentials from logon.
1685: TESTPC: May 16 2016 17:55:17.232 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Auth[WiredPEAP:user-auth]: ...resumed
 

Explicação: o NAM procura que a identidade interna/protegida seja enviada ao servidor RADIUS após o túnel ser estabelecido. Nesse caso, a opção "Usar automaticamente meu nome e senha de logon do Windows" foi ativada no adaptador com fio, de modo que o NAM usa as credenciais de logon do Windows em vez de solicitar as credenciais do usuário.

1700: TESTPC: May 16 2016 17:55:17.247 +0600: %NAM-7-DEBUG_MSG: %[tid=1464][comp=SAE]: EAP (0) SSL STATE: SSLv3 write client key exchange A (eap_auth_tls_p.c 394)
1701: TESTPC: May 16 2016 17:55:17.247 +0600: %NAM-7-DEBUG_MSG: %[tid=1464][comp=SAE]: EAP (0) SSL STATE: SSLv3 write change cipher spec A (eap_auth_tls_p.c 394)
1750: TESTPC: May 16 2016 17:55:17.278 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) SSL STATE: SSL negotiation finished successfully (eap_auth_tls_p.c 394)
1751: TESTPC: May 16 2016 17:55:17.278 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) EAP-PEAP: SSL handshake done (eap_auth_tls_p.c 425)
1752: TESTPC: May 16 2016 17:55:17.278 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) EAP-PEAP: New session. (eap_auth_tls_p.c 433)
1753: TESTPC: May 16 2016 17:55:17.278 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: EAP (0) EAP-PEAP: session cipher AES256-SHA. (eap_auth_tls_p.c 441)
 

Explicação: o NAM enviou a chave do cliente e a especificação da codificação para o servidor e recebeu a confirmação. A negociação SSL é bem-sucedida e um túnel é estabelecido.

1810: TESTPC: May 16 2016 17:55:17.294 +0600: %NAM-6-INFO_MSG: %[tid=1412]: Protected identity/(Username) sent.
1814: TESTPC: May 16 2016 17:55:17.294 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Auth[WiredPEAP:user-auth]: Authentication state transition: AUTH_STATE_UNPROTECTED_IDENTITY_ACCEPTED -> AUTH_STATE_PROTECTED_IDENTITY_SENT
1883: TESTPC: May 16 2016 17:55:17.310 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Auth[WiredPEAP:user-auth]: Authentication state transition: AUTH_STATE_PROTECTED_IDENTITY_SENT -> AUTH_STATE_PROTECTED_IDENTITY_ACCEPTED
 

Explicação: A identidade protegida é enviada ao servidor, que aceita a identidade. Agora o servidor solicita a senha.

1902: TESTPC: May 16 2016 17:55:17.310 +0600: %NAM-7-DEBUG_MSG: %[tid=1464][comp=SAE]: EAP (5) deferred password request (eapRequest.c 147)
1918: TESTPC: May 16 2016 17:55:17.310 +0600: %NAM-6-INFO_MSG: %[tid=1412]: Protected password sent.
1921: TESTPC: May 16 2016 17:55:17.325 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Auth[WiredPEAP:user-auth]: Authentication state transition: AUTH_STATE_PROTECTED_IDENTITY_ACCEPTED -> AUTH_STATE_CREDENTIAL_SENT
 

Explicação: o NAM recebe uma solicitação de senha e envia a senha ao servidor.

2076: TESTPC: May 16 2016 17:55:17.856 +0600: %NAM-7-DEBUG_MSG: %[tid=1412]: Auth[WiredPEAP:user-auth]: Authentication state transition: AUTH_STATE_CREDENTIAL_SENT -> AUTH_STATE_SUCCESS
2077: TESTPC: May 16 2016 17:55:17.856 +0600: %NAM-7-DEBUG_MSG: %[tid=1468][comp=SAE]: STATE (4) S_enterStateAux called with state = AUTHENTICATED (dot1x_sm.c 142)
 

Explicação: o servidor recebe a senha, verifica-a e envia EAP-Success. A autenticação é bem-sucedida neste ponto, e o cliente continua à medida que obtém o endereço IP do DHCP.