Solucionar problemas de falhas de Kerberos no Internet Explorer

Este artigo ajuda a isolar e corrigir as causas de vários erros ao acessar sites configurados para usar a autenticação Kerberos no Internet Explorer. O número de problemas potenciais é quase tão grande quanto o número de ferramentas disponíveis para resolvê-los.

Sintoma comum quando o Kerberos falha

Você tenta acessar um site em que o Windows Integrated Authenticated foi configurado e espera usar o protocolo de autenticação Kerberos. Nessa situação, seu navegador solicita imediatamente as credenciais, da seguinte maneira:

Embora você insira um nome de usuário e senha válidos, você será solicitado novamente (três prompts no total). Em seguida, é exibida uma tela que indica que você não tem permissão para acessar o recurso desejado. A tela exibe um código de status HTTP 401 semelhante ao seguinte erro:

Não autorizado
Erro HTTP 401. O recurso solicitado requer a autenticação do usuário.

No servidor IIS (Serviços de Informações da Internet) da Microsoft, os logs do site contêm solicitações que terminam em um código de status 401.2, como o seguinte log:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

Ou a tela exibe um código de status 401.1, como o seguinte log:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Determinar se o Kerberos é usado

Ao solucionar problemas de falha de autenticação Kerberos, recomendamos que você simplifique a configuração ao mínimo. Ou seja, um cliente, um servidor e um site do IIS em execução na porta padrão. Além disso, você pode seguir algumas etapas básicas de solução de problemas. Por exemplo, use uma página de teste para verificar o método de autenticação usado. Se você usar ASP.NET, poderá criar essa página de teste de autenticação ASP.NET.

Se você estiver usando o ASP clássico, poderá usar a seguinte página Testkerb.asp:

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

Você também pode usar as seguintes ferramentas para determinar se o Kerberos é usado:

• Fiddler
• Vigilância Http
• Monitor de Rede
• As ferramentas de desenvolvedor em seu navegador

Para obter mais informações sobre como esses rastreamentos podem ser gerados, consulte rastreamento do lado do cliente.

Quando o Kerberos é usado, a solicitação enviada pelo cliente é grande (mais de 2.000 bytes), pois o HTTP_AUTHORIZATION cabeçalho inclui o tíquete Kerberos. A solicitação a seguir é para uma página que usa a Autenticação do Windows baseada em Kerberos para autenticar usuários de entrada. O tamanho da solicitação GET é superior a 4.000 bytes.

Se o handshake NTLM for usado, a solicitação será muito menor. A captura do lado do cliente a seguir mostra uma solicitação de autenticação NTLM. A solicitação GET é muito menor (menos de 1.400 bytes).

Depois de determinar que a autenticação Kerberos está falhando, verifique cada um dos itens a seguir na ordem especificada.

O que verificar se a autenticação Kerberos falhar

As seções a seguir descrevem as coisas que você pode usar para verificar se a autenticação Kerberos falha.

O cliente e o servidor estão no mesmo domínio

O uso do Kerberos requer um domínio, pois um tíquete Kerberos é entregue pelo controlador de domínio (DC). Cenários avançados também são possíveis onde:

• O cliente e o servidor não estão no mesmo domínio, mas em dois domínios da mesma floresta.
• O cliente e o servidor estão em duas florestas diferentes.

Esses cenários possíveis são discutidos na seção Por que a delegação Kerberos falha entre minhas duas florestas, embora tenha funcionado deste artigo.

O IIS está configurado para usar a autenticação integrada

A autenticação integrada está habilitada no Internet Explorer

A URL usada é resolvida para uma zona de segurança para a qual as credenciais podem ser enviadas

Sempre execute essa verificação para os seguintes sites:

• Sites que correspondem à zona da Intranet Local do navegador.
• Sites na zona Sites Confiáveis.

Você pode verificar em qual zona seu navegador decide incluir o site. Para fazer isso, abra o menu Arquivo do Internet Explorer e selecione Propriedades. A janela Propriedades exibirá a zona na qual o navegador decidiu incluir o site para o qual você está navegando.

Você pode verificar se a zona na qual o site está incluído permite o logon automático. Para fazer isso, abra o menu de opções da Internet do Internet Explorer e selecione a guia Segurança. Depois de selecionar a zona desejada, selecione o botão Nível personalizado para exibir as configurações e verifique se o logon automático está selecionado. (Normalmente, esse recurso é ativado por padrão para as zonas de Intranet e Sites Confiáveis).

