Habilitar a entrada de chave de segurança sem senha em recursos locais usando o Microsoft Entra ID

Este tópico mostra como habilitar a autenticação sem senha para recursos locais em ambientes com dispositivos que executam o Windows 10 versão 2004 ou posterior. Os dispositivo podem ser ingressados no Microsoft Entra ou ingressados no Microsoft Entra híbrido. Essa funcionalidade de autenticação sem senha oferece a opção de logon único (SSO) contínuo a recursos locais quando você usa chaves de segurança compatíveis com a Microsoft ou com a Confiança de nuvem do Windows Hello para Empresas.

Usar o SSO para se conectar a recursos locais usando chaves FIDO2

O Microsoft Entra ID pode emitir tíquetes de concessão de tíquete Kerberos (TGTs) para um ou mais de seus domínios do Active Directory. Com essa funcionalidade, os usuários podem entrar no Windows com credenciais modernas, como chaves de segurança FIDO2, e acessar recursos tradicionais baseados no Active Directory. Os Tíquetes do Serviço Kerberos e autorização continuam a ser controlados por seus DCs (controladores de domínio) locais do Active Directory.

Um objeto de servidor Kerberos do Microsoft Entra é criado em sua instância local do Active Directory e, em seguida, publicado com segurança na ID do Microsoft Entra. O objeto não está associado a nenhum servidor físico. É simplesmente um recurso que pode ser usado pelo Microsoft Entra ID para gerar TGTs Kerberos para seu domínio do Active Directory.

1. Um usuário entra em um dispositivo Windows 10 com uma chave de segurança FIDO2 e autentica no Microsoft Entra ID.

2. A ID do Microsoft Entra verifica no diretório uma chave do servidor Kerberos que corresponda ao domínio do Active Directory local do usuário.

   O Microsoft Entra ID gera um TGT Kerberos para o domínio do Active Directory local do usuário. O TGT inclui apenas o SID do usuário e nenhum dado de autorização.

3. O TGT é retornado ao cliente junto com o token principal de atualização (PRT) do Microsoft Entra do usuário.

4. O computador cliente entra em contato com um Controlador de Domínio do Active Directory local e troca o TGT parcial por um TGT totalmente formado.

5. A máquina cliente agora tem um PRT do Microsoft Entra e um TGT completo do Active Directory e pode acessar recursos locais e na nuvem.

Pré-requisitos

Antes de iniciar os procedimentos neste artigo, sua organização deve concluir as instruções em Habilitar as chaves de passagem (FIDO2) na sua organização.

Você também deve atender aos seguintes requisitos do sistema:

• Os dispositivos devem estar executando o Windows 10 versão 2004 ou posterior.

• Os controladores de domínio do seu Windows Server precisam executar o Windows Server 2016 ou posterior e ter patches instalados para os seguintes servidores:

  • Windows Server 2016
  • Windows Server 2019

• AES256_HMAC_SHA1 deve ser habilitado quando a Segurança de rede: configurar tipos de criptografia permitidos para a política Kerberos estiver configurada em controladores de domínio.

• Tenha as credenciais necessárias para concluir as etapas no cenário:

  • Um usuário do Active Directory que é membro do grupo Administradores do Domínio de um domínio e membro do grupo Administradores Corporativos de uma floresta. Indicado como $domainCred.
  • Um usuário do Microsoft Entra que é membro da função Administradores Globais. Indicado como $cloudCred.

• Os usuários devem ter os seguintes atributos do Microsoft Entra preenchidos pelo Microsoft Entra Connect:

  • onPremisesSamAccountName (accountName no Microsoft Entra Connect)
  • onPremisesDomainName (domainFQDN no Microsoft Entra Connect)
  • onPremisesSecurityIdentifier (objectSID no Microsoft Entra Connect)

  O Microsoft Entra Connect sincroniza esses atributos por padrão. Se você alterar quais atributos sincronizar, selecione accountName, domainFQDNe objectSID para sincronização.

Cenários com suporte

O cenário neste artigo dá suporte ao SSO nas duas instâncias a seguir:

