Autenticação de salto duplo irrestrito Kerberos com o Microsoft Edge (Chromium)

Aplica-se a: Serviços de Informações da Internet

Introdução

Configurar a Autenticação do Windows com base no protocolo de autenticação Kerberos pode ser uma tarefa complexa, especialmente ao lidar com cenários como delegação de identidade de um site front-end para um serviço de back-end no contexto do IIS e do ASP.NET. Siga as etapas deste artigo para configurar a delegação de tíquetes de autenticação e usar serviços com um navegador moderno, como o Microsoft Edge versão 87 ou superior.

Este artigo pressupõe que você esteja configurando uma arquitetura semelhante à representada no diagrama abaixo:

• O computador Workstation-Client1 faz parte do mesmo Active Directory que o Servidor Web primário, chamado Primary-IIS-SRV e o servidor Web de back-end, chamado Backend-Web-SRV.
• Os usuários do computador Workstation-Client1 farão logon na máquina usando a conta do Windows Active Directory.
• Em seguida, eles iniciarão um navegador (Microsoft Edge), navegarão até um site localizado no Web-Server, que é o nome do alias usado para Primary-IIS-SRV e autenticarão por meio da autenticação integrada do Windows usando Kerberos.
• O site localizado no Web-Server fará chamadas HTTP usando credenciais de usuário autenticadas para API-Server (que é o alias de Backend-Web-SRV) para recuperar dados de aplicativos em nome dos usuários, usando a delegação de credenciais Kerberos.

As etapas abaixo ajudarão você a solucionar esse cenário: A configuração funciona com o Internet Explorer, mas quando os usuários adotam o Microsoft Edge, eles não podem mais usar o recurso de delegação de credenciais. Para usar a delegação de credenciais Kerberos, consulte Solucionar problemas de falhas Kerberos no Internet Explorer primeiro.

Delegação restrita ou irrestrita

No cenário acima, ambas as configurações permitem que os usuários deleguem credenciais de sua sessão de usuário na máquina Workstation-Client1 para o servidor de API de back-end enquanto se conectam por meio do servidor Web de front-end.

Em uma configuração de delegação Kerberos irrestrita, a identidade do pool de aplicativos é executada no Servidor Web e é configurada no Active Directory para ser confiável para delegação a qualquer serviço. A conta do pool de aplicativos em execução no Servidor Web pode delegar as credenciais de usuários autenticados do site hospedado nesse servidor a qualquer outro serviço no Active Directory. Por exemplo, um servidor SMTP, um servidor de arquivos, um servidor de banco de dados, outro servidor web, etc. Isso é chamado de delegação irrestrita porque a conta do pool de aplicativos tem permissão (irrestrita) para delegar credenciais a qualquer serviço que contata.

Em uma configuração de delegação restrita, a conta do Active Directory usada como uma identidade do pool de aplicativos pode delegar as credenciais de usuários autenticados somente a uma lista de serviços que foram autorizados a delegar. Se o aplicativo Web que reside no servidor chamado Web-Server também precisar entrar em contato com um banco de dados e autenticar em nome do usuário, esse SPN (nome da entidade de serviço) deverá ser adicionado à lista de serviços autorizados.

A delegação restrita é mais segura do que a delegação irrestrita com base no princípio do menor privilégio. Um aplicativo recebe os direitos necessários para funcionar e nada mais, enquanto a delegação irrestrita permite que um aplicativo entre em contato com recursos que não deveria entrar em contato em nome do usuário.

Como saber se o tíquete Kerberos obtido no cliente para enviar ao servidor Web usa delegação restrita ou irrestrita?

Use a ferramenta de comando klist presente no Windows para listar o cache de tíquetes Kerberos da máquina cliente (Workstation-Client1 no diagrama acima). Procure um tíquete chamado HTTP/<Nome do Servidor> Web. Observação: <o nome do servidor> Web é o SPN do serviço que você deseja contatar e autenticar via Kerberos. O ticket também contém algumas bandeiras. Dois deles são de interesse: forwardable e ok_as_delegate.

