Delegação restrita de Kerberos para logon único (SSO) para seus aplicativos com proxy de aplicativo

Você pode fornecer logon único para aplicativos locais publicados por meio de proxy de aplicativo que são protegidos com autenticação integrada do Windows. Estas aplicações requerem uma permissão de acesso do Kerberos. O proxy de aplicativo usa a Delegação Restrita de Kerberos (KCD) para dar suporte a esses aplicativos.

Para saber mais sobre o logon único (SSO), consulte O que é logon único?.

Você pode habilitar o logon único em seus aplicativos usando a autenticação integrada do Windows (IWA) dando permissão aos conectores de rede privada no Ative Directory para representar usuários. Os conectores usam essa permissão para enviar e receber tokens em seu nome.

Como funciona o logon único com o KCD

Este diagrama explica o fluxo quando um usuário tenta acessar um aplicativo local que usa IWA.

1. O usuário insere a URL para acessar o aplicativo local por meio do proxy do aplicativo.
2. O proxy de aplicativo redireciona a solicitação para os serviços de autenticação do Microsoft Entra para pré-autenticação. Neste ponto, o Microsoft Entra ID aplica todas as políticas de autenticação e autorização aplicáveis, como a autenticação multifator. Se o usuário for validado, o Microsoft Entra ID criará um token e o enviará para o usuário.
3. O usuário passa o token para o proxy do aplicativo.
4. O proxy de aplicativo valida o token e recupera o UPN (Nome Principal do Usuário) dele e, em seguida, o Conector extrai o UPN e o SPN (Nome da Entidade de Serviço) por meio de um canal seguro autenticado duplamente.
5. O Conector realiza a negociação da Delegação Restrita de Kerberos (KCD) com o AD no local ao representar o utilizador para obter um token do Kerberos para a aplicação.
6. O Active Directory envia o token do Kerberos da aplicação para o Conector.
7. O Conector envia o pedido original para o servidor de aplicações ao utilizar o token do Kerberos que recebeu do AD.
8. O aplicativo envia a resposta para o conector, que é então retornado para o serviço de proxy do aplicativo e, finalmente, para o usuário.

Pré-requisitos

Antes de começar com o logon único para aplicativos IWA, verifique se seu ambiente está pronto com as seguintes definições e configurações:

• Seus aplicativos, como os aplicativos Web do SharePoint, estão definidos para usar a autenticação integrada do Windows. Para obter mais informações, consulte Habilitar suporte para autenticação Kerberos ou para SharePoint consulte Planejar a autenticação Kerberos no SharePoint 2013.
• Todas as suas aplicações têm Nomes de Entidade de Serviço.
• O servidor que executa o Conector e o servidor que executa o aplicativo são associados ao domínio e fazem parte do mesmo domínio ou domínios confiáveis. Para obter mais informações sobre a associação a um domínio, consulte Associar um computador a um domínio.
• O servidor que executa o conector tem acesso para ler o atributo TokenGroupsGlobalAndUniversal para usuários. Essa configuração padrão pode ter sido afetada pela proteção de segurança do ambiente. Adicionar os servidores Connector ao "Grupo de Acesso de Autorização do Windows" normalmente fará isso.

Configurar o Active Directory

A configuração do Ative Directory varia, dependendo se o conector de rede privada e o servidor de aplicativos estão no mesmo domínio ou não.

Conector e servidor de aplicações no mesmo domínio

1. No Ative Directory, vá para Ferramentas>Usuários e Computadores.

2. Selecione o servidor que executa o conector.

3. Clique com o botão direito do mouse e selecione Delegação de propriedades>.

4. Selecione Confiar neste computador para delegação apenas a serviços especificados.

5. Selecione Usar qualquer protocolo de autenticação.

6. Em Serviços aos quais essa conta pode apresentar credenciais delegadas, adicione o valor para a identidade SPN do servidor de aplicativos. Isso permite que o conector de rede privada represente usuários no AD em relação aos aplicativos definidos na lista.

   

Conector e servidor de aplicações em diferentes domínios

1. Para obter uma lista de pré-requisitos para trabalhar com KCD entre domínios, consulte Delegação restrita de Kerberos entre domínios.

2. Use a principalsallowedtodelegateto propriedade da conta de serviço (computador ou conta de usuário de domínio dedicado) do aplicativo Web para habilitar a delegação de autenticação Kerberos do proxy do aplicativo (conector). O servidor de aplicativos está sendo executado no contexto de webserviceaccount e o servidor delegador é connectorcomputeraccount. Execute os comandos abaixo em um Controlador de Domínio (executando o Windows Server 2012 R2 ou posterior) no domínio do webserviceaccount. Use nomes simples (não UPN) para ambas as contas.

   Se a for uma conta de webserviceaccount computador, use estes comandos:

   $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com
   
   Set-ADComputer -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
   
   Get-ADComputer webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
   

   Se a webserviceaccount for uma conta de usuário, use estes comandos:

   $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com
   
   Set-ADUser -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
   
   Get-ADUser webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
   

Configurar o início de sessão único

1. Publique seu aplicativo de acordo com as instruções descritas em Publicar aplicativos com proxy de aplicativo. Certifique-se de selecionar Microsoft Entra ID como o método de pré-autenticação.

2. Depois que seu aplicativo aparecer na lista de aplicativos corporativos, selecione-o e clique em Logon único.

3. Defina o modo de logon único como Autenticação integrada do Windows.

4. Insira o SPN de aplicativo interno do servidor de aplicativos. Neste exemplo, o SPN do nosso aplicativo publicado é http/www.contoso.com. Esse SPN precisa estar na lista de serviços para os quais o conector pode apresentar credenciais delegadas.

