Use Kerberos para logon único (SSO) para seus recursos com o Microsoft Entra Private Access

Forneça logon único para recursos locais publicados por meio do Microsoft Entra Private Access. O Microsoft Entra Private Access usa Kerberos para oferecer suporte a esses recursos. Opcionalmente, utilize a confiança Kerberos em cloud do Windows Hello para Empresas para permitir single sign-on para utilizadores.

Pré-requisitos

Antes de começar com o logon único, verifique se o ambiente está pronto.

• Uma floresta do Ative Directory. O guia utiliza um nome de domínio da floresta que pode ser resolvido publicamente. No entanto, um domínio resolvido publicamente não é um requisito.
• Você habilitou o perfil de encaminhamento do Microsoft Entra Private Access.
• A versão mais recente do conector Microsoft Entra Private Access está instalada num servidor Windows que tem acesso aos controladores de domínio.
• A versão mais recente do cliente Global Secure Access. Para obter mais informações sobre o cliente, consulte Clientes de acesso seguro global.

Publicar recursos para uso com logon único

Para testar o logon único, crie um novo aplicativo corporativo que publique um compartilhamento de arquivos. O uso de um aplicativo corporativo para publicar seu compartilhamento de arquivos permite atribuir uma política de Acesso Condicional ao recurso e impor controles de segurança extras, como autenticação multifator.

1. Entre no Microsoft Entra como pelo menos um Administrador de Aplicações .
2. Navegue até Global Secure Access>Aplicações>Aplicações Empresariais.
3. Selecione Nova Aplicação.
4. Adicione um novo segmento de aplicativo com o IP do seu servidor de arquivos usando a porta 445/TCP e selecione Salvar. O protocolo SMB (Server Message Block) usa a porta.
5. Abra o aplicativo empresarial que você criou e selecione Usuários e Grupos para atribuir acesso ao recurso.

Dispositivos associados ao Microsoft Entra ID - SSO baseado em senha

Não é necessária uma configuração adicional para além deste guia se os utilizadores utilizarem palavras-passe para iniciar sessão no Windows.

Os dispositivos ingressados no Microsoft Entra ID dependem do domínio do Ative Directory e das informações do usuário sincronizadas pelo Microsoft Entra ID Connect. O localizador do controlador de domínio do Windows localiza os controladores de domínio devido à sincronização. O UPN (Nome Principal do Utilizador) e a senha do utilizador são usados para solicitar um TGT (Tíquete de Concessão de Tíquete) Kerberos. Para obter mais informações sobre esse fluxo, consulte Como o SSO para recursos locais funciona em dispositivos associados do Microsoft Entra.

Dispositivos em associação com Microsoft Entra ID e dispositivos híbridos associados ao Microsoft Entra ID – início de sessão único com Windows Hello para Empresas

Configuração extra além deste guia é necessária para o Windows Hello for Business.

Recomenda-se a implantação do Hybrid Cloud Kerberos Trust com o Microsoft Entra ID. Os dispositivos que usam a confiança Kerberos em ambiente de nuvem recebem um tíquete TGT que é usado para autenticação única. Para saber mais sobre a confiança de Kerberos na nuvem, consulte Habilitar o início de sessão com chave de segurança sem palavra-passe em recursos locais usando o Microsoft Entra ID.

Para implantar a confiança Kerberos em nuvem para o Windows Hello for Business com o Active Directory local.

1. Crie o objeto de servidor Kerberos do Microsoft Entra ID. Para saber como criar o objeto, consulte Instalar o módulo AzureADHybridAuthenticationManagement.
2. Habilite o WHfB Cloud Trust em seus dispositivos usando o Intune ou as Políticas de Grupo. Para saber como habilitar o WHfB, consulte Guia de implantação de confiança do Cloud Kerberos.

Publicar controladores de domínio

Os Controladores de Domínio devem ser publicados para que os clientes obtenham bilhetes Kerberos. Os bilhetes são necessários para o logon único em recursos locais.

No mínimo, publique todos os Controladores de Domínio configurados no site do Ative Directory onde os conectores de Acesso Privado estão instalados. Por exemplo, se os conectores de Acesso Privado estiverem no data center de Brisbane, publique todos os Controladores de Domínio no data center de Brisbane.

As portas do Controlador de Domínio são necessárias para habilitar o SSO para recursos locais.

Porto	Protocolo	Propósito
88	Protocolo de Datagrama de Usuário (UDP) / Protocolo de Controle de Transmissão (TCP)	Kerberos
123	UDP	NTP (Network Time Protocol)
135	UDP/TCP	Operações de controlador de domínio para controlador de domínio e de cliente para controlador de domínio.
138	UDP	Serviço de replicação de ficheiros entre controladores de domínio
139	TCP	Serviço de replicação de ficheiros entre controladores de domínio
389	UDP	Localizador DC
445	UDP/TCP	Replicação, Autenticação de Utilizadores e Computadores, Política de Grupo
464	UDP/TCP	Pedido de alteração de palavra-passe
636	TCP	LDAP SSL
1025-5000	UDP/TCP	Portas efémeras, inclui 3268-3269 TCP usado para catálogo global do cliente ao controlador de domínio
49152-65535	UDP/TCP	Portas efémeras