• O primeiro sinalizador, , indica que o KDC (centro de distribuição de chaves) pode emitir um novo tíquete com uma nova máscara de rede, forwardablese necessário. Isso permite que um usuário faça login em um sistema remoto e que o sistema remoto obtenha um novo tíquete em nome do usuário para fazer login em outro sistema de back-end como se o usuário tivesse feito login no sistema remoto localmente.

• O segundo sinalizador ok_as_delegate indica que a conta de serviço do serviço no qual o usuário está tentando se autenticar (no caso do diagrama acima, a conta do pool de aplicativos do pool de aplicativos do IIS que hospeda o aplicativo Web) é confiável para delegação irrestrita.

Se esses serviços estiverem usando delegação irrestrita, os tíquetes na máquina cliente conterão os ok_as_delegate sinalizadores e forwardable . Na maioria dos casos, quando a delegação restrita é configurada, os tickets não contêm o ok_as_delegate sinalizador, mas contêm o forwardable sinalizador.

Por que a delegação irrestrita funciona no Internet Explorer e não no Microsoft Edge?

Quando é feita uma tentativa de autenticação em um site usando a autenticação baseada em Kerberos, o navegador chama uma API do Windows para configurar o contexto de autenticação. A API em questão é InitializeSecurityContext. Essa API pode receber uma série de sinalizadores para indicar se o navegador permite o tíquete delegatable que o usuário recebeu. O tíquete é marcado como delegatable porque o serviço no qual o usuário está tentando se autenticar tem o direito de delegar credenciais de maneira irrestrita. No entanto, isso não significa que o aplicativo que está tentando se autenticar (neste caso, o navegador) deva usar essa capacidade.

Por padrão, o Internet Explorer passa o sinalizador para InitializeSecurityContext, indicando que, se o tíquete puder ser delegado, ele deverá ser. O Microsoft Edge da versão 87 e superior não passa o sinalizador apenas InitializeSecurityContext porque o tíquete está marcado com o ok_as_delegate sinalizador. Não recomendamos o uso da delegação irrestrita em aplicativos porque ela dá aos aplicativos mais privilégios do que o necessário. Os aplicativos podem delegar a identidade do usuário a qualquer outro serviço no domínio e autenticar como o usuário, o que não é necessário para a maioria dos aplicativos que usam a delegação de credenciais. Os aplicativos devem entrar em contato apenas com os serviços na lista que foi especificada ao configurar a delegação restrita.

Por padrão, o Microsoft Edge funciona com delegação restrita, em que o site do IIS em execução no Servidor Web só tem o direito de entrar em contato com o site da API de back-end hospedado no Servidor de API, conforme mostrado na configuração da conta de identidade do pool de aplicativos do Active Directory listada abaixo:

Habilitar o Edge-Chromium para trabalhar com delegação irrestrita no Active Directory

Para fins de compatibilidade, se você precisar manter um aplicativo usando delegação irrestrita via Kerberos, habilite o Microsoft Edge para permitir a delegação de tíquetes. As etapas abaixo são detalhadas nas seguintes seções deste artigo:

1. Instale os modelos administrativos do repositório central de Política de Grupo no Active Directory (se ainda não estiver presente).
2. Instale os modelos administrativos do Microsoft Edge.
3. Crie um novo objeto de Diretiva de Grupo.
4. Edite a configuração da Diretiva de Grupo para permitir a delegação irrestrita ao autenticar em servidores.
5. (Opcional) Verifique se o Microsoft Edge está usando os sinalizadores de delegação corretos.

Etapa 1: Instalar os modelos administrativos do Active Directory

1. Baixe os modelos de Modelos Administrativos (.admx) (para Windows Server 2019).

2. Baixe o instalador e extraia o conteúdo para uma pasta de sua escolha. Você pode simplesmente extraí-lo para o local padrão especificado do pacote, que é C:\Arquivos de Programas (x86)\Política de Grupo da Microsoft\Atualização de outubro de 2018 do Windows 10 (1809) v2\PolicyDefinitions.

3. Depois que o pacote for descompactado, localize a pasta Sysvol no controlador de domínio. O caminho para a pasta é C:\Windows\SYSVOL\sysvol\. Dentro da pasta Sysvol há uma pasta com o mesmo nome do Active Directory (no exemplo aqui, Oddessy.local). A partir daí, navegue até a pasta Políticas . Se não existir, crie uma pasta chamada Definições de Política , conforme mostrado abaixo:

   