• Recursos de nuvem, como Microsoft 365 e outros aplicativos habilitados para SAML (Security Assertion Markup Language).
• Recursos locais e autenticação integrada do Windows para sites. Os recursos podem incluir sites da Web e sites do SharePoint que exigem autenticação IIS e/ou recursos que usam autenticação NTLM.

Cenários sem suporte

Ainda não há suporte para os cenários a seguir:

• Implantação ingressada no AD DS (Windows Server Active Directory Domain Services) (dispositivos somente locais).
• Cenários de RDP (Protocolo RDP), VDI (Infraestrutura de área de trabalho virtual) e Citrix usando uma chave de segurança.
• S/MIME usando uma chave de segurança.
• Executar como usando uma chave de segurança.
• Faça login em um servidor usando a chave de segurança.

Instalar o módulo AzureADHybridAuthenticationManagement

O módulo AzureADHybridAuthenticationManagement fornece recursos de gerenciamento FIDO2 para administradores.

1. Abra um prompt do PowerShell utilizando a opção Executar como administrador.

2. Instalar o módulo AzureADHybridAuthenticationManagement:

   # First, ensure TLS 1.2 for PowerShell gallery access.
   [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
   
   # Install the AzureADHybridAuthenticationManagement PowerShell module.
   Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
   

Criar um objeto de servidor Kerberos

Os administradores usam o módulo AzureADHybridAuthenticationManagement para criar um objeto de servidor Kerberos do Microsoft Entra no seu diretório local.

Execute as seguintes etapas em cada domínio e floresta em sua organização que contêm usuários do Microsoft Entra:

1. Abra um prompt do PowerShell utilizando a opção Executar como administrador.
2. Execute os seguintes comandos do PowerShell para criar um novo objeto de servidor Microsoft Entra Kerberos no domínio do Active Directory local e no locatário do Microsoft Entra.

Selecione a Nuvem do Azure (o padrão é Azure Commercial)

Por padrão, o cmdlet Set-AzureADKerberosSever usará os pontos de extremidade de nuvem comercial. Se você estiver configurando o Kerberos em outro ambiente de nuvem, precisará definir o cmdlet para usar a nuvem especificada.

Para obter uma lista das nuvens disponíveis e o valor numérico necessário para alterar, execute o seguinte:
Get-AzureADKerberosServerEndpoint

Exemplo de saída:

Current Endpoint = 0(Public)
Supported Endpoints:
   0 :Public
   1 :China
   2 :Us Government

Observe o valor numérico ao lado do ambiente de nuvem desejado.

Para definir o ambiente de nuvem desejado, execute o seguinte:

(Exemplo: para a nuvem do Governo dos EUA)

Set-AzureADKerberosServerEndpoint -TargetEndpoint 2

Prompt de exemplo 1 para todas as credenciais

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory Global Administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Global Administrators group for Microsoft Entra ID.'

# Enter a Domain Administrator username and password.
$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group.'

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

Prompt de exemplo 2 para todas as credenciais

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory Global Administrator username and password.
$cloudCred = Get-Credential

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Use the current windows login credential to access the on-premises AD.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred

Prompt de exemplo 3 para todas as credenciais usando autenticação moderna

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Global Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Enter a Domain Administrator username and password.
$domainCred = Get-Credential

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Prompt de exemplo 4 para todas as credenciais usando autenticação moderna

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Global Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Exibir e verificar o servidor Microsoft Entra Kerberos

Você pode exibir e verificar o servidor Microsoft Entra Kerberos recém-criado usando o seguinte comando:

 # When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)

Esse comando gera as propriedades do servidor Kerberos do Microsoft Entra. Você pode examinar as propriedades para verificar se tudo está em uma ordem boa.

Girar a chave do servidor Microsoft Entra Kerberos

As chaves de criptografia do servidor Microsoft Entra Kerberos krbtgt devem ser giradas regularmente. É recomendável que você siga o mesmo agendamento usado para girar todas as outras chaves krbtgt do Controlador de Domínio do Active Directory.

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey

Remover o servidor Kerberos do Microsoft Entra

Se você quiser reverter o cenário e remover o servidor Kerberos do Microsoft Entra do Active Directory local e da ID do Microsoft Entra, execute o seguinte comando:

Remove-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

Cenários de várias florestas e vários domínios

O objeto de servidor Kerberos do Microsoft Entra é representado na ID do Microsoft Entra como um objeto KerberosDomain de dados. Cada domínio do Active Directory local é representado como um único objeto KerberosDomain na ID do Microsoft Entra.

Por exemplo, digamos que sua organização tem uma floresta do Active Directory com dois domínios contoso.com e fabrikam.com. Se você optar por permitir que o Microsoft Entra ID emita TGTs Kerberos para toda a floresta, haverá dois objetos KerberosDomain no Microsoft Entra ID, um objeto KerberosDomain para contoso.com e o outro para fabrikam.com. Se você tiver várias florestas Active Directory, haverá um objeto KerberosDomain para cada domínio em cada floresta.

Siga as instruções em Criar um objeto do servidor Kerberos em cada domínio e floresta em sua organização que contém usuários do Microsoft Entra.

Comportamento conhecido

Se sua senha tiver expirado, a entrada com FIDO será bloqueado. A expectativa é que os usuários redefinam suas senhas antes de poderem fazer logon usando o FIDO. Esse comportamento também se aplica à entrada de usuário sincronizada local híbrida com a confiança kerberos na nuvem do Windows Hello for Business.

Solução de problemas e comentários

Se você encontrar problemas ou desejar compartilhar comentários sobre esse recurso de credenciais de chave de segurança sem senha, compartilhe no aplicativo Hub de Comentários do Windows fazendo o seguinte:

1. Abra o Hub de Comentários e verifique se você está conectado.
2. Envie os comentários selecionando as seguintes categorias:
   • Categoria: Segurança e Privacidade
   • Subcategoria: FIDO
3. Para capturar os logs, use a opção Recriar meu Problema.

Perguntas frequentes sobre credenciais de chave de segurança sem senha

Aqui estão algumas respostas para perguntas frequentes sobre a entrada sem senha:

As credenciais de chave de segurança sem senha funcionam em meu ambiente local?

O recurso não funciona em um ambiente do AD DS local puro.

Minha organização requer autenticação de dois fatores para acessar recursos. O que posso fazer para dar suporte a esse requisito?

As chaves de segurança vêm em uma variedade de fatores forma. Entre em contato com o fabricante do dispositivo de registro para discutir como seus dispositivos podem ser habilitados com um PIN ou biométrica como um segundo fator.

Os administradores podem configurar chaves de segurança?

Estamos trabalhando nessa funcionalidade para a versão de GA (disponibilidade geral) desse recurso.

Onde posso encontrar chaves de segurança em conformidade?

Para obter informações sobre chaves de segurança em conformidade, consulte chaves de segurança FIDO2.

O que posso fazer se perder minha chave de segurança?

Para excluir uma chave de segurança registrada, entre em myaccount.microsoft.com e vá para a página Informações de segurança.

O que posso fazer se não conseguir usar a chave de segurança FIDO imediatamente após criar uma máquina híbrida ingressada no Microsoft Entra?

Se você estiver instalando uma máquina híbrida ingressada no Microsoft Entra, após o processo de ingresso e reinicialização do domínio, deverá entrar com uma senha e aguardar a sincronização da política antes de poder usar a chave de segurança FIDO para entrar.

• Verifique o status atual executando dsregcmd /status em uma janela do prompt de comando e verifique se os status AzureAdJoined e DomainJoined estão sendo exibidos como SIM.
• Esse atraso na sincronização é uma limitação conhecida de dispositivos ingressados no domínio e não é específico do FIDO.

E se eu não conseguir obter o logon único no meu recurso de rede NTLM depois de entrar com FIDO e obter uma solicitação de credencial?

Verifique se existem controladores de domínio suficientes sendo corrigidos para atender a tempo a sua solicitação de recurso. Para ver se um controlador de domínio está executando o recurso, execute nltest /dsgetdc:contoso /keylist /kdc e, em seguida, examine a saída.

As chaves de segurança FIDO2 funcionam em um logon do Windows com RODC presente no ambiente híbrido?

Um logon do Windows FIDO2 procura por um DC gravável para trocar o TGT do usuário. Desde que você tenha pelo menos um DC gravável por site, o logon funcionará corretamente.

Próximas etapas

Saiba mais sobre a autenticação sem senha