Nota

O guia se concentra em habilitar o SSO para recursos locais e exclui a configuração necessária para que os clientes ingressados no domínio do Windows executem operações de domínio (alteração de senha, Diretiva de Grupo, etc.). Para saber mais sobre os requisitos de portas de rede do Windows, consulte Visão geral dos serviços e requisitos de portas de rede para Windows.

1. Entre no Microsoft Entra como pelo menos um Administrador de Aplicações .
2. Navegue até Global Secure Access>Aplicações>Aplicações Empresariais.
3. Selecione Novo Aplicativo para criar um novo aplicativo para publicar seus Controladores de Domínio.
4. Selecione Adicionar segmento de aplicativo e, em seguida, adicione todos os IPs ou FQDNs (Nomes de Domínio Totalmente Qualificados) e portas dos controladores de domínio, conforme a tabela. Somente os Controladores de Domínio no site do Ative Directory onde os conectores de Acesso Privado estão localizados devem ser publicados.

Nota

Certifique-se de não usar FQDNs com caracteres curinga para publicar os seus controladores de domínio, ao invés disso, adicione os seus IPs ou FQDNs específicos.

Depois que o aplicativo corporativo for criado, navegue de volta para o aplicativo e selecione Usuários e Grupos. Adicione todos os usuários sincronizados do Ative Directory.

Publicar sufixos DNS

Configure o DNS privado para que os clientes de Acesso Seguro Global possam resolver nomes DNS privados. Os nomes DNS privados são necessários para a autenticação única. Os clientes os usam para acessar recursos publicados no local. Para saber mais sobre DNS privado com acesso rápido, consulte how-to-configure-quick-access.md#add-private-dns-suffixes.

1. Navegue até Acesso Seguro Global>Aplicações>Acesso Rápido.
2. Selecione o separador DNS privado e depois selecione Ativar DNS privado.
3. Selecione Adicionar sufixo DNS. No mínimo, adicione os sufixos de nível superior das florestas do Active Directory que hospedam utilizadores sincronizados com o Microsoft Entra ID.
4. Selecione Guardar.

Como usar o SSO Kerberos para acessar um compartilhamento de arquivos SMB

Este diagrama demonstra como o Microsoft Entra Private Access funciona ao tentar acessar um compartilhamento de arquivos SMB de um dispositivo Windows configurado com o Windows Hello for Business + Cloud Trust. Neste exemplo, o administrador configurou o DNS Privado de Acesso Rápido e dois aplicativos empresariais - um para os Controladores de Domínio e outro para o compartilhamento de arquivos SMB.

Passo	Descrição
Um	O usuário tenta acessar o compartilhamento de arquivos SMB usando FQDN. O Cliente GSA interceta todo o tráfego e encaminha-o para o SSE Edge. As políticas de autorização no Microsoft Entra ID são avaliadas e aplicadas, por exemplo, se o utilizador está atribuído à aplicação e se o Acesso Condicional é cumprido. Depois que o usuário tiver sido autorizado, o Microsoft Entra ID emitirá um token para o Aplicativo Empresarial SMB. O tráfego é liberado para continuar para o serviço de Acesso Privado junto com o token de acesso do aplicativo. O serviço de Acesso Privado valida o token de acesso e a conexão é intermediada para o serviço de back-end de Acesso Privado. A conexão é então intermediada para o conector de rede privada.
B	O Conector de Rede Privada executa uma consulta DNS para identificar o endereço IP do servidor de destino. O serviço DNS na rede privada envia a resposta. O Conector de Rede Privada tenta aceder à partilha de ficheiros SMB de destino que, em seguida, solicita autenticação Kerberos.
C	O cliente gera uma consulta DNS SRV para localizar controladores de domínio. A fase A é repetida, intercetando a consulta DNS e autorizando o usuário para o aplicativo de Acesso Rápido. O Conector de Rede Privada envia a consulta DNS SRV para a rede privada. O serviço DNS envia a resposta DNS para o cliente através do Conector de Rede Privada.
D	O dispositivo Windows solicita um TGT parcial (também chamado Cloud TGT) do Microsoft Entra ID, caso ainda não tenha um. O Microsoft Entra ID emite um TGT parcial.
E	O Windows inicia uma conexão de localizador de DC pela porta UDP 389 com cada controlador de domínio listado na resposta DNS da fase C. A fase A é repetida, intercetando o tráfego do localizador de DC e autorizando o usuário para a aplicação empresarial que publica os controladores de domínio on-premises. O Conector de Rede Privada envia o tráfego do localizador de DC para cada controlador de domínio. As respostas são retransmitidas ao cliente. O Windows seleciona e armazena em cache o controlador de domínio com a resposta mais rápida.
F	O cliente troca o TGT parcial por um TGT completo. O TGT completo é então utilizado para solicitar e receber um TGS para o compartilhamento de arquivos SMB.
G	O cliente apresenta o TGS à partilha de ficheiros SMB. O compartilhamento de arquivos SMB valida o TGS. O acesso ao compartilhamento de arquivos é concedido.