4. Copie o conteúdo da pasta PolicyDefinitions (que foi extraída do instalador para a pasta PolicyDefinitions) que você criou dentro do domínio na pasta sysvol no controlador de domínio.

   Observação

   Os arquivos que foram extraídos pelo instalador também contêm conteúdo localizado. Para economizar espaço, transfira os arquivos localizados apenas para os idiomas desejados. Por exemplo, a pasta chamada fr-FR contém todo o conteúdo localizado em francês.

5. Quando a transferência for concluída, verifique se os modelos estão disponíveis no Active Directory. Para fazer isso, abra o snap-in Gerenciamento de Política de Grupo do Console de Gerenciamento Microsoft (pressione Windows+R e digite gpmc.msc para iniciar). Dentro do Gerenciamento de Política de Grupo, localize um objeto de política de grupo e edite-o.

   

   Conforme mostrado na captura de tela acima, no nó Configuração do Computador, há um nó Políticas e um nó Modelos administrativos.

Etapa 2: Instalar os modelos administrativos do Microsoft Edge

Embora você possa ter os Modelos Administrativos de Política no controlador de domínio para começar, você ainda precisará instalar os arquivos de Política do Microsoft Edge para ter acesso à política destinada a habilitar a delegação irrestrita de salto duplo por meio desse navegador. Para instalar os arquivos de política do Microsoft Edge, siga as etapas:

1. Acesse o site de download do Microsoft Edge para empresas.

2. Selecione a versão que deseja baixar no menu suspenso de canal/versão . A versão estável mais recente é recomendada.

3. Selecione a compilação desejada na lista suspensa de compilação e, finalmente, o sistema operacional de destino na lista suspensa da plataforma . Assim que a seleção for feita, mais dois botões (um botão e um link) aparecerão.

   

4. Clique em OBTER ARQUIVOS DE POLÍTICA e aceite o contrato de licença para baixar o arquivo chamado MicrosoftEdgePolicyTemplates.cab. Esse arquivo contém os arquivos de definição de política para o Microsoft Edge.

5. Clique duas vezes no arquivo para explorar o conteúdo (um arquivo zip com o mesmo nome).

6. Extraia o conteúdo do arquivo zip para uma pasta no disco local. O conteúdo extraído conterá uma pasta chamada Windows na qual você encontrará uma subpasta chamada Admx. Isso conterá os modelos administrativos, bem como suas versões localizadas (você deve precisar deles em um idioma diferente do inglês).

   

7. Transfira os arquivos .admx dentro da mesma pasta no diretório Sysvol para o qual os Modelos Administrativos anteriores foram transferidos (no exemplo acima: C:\Windows\SYSVOL\sysvol\odessy.local\Policies\PolicyDefinitions).

8. Abra o Editor de Política de Grupo do Active Directory e selecione um objeto de política de grupo existente para edição para verificar a presença dos modelos do Microsoft Edge recém-transferidos. Eles estarão localizados em uma pasta chamada Microsoft Edge localizada abaixo da pasta Modelos Administrativos no modo de exibição de árvore:

   

Etapa 3: Criar um novo objeto de Política de Grupo

Veja como criar um novo objeto de Política de Grupo usando o snap-in MMC do Gerenciador de Política de Grupo do Active Directory:

1. Pressione a tecla Windows+R para abrir o menu Executar no controlador de domínio.
2. Digite Gpmc.msc para abrir o Console de Gerenciamento Microsoft e carregar o snap-in do Gerenciador de Política de Grupo do Active Directory.
3. Localize o nó Objetos de Diretiva de Grupo no modo de exibição de árvore do console e clique com o botão direito do mouse no nó para abrir o menu de contexto.
4. Selecione o item de menu Novo, preencha o nome da política de grupo que deseja criar e clique em OK.

Etapa 4: Editar a configuração da Política de Grupo para permitir a delegação irrestrita ao autenticar em servidores