O servidor IIS está configurado para enviar o cabeçalho WWW-Authenticate: Negotiate

Se o IIS não enviar esse cabeçalho, use o console do Gerenciador do IIS para definir o cabeçalho Negotiate por meio da propriedade de configuração NTAuthenticationProviders . Para obter mais informações, consulte Provedores> de Autenticação <do Windows. Você pode acessar o console por meio da configuração Provedores dos detalhes de Autenticação do Windows no gerenciador do IIS.

O cliente e o servidor estão instalados no mesmo computador

Por padrão, o Kerberos não está habilitado nessa configuração. Para alterar esse comportamento, você precisa definir a DisableLoopBackCheck chave do Registro. Para obter mais informações, consulte KB 926642.

O cliente pode obter um tíquete Kerberos

Você pode usar a ferramenta Lista Kerberos (KLIST) para verificar se o computador cliente pode obter um tíquete Kerberos para um determinado nome de entidade de serviço. Neste exemplo, o SPN (nome da entidade de serviço) é http/web-server.

Quando a solicitação de tíquete Kerberos falha, a autenticação Kerberos não é usada. O fallback NTLM pode ocorrer, pois o SPN solicitado é desconhecido para o DC. Se o DC estiver inacessível, nenhum fallback NTLM ocorrerá.

Para declarar um SPN, consulte o seguinte artigo:

Como usar SPNs ao configurar aplicativos Web hospedados nos Serviços de Informações da Internet.

O servidor web usa uma porta diferente da padrão (80)

Por padrão, o Internet Explorer não inclui as informações de número de porta no SPN usado para solicitar um tíquete Kerberos. Pode ser um problema se você usar o IIS para hospedar vários sites em diferentes portas e identidades. Nessa configuração, a autenticação Kerberos pode funcionar apenas para sites específicos, mesmo que todos os SPNs tenham sido declarados corretamente no Active Directory. Para corrigir esse problema, você deve definir o valor do FEATURE_INCLUDE_PORT_IN_SPN_KB908209 Registro. (Veja o Chaves de recurso do Internet Explorer para obter informações sobre como declarar a chave.) Essa configuração força o Internet Explorer a incluir o número da porta no SPN usado para solicitar o tíquete Kerberos.

O Internet Explorer usa o SPN esperado

Se um site for acessado usando um nome de alias (CNAME), o Internet Explorer primeiro usará a resolução DNS para resolver o nome de alias para um nome de computador (ANAME). O nome do computador é usado para criar o SPN e solicitar um tíquete Kerberos. Mesmo que a URL inserida na barra de endereços do Internet Explorer seja http://MYWEBSITE, o Internet Explorer solicitará um SPN para HTTP/MYSERVER se MYWEBSITE for um alias (CNAME) de MYSERVER (ANAME). Você pode alterar esse comportamento usando a chave do FEATURE_USE_CNAME_FOR_SPN_KB911149 Registro. (Veja o Chaves de recurso do Internet Explorer para obter informações sobre como declarar a chave.)

Um rastreamento do Monitor de Rede é um bom método para verificar o SPN associado ao tíquete Kerberos, como no exemplo a seguir:

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

A identidade do pool de aplicativos corresponde à conta associada ao SPN

Quando um tíquete Kerberos é enviado do Internet Explorer para um servidor IIS, o tíquete é criptografado usando uma chave privada. A chave privada é um hash da senha usada para a conta de usuário associada ao SPN. Portanto, apenas um aplicativo em execução nessa conta pode decodificar o tíquete.

O procedimento a seguir é um resumo do algoritmo de autenticação Kerberos:

1. O Internet Explorer determina um SPN usando a URL inserida na barra de endereços.

2. O SPN é passado por meio de uma API SSPI (Interface do Provedor de Suporte de Segurança) (InitializeSecurityContext) para o componente do sistema responsável pela segurança do Windows (o processo LSASS (Serviço de Subsistema de Autoridade de Segurança Local)). Neste estágio, você pode ver que o código do Internet Explorer não implementa nenhum código para construir o tíquete Kerberos. O Internet Explorer chama apenas APIs SSPI.

