Compartilhar via

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

Você pode fornecer o logon único para aplicativos locais publicados por meio do proxy de aplicativo que sejam protegidos com a autenticação integrada do Windows. Esses aplicativos exigem um tíquete Kerberos para acessar. O proxy de aplicativo usa a Delegação Restrita do Kerberos (KCD) para dar suporte a esses aplicativos.

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

Você pode habilitar o logon único para seus aplicativos usando a IWA (Autenticação Integrada do Windows) concedendo permissão aos conectores de rede privada no Active 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 a KCD

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

Diagrama de fluxo de autenticação do Microsoft Entra

  1. O usuário insere a URL para acessar o aplicativo local por meio do proxy de aplicativo.
  2. O proxy de aplicativo redireciona a solicitação para os serviços de autenticação do Microsoft Entra para serem pré-autenticados. Nesse 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 cria um token e o envia para o usuário.
  3. O usuário repassa o token para o proxy de aplicativo.
  4. O proxy de aplicativo valida o token, recupera o respectivo nome UPN e, em seguida, o Conector extrai o UPN e o Nome da Entidade de Serviço (SPN) por meio de um canal seguro com autenticação dupla.
  5. O conector realiza a negociação do KCD (Delegação Restrita de Kerberos) com o AD local, representando o usuário para obter um token Kerberos para o aplicativo.
  6. O Active Directory envia o token Kerberos para o aplicativo para o Conector.
  7. O Conector envia a solicitação original para o servidor de aplicativos usando o token Kerberos recebido do AD.
  8. O aplicativo envia a resposta para o Conector, que é, a seguir, retornada para o serviço do proxy de aplicativo e, finalmente, para o usuário.

Pré-requisitos

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

  • Seus aplicativos, como os aplicativos Web do SharePoint, são definidos para usar a Autenticação Integrada do Windows. Para sabe rmais, veja Habilitar suporte para autenticação Kerberos, ou para o SharePoint, consulte Planejar a autenticação Kerberos no SharePoint 2013.
  • Todos os seus aplicativos têm nome da entidade de serviço.
  • O servidor que executa o Conector e o servidor que executa o aplicativo que você está publicando são ingressados em domínio e fazem parte desse mesmo domínio ou em domínios confiáveis. Para obter mais informações sobre o ingresso no domínio, consulte Ingressar um computador em um domínio.
  • Verifique se o servidor conector pode ler o TokenGroupsGlobalAndUniversal atributo para os usuários. O endurecimento de segurança pode restringir esse acesso. Habilite os servidores conectores adicionando-os ao grupo acesso de autorização do Windows .

Configurar o Active Directory

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

O conector e o servidor de aplicativos estão no mesmo domínio

  1. No Active 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 Propriedades>Delegação.

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

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

  6. Em Serviços aos quais esta conta pode apresentar credenciais delegadas, adicione o valor da identidade SPN do servidor de aplicativos. A configuração permite que o conector de rede privada represente usuários no Active Directory (AD) contra os aplicativos definidos na lista.

    Captura de tela da janela Propriedades do Conector SVR

O conector e o servidor de aplicativos estão em domínios diferentes

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

  2. Para habilitar a delegação de autenticação Kerberos do proxy de aplicativo (conector), use a propriedade da conta de serviço da aplicação web (PrincipalsAllowedToDelegateTowebserviceaccount). O servidor de aplicativos é executado sob webserviceaccount, e o servidor de delegação é connectorcomputeraccount. Execute os comandos a seguir em um Controlador de Domínio (Windows Server 2012 R2 ou posterior) no mesmo domínio webserviceaccountque . Use nomes simples (não UPN) para ambas as contas.

    Se webserviceaccount for uma conta de 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 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 logon ú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 empresariais, selecione-o e selecione Logon único.

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

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

  5. Escolha a Identidade de Logon Delegada para que o conector use em nome de seus usuários. Para saber mais, confira Trabalhar com diferentes identidades de nuvem e locais.

    Configuração de Aplicativo Avançada

