Compartilhar via


Diretrizes de solução de problemas de autenticação Kerberos

Este guia fornece os conceitos fundamentais usados ao solucionar problemas de autenticação Kerberos.

Lista de verificação de solução de problemas

  • Um erro relacionado ao Kerberos é um sintoma de falha de outro serviço. O protocolo Kerberos depende de muitos serviços que devem estar disponíveis e funcionando corretamente para que qualquer autenticação ocorra.

  • Para determinar se um problema está ocorrendo com a autenticação Kerberos, verifique se há erros no log de eventos do sistema de qualquer serviço filtrando-o usando a "origem" (como Kerberos, kdc, LsaSrv ou Netlogon) no cliente, servidor de destino ou controlador de domínio que fornece autenticação. Se houver algum desses erros, também poderá haver erros associados ao protocolo Kerberos.

  • As auditorias de falha no log de eventos de segurança do servidor de destino podem mostrar que o protocolo Kerberos estava sendo usado quando ocorreu uma falha de logon.

  • Antes de inspecionar o protocolo Kerberos, verifique se os seguintes serviços ou condições estão funcionando corretamente:

    • A infraestrutura de rede está funcionando corretamente e todos os computadores e serviços podem se comunicar.
    • O controlador de domínio está acessível. Você pode executar o comando nltest /dsgetdc:<Domain Name> /force /kdc (por exemplo, nltest /dsgetdc:contoso.com /force /kdc) no cliente ou no servidor de destino.
    • O DNS (Sistema de Nomes de Domínio) está configurado corretamente e resolve nomes de host e serviços adequadamente.
    • Os relógios são sincronizados em todo o domínio.
    • Todas as atualizações críticas e atualizações de segurança para o Windows Server são instaladas.
    • Todos os softwares, incluindo softwares que não são da Microsoft, são atualizados.
    • O computador será reiniciado se você estiver executando um sistema operacional de servidor.
    • Os serviços e o servidor necessários estão disponíveis. O protocolo de autenticação Kerberos requer um controlador de domínio em funcionamento, infraestrutura DNS e rede para funcionar corretamente. Verifique se você pode acessar esses recursos antes de começar a solucionar problemas do protocolo Kerberos.

Se você examinou todas essas condições e ainda está tendo problemas de autenticação ou erros Kerberos, precisa procurar uma solução. Os problemas podem ser causados pela forma como o protocolo Kerberos é configurado ou pela forma como outras tecnologias que funcionam com o protocolo Kerberos são configuradas.

Problemas comuns e soluções

Problemas de delegação Kerberos

Em um cenário típico, a conta de representação seria uma conta de serviço atribuída a um aplicativo Web ou à conta de computador de um servidor Web. A conta representada seria uma conta de usuário que requer acesso a recursos por meio de um aplicativo Web.

Há três tipos de delegação usando Kerberos:

  • Delegação completa (delegação irrestrita)

    A delegação total deve ser evitada tanto quanto possível. O usuário (usuário front-end e usuário back-end) pode estar localizado em diferentes domínios e também em diferentes florestas.

  • Delegação restrita (somente Kerberos e transição de protocolo)

    O usuário pode ser de qualquer domínio ou floresta, mas os serviços de front-end e back-end devem estar em execução no mesmo domínio.

  • Delegação restrita baseada em recursos (RBCD)

    O usuário pode ser de qualquer domínio, e os recursos de front-end e back-end podem ser de qualquer domínio ou floresta.

Solução de problemas de delegação Kerberos mais comum

  • Nome da Entidade de Serviço ausente ou duplicado
  • Falhas de resolução de nomes ou respostas incorretas (endereços IP incorretos fornecidos para um nome de servidor)
  • Tamanho grande de tíquetes Kerberos (MaxTokenSize) e ambiente não configurado corretamente
  • As portas estão sendo bloqueadas por firewalls ou roteadores
  • A conta de serviço não recebeu os privilégios apropriados (Atribuição de Direitos de Usuário)
  • Serviços front-end ou back-end que não estão no mesmo domínio e configuração de delegação restrita (não RBCD)

Para saber mais, veja:

Logon único (SSO) interrompido e solicitando autenticação uma vez

Considere os seguintes cenário:

  • Um aplicativo cliente e servidor como o Microsoft Edge e o servidor IIS (Serviços de Informações da Internet). O servidor IIS é configurado com a Autenticação do Windows (Negociar).
  • Um aplicativo cliente e servidor como um cliente SMB e um servidor SMB. Por padrão, o servidor SMB é configurado com a SSPI (Interface do Provedor de Suporte de Segurança) de Negociação.

