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 está ocorrendo um problema com a autenticação Kerberos, verifique o log de eventos do sistema em busca de erros de quaisquer serviços (como Kerberos, kdc, LsaSrv ou Netlogon) no cliente, no servidor de destino ou no controlador de domínio que fornecem 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 servidor)
- Tíquetes Kerberos grandes (MaxTokenSize) e ambiente não configurados corretamente
- Portas bloqueadas por firewalls ou roteadores
- Conta de serviço sem 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
Para saber mais, veja:
- A delegação restrita para CIFS falha com ACCESS_DENIED erro
- Configurar delegação restrita para uma conta de serviço personalizada
- Configurar a delegação restrita na conta NetworkService
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 /allcomando 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
- Execute o
nslookupcomando para identificar quaisquer configurações incorretas de DNS. - 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ínioContoso.com.Utilizador
JohnO usuário pertence e
Contoso.comentra no computador cliente.Opções de Internet na máquina cliente
Todos os sites fazem parte da zona da intranet local.
Servidor
IISServer.contoso.com(Windows Server 2019) ingressa no domínioContoso.com.Configuração de autenticação
A autenticação do Windows está habilitada.
Provedores de autenticação: negociar
Os provedores habilitados são definidos da seguinte maneira:
Fluxo de autenticação
- O usuário
Johnentra noClient1.contoso.com, abre um navegador Microsoft Edge e se conecta aoIISServer.contoso.com. - A máquina cliente executará as etapas abaixo (Etapa 1 no diagrama acima):
- O resolvedor de DNS armazena
IISServer.contoso.comem cache para verificar se essas informações já estão armazenadas em cache. - O resolvedor de DNS verifica o arquivo HOSTS em busca de
IISServer.contoso.comqualquer mapeamento localizado em C:\Windows\System32\drivers\etc\Hosts. - 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.
- O resolvedor de DNS armazena
- 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). - A máquina cliente executará um handshake TCP de três vias na porta TCP 80 para
IISServer.contoso.com. - A máquina cliente enviará uma solicitação HTTP anônima para o
IISServer.contoso.com. - 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). - O processo do Microsoft Edge em
Client1.contoso.comexecuçã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 SPNHTTP\IISServer.contoso.com(Etapa 5 no diagrama acima). - O controlador de domínio (serviço KDC) receberá a solicitação de , pesquisará o SPN
HTTP\IISServer.contoso.comem seu banco deClient1.contoso.comdados e findIISServer.contoso.comestá configurado com esse SPN. - O controlador de domínio responderá com uma resposta TGS com o tíquete para o servidor IIS (Etapa 6 no diagrama acima).
- 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.
- 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.
- 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.
Instale o Monitor de Rede da Microsoft no computador cliente (
Client1.contoso.com).Execute o seguinte comando em uma janela de prompt de comando com privilégios elevados (cmd.exe):
ipconfig /flushdnsInicie o Monitor de Rede.
Abra o navegador Microsoft Edge e digite
http://iisserver.contoso.com.Análise de rastreamento de rede:
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 InternetResposta 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.104O processo do Microsoft Edge em
Client1.contoso.comse conecta ao servidor Web do IISIISServer.contoso.com(conexão anônima).3027 00:59:30.1609409 Client1.contoso.com iisserver.contoso.com HTTP HTTP:Request, GET / Host: iisserver.contoso.comO 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: NTLMA solicitação Kerberos de vai para o controlador
DCA.contoso.comdeClient1.contoso.comdomí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.comO controlador
DCA.contoso.comde 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.comO processo do Microsoft Edge agora
Client1.contoso.comvai 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.comO 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)
Execute o
klist ticketscomando para revisar o tíquete Kerberos na saída do comando emClient1.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.comExamine a ID do Evento 4624 no servidor IIS que mostra a
Successauditoria:
Por padrão, as
Successauditorias ouFailureestã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 FailureSe 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 IDNoNew Logoncampo:Contoso\JohnSource Network Address: Endereço IP da máquina clienteLogon ProcesseAuthentication 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) deClient1.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.104Verifique 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 : TrueVerifique se você está recebendo um tíquete Kerberos do controlador de domínio.
Abra um prompt de comando normal (não um prompt de comando de administrador) no contexto do usuário que tenta acessar o site.
Execute o comando
klist purge.Execute o comando
klist get http/iisserver.contoso.comda 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.comVocê descobrirá que recebe um tíquete Kerberos para o SPN
http/IISServer.contoso.comnaCached 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
Johnpermissões para Ler em uma das pastas (por exemplo, Software$) que já está compartilhada no computador.Entrar no
Client1.contoso.com.Abra o Windows Explorer.
Digite \IISServer.contoso.com \Software$.
Abra os eventos de segurança ativados
IISServer.contoso.come verifique se você observa a ID do evento 4624.Abra um prompt de comando normal como
Client1.contoso.como usuárioJohn. Execute oklist ticketscomando e revise o tíqueteCIFS/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.comColete 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.