Partilhar via

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 nos seus aplicativos usando a autenticação integrada do Windows (IWA) concedendo aos conectores de rede privada no Active Directory permissão para personificar utilizadores. Os conectores usam essa permissão para enviar e receber tokens em seu nome.

Como funciona o logon único com o KCD

O diagrama explica o fluxo quando um usuário tenta acessar um aplicativo local que usa 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 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 local, representando o utilizador para obter um token 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 Principal 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.
  • Verifique se o servidor Connector pode ler o TokenGroupsGlobalAndUniversal atributo para os usuários. O endurecimento da segurança pode restringir esse acesso. Habilite os servidores de conectores ao adicioná-los ao grupo Acesso de Autorização do Windows.

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

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

  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. A configuração permite que o conector de rede privada represente utilizadores no Active Directory relativamente às aplicações definidas na lista.

    Captura de ecrã da janela de propriedades do conector-SVR

Conector e servidor de aplicação localizados em diferentes domínios

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

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

    Se a 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 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 a autenticação única

  1. Publique a sua aplicação de acordo com as instruções descritas em Publicar aplicações com proxy de aplicação. 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 selecione Logon único.

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

  4. Insira o SPN da aplicação interna do servidor de aplicações. Neste exemplo, o SPN do nosso aplicativo publicado é http/www.contoso.com. O 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 ser usada pelo conector em nome dos seus utilizadores. Para obter mais informações, consulte Trabalhando com diferentes identidades locais e na nuvem.

    Configuração Avançada de Aplicações

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

O fluxo de delegação Kerberos no proxy de aplicações 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. O processo é conhecido como Delegação Restrita de Kerberos (KCD).

Na próxima fase, uma solicitação é enviada para a aplicação de back-end com esse bilhete 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. O 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. As aplicações que requerem um token Kerberos padrão devem ser encaminhadas através de outros conectores que não estejam 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. 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 entrada delegada 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 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 aplicativos. Você ainda pode habilitar o KCD para logon único configurando uma identidade de login delegado 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 nomes de usuário e senhas diferentes. Os cenários comuns incluem:

  • Usando vários domínios internos (por exemplo, joe@us.contoso.com, joe@eu.contoso.com) com 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).
  • Atribuição de aliases diferentes para usuários locais e na nuvem (por exemplo, joe-johns@contoso.com vs. joej@contoso.com).

Com o proxy do aplicativo, você pode escolher a identidade usada para obter o tíquete Kerberos. Esta definição é definida por aplicação e suporta sistemas que requerem formatos que não sejam de e-mail ou métodos de início de sessão alternativos.

Captura de tela do parâmetro de identidade de login delegado

Se a identidade de entrada delegada 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 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 identidades diferentes

  1. Configure as configurações do Microsoft Entra Connect para que a identidade principal seja o endereço de e-mail (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, computadores Windows e outros aplicativos que usam o Microsoft Entra ID como armazenamento de identidade.
    Captura de ecrã Identificar utilizadores - Lista pendente Nome Principal do Utilizador

  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 utilizador parte do Nome Principal de Utilizador 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 a aplicação back-end responder com respostas HTTP inesperadas, inicie a resolução de problemas verificando o evento 24029 no evento de início de sessão da sessão de proxy da aplicação na máquina conectora. O campo "utilizador" nos detalhes do evento mostra a identidade usada para a delegação. Para habilitar logs de sessão, vá para o Visualizador de Eventos, abra o menu Exibir e selecione Mostrar logs analíticos e de depuração.

Próximos passos