Um usuário abre o Microsoft Edge e navega em um site http://webserver.contoso.cominterno. O site é configurado com Negociar e solicita autenticação. Depois que o usuário insere manualmente o nome de usuário e a senha, o usuário obtém a autenticação e o site funciona conforme o esperado.

Observação

Este cenário é um exemplo de cliente e servidor. A técnica de solução de problemas é a mesma para qualquer cliente e servidor configurado com a autenticação integrada do Windows.

A autenticação integrada do Windows é interrompida no nível do usuário ou no nível do computador.

Métodos de solução de problemas

  • Examine a configuração do cliente para obter uma configuração de autenticação integrada, que pode ser habilitada em um nível de aplicativo ou computador. Por exemplo, todos os aplicativos baseados em HTTP procurariam que o site estivesse em uma zona confiável ao tentar executar a autenticação integrada.

    Abra inetcpl.cpl (Opções da Internet), que todos os aplicativos baseados em HTTP usam para configurações do Internet Explorer, e verifique se o site está configurado como Intranet local.

  • Os aplicativos também têm uma configuração para executar a autenticação integrada do Windows.

    O Microsoft Edge ou o Internet Explorer tem uma configuração Habilitar a Autenticação Integrada do Windows para ser habilitada.

  • Examine a configuração do aplicativo e o computador cliente poderá obter um tíquete Kerberos para um determinado SPN (nome da entidade de serviço). Neste exemplo, o SPN é http/webserver.contoso.com.

    • Mensagem de sucesso quando você pode encontrar o SPN:

      C:>klist get http/webserver.contoso.com
      Current LogonId is 0:0x9bd1f
      A ticket to http/webserver.contoso.com has been retrieved successfully.
      
    • Mensagem de erro quando você não consegue encontrar o SPN:

      C:>klist get http/webserver.contoso.com
      klist failed with 0xc000018b/-1073741429: The SAM database on the Windows Server does not have a computer account for this workstation trust relationship.
      

    Identifique e adicione os respectivos SPNs às contas de usuário, serviço ou computador apropriadas.

  • Se você identificou que os SPNs podem ser recuperados, poderá verificar se eles estão registrados na conta correta usando o seguinte comando:

    setspn -F -Q */webserver.contoso.com
    

Problemas de descoberta de DC de autenticação

Os servidores de aplicativos configurados com a autenticação integrada do Windows precisam de controladores de domínio (DCs) para autenticar o usuário/computador e o serviço.

A incapacidade de entrar em contato com um controlador de domínio durante o processo de autenticação leva ao erro 1355:

O domínio especificado não existe ou não pôde ser contatado

Não é possível acessar um recurso configurado com autenticação integrada do Windows com um erro 1355

Observação

As mensagens de erro podem diferir do ponto de vista do aplicativo, mas o significado do erro é que o cliente ou servidor não consegue descobrir um controlador de domínio.

Aqui estão exemplos dessas mensagens de erro:

  • Ocorreu o seguinte erro ao tentar ingressar no domínio "Contoso":
    O domínio especificado não existe ou não pôde ser contatado.

  • Não foi possível encontrar o controlador de domínio para o domínio contoso.com

  • Não foi possível contatar o controlador de domínio 1355

Principais causas do problema

  • Configuração incorreta de DNS no cliente

    Você pode executar o ipconfig /all comando e revisar a lista de servidores DNS.

  • Configuração incorreta de DNS nos controladores de domínio em um domínio ou floresta confiável

  • Portas de rede bloqueadas entre o cliente e os controladores de domínio

    Portas de descoberta DC: UDP 389 (UDP LDAP) e UDP 53 (DNS)

Etapas para solucionar problemas

  1. Execute o nslookup comando para identificar quaisquer configurações incorretas de DNS.
  2. Abra as portas necessárias entre o cliente e o controlador de domínio. Para obter mais informações, consulte Como configurar um firewall para domínios e relações de confiança do Active Directory.

Cenário de teste de análise de log

Ambiente e configuração

  • Máquina cliente

    Client1.contoso.com (uma máquina com Windows 11) ingressa no domínio Contoso.com.

  • Utilizador John

    O usuário pertence e Contoso.com entra no computador cliente.

  • Opções de Internet na máquina cliente

    Todos os sites fazem parte da zona da intranet local.

    Captura de tela das Propriedades da Internet, que mostra que todos os sites fazem parte da zona da intranet local.

  • Servidor

    IISServer.contoso.com (Windows Server 2019) ingressa no domínio Contoso.com.

  • Configuração de autenticação

    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.

  • Provedores de autenticação: negociar

    Os provedores habilitados são definidos da seguinte maneira:

    Captura de tela da janela Provedores mostrando que os Provedores habilitados incluem Negociar.