3. O LSASS usa o SPN que é passado para solicitar um tíquete Kerberos para um DC. Se o controlador de domínio puder atender à solicitação (SPN conhecido), ele criará um tíquete Kerberos. Em seguida, ele criptografa o tíquete usando uma chave construída a partir do hash da senha da conta de usuário para a conta associada ao SPN. O LSASS então envia o tíquete para o cliente. No que diz respeito ao Internet Explorer, o tíquete é um blob opaco.

4. O Internet Explorer encapsula o tíquete Kerberos fornecido pelo LSASS no cabeçalho e, em Authorization: Negotiate seguida, envia o tíquete para o servidor IIS.

5. O IIS lida com a solicitação e a roteia para o pool de aplicativos correto usando o cabeçalho de host especificado.

6. O pool de aplicativos tenta descriptografar o tíquete usando APIs SSPI/LSASS e seguindo estas condições:

   • Se o tíquete puder ser descriptografado, a autenticação Kerberos será bem-sucedida. Todos os serviços associados ao ticket (representação, delegação, se o ticket permitir e assim por diante) estão disponíveis.

   • Se o tíquete não puder ser descriptografado, um erro Kerberos (KRB_AP_ERR_MODIFIED) será retornado. Esse erro é um erro genérico que indica que o bilhete foi alterado de alguma forma durante o transporte. Portanto, o tíquete não pode ser descriptografado. Esse erro também é registrado nos logs de eventos do Windows.

Se você não declarar explicitamente um SPN, a autenticação Kerberos funcionará somente em uma das seguintes identidades de pool de aplicativos:

• Serviço de Rede
• ApplicationPoolIdentity
• Outra conta do sistema, como LOCALSYSTEM ou LOCALSERVICE

Mas essas identidades não são recomendadas, porque são um risco de segurança. Nesse caso, o tíquete Kerberos é criado usando um SPN padrão criado no Active Directory quando um computador (nesse caso, o servidor em que o IIS está sendo executado) é adicionado ao domínio. Esse SPN padrão está associado à conta do computador. No IIS, a conta de computador é mapeada para Serviço de Rede ou ApplicationPoolIdentity.

Se o pool de aplicativos precisar usar uma identidade diferente das identidades listadas, declare um SPN (usando SETSPN). Em seguida, associe-o à conta usada para a identidade do pool de aplicativos. Um erro comum é criar SPNs semelhantes com contas diferentes. Por exemplo:

• SETSPN http/meusite UserAppPool1
• SETSPN http/meusite UserAppPool2

Essa configuração não funcionará, pois não há uma maneira determinística de saber se o tíquete Kerberos para o SPN http/mywebsite será criptografado usando a senha UserAppPool1 ou UserAppPool2. Essa configuração normalmente gera erros KRB_AP_ERR_MODIFIED. Para determinar se você está nesse cenário de SPNs duplicados inválidos, use as ferramentas documentadas no artigo a seguir:

Por que você ainda pode ter SPNs duplicados no AD 2012 R2 e no AD 2016

Do Windows Server 2008 em diante, você também pode usar uma versão atualizada do SETSPN para Windows que permite a detecção de SPNs duplicados usando o setspn –X comando ao declarar um novo SPN para sua conta de destino. Para obter mais informações, consulte Setspn.

Também recomendamos que você revise os seguintes artigos:

• Problemas de autenticação Kerberos – problemas de SPN (Nome da Entidade de Serviço) – Parte 1

• Problemas de autenticação Kerberos – Problemas de SPN (Nome da Entidade de Serviço) – Parte 2

• Problemas de autenticação Kerberos – problemas de SPN (Nome da Entidade de Serviço) – Parte 3

A autenticação Kerberos falha no IIS 7 e versões posteriores, embora funcione no IIS 6

A autenticação do modo kernel é um recurso que foi introduzido no IIS 7. Ela oferece as seguintes vantagens:

• O desempenho é aumentado, pois as transições do modo kernel para o modo de usuário não são mais feitas.
• A decodificação de tíquetes Kerberos é feita usando a conta do computador, não a identidade do pool de aplicativos. Essa alteração permite que você tenha vários pools de aplicativos em execução em identidades diferentes sem precisar declarar SPNs.

Por que a delegação falha, embora a autenticação Kerberos funcione

Nesse cenário, verifique os seguintes itens:

