Solucionar problemas de falhas do Kerberos no Explorer da Internet

Este artigo ajuda você a isolar e corrigir as causas de vários erros ao acessar sites configurados para usar a autenticação Kerberos na 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 Kerberos falha

Você tenta acessar um site em que a Autenticação Integrada do Windows foi configurada e espera usar o protocolo de autenticação Kerberos. Nesta situação, o navegador solicita imediatamente credenciais, da seguinte maneira:

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

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

No servidor Serviços de Informações da Internet da Microsoft (IIS), 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 401.1 status, 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 Kerberos é usado

Ao solucionar problemas de falha de autenticação kerberos, recomendamos simplificar 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 esta 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 Kerberos é usado:

• Fiddler
• HttpWatch
• 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 Kerberos é usado, a solicitação enviada pelo cliente é grande (mais de 2.000 bytes), porque 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 é de mais de 4.000 bytes.

Se o aperto de mão 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 se a autenticação Kerberos está falhando, marcar cada um dos itens a seguir na ordem determinada.

O que marcar se a autenticação Kerberos falhar

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

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

Usar 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 funcionasse esta seção.

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

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

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

Execute sempre este marcar para os seguintes sites:

• Sites que são compatíveis com a zona intranet local do navegador.
• Sites na zona Sites Confiáveis.

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

Você pode marcar se a zona na qual o site está incluído permite logon automático. Para fazer isso, abra o menu opções de Internet do Explorer da Internet 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 intranet e sites confiáveis).

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

Se o IIS não enviar esse cabeçalho, use o console do IIS Manager para definir o cabeçalho Negociar 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 da Autenticação do Windows no gerenciador do IIS.

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

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

O cliente pode obter um tíquete Kerberos

Você pode usar a ferramenta KLIST (Lista Kerberos) para verificar se o computador cliente pode obter um tíquete Kerberos para um determinado nome de entidade de serviço. Neste exemplo, o nome da entidade de serviço (SPN) é 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 for inacessível, não ocorrerá nenhum fallback NTLM.

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 do padrão (80)

Por padrão, o Explorer da Internet não inclui as informações de número da 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. Nesta 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. (Consulte a seção Chaves de recursos Explorer internet para obter informações sobre como declarar a chave.) Essa configuração força o Explorer da Internet a incluir o número da porta no SPN usado para solicitar o tíquete Kerberos.

A Internet Explorer usa o SPN esperado

Se um site for acessado usando um CNAME (nome de alias), o Explorer da Internet primeiro usará a resolução DNS para resolve o nome do alias para um nome de computador (ANAME). Em seguida, 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 Explorer da Internet seja http://MYWEBSITE, a Internet Explorer solicitará um SPN para HTTP/MYSERVER se MYWEBSITE for um alias (CNAME) do MYSERVER (ANAME). Você pode alterar esse comportamento usando a chave do FEATURE_USE_CNAME_FOR_SPN_KB911149 registro. (Consulte as chaves de recurso Explorer internet para obter informações sobre como declarar a chave.)

Um rastreamento do Monitor de Rede é um bom método para marcar 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 da 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, somente 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 Explorer da Internet determina um SPN usando a URL inserida na barra de endereços.

2. O SPN é passado por meio de uma API de 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 da Autoridade de Segurança Local). Nesta fase, você pode ver que o código de Explorer da Internet não implementa nenhum código para construir o tíquete Kerberos. A 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 DC puder atender à solicitação (SPN conhecida), ele criará um tíquete Kerberos. Em seguida, ele criptografa o tíquete usando uma chave que é construída a partir do hash da senha da conta de usuário para a conta associada ao SPN. Em seguida, o LSASS envia o tíquete para o cliente. No que diz respeito ao Explorer da Internet, o tíquete é um blob opaco.

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

5. O IIS manipula a solicitação e encaminha-a para o pool de aplicativos correto usando o cabeçalho do 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 tíquete (representação, delegação se o tíquete 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 tíquete foi alterado de alguma forma durante o transporte. Portanto, o tíquete não pode ser descriptografado. Esse erro também está 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 do 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 à 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á em execução) é adicionado ao domínio. Esse SPN padrão está associado à conta do computador. Em 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-a à conta usada para a identidade do pool de aplicativos. Um erro comum é criar SPNs semelhantes que tenham contas diferentes. Por exemplo:

• SETSPN http/mywebsite UserAppPool1
• SETSPN http/mywebsite 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. Normalmente, essa configuração gera erros de KRB_AP_ERR_MODIFIED. Para determinar se você está nesse cenário de SPNs duplicados, use as ferramentas documentadas no seguinte artigo:

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

No 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ê examine 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 nas versões posteriores e IIS 7, mesmo que funcione no IIS 6

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

• O desempenho é aumentado, pois as transições kernel-mode-to-user-mode não são mais feitas.
• A decodificação de tíquetes Kerberos é feita usando a conta do computador e 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, marcar os seguintes itens:

• A Zona de Explorer da Internet usada para a URL. A delegação Kerberos é permitida apenas para as zonas intranet e sites confiáveis. (Em outras palavras, a 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 Trusted for delegation definido no Active Directory.

Se a delegação ainda falhar, considere usar o Configuration Manager Kerberos para IIS. Essa ferramenta permite diagnosticar e corrigir configurações de 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 daqui.

Por que tenho um desempenho ruim quando uso 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 bastante 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. Em versões mais recentes do IIS, do Windows 2012 R2 em diante, 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 em versões IIS 7 e posteriores. Se a propriedade for definida como true, Kerberos se tornará baseado em sessão. Caso contrário, ele será baseado em solicitação. Ele terá um desempenho pior porque temos que incluir uma quantidade maior de dados para enviar ao servidor sempre. Para obter mais informações, consulte Autenticação Kerberos baseada em solicitação versus sessão (ou o parâmetro AuthPersistNonNTLM).

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

Considere o seguinte cenário:

• Os usuários do 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 trabalhar, mesmo que tenha funcionado 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 no Windows Server lançadas pela Microsoft em março de 2019 e julho de 2019. Essas atualizações desabilitam a delegação kerberos sem restrições (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 confianças novas e existentes. Para obter mais informações, consulte Atualizações à delegação do TGT entre os trusts de entrada no Windows Server.

Chaves de recurso de Explorer internet

Essas chaves são chaves de registro que ativam ou desativam alguns recursos do navegador. As chaves estão localizadas nos seguintes locais de 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 do computador

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

• para todos os usuários no computador
• para apenas 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, o valor de ambas as chaves FEATURE_INCLUDE_PORT_IN_SPN_KB908209 de recurso e FEATURE_USE_CNAME_FOR_SPN_KB911149, é falso. Para concluir, aqui está um exemplo de exportação do registro, transformando a chave do recurso para incluir números de porta no tíquete Kerberos como 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