Compartilhar via


Utilize um cenário de teste de análise de log para solucionar problemas de autenticação Kerberos.

Este artigo usa uma implantação hipotética de cliente e servidor para demonstrar abordagens de solução de problemas de autenticação Kerberos.

Ambiente e configuração

  • O usuário "John" pertence ao contoso.com domínio.

  • Todos os servidores DNS (Sistema de Nomes de Domínio) do domínio são controladores de domínio.

  • João está conectado a um computador cliente configurado da seguinte maneira:

    • Nome e domínio: Client1.contoso.com

    • Sistema operacional: Windows 11

    • Navegador: Microsoft Edge

    • Aplicativo de monitoramento: Monitor de Rede (instalado do Microsoft Network Monitor)

    • Configuração de opções da Internet: todos os contoso.com sites pertencem à zona de intranet local

      Captura de tela das Propriedades da Internet mostrando que todos os sites 'contoso.com' estão na zona da intranet local.

  • No computador cliente, João se conecta a um servidor de destino configurado da seguinte maneira:

    • Nome e domínio: IISServer.contoso.com

    • Sistema operacional: Windows Server 2019

    • Serviço de destino: site que é executado no IIS (Serviços de Informações da Internet)

    • Conta de serviço de destino: a conta do computador (o serviço é executado no contexto de IISServer.contoso.com)

    • Porta de serviço de destino: porta TCP 80

    • Configuração de autenticação (configurada no Gerenciador de Serviços de Informações da Internet):

      • A Autenticação do Windows está habilitada.

        Captura de tela da janela do Gerenciador de Serviços de Informações da Internet mostrando que a Autenticação do Windows está habilitada.

      • A lista de provedores de autenticação habilitados inclui o Negotiate, conforme mostrado na seguinte captura de tela:

        Captura de tela da janela Provedores mostrando que os Provedores Ativados incluem Negotiate.

    • Configuração de auditoria de logon: a auditoria de Sucesso de Logon e a auditoria de Falha de Logon estão habilitadas.

      Observação

      Por padrão, todos os sistemas operacionais do Windows Server têm a auditoria de logon de êxito e falha habilitada. Para verificar essa configuração, abra uma janela do Prompt de Comando administrativo e execute o seguinte comando:

      auditpol /get /Subcategory:"logon"
      

      Se a configuração estiver habilitada, esse comando gerará a seguinte saída:

      System audit policy
      Category/Subcategory                    Setting
      Logon/Logoff
        Logon                                 Success and Failure
      

      Se você não vir esse resultado, execute o seguinte comando para habilitar o registro de auditoria de sucesso e falha:

      auditpol /set /subcategory:"Logon" /Success:enable /Failure:enable
      

Fluxo de autenticação esperado

O diagrama a seguir mostra a sequência de mensagens de solicitação e resposta Kerberos e os caminhos dessas mensagens no ambiente descrito na seção anterior.

Captura de tela de um fluxo de autenticação.

O processo começa quando o usuário John, que está conectado ao computador Client1.contoso.comcliente, abre um navegador do Microsoft Edge e se conecta ao IISServer.contoso.com.

A etapa 1 ocorre no computador cliente e inclui as seguintes etapas:

  1. O serviço de resolvedor DNS armazena IISServer.contoso.com em cache para verificar se essas informações já estão armazenadas em cache.
  2. O serviço de resolvedor DNS verifica o arquivo HOSTS (C:\Windows\System32\drivers\etc\Hosts) para qualquer mapeamento de IISServer.contoso.com.
  3. O serviço cliente DNS envia uma consulta DNS para o servidor DNS preferencial (conforme configurado nas configurações de IP).

A etapa 2 ocorre no servidor DNS (controlador de domínio) e inclui as seguintes etapas:

  1. O serviço de servidor DNS verifica suas zonas configuradas, localiza o registro "A" do host e resolve IISServer.contoso.com para o endereço IP 192.168.2.104.
  2. O servidor DNS retorna o endereço IP para o computador cliente.