5. Escolha a Identidade de Login Delegado para o conector usar em nome de seus usuários. Para obter mais informações, consulte Trabalhando com diferentes identidades locais e na nuvem.

   

SSO para aplicativos que não são do Windows

O fluxo de delegação Kerberos no proxy de aplicativo do Microsoft Entra começa quando o Microsoft Entra autentica o usuário na nuvem. Quando a solicitação chega localmente, o conector de rede privada Microsoft Entra emite um tíquete Kerberos em nome do usuário interagindo com o Ative Directory local. Esse processo é conhecido como Delegação Restrita de Kerberos (KCD).

Na próxima fase, uma solicitação é enviada para o aplicativo de back-end com esse tíquete Kerberos.

Existem vários mecanismos que definem como enviar o tíquete Kerberos em tais solicitações. A maioria dos servidores não-Windows espera recebê-lo na forma de token SPNEGO. Esse mecanismo é suportado no proxy de aplicativo Microsoft Entra, mas é desabilitado por padrão. Um conector pode ser configurado para SPNEGO ou token Kerberos padrão, mas não ambos.

Se você configurar uma máquina conectora para SPNEGO, certifique-se de que todos os outros conectores nesse grupo de conectores também estejam configurados com SPNEGO. Os aplicativos que esperam token Kerberos padrão devem ser roteados por meio de outros conectores que não estão configurados para SPNEGO. Algumas aplicações Web aceitam ambos os formatos sem exigir qualquer alteração na configuração.

Para habilitar o SPNEGO:

1. Abra um prompt de comando que seja executado como administrador.

2. No prompt de comando, execute os seguintes comandos nos servidores conectores que precisam de SPNEGO.

   REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft Entra private network connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1
   net stop WAPCSvc & net start WAPCSvc
   

Normalmente, os aplicativos que não são do Windows usam nomes de usuário ou nomes de conta SAM em vez de endereços de email de domínio. Se essa situação se aplicar aos seus aplicativos, você precisará configurar o campo de identidade de login delegado para conectar suas identidades de nuvem às identidades de aplicativos.

Trabalhar com diferentes identidades locais e na nuvem

O proxy de aplicativo pressupõe que os usuários tenham exatamente a mesma identidade na nuvem e no local. Mas em alguns ambientes, devido a políticas corporativas ou dependências de aplicativos, as organizações podem ter que usar IDs alternativas para entrar. Nesses casos, você ainda pode usar o KCD para logon único. Configure uma identidade de login delegado para cada aplicativo para especificar qual identidade deve ser usada ao executar o logon único.

Esse recurso permite que muitas organizações que têm identidades locais e na nuvem diferentes tenham SSO da nuvem para aplicativos locais sem exigir que os usuários insiram nomes de usuário e senhas diferentes. Isso inclui organizações que:

• Ter vários domínios internamente (joe@us.contoso.com, joe@eu.contoso.com) e um único domínio na nuvem (joe@contoso.com).
• Ter um nome de domínio não roteável internamente (joe@contoso.usa) e um legal na nuvem.
• Não use nomes de domínio internamente (joe)
• Use aliases diferentes no local e na nuvem. Por exemplo, joe-johns@contoso.com vs. joej@contoso.com

Com o proxy de aplicativo, você pode selecionar qual identidade usar para obter o tíquete Kerberos. Essa configuração é por aplicativo. Algumas dessas opções são adequadas para sistemas que não aceitam o formato de endereço de e-mail, outras são projetadas para login alternativo.

Se a identidade de login delegado for usada, o valor pode não ser exclusivo em todos os domínios ou florestas da sua organização. Você pode evitar esse problema publicando esses aplicativos duas vezes usando dois grupos de conectores diferentes. Como cada aplicativo tem um público de usuário diferente, você pode unir seus conectores a um domínio diferente.

Se o nome da conta SAM local for usado para a identidade de logon, o computador que hospeda o conector deverá ser adicionado ao domínio no qual a conta de usuário está localizada.

Configurar o SSO para identidades diferentes

1. Configure as configurações do Microsoft Entra Connect para que a identidade principal seja o endereço de e-mail (email). Isso é feito como parte do processo de personalização, alterando o campo Nome Principal do Usuário nas configurações de sincronização. Essas configurações também determinam como os usuários entram no Microsoft 365, computadores Windows e outros aplicativos que usam o Microsoft Entra ID como armazenamento de identidade.
   

2. Nas definições de Configuração do Aplicativo para o aplicativo que você deseja modificar, selecione a Identidade de Login Delegado a ser usada:

   • Nome Principal do Usuário (por exemplo, joe@contoso.com)
   • Nome principal de usuário alternativo (por exemplo, joed@contoso.local)
   • Nome de utilizador parte do Nome Principal do Utilizador (por exemplo, joe)
   • Nome de usuário parte do Nome Principal de Usuário Alternativo (por exemplo, joed)
   • Nome da conta SAM local (depende da configuração do controlador de domínio)

Resolver problemas do SSO para diferentes identidades

Se houver um erro no processo de SSO, ele aparecerá no log de eventos da máquina conectora, conforme explicado em Solução de problemas. Mas, em alguns casos, a solicitação é enviada com êxito para o aplicativo de back-end enquanto esse aplicativo responde em várias outras respostas HTTP. A solução de problemas desses casos deve começar examinando o número de evento 24029 na máquina conectora no log de eventos da sessão de proxy do aplicativo. A identidade do usuário que foi usada para delegação aparece no campo "usuário" dentro dos detalhes do evento. Para ativar o log de sessão, selecione Mostrar logs analíticos e de depuração no menu de exibição do visualizador de eventos.

Próximos passos

• Como configurar um aplicativo proxy de aplicativo para usar a delegação restrita de Kerberos
• Solucionar problemas que você está tendo com o proxy de aplicativo