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, use a confiança Kerberos na nuvem do Windows Hello for Business para permitir o logon único para os usuários.
Pré-requisitos
Antes de começar com o logon único, verifique se o ambiente está pronto.
- Uma floresta do Ative Directory. O guia usa um nome de domínio de 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.
- Entre no Microsoft Entra como pelo menos um administrador de aplicativos.
- Navegue até Global Secure Access>Applications>Enterprise Applications.
- Selecione Nova Aplicação.
- Adicione um novo segmento de aplicativo com o IP do seu servidor de arquivos usando a porta
445/TCPe selecione Salvar. O protocolo SMB (Server Message Block) usa a porta. - 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 Usuário) e a senha do usuário são usados para solicitar um Tíquete de Concessão de Tíquete Kerberos (TGT). Para obter mais informações sobre esse fluxo, consulte Como o SSO para recursos locais funciona em dispositivos associados do Microsoft Entra.
Dispositivos associados ao Microsoft Entra ID e híbridos do Microsoft Entra ID – logon único do Windows Hello for Business
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 na nuvem recebem um tíquete TGT que é usado para logon único. Para saber mais sobre a confiança Kerberos na nuvem, consulte Habilitar a entrada de chave de segurança sem senha em recursos locais usando a ID do Microsoft Entra.
Para implantar a confiança Kerberos na nuvem do Windows Hello for Business com o Ative Directory local.
- Crie o objeto de servidor Kerberos do Microsoft Entra ID. Para saber como criar o objeto, consulte Instalar o módulo AzureADHybridAuthenticationManagement.
- 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 tíquetes Kerberos. Os tíquetes 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.
| Porta | Protocolo | Propósito |
|---|---|---|
| 88 | Protocolo de Datagrama de Usuário (UDP) / Protocolo de Controle de Transmissão (TCP) | Kerberos |
| 389 | UDP | Localizador DC |
| 464 | UDP/TCP | Pedido de alteração de palavra-passe |
| 123 | UDP | Sincronização de tempo |
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.).
- Entre no Microsoft Entra como pelo menos um administrador de aplicativos.
- Navegue até Global Secure Access>Applications>Enterprise Applications.
- Selecione Novo Aplicativo para criar um novo aplicativo para publicar seus Controladores de Domínio.
- 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 curinga para publicar seus controladores de domínio, em vez disso, adicione 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 o início de sessão único. Os clientes os usam para acessar recursos publicados no local. Para saber mais sobre o DNS privado com acesso rápido, consulte how-to-configure-quick-access.md#add-private-dns-suffixes.
- Navegue até Acesso rápido a aplicativos>de acesso>seguro global.
- Selecione a guia DNS privado e, em seguida, selecione Ativar DNS privado.
- Selecione Adicionar sufixo DNS. No mínimo, adicione os sufixos de nível superior das florestas do Ative Directory que hospedam usuários sincronizados com o ID do Microsoft Entra.
- 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 | Description |
|---|---|
| A | O usuário tenta acessar o compartilhamento de arquivos SMB usando FQDN. O Cliente GSA interceta o tráfego e o encapsula até a borda SSE. As políticas de autorização no Microsoft Entra ID são avaliadas e impostas, como se o usuário está atribuído ao aplicativo e ao Acesso Condicional. 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. |
| N | 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 acessar o compartilhamento de arquivos 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 (se ainda não tiver 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 o aplicativo Enterprise que publica os controladores de domínio locais. 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 usado para solicitar e receber um TGS para o compartilhamento de arquivos SMB. |
| G | O cliente apresenta o TGS ao compartilhamento de arquivos SMB. O compartilhamento de arquivos SMB valida o TGS. O acesso ao compartilhamento de arquivos é concedido. |
Resolver 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 não elevada.
dsregcmd /status
Verifique se os atributos têm YES como valores.
PRT devem estar presentes. Para saber mais sobre PRTo , 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 usuário recebeu um TGT parcial para SSO para recursos locais. 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 a klist bandeira.
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 cache negativo Kerberos causa um atraso nos tíquetes 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 atenuar esse problema, você pode alterar a hora padrão FarKdcTimeout no Registro ou liberar manualmente instantaneamente 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 a proteção de suporte, o registo para o qual pretende modificar. Em seguida, pode restaurar o registo se o problema ocorrer. 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 Registro 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