A etapa final é habilitar a política que permite que o navegador Microsoft Edge passe o sinalizador para a chamada de InitializeSecurityContext API ao executar a ok_as_delegate autenticação usando Kerberos em um site habilitado para Windows Integrado. Se você não souber se o navegador Microsoft Edge está usando Kerberos para autenticação (e não NTLM), consulte Solucionar problemas de falhas de Kerberos no Internet Explorer.

No Editor de Política de Grupo do Active Directory, selecione o objeto de política de grupo que será aplicado aos computadores dentro do Active Directory a partir do qual você pretende permitir que os usuários finais se autentiquem por meio da autenticação Kerberos e tenham suas credenciais delegadas aos serviços de back-end por meio de delegação irrestrita. A política que habilitará a delegação irrestrita do Microsoft Edge está localizada na pasta de autenticação HTTP dos modelos do Microsoft Edge , conforme mostrado abaixo:

Use essa configuração para configurar uma lista de servidores para os quais a delegação de tíquetes Kerberos é permitida.

Depois que o objeto de política de grupo recém-editado for aplicado aos computadores cliente dentro do domínio, vá para a página de autenticação de teste em Páginas de diagnóstico para solução de problemas de autenticação integrada do Windows e baixe a página whoami.aspx do Repositório de Exemplos do ASP.net no GitHub. Ele produzirá uma configuração ImpersonationLevel de Delegate em vez de Impersonate, sinalizando que a delegação de credenciais agora é permitida.

Para testar se a política foi aplicada corretamente na estação de trabalho do cliente, abra uma nova guia do Microsoft Edge e digite edge://policy.

A AuthNegotiateDelegateAllowlist política deve ser definida para indicar os valores dos nomes de servidor para os quais o Microsoft Edge tem permissão para executar a delegação de tíquetes Kerberos. Se a política não aparecer na lista, ela não foi implantada ou foi implantada nos computadores errados.

Etapa 5 (opcional): verifique se o Microsoft Edge está usando os sinalizadores de delegação corretos

Aqui está a etapa de solução de problemas/verificação opcional.

Depois que a política for configurada e implantada, as etapas a seguir deverão ser executadas para verificar se o Microsoft Edge está passando os sinalizadores de delegação corretos para IntializeSecurityContexto . As etapas usam ferramentas que já estão incorporadas ao Microsoft Edge ou que estão disponíveis como serviços online.

1. Use o recurso de log disponível no Microsoft Edge para registrar o que o navegador está fazendo ao solicitar um site. Para habilitar o registro em log:

   1. Abra uma nova janela do Microsoft Edge e digite edge://net-export/.

   2. Use a opção Incluir cookies e credenciais ao rastrear. Sem essa opção, os dados de nível de rastreamento de autenticação serão omitidos.

      

   3. Clique no botão Iniciar Registro em Log no Disco e forneça o nome do arquivo sob o qual você deseja salvar o rastreamento.

   4. Abra outra guia do Microsoft Edge, navegue até o site no qual você deseja executar a autenticação integrada do Windows usando o Microsoft Edge.

   5. Depois de tentar autenticar, volte para a guia anterior onde o rastreamento foi ativado e clique no botão Parar registro . A interface de rastreamento indicará onde o arquivo que contém o rastreamento foi gravado.

2. Use o arquivo JSON que contém o rastreamento para ver quais parâmetros o navegador passou para a InitializeSecurityContext função ao tentar autenticar. Para analisar o rastreamento, use o netlog_viewer.

3. Dentro do rastreamento analisado há um log de eventos semelhante ao seguinte:

   t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                         --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                         --> spn = "HTTP/web-server.odessy.local"
   

   Este registro mostra que:

   • AUTH_LIBRARY_INIT_SEC_CTX significa que o navegador está chamando a InitializeSecurityContext função.
   • "delegated":false significa que o ticket não deve ser delegado, mesmo que esteja marcado como delegatable.
   • "mutual":false significa que o cliente (navegador) não exige que o servidor também se autentique no cliente e prove sua identidade. Somente o cliente deve se autenticar no servidor para provar sua identidade.
   • HTTP/web-server.odessy.local é o SPN usado pelo navegador ao fazer a chamada de autenticação.

Mais informações

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