Fluxo de autenticação

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

  1. O usuário John entra no Client1.contoso.com, abre um navegador Microsoft Edge e se conecta ao IISServer.contoso.com.
  2. A máquina cliente executará as etapas abaixo (Etapa 1 no diagrama acima):
    1. O resolvedor de DNS armazena IISServer.contoso.com em cache para verificar se essas informações já estão armazenadas em cache.
    2. O resolvedor de DNS verifica o arquivo HOSTS em busca de IISServer.contoso.com qualquer mapeamento localizado em C:\Windows\System32\drivers\etc\Hosts.
    3. Envie uma consulta DNS para o servidor DNS preferencial (definido nas definições de configuração de IP), que também é um controlador de domínio no ambiente.
  3. O serviço DNS em execução no controlador de domínio examinará suas zonas configuradas, resolverá o registro do Host A e responderá com um endereço IP de IISServer.contoso.com (Etapa 2 no diagrama acima).
  4. A máquina cliente executará um handshake TCP de três vias na porta TCP 80 para IISServer.contoso.com.
  5. A máquina cliente enviará uma solicitação HTTP anônima para o IISServer.contoso.com.
  6. O servidor IIS que escuta na porta 80 receberá a solicitação de , examinará a configuração de autenticação dos servidores IIS e enviará de volta uma resposta de desafio HTTP 401 para o computador cliente com Negotiate como a configuração de Client1.contoso.comautenticação (Etapa 3 no diagrama acima).
  7. O processo do Microsoft Edge em Client1.contoso.com execução saberá que o servidor IIS está configurado com Negociar e verificará se o site faz parte da zona da intranet local. Se o site estiver na zona da intranet local, o processo do Microsoft Edge chamará LSASS.exe para obter um tíquete Kerberos com um SPN HTTP\IISServer.contoso.com (Etapa 5 no diagrama acima).
  8. O controlador de domínio (serviço KDC) receberá a solicitação de , pesquisará o SPN HTTP\IISServer.contoso.com em seu banco de Client1.contoso.comdados e find IISServer.contoso.com está configurado com esse SPN.
  9. O controlador de domínio responderá com uma resposta TGS com o tíquete para o servidor IIS (Etapa 6 no diagrama acima).
  10. O processo do Microsoft Edge no computador cliente enviará uma solicitação de AP (Protocolo de Aplicativo) Kerberos para o servidor Web do IIS com o tíquete TGS Kerberos emitido pelo controlador de domínio.
  11. O processo do IIS chamará LSASS.exe no servidor Web para descriptografar o tíquete e criar um token com SessionID e associação ao grupo Usuários para autorização.
  12. O processo do IIS obterá um identificador de LSASS.exe para o token para tomar decisões de autorização e permitir que o usuário se conecte a uma resposta de AP.

Análise do fluxo de trabalho do Monitor de Rede

Observação

Você precisa ser um usuário do grupo Administradores local para executar as atividades abaixo.

  1. Instale o Monitor de Rede da Microsoft no computador cliente (Client1.contoso.com).

  2. Execute o seguinte comando em uma janela de prompt de comando com privilégios elevados (cmd.exe):

    ipconfig /flushdns
    
  3. Inicie o Monitor de Rede.

  4. Abra o navegador Microsoft Edge e digite http://iisserver.contoso.com.

  5. Análise de rastreamento de rede:

    1. Consulta DNS ao controlador de domínio para um registro do Host A: IISServer.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
      
    2. 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
      
    3. O processo do Microsoft Edge em Client1.contoso.com se conecta ao servidor Web do IIS IISServer.contoso.com (conexão anônima).

      3027    00:59:30.1609409    Client1.contoso.com    iisserver.contoso.com    HTTP    HTTP:Request, GET /
      Host:  iisserver.contoso.com
      
    4. O servidor IIS responde com a resposta HTTP 401: Negotiate e NTLM (configuração executada no servidor IIS).

      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
      
    5. A solicitação Kerberos de vai para o controlador DCA.contoso.com de Client1.contoso.com domínio com um SPN: HTTP/iisserver.contoso.com.

      3034    00:59:30.1834048    Client1.contoso.com    DCA.contoso.com    KerberosV5    KerberosV5:TGS Request Realm: CONTOSO.COM Sname: HTTP/iisserver.contoso.com
      
    6. O controlador DCA.contoso.com de domínio responde com a solicitação Kerberos, que tem uma resposta TGS com um tíquete Kerberos.

      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
      
    7. O processo do Microsoft Edge agora Client1.contoso.com vai para o servidor IIS com uma solicitação de AP Kerberos.

      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
      
    8. O servidor IIS responde com uma resposta informando que a autenticação foi concluída.

      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)
      
  6. Execute o klist tickets comando para revisar o tíquete Kerberos na saída do comando em Client1.contoso.com.

    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
    
  7. Examine a ID do Evento 4624 no servidor IIS que mostra a Success auditoria:

  • Por padrão, as Success auditorias ou Failure estão habilitadas em todos os sistemas operacionais do servidor Windows. Você pode verificar se a auditoria está habilitada pelo comando a seguir.

  • Se você achar que a auditoria não está habilitada, habilite a auditoria. Examine a categoria de logon na lista abaixo. Como você pode observar, a subcategoria de logon é ativada com Success and Failure.

    C:\>auditpol /get /Subcategory:"logon"
    System audit policy
    Category/Subcategory                      Setting
    Logon/Logoff
      Logon                                   Success and Failure
    

    Se você não observar logon com Success and Failure, execute o comando para habilitá-lo:

    C:\>auditpol /set /subcategory:"Logon" /Success:enable /Failure:enable
    The command was successfully executed.
    