A etapa 3 ocorre no computador cliente e inclui as seguintes etapas:

  1. O computador cliente realiza um handshake TCP de três vias com IISServer.contoso.com usando a porta TCP 80.
  2. O computador cliente envia uma solicitação HTTP anônima para IISServer.contoso.com.

A etapa 4 ocorre no servidor de destino e inclui as seguintes etapas:

  1. O serviço Web (em execução como IISServer.contoso.com) recebe a solicitação de Client1.contoso.com.
  2. O serviço Web envia uma mensagem de resposta para Client1.contoso.com a qual contém uma resposta de desafio "HTTP 401". a mensagem especifica Negociar como o provedor de autenticação preferencial e o NTLM como o provedor de autenticação secundário.

A etapa 5 ocorre no computador cliente e inclui as seguintes etapas:

  1. O computador cliente recebe a mensagem de resposta ao desafio de IISServer.contoso.com.
  2. O processo do Microsoft Edge verifica se IISServer.contoso.com pertence à zona de intranet local. Portanto, o processo de autenticação deve usar Kerberos em vez de NTLM.
  3. O processo do Microsoft Edge chama LSASS.exe para procurar um tíquete de serviço para IISServer.contoso.com.
  4. Nesse caso, o computador cliente não tem um tíquete de serviço apropriado. O processo do Microsoft Edge envia uma solicitação ao KDC (Centro de Distribuição Kerberos) para um tíquete.

A etapa 6 ocorre no controlador de domínio e inclui as seguintes etapas:

  1. O controlador de Client1.contoso.com domínio (serviço KDC) recebe a solicitação e pesquisa o serviço que usa o SPN HTTP\IISServer.contoso.com (ou HOST\IISServer.contoso.com).
  2. O controlador de domínio identifica o serviço solicitado como o serviço Web executado no contexto de IISServer.contoso.com.
  3. O controlador de domínio envia uma resposta ao computador cliente que inclui um tíquete de serviço para o IISServer.contoso.com serviço Web.

A etapa 7 ocorre no controlador de domínio e inclui as seguintes etapas:

  1. O processo do Microsoft Edge cria uma mensagem AP (Protocolo de Aplicativo Kerberos) que inclui o tíquete de serviço.
  2. O processo do Microsoft Edge envia a mensagem AP para IISServer.contoso.com em resposta à mensagem de resposta do desafio "HTTP 401".

A etapa 8 ocorre no servidor Web e inclui as seguintes etapas:

  1. O processo do IIS consulta o processo local LSASS.exe.
  2. O processo LSASS.exe descriptografa o tíquete e, em seguida, cria um token para o usuário que inclui um ID de Sessão e as associações de grupo de John.
  3. O processo LSASS.exe retorna um identificador do token para o processo do IIS.
  4. O processo do IIS verifica as informações do grupo no token para garantir que João tenha permissão para acessar a página solicitada.
  5. O processo do IIS envia a página solicitada para o navegador.

Usar o Monitor de Rede para registrar um teste de autenticação

Use as etapas a seguir para coletar dados de rastreamento em um ambiente semelhante ao descrito na seção Ambiente e configuração . Durante esse teste, os componentes do sistema devem interagir da maneira descrita na seção fluxo de autenticação esperada .

Observação

Para usar os procedimentos nesta seção, você deve pertencer ao grupo de Administradores local:

  1. No computador cliente, abra uma janela do Prompt de Comando administrativo e execute ipconfig /flushdns.
  2. Abra o Monitor de Rede e inicie a gravação.
  3. Abra o Microsoft Edge. Na barra de endereços, insira http://iisserver.contoso.com.
  4. Quando a operação do Microsoft Edge for concluída, pare de gravar no Monitor de Rede.

Examinar os dados gerados pelo teste de autenticação

O teste de autenticação gera as seguintes informações:

  • Dados de rastreamento do Monitor de Rede
  • Dados do tíquete
  • Dados de eventos de Sucesso de Auditoria e Falha de Auditoria para eventos de autenticação

O restante desta seção fornece mais detalhes sobre quais dados o fluxo de autenticação produz.

Examinar os dados de rastreamento para eventos significativos

