Usar o Kerberos para SSO (logon único) para seus recursos com o Acesso privado do Microsoft Entra
Forneça o logon único para recursos locais publicados por meio do Acesso privado do Microsoft Entra. O Acesso privado do Microsoft Entra emprega o Kerberos para dar suporte a esses recursos. Como opção, use o Windows Hello para Empresas com confiança Kerberos na nuvem para permitir o logon único aos usuários.
Pré-requisitos
Antes de começar a usar o logon único, verifique se o ambiente está preparado.
- Conta com uma floresta do Active Directory. O guia usa um nome de domínio de floresta que pode ser resolvido publicamente. No entanto, ter um domínio resolvido publicamente não é um requisito.
- Você habilitou o perfil de encaminhamento do Acesso privado do Microsoft Entra.
- A versão mais recente do conector do Acesso Privado do Microsoft Entra está instalada em um servidor Windows que tem acesso aos seus controladores de domínio.
- Possui a versão mais recente do cliente do Acesso Global Seguro. Para obter mais informações, confira o artigo Clientes do Acesso Global Seguro.
Publicar recursos para usar com o logon único
Para testar o logon único, crie um novo aplicativo empresarial que publique um compartilhamento de arquivos. Publicar seu compartilhamento de arquivos por meio de um aplicativo empresarial permite que você defina uma política de Acesso Condicional para o recurso e aplique controles de segurança adicionais, como a autenticação multifator.
- Entre no Microsoft Entra como, pelo menos, um Administrador de aplicativos.
- Navegue até Acesso Global Seguro>Aplicativos>Aplicativos Corporativos.
- Selecione Novo Aplicativo.
- Adicione um novo segmento de aplicativo com o IP do servidor de arquivos usando a porta
445/TCPe depois selecione Salvar. O protocolo SMB (Server Message Block) usa essa porta. - Abra o aplicativo empresarial que você criou e selecione Usuários e Grupos para atribuir acesso ao recurso.
Dispositivos ingressados no Microsoft Entra ID: SSO baseado em senha
Não é preciso realizar configurações extras além desse guia se os usuários usarem senhas para entrar no Windows.
Os dispositivos ingressados no Microsoft Entra ID dependem do domínio do Active Directory e das informações do usuário sincronizadas pelo Microsoft Entra ID Connect. O localizador do controlador de domínio do Windows identifica os controladores de domínio por causa da sincronização. O nome UPN e a senha do usuário são usados para solicitar um TGT (tíquete de concessão de tíquete) do Kerberos. Para obter mais informações sobre esse processo, confira o artigo: Como funciona o SSO para recursos locais em dispositivos ingressados no Microsoft Entra.
Dispositivos ingressados no Microsoft Entra ID e dispositivos ingressados no Microsoft Entra ID híbrido – logon único do Windows Hello para Empresas
É necessário realizar configurações extras além desse guisa para o Windows Hello para Empresas.
Recomenda-se a implantação da Confiança Kerberos na Nuvem Híbrida com o Microsoft Entra ID. Os dispositivos que usam a confiança Kerberos na nuvem recebem um tíquete TGT usado para logon único. Para saber mais sobre a confiança do Kerberos na nuvem, confira o artigo: Habilitar o logon sem senha com chave de segurança em recursos locais usando o Microsoft Entra ID.
Para implementar o Windows Hello para Empresas com confiança Kerberos na nuvem com o Active Directory local.
- Crie o objeto de servidor Kerberos do Microsoft Entra ID. Para aprender como criar o objeto, veja Instalar o módulo AzureADHybridAuthenticationManagement.
- Habilite a Confiança WHfB na Nuvem em seus dispositivos usando o Intune ou Políticas de Grupo. Para aprender a habilitar o WHfB, confira o Guia de implantação de confiança Kerberos na nuvem.
Publicar controladores de domínio
Os Controladores de Domínio devem ser publicados para que os clientes recebam os tíquetes de autenticação Kerberos. Os tíquetes são necessários para fazer logon único em recursos locais.
No mínimo, publique todos os Controladores de Domínio configurados no site do Active Directory em que os conectores do Acesso Privado estão instalados. Por exemplo, se os conectores do 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 em recursos locais.
| Porta | Protocolo | Finalidade |
|---|---|---|
| 88 | Protocolo UDP/Protocolo TCP | Kerberos |
| 389 | UDP | Localizador de controlador de domínio |
| 464 | UDP/TCP | Solicitação de alteração de senha |
| 123 | UDP | Sincronização de horário |
Observação
O foco desse guia é habilitar o SSO em recursos locais e não inclui as configurações necessárias para que clientes conectados ao domínio do Windows realizem operações de domínio (como alteração de senha, Política de Grupo etc.).
- Entre no Microsoft Entra como, pelo menos, um Administrador de aplicativos.
- Navegue até Acesso Global Seguro>Aplicativos>Aplicativos Corporativos.
- Selecione Novo Aplicativo para criar um novo aplicativo para publicar seus Controladores de Domínio.
- Selecione Adicionar segmento de aplicativo e depois adicione todos os IPs ou FQDNs (Nomes de Domínio Totalmente Qualificados) e portas dos seus Controladores de Domínio conforme a tabela. Apenas os Controladores de Domínio no site do Active Directory em que os conectores de Acesso Privado estão localizados devem ser publicados.
Observação
Não use FQDNs curinga para publicar seus controladores de domínio; em vez disso, adicione seus IPs ou FQDNs específicos.
Depois de criar o aplicativo empresarial, volte para o aplicativo e selecione Usuários e Grupos. Adicione todos os usuários sincronizados do Active Directory.
Publicar sufixos DNS
Configure o DNS privado para que os clientes do Acesso Global Seguro possam resolver nomes DNS privados. Nomes DNS privados são necessários para realizar logon único. Os clientes os usam para acessar recursos locais publicados. 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 Global Seguro>Aplicativos>Acesso Rápido.
- Selecione a guia DNS privado e, em seguida, selecione Habilitar DNS privado.
- Selecione Adicionar sufixo DNS. Pelo menos, adicione os sufixos de nível superior das florestas do Active Directory que hospedam usuários sincronizados com o Microsoft Entra ID.
- Selecione Salvar.
Como usar o SSO do Kerberos para acessar um compartilhamento de arquivo SMB
Este diagrama demonstra como o Acesso privado do Microsoft Entra funciona ao tentar acessar um compartilhamento de arquivo SMB de um dispositivo Windows configurado com o Windows Hello para Empresas + Relação de confiança na nuvem. 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.
| Etapa | Descrição |
|---|---|
| Um | O usuário tenta acessar o compartilhamento de arquivo SMB usando o FQDN. O cliente GSA intercepta o tráfego e o encapsula para o SSE Edge. As políticas de autorização no Microsoft Entra ID são avaliadas e impostas, como se o usuário estivesse atribuído ao aplicativo e ao acesso condicional. Depois que o usuário é autorizado, o Microsoft Entra ID emite um token para o aplicativo empresarial de SMB. O tráfego é liberado para continuar no 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 backend de acesso privado. A conexã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 acessar o compartilhamento de arquivo SMB de destino que, em seguida, solicita a autenticação Kerberos. |
| C | O cliente gera uma consulta DNS no SRV para localizar controladores de domínio. A fase A é repetida, interceptando a consulta DNS e autorizando o usuário no aplicativo de acesso rápido. O Conector de rede privada envia a consulta DNS no SRV para a rede privada. O serviço DNS envia a resposta DNS ao cliente por meio do Conector de rede privada. |
| D | O dispositivo Windows solicita um TGT parcial (também chamado de Nuvem TGT) do Microsoft Entra ID (se ele ainda não tiver um). O Microsoft Entra ID emite um TGT parcial. |
| E | O Windows inicia uma conexão do localizador de DC pela porta UDP 389 com cada controlador de domínio listado na resposta DNS da fase C. A fase A é repetida, interceptando o tráfego do localizador de DC e autorizando o usuário para o aplicativo empresarial 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 para o 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 arquivo SMB. |
| G | O cliente apresenta o TGS para o compartilhamento de arquivo SMB. O compartilhamento de arquivo SMB valida o TGS. O acesso ao compartilhamento de arquivos é concedido. |
Solucionar problemas
Os dispositivos ingressados no Microsoft Entra ID usando a autenticação de senha dependem de atributos sincronizados pelo Microsoft Entra ID Connect. Verifique se os atributos onPremisesDomainName, onPremisesUserPrincipalName e onPremisesSamAccountName têm os valores corretos. Use o Explorador do Graph e o PowerShell para verificar esses valores.
Caso esses valores não estejam presentes, verifique as configurações de sincronização do Microsoft Entra ID Connect e confirme se esses atributos estão sendo sincronizados. Para mais informações sobre a sincronização de atributos, confira o artigo: Microsoft Entra Connect Sync: atributos sincronizados para o Microsoft Entra ID.
Se estiver usando o Windows Hello para Empresas para entrar, execute os comandos a partir de um prompt de comando sem privilégios elevados.
dsregcmd /status
Verifique se os atributos possuem YES como valores.
PRT deve estar presente. Para saber mais sobre PRT, confira o artigo: Solucionar problemas de token de atualização primário em dispositivos Windows.
OnPremTgt : SIM indica que o Kerberos do Entra está configurado corretamente e que o usuário recebeu um TGT parcial para SSO para recursos locais. Para saber mais sobre como configurar a confiança do Cloud Kerberos, consulte: Credenciais de chave de segurança sem senha para recursos locais.
Execute o comando klist.
klist cloud_debug
Verifique se o campo Cloud Primary (Hybrid logon) TGT available: apresenta o valor 1.
Execute o comando nltest.
nltest /dsgetdc:contoso /keylist /kdc
Confirme se o localizador de controlador de domínio retorna um Controlador de Domínio que participa das operações de confiança Kerberos na nuvem. O controlador de domínio retornado deve ter o sinalizador klist.
Como evitar o cache negativo da autenticação Kerberos em computadores Windows
Kerberos é o método preferencial de autenticação para serviços no Windows que verificam identidades de usuários ou hosts. O cache negativo do Kerberos causa um atraso na obtenção de tíquetes Kerberos.
O cache negativo do Kerberos ocorre em dispositivos Windows que possuem o cliente GSA (Acesso Global Seguro) instalado. O cliente GSA tenta se conectar ao controlador de domínio mais próximo para obter 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 falha, o cliente não tenta se conectar novamente ao controlador de domínio logo em seguida, pois o tempo padrão FarKdcTimeout no registro está definido para 10 minutos. Mesmo que o cliente GSA possa estar conectado antes desse tempo padrão de 10 minutos, ele mantém a entrada de cache negativo e acredita que o processo de localização do controlador de domínio falhou. Após o término do tempo padrão de 10 minutos, o cliente GSA solicita o tíquete Kerberos ao controlador de domínio e a conexão é estabelecida com sucesso.
Para mitigar esse problema, você pode alterar o tempo padrão FarKdcTimeout no registro ou limpar manualmente o cache do Kerberos instantaneamente sempre que o cliente GSA for reiniciado.
Opção 1: alterar o tempo padrão FarKdcTimeout no registro
Se você estiver usando o Windows, poderá modificar os parâmetros do Kerberos para ajudar na solução dos problemas de autenticação Kerberos ou testar o protocolo Kerberos.
Importante
Esta seção, método ou tarefa contém etapas que descrevem como modificar o Registro. Entretanto, sérios problemas poderão ocorrer caso você modifique o Registro incorretamente. Portanto, certifique-se de seguir essas etapas com atenção. Para proteção acrescida, faça backup do Registro antes de modificá-lo. Em, é possível restaurar o Registro caso ocorra um problema. Para obter mais informações sobre como fazer backup e restaurar o Registro, consulte Como fazer backup e restaurar o Registro no Windows.
Entradas de registro e valores na chave Parâmetros
As entradas do registro listadas nesta seção devem ser adicionadas à seguinte subchave de registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Observação
Se a chave Parameters não estiver listada no Kerberos, você deverá criá-la.
Modifique entrada de registro FarKdcTimeout a seguir
- Entrada:
FarKdcTimeout - Digite:
REG_DWORD - Valor padrão:
0 (minutes)
É o valor de tempo limite usado para invalidar um controlador de domínio de outro site no cache do controlador de domínio.
Opção 2: limpar manualmente o cache do Kerberos
Se você optar pela limpeza manual do cache Kerberos, esse processo precisará ser realizado sempre que o cliente GSA for reiniciado.
Abra um prompt de comando como administrador e execute o comando: KLIST PURGE_BIND