Share via

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

  • Artigo

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

Este diagrama explica o fluxo de quando um usuário tenta acessar um aplicativo local que usa a Autenticação Integrada do Windows (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.
  • O servidor que executa o conector tem acesso de leitura ao atributo TokenGroupsGlobalAndUniversal para usuários. Essa configuração padrão pode ter sido afetada pelo aumento das restrições de segurança que protegem o ambiente.

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. Isso permite que o conector de rede privada represente usuários no AD para 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. Use a propriedade principalsallowedtodelegateto da conta de serviço (conta de usuário do computador ou do domínio dedicado) do aplicativo web para habilitar a delegação de autenticação do Kerberos do proxy de aplicativo (conector). O servidor de aplicativos está sendo executado no contexto de webserviceaccount e o servidor de delegação é connectorcomputeraccount. Execute os comandos abaixo em um controlador de domínio (executando o Windows Server 2012 R2 ou posterior) no domínio de webserviceaccount. 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 o aplicativo aparecer na lista de aplicativos empresariais, selecione-o e clique em 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. Esse 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. Esse processo é conhecido como KCD (delegação restrita do 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. Esse mecanismo é compatível com o Proxy de Aplicativo do Microsoft Entra, mas é 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. 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. No prompt de comando, execute os seguintes comandos em servidores do conector 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 identificação de logon delegada para conectar as identidades de nuvem às identidades de aplicativo.

Trabalhando com identidades diferentes de nuvem e local

O proxy de aplicativo pressupõe que os usuários têm 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 talvez precisem usar IDs alternativas para entrar. Nesses casos, você ainda pode usar o KCD para logon único. Configure uma Identificação de logon delegada para cada aplicativo a fim de especificar qual identidade deve ser usada ao realizar o logon único.

Essa capacidade permite que muitas organizações com identidades diferentes localmente e na nuvem usem o SSO da nuvem para aplicativos locais, sem exigir que os usuários insiram senhas e nomes de usuários diferentes. Isso inclui as organizações que:

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

Com o proxy de aplicativo, você pode selecionar qual identidade deve ser usada para obter o tíquete do 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 email, e outras são desenvolvidas para logon alternativo.

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

Se a identidade de logon delegada for usada, o valor não poderá ser exclusivo em todos os domínios ou florestas em 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 logon, o computador que hospeda o conector precisará 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). Isso é feito como parte do processo de personalização, alterando o campo Nome UPN 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 houver um erro no processo de SSO, ele aparecerá no log de eventos do computador do conector, conforme explicado na Solução de problemas. Porém, em alguns casos, a solicitação será enviada com êxito para o aplicativo de back-end embora este aplicativo responderá em várias outras respostas HTTP. Nesses casos, a solução de problemas deve começar por examinar o evento número 24029 no computador do conector no log de eventos da sessão do proxy de aplicativo. A identidade do usuário que foi usada para delegação será exibida no campo "usuário" nos 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óximas etapas