Nos dados de rastreamento, procure informações semelhantes aos seguintes trechos de rastreamento:

  • Consulta DNS ao controlador de domínio para o registro "A" do host paraIISServer.contoso.com:

    3005    00:59:30.0738430    Client1.contoso.com    DCA.contoso.com    DNS    DNS:QueryId = 0x666A, QUERY (Standard query), Query  for iisserver.contoso.com of type Host Addr on class Internet
    
  • Resposta DNS do serviço DNS no controlador de domínio:

    3006    00:59:30.0743438    DCA.contoso.com    Client1.contoso.com    DNS    DNS:QueryId = 0x666A, QUERY (Standard query), Response - Success, 192.168.2.104
    
  • Solicitação anônima do processo do Microsoft Edge em Client1.contoso.com para o servidor IIS em IISServer.contoso.com.

    3027    00:59:30.1609409    Client1.contoso.com    iisserver.contoso.com    HTTP    HTTP:Request, GET /
    Host:  iisserver.contoso.com
    
  • Mensagem de resposta de desafio HTTP 401 de IISServer.contoso.com para Client1.contoso.com:

    3028    00:59:30.1633647    iisserver.contoso.com    Client1.contoso.com    HTTP    HTTP:Response, HTTP/1.1, Status: Unauthorized, URL: /favicon.ico Using Multiple Authetication Methods, see frame details
    
    WWWAuthenticate: Negotiate
    WWWAuthenticate: NTLM
    
  • Solicitação de tíquete de serviço de Client1.contoso.com para o controlador de domínio DCA.contoso.com para o serviço que usa HTTP/iisserver.contoso.com como seu SPN (também conhecido como a solicitação de TGS):

    3034    00:59:30.1834048    Client1.contoso.com    DCA.contoso.com    KerberosV5    KerberosV5:TGS Request Realm: CONTOSO.COM Sname: HTTP/iisserver.contoso.com
    
  • A resposta do tíquete de serviço proveniente de DCA.contoso.com inclui o tíquete de serviço para IISServer.contoso.com (também conhecido como a mensagem de resposta do TGS):

    3036    00:59:30.1848687    DCA.contoso.com    Client1.contoso.com    KerberosV5    KerberosV5:TGS Response Cname: John 
    Ticket: Realm: CONTOSO.COM, Sname: HTTP/iisserver.contoso.com
    Sname: HTTP/iisserver.contoso.com
    
  • Segunda solicitação do processo do Microsoft Edge de Client1.contoso.com para IISServer.contoso.com. Esta mensagem inclui o tíquete de serviço:

    3040    00:59:30.1853262    Client1.contoso.com    iisserver.contoso.com    HTTP    HTTP:Request, GET /favicon.ico , Using GSS-API Authorization
    Authorization: Negotiate
    Authorization:  Negotiate YIIHGwYGKwYBBQUCoIIHDzCCBwugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBtUEggbRYIIGzQYJKoZIhvcSAQICAQBugga8MIIGuKADAgEFoQMCAQ6iBwMFACAAAACjggTvYYIE6zCCBOegAwIBBaENGwtDT05UT1NPLkNPTaIoMCagAwIBAqEfMB0bBEhUVFAbF
    SpnegoToken: 0x1
    NegTokenInit: 
    ApReq: KRB_AP_REQ (14)
    Ticket: Realm: CONTOSO.COM, Sname: HTTP/iisserver.contoso.com
    
  • Mensagem do servidor do IIS para Client1.contoso.com. Esta mensagem indica que o usuário está autenticado e autorizado:

    3044    00:59:30.1875763    iisserver.contoso.com    Client1.contoso.com    HTTP    HTTP:Response, HTTP/1.1, Status: Not found, URL: / , Using GSS-API Authentication
    WWWAuthenticate: Negotiate oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuIF62dHj2/qKDRV5XjGKmyFl2/z6b9OHTCTKigAatXS1vZTVC1dMvtNniSN8GpXJspqNvEfbETSinF0ee7KLaprxNgTYwTrMVMnd95SoqBkm/FuY7WbTAuPvyRmUuBY3EKZEy
    NegotiateAuthorization: 
    GssAPI: 0x1
    NegTokenResp: 
    ApRep: KRB_AP_REP (15)
    