Examine a ID de evento de segurança bem-sucedida 4624 no IISServer.contoso.com

Observe os seguintes campos:

  • Logon type: 3 (logon de rede)
  • Security ID No New Logon campo: Contoso\John
  • Source Network Address: Endereço IP da máquina cliente
  • Logon Process e Authentication Package: Kerberos
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 de fluxo de trabalho de autenticação

Use um dos métodos a seguir para solucionar o problema.

  • Verifique se você pode resolver o nome do servidor Web do IIS (IISServer.contoso.com) de Client1.contoso.com.

  • Verifique se o servidor DNS está respondendo ao endereço IP correto do servidor IIS usando o seguinte cmdlet:

    PS C:\> Resolve-DnsName -Name IISServer.contoso.com
    
    Name                                           Type   TTL   Section    IPAddress
    ----                                           ----   ---   -------    ---------
    IISServer.contoso.com                          A      1200  Answer     192.168.2.104
    
  • Verifique se as portas de rede estão abertas entre o computador cliente e o servidor Web do IIS (IISServer.contoso.com) usando o seguinte cmdlet:

    PS C:\> Test-NetConnection -Port 80 IISServer.contoso.com                                                               
    
    ComputerName     : IISServer.contoso.com
    RemoteAddress    : 192.168.2.104
    RemotePort       : 80
    InterfaceAlias   : Ethernet 2
    SourceAddress    : 192.168.2.101
    TcpTestSucceeded : True
    
  • Verifique se você está recebendo um tíquete Kerberos do controlador de domínio.

    1. Abra um prompt de comando normal (não um prompt de comando de administrador) no contexto do usuário que tenta acessar o site.

    2. Execute o comando klist purge.

    3. Execute o comando klist get http/iisserver.contoso.com da seguinte forma:

      PS C:\> klist get http/iisserver.contoso.com
      
      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
      

      Você descobrirá que recebe um tíquete Kerberos para o SPN http/IISServer.contoso.com na Cached Ticket (2) coluna.

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

    Abra um Prompt do PowerShell normal (não um Prompt do PowerShell de administrador) no contexto do usuário que está tentando acessar o site.

    PS C:\> invoke-webrequest -Uri http://IIsserver.contoso.com -UseDefaultCredentials
    PS C:\> invoke-webrequest -Uri http://IIsserver.contoso.com -UseDefaultCredentials
    
    
    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...
    
  • Examine o log de eventos de segurança no servidor IIS:

    • Registro de eventos de sucesso 4624
    • Log de eventos de erro 4625
  • Processo de isolamento: você pode usar as etapas de solução de problemas abaixo para verificar se outros serviços no servidor IIS podem processar a autenticação Kerberos.

    Pré-requisitos:

    • O servidor IIS deve estar executando uma versão de servidor do Windows.

    • O servidor IIS deve ter uma porta aberta para serviços como SMB (porta 445).

    • Crie um novo compartilhamento ou forneça ao usuário John permissões para Ler em uma das pastas (por exemplo, Software$) que já está compartilhada no computador.

      1. Entrar no Client1.contoso.com.

      2. Abra o Windows Explorer.

      3. Digite \IISServer.contoso.com \Software$.

      4. Abra os eventos de segurança ativados IISServer.contoso.com e verifique se você observa a ID do evento 4624.

      5. Abra um prompt de comando normal como Client1.contoso.com o usuário John. Execute o klist tickets comando e revise o tíquete CIFS/IISServer.contoso.com.

        #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
        
      6. Colete rastreamentos de rede no Client1.contoso.com. Examine os rastreamentos de rede para observar qual etapa falha para que você possa restringir ainda mais as etapas e solucionar o problema.