• A Zona do Internet Explorer usada para a URL. A delegação Kerberos é permitida apenas para as zonas de Intranet e Sites Confiáveis. (Em outras palavras, o Internet Explorer define o ISC_REQ_DELEGATE sinalizador quando chama InitializeSecurityContext somente se a zona determinada for Intranet ou Sites Confiáveis.)

• A conta de usuário do pool de aplicativos do IIS que hospeda seu site deve ter o sinalizador Confiável para delegação definido no Active Directory.

Se a delegação ainda falhar, considere usar o Kerberos Configuration Manager para IIS. Essa ferramenta permite diagnosticar e corrigir configurações do IIS para autenticação Kerberos e para os SPNs associados nas contas de destino. Para obter mais informações, consulte o README.md. Você pode baixar a ferramenta aqui.

Por que obtenho um desempenho ruim ao usar a autenticação Kerberos

Kerberos é um protocolo de autenticação baseado em solicitação em versões mais antigas do Windows Server, como Windows Server 2008 SP2 e Windows Server 2008 R2. Isso significa que o cliente deve enviar o tíquete Kerberos (que pode ser um blob bem grande) com cada solicitação feita ao servidor. É contrário aos métodos de autenticação que dependem do NTLM. Por padrão, o NTLM é baseado em sessão. Isso significa que o navegador autenticará apenas uma solicitação quando abrir a conexão TCP com o servidor. Cada solicitação subsequente na mesma conexão TCP não exigirá mais autenticação para que a solicitação seja aceita. Nas versões mais recentes do IIS, do Windows 2012 R2 em diante, o Kerberos também é baseado em sessão. Somente a primeira solicitação em uma nova conexão TCP deve ser autenticada pelo servidor. As solicitações subsequentes não precisam incluir um tíquete Kerberos.

Você pode alterar esse comportamento usando a propriedade authPersistNonNTLM se estiver executando no IIS 7 e versões posteriores. Se a propriedade for definida como true, o Kerberos se tornará baseado em sessão. Caso contrário, será baseado em solicitação. Terá um desempenho pior porque temos que incluir uma quantidade maior de dados para enviar ao servidor a cada vez. Para obter mais informações, consulte Autenticação Kerberos baseada em solicitação versus Autenticação Kerberos baseada em sessão (ou o parâmetro AuthPersistNonNTLM).

Por que a delegação Kerberos falha entre minhas duas florestas, embora costumava funcionar

Considere o cenário a seguir.

• Os usuários do seu aplicativo estão localizados em um domínio dentro da floresta A.
• Seu aplicativo está localizado em um domínio dentro da floresta B.
• Você tem uma relação de confiança entre as florestas.

Nesse cenário, a delegação Kerberos pode parar de funcionar, mesmo que ela costumava funcionar anteriormente e você não tenha feito nenhuma alteração em florestas ou domínios. A autenticação Kerberos ainda funciona nesse cenário. Somente a delegação falha.

Esse problema pode ocorrer devido a atualizações de segurança para o Windows Server lançadas pela Microsoft em março de 2019 e julho de 2019. Essas atualizações desabilitaram a delegação Kerberos irrestrita (a capacidade de delegar um token Kerberos de um aplicativo para um serviço de back-end) entre os limites da floresta para todas as relações de confiança novas e existentes. Para obter mais informações, consulte Atualizações para delegação de TGT em relações de confiança de entrada no Windows Server.

Teclas de recursos do Internet Explorer

Essas chaves são chaves de registro que ativam ou desativam alguns recursos do navegador. As chaves estão localizadas nos seguintes locais do Registro:

• HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – se definido no nível do usuário
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - se definido no nível da máquina

As chaves de recurso devem ser criadas em um destes locais, dependendo se você deseja ativar ou desativar o recurso:

• para todos os usuários no computador
• apenas para uma conta específica

Essas chaves devem ser criadas no respectivo caminho. Dentro da chave, um valor DWORD nomeado iexplorer.exe deve ser declarado. O valor padrão de cada chave deve ser verdadeiro ou falso, dependendo da configuração desejada do recurso. Por padrão, FEATURE_INCLUDE_PORT_IN_SPN_KB908209 o valor de ambas as chaves de recurso e FEATURE_USE_CNAME_FOR_SPN_KB911149, é false. Para fins de integridade, aqui está um exemplo de exportação do Registro girando a chave de recurso para incluir números de porta no tíquete Kerberos para true:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

Mais informações

Páginas de diagnóstico para solução de problemas de Autenticação Integrada do Windows