Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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
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.
A lista de provedores de autenticação habilitados inclui o Negotiate, conforme mostrado na seguinte captura de tela:
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.
O processo começa quando o usuário John, que está conectado ao computador Client1.contoso.com
cliente, 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:
- O serviço de resolvedor DNS armazena
IISServer.contoso.com
em cache para verificar se essas informações já estão armazenadas em cache. - O serviço de resolvedor DNS verifica o arquivo HOSTS (C:\Windows\System32\drivers\etc\Hosts) para qualquer mapeamento de
IISServer.contoso.com
. - 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:
- 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 IP192.168.2.104
. - O servidor DNS retorna o endereço IP para o computador cliente.
A etapa 3 ocorre no computador cliente e inclui as seguintes etapas:
- O computador cliente realiza um handshake TCP de três vias com
IISServer.contoso.com
usando a porta TCP 80. - 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:
- O serviço Web (em execução como
IISServer.contoso.com
) recebe a solicitação deClient1.contoso.com
. - 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:
- O computador cliente recebe a mensagem de resposta ao desafio de
IISServer.contoso.com
. - 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. - O processo do Microsoft Edge chama LSASS.exe para procurar um tíquete de serviço para
IISServer.contoso.com
. - 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:
- O controlador de
Client1.contoso.com
domínio (serviço KDC) recebe a solicitação e pesquisa o serviço que usa o SPNHTTP\IISServer.contoso.com
(ouHOST\IISServer.contoso.com
). - O controlador de domínio identifica o serviço solicitado como o serviço Web executado no contexto de
IISServer.contoso.com
. - 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:
- O processo do Microsoft Edge cria uma mensagem AP (Protocolo de Aplicativo Kerberos) que inclui o tíquete de serviço.
- 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:
- O processo do IIS consulta o processo local LSASS.exe.
- 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.
- O processo LSASS.exe retorna um identificador do token para o processo do IIS.
- 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.
- 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:
- No computador cliente, abra uma janela do Prompt de Comando administrativo e execute
ipconfig /flushdns
. - Abra o Monitor de Rede e inicie a gravação.
- Abra o Microsoft Edge. Na barra de endereços, insira
http://iisserver.contoso.com
. - 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 para
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
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 emIISServer.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
paraClient1.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ínioDCA.contoso.com
para o serviço que usaHTTP/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 paraIISServer.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
paraIISServer.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
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.
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:
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.
No computador cliente, entre (como o usuário "John" e abra o Windows Explorer.
Na barra de endereços, insira \\IISServer.contoso.com \Software$.
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.
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 paraCIFS/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