SSO para aplicativos não Windows

O fluxo de delegação do 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 do Microsoft Entra emite um tíquete Kerberos em nome do usuário, interagindo com o Active Directory local. O processo é conhecido como KCD (Delegação Restrita de Kerberos).

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

Há 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. O mecanismo tem suporte no proxy de aplicativo do Microsoft Entra, mas está desabilitado por padrão. Um conector pode ser configurado para o token Kerberos SPNEGO ou padrão, mas não para ambos.

Se você configurar um computador conector para SPNEGO, certifique-se de que todos os outros conectores nesse grupo conector também estejam configurados com SPNEGO. Os aplicativos que esperam o token Kerberos padrão devem ser roteados por meio de outros conectores que não estão configurados para SPNEGO. Alguns aplicativos Web aceitam os dois formatos sem a necessidade de alteração na configuração.

Para habilitar SPNEGO:

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

  2. Execute os comandos a seguir 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

Os aplicativos que não são do Windows normalmente utilizam 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 entrada delegado para conectar suas identidades de nuvem às identidades do aplicativo.

Trabalhando com identidades diferentes de nuvem e local

O proxy de aplicativo pressupõe que os usuários tenham a mesma identidade na nuvem e no local. No entanto, algumas organizações precisam usar IDs alternativas para entrar devido a políticas corporativas ou requisitos de aplicativo. Você ainda pode habilitar o KCD para logon único configurando uma identidade de logon delegada para cada aplicativo. Essa configuração especifica qual identidade usar para logon único.

Esse recurso permite que as organizações habilitem o SSO da nuvem para aplicativos locais sem exigir que os usuários gerenciem diferentes nomes de usuário e senhas. Cenários comuns incluem:

  • Usando vários domínios internos (por exemplo, joe@us.contoso.com, ) joe@eu.contoso.comcom um único domínio de nuvem (por exemplo, joe@contoso.com).
  • Ter nomes de domínio internos não roteáveis (por exemplo, joe@contoso.usa) ao usar nomes de domínio válidos na nuvem.
  • Operando sem nomes de domínio internos (por exemplo, joe).
  • Atribuir aliases diferentes para usuários locais e na nuvem (por exemplo, joe-johns@contoso.com vs. joej@contoso.com).

Com o proxy de aplicativo, você pode escolher a identidade usada para obter o tíquete Kerberos. Essa configuração é configurada por aplicativo e dá suporte a sistemas que exigem formatos nonemail ou métodos alternativos de entrada.

Captura de tela de parâmetro de identidade de logon delegada

Se a identidade de entrada delegada for usada, o valor poderá 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 com dois grupos diferentes de Conectores. Como cada aplicativo tem um público de usuários diferente, é possível ingressar seus Conectores em um domínio diferente.

Se o nome da conta SAM local for usado para a identidade de entrada, 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 diferentes identidades

  1. Defina as configurações do Microsoft Entra Connect para que a identidade principal seja o endereço de email (email). A configuração é feita 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, em computadores Windows e outros aplicativos que usam o Microsoft Entra ID como seu repositório de identidades.
    Identificando a captura de tela de usuários - lista suspensa Nome UPN

  2. Nas definições de configuração de aplicativo para o aplicativo que você deseja modificar, selecione a Identidade de Logon Delegada a ser usada:

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

Solucionando problemas de SSO para diferentes identidades

Se o aplicativo de back-end responder com respostas HTTP inesperadas, inicie a solução de problemas verificando o evento 24029 na entrada do evento de sessão do proxy de aplicativo no computador conector. O campo "usuário" nos detalhes do evento mostra a identidade usada para delegação. Para habilitar os logs de sessão, acesse o Visualizador de Eventos, abra o menu Exibir e selecione Mostrar logs analíticos e de depuração.

Próximas etapas