Resolução de Problemas

Os dispositivos ingressados no Microsoft Entra ID que usam autenticação de senha dependem de atributos que estão sendo sincronizados pelo Microsoft Entra ID Connect. Certifique-se de que os atributos onPremisesDomainName, onPremisesUserPrincipalNamee onPremisesSamAccountName têm os valores corretos. Use o Graph Explorer e o PowerShell para verificar os valores.

Se esses valores não estiverem presentes, verifique as configurações de sincronização do Microsoft Entra ID Connect e valide se esses atributos estão sendo sincronizados. Para saber mais sobre a sincronização de atributos, consulte Microsoft Entra Connect Sync: atributos sincronizados com o Microsoft Entra ID.

Se estiver a utilizar o Windows Hello para Empresas para iniciar sessão, execute os comandos a partir de uma linha de comandos sem privilégios elevados. dsregcmd /status

Verifique se os atributos têm YES como valores.

PRT deve estar presente. Para saber mais sobre PRT, consulte Solucionar problemas de token de atualização primário em dispositivos Windows.

OnPremTgt : SIM indica que o Entra Kerberos está configurado corretamente e o utilizador recebeu um TGT parcial para SSO em recursos no local. Para saber mais sobre como configurar a confiança Kerberos na nuvem, consulte Entrada de chave de segurança sem senha em recursos locais.

Execute o comando klist.

klist cloud_debug

Verifique se o Cloud Primary (Hybrid logon) TGT available: campo tem um valor de 1.

Execute o comando nltest.

nltest /dsgetdc:contoso /keylist /kdc

Verifique se o localizador de DC retorna um Controlador de Domínio que é participante de operações de confiança Kerberos na nuvem. O DC retornado deve ter o klist indicador.

Como evitar o cache negativo Kerberos em máquinas Windows

Kerberos é o método de autenticação preferencial para serviços no Windows que verificam identidades de usuário ou host. O armazenamento em cache negativo do Kerberos provoca um atraso nos bilhetes Kerberos.

O cache negativo Kerberos ocorre em dispositivos Windows que têm o cliente Global Secure Access instalado. O cliente GSA tenta se conectar ao Controlador de Domínio mais próximo para o tíquete Kerberos, mas a solicitação falha porque o cliente GSA ainda não está conectado ou o Controlador de Domínio não está acessível naquele momento. Quando a solicitação falhar, o cliente não tenta se conectar ao controlador de domínio novamente, imediatamente, porque o tempo padrão FarKdcTimeout no registro é definido como 10 minutos. Embora o cliente GSA possa estar conectado antes desse tempo padrão de 10 minutos, o cliente GSA mantém a entrada de cache negativa e acredita que o processo de localização do controlador de domínio é uma falha. Quando o tempo padrão de 10 minutos for concluído, o cliente GSA consultará o Controlador de Domínio com o tíquete Kerberos e a conexão será bem-sucedida.

Para mitigar esse problema, pode-se alterar a hora padrão FarKdcTimeout no registo ou libertar instantaneamente e manualmente o cache Kerberos sempre que o cliente GSA for reiniciado.

Opção 1: Alterar o tempo padrão FarKdcTimeout no registro

Se você estiver executando o Windows, poderá modificar os parâmetros Kerberos para ajudar a solucionar problemas de autenticação Kerberos ou para testar o protocolo Kerberos.

Importante

Esta secção, método ou tarefa contém passos que explicam como modificar o registo. No entanto, poderão ocorrer problemas graves se modificar o registo incorretamente. Consequentemente, certifique-se de que segue estes passos cuidadosamente. Para maior proteção, faça backup do registo antes de o modificar. Em seguida, pode restaurar o registo caso ocorra um problema. Para mais informações sobre como fazer uma cópia de segurança e restaurar o registo, consulte Como fazer uma cópia de segurança e restaurar o registo no Windows.

Entradas e valores do Registo sob a chave Parâmetros

As entradas do Registro listadas nesta seção devem ser adicionadas à seguinte subchave do Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Nota

Se a chave não estiver listada Parameters em Kerberos, você deverá criá-la.

Modifique a seguinte FarKdcTimeout entrada do Registro:

• Entrada: FarKdcTimeout
• Tipo: REG_DWORD
• Valor predefinido: 0 (minutes)

É o valor de tempo limite usado para invalidar um controlador de domínio de um site diferente no cache do controlador de domínio.

Opção 2: Limpeza manual de cache Kerberos

Se você optar por limpar manualmente o cache Kerberos, essa etapa terá que ser concluída sempre que o cliente GSA for reiniciado.

Abra um prompt de comando como administrador e execute o seguinte comando: KLIST PURGE_BIND

Próximos passos

• Clientes de Acesso Seguro Global