Examine as informações do tíquete no computador cliente

Em um prompt de comando no computador cliente, execute klist tickets. A saída deve ser semelhante ao seguinte trecho:

Client: John @ CONTOSO.COM
Server: HTTP/iisserver.contoso.com @ CONTOSO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/28/2022 0:59:30 (local)
End Time:   11/28/2022 10:58:56 (local)
Renew Time: 12/5/2022 0:58:56 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DCA.contoso.com

Examinar eventos de auditoria no servidor de destino

No Visualizador de Eventos em IISServer.contoso.com, vá para os Logs do Windows> no log de Segurança para revisar os eventos de entrada (logon). Procure instâncias da ID do evento 4624 ou 4625 e verifique os seguintes campos:

  • Palavras-chave: Sucesso de Auditoria ou Falha de Auditoria
  • Tipo de logon: 3 (logon de rede)
  • ID de segurança no novo campo Logon : Contoso\John
  • Endereço de rede de origem: endereço IP do computador cliente
  • Processo de logon e pacote de autenticação: Kerberos

O texto completo do registro de evento é semelhante ao seguinte trecho:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          11/28/2022 12:59:30 AM
Event ID:      4624
Task Category: Logon
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      IISServer.contoso.com
Description:
An account was successfully logged on.

Subject:
    Security ID:        NULL SID
    Account Name:        -
    Account Domain:        -
    Logon ID:        0x0

Logon Information:
    Logon Type:        3
    Restricted Admin Mode:    -
    Virtual Account:        No
    Elevated Token:        No

Impersonation Level:        Impersonation

New Logon:
    Security ID:        CONTOSO\John
    Account Name:        John
    Account Domain:        CONTOSO.COM
    Logon ID:        0x1B64449
    Linked Logon ID:        0x0
    Network Account Name:    -
    Network Account Domain:    -
    Logon GUID:        {<GUID>}

Process Information:
    Process ID:        0x0
    Process Name:        -

Network Information:
    Workstation Name:    -
    Source Network Address:    192.168.2.101
    Source Port:        52655

Detailed Authentication Information:
    Logon Process:        Kerberos
    Authentication Package:    Kerberos

Solucionar problemas do fluxo de trabalho de autenticação

Examine os rastreamentos de rede para observar qual etapa falha para que você possa restringir o local no processo em que o problema ocorre. Use essas informações para determinar quais métodos de solução de problemas podem ajudá-lo a corrigir o problema.

Verificar a conectividade de rede

Se parece haver um problema nas comunicações DNS ou TCP, verifique as seguintes interações:

  • Verifique se você pode resolver o nome do servidor de destino (IISServer.contoso.com) do computador cliente (Client1.contoso.com).

  • Verifique se o servidor DNS resolve corretamente o endereço IP do servidor de destino. Para fazer isso, abra uma janela do PowerShell e execute o seguinte cmdlet:

    Resolve-DnsName -Name IISServer.contoso.com
    

    A saída desse cmdlet deve ser semelhante ao seguinte trecho:

    Name                                       Type   TTL   Section    IPAddress
    ----                                       ----   ---   -------    ---------
    IISServer.contoso.com                      A      1200  Answer     192.168.2.104
    
  • Verifique se as portas de rede necessárias estão abertas entre o computador cliente e o servidor de destino. Para fazer isso, execute o seguinte cmdlet:

    Test-NetConnection -Port 80 IISServer.contoso.com 
    

    A saída desse cmdlet deve ser semelhante ao seguinte trecho:

    ComputerName     : IISServer.contoso.com
    RemoteAddress    : 192.168.2.104
    RemotePort       : 80
    InterfaceAlias   : Ethernet 2
    SourceAddress    : 192.168.2.101
    TcpTestSucceeded : True
    

Verificar as informações do tíquete no computador cliente

  1. Abra uma janela padrão do Prompt de Comando (em vez de uma janela do Prompt de Comando administrativo) no contexto do usuário que está tentando acessar o site.

  2. Execute os seguintes comandos, na ordem fornecida:

    klist purge
    klist get http/iisserver.contoso.com
    

    A saída desses comandos deve ser semelhante ao seguinte trecho:

    Current LogonId is 0:0xa8a98b
    A ticket to http/iisserver.contoso.com has been retrieved successfully.
    
    Cached Tickets: (2)
    
    #0>     Client: John @ CONTOSO.COM
            Server: krbtgt/CONTOSO.COM @ CONTOSO.COM
            KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
            Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
            Start Time: 11/28/2022 1:28:11 (local)
            End Time:   11/28/2022 11:28:11 (local)
            Renew Time: 12/5/2022 1:28:11 (local)
            Session Key Type: AES-256-CTS-HMAC-SHA1-96
            Cache Flags: 0x1 -> PRIMARY
            Kdc Called: DCA.contoso.com
    
    #1>     Client: John @ CONTOSO.COM
            Server: http/iisserver.contoso.com @ CONTOSO.COM
            KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
            Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
            Start Time: 11/28/2022 1:28:11 (local)
            End Time:   11/28/2022 11:28:11 (local)
            Renew Time: 12/5/2022 1:28:11 (local)
            Session Key Type: AES-256-CTS-HMAC-SHA1-96
            Cache Flags: 0
            Kdc Called: DCA.contoso.com
    

    Este excerto indica que o tíquete foi recuperado com sucesso. Os detalhes do tíquete são rotulados "#1>" na seção Tíquetes Armazenados em Cache.

Verifique se o serviço Web do IIS está em execução no servidor IIS usando as credenciais padrão

Abra uma janela padrão do Prompt do PowerShell (em vez de uma janela administrativa do Prompt do PowerShell) no contexto do usuário que está tentando acessar o site:

invoke-webrequest -Uri http://IIsserver.contoso.com -UseDefaultCredentials

A saída desses comandos deve ser semelhante ao seguinte trecho:

StatusCode        : 200
StatusDescription : OK
Content           : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
                    <html xmlns="http://www.w3.org/1999/xhtml">
                    <head>
                    <meta http-equiv="Content-Type" cont...
RawContent        : HTTP/1.1 200 OK
                    Persistent-Auth: true
                    Accept-Ranges: bytes
                    Content-Length: 703
                    Content-Type: text/html
                    Date: Mon, 28 Nov 2022 09:31:40 GMT
                    ETag: "3275ea8a1d91:0"
                    Last-Modified: Fri, 25 Nov 2022...

Examinar o log de eventos de segurança no servidor de destino

No Visualizador de Eventos no servidor de destino, vá para o log de Logs do Windows > Segurança. Procure por instâncias do ID do evento 4624 (Sucesso de Auditoria) ou 4625 (Falha de Auditoria).

Verifique se outros serviços funcionam corretamente

Para verificar se outros serviços no servidor de destino podem processar a autenticação Kerberos, siga estas etapas:

  1. No servidor de destino, crie um compartilhamento de arquivos ou identifique um compartilhamento de arquivos existente a ser usado para teste. Certifique-se de que você (na função de "João") tenha permissão de leitura na pasta correta.

  2. No computador cliente, entre (como o usuário "John" e abra o Windows Explorer.

  3. Na barra de endereços, insira \\IISServer.contoso.com \Software$.

  4. No servidor de destino, abra o Visualizador de Eventos e examine os eventos de segurança. Verifique se há novos eventos com o ID 4624 ou 4625.

  5. No computador cliente, execute o klist tickets comando no prompt de comando. A saída do comando deve incluir um tíquete de serviço para CIFS/IISServer.contoso.com, conforme mostrado no seguinte trecho:

    #1>     Client: John @ CONTOSO.COM
            Server: cifs/iisserver.contoso.com @ CONTOSO.COM
            KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
            Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
            Start Time: 11/28/2022 1:40:22 (local)
            End Time:   11/28/2022 11:28:11 (local)
            Renew Time: 12/5/2022 1:28:11 (local)
            Session Key Type: AES-256-CTS-HMAC-SHA1-96
            Cache Flags: 0
            Kdc Called: DCA.contoso.com