Compartilhar via

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

  • Artigo

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.

Diagrama mostrando como obter um TGT da ID do Microsoft Entra e dos Serviços de Domínio 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:

  • 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 com a função Administradores de Identidade Híbrida. 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.

Instale 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

Observação

  • A partir da atualização 2.3.331.0, o módulo AzureADHybridAuthenticationManagement não instala o módulo AzureADPreview.
  • Você pode instalar o AzureADHybridAuthenticationManagement módulo em qualquer computador a partir do qual possa acessar o Controlador de Domínio do Active Directory local, sem depender da solução do Microsoft Entra Connect.
  • O módulo AzureADHybridAuthenticationManagement do Azure AD é distribuído usando a Galeria do PowerShell. A Galeria do PowerShell é o repositório central de conteúdo do PowerShell. Nela, você pode encontrar módulos úteis do PowerShell que contêm comandos do PowerShell e recursos de DSC (Configuração de Estado Desejado).

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. O objeto deve ser criado no servidor do Microsoft Entra Connect ou em um servidor que tenha a dependência Microsoft.Online.PasswordSynchronization.Rpc.dll instalada.

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 Hybrid Identity Administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Hybrid Identity 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

Observação

Se estiver trabalhando em um computador conectado ao domínio com uma conta que tenha privilégios de administrador de domínio, você poderá ignorar o parâmetro "-DomainCredential". Se o parâmetro "-DomainCredential" não for fornecido, a credencial atual de logon do Windows será usada para acessar o Controlador de Domínio do Active Directory local.

# 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 Hybrid Identity 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

Observação

Se sua organização protege a entrada baseada em senha e impõe métodos de autenticação moderna, como autenticação multifator, FIDO2 ou tecnologia de cartão inteligente, você deverá usar o parâmetro -UserPrincipalName com o nome UPN (UPN) de um Administrador de Identidade Híbrida.

  • Substitua contoso.corp.com no exemplo a seguir pelo seu nome de domínio do Active Directory local.
  • Substitua administrator@contoso.onmicrosoft.com no exemplo a seguir pelo UPN de um Administrador de Identidade Híbrida.
# 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 Hybrid Identity 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

Observação

Se você estiver trabalhando em um computador ingressado no domínio com uma conta que tenha privilégios de administrador de domínio e sua organização protege a entrada baseada em senha e impõe métodos de autenticação moderna, como autenticação multifator, FIDO2 ou tecnologia de cartão inteligente, você deverá usar o parâmetro -UserPrincipalName com o nome UPN (UPN) de um Administrador de Identidade Híbrida. E você pode ignorar o parâmetro "-DomainCredential". > - Substitua administrator@contoso.onmicrosoft.com no exemplo a seguir pelo UPN de um Administrador de Identidade Híbrida.

# 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 Hybrid Identity 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.

Observação

Executar em outro domínio fornecendo a credencial no formato domain\username fará a conexão por NTLM e, em seguida, falhará. No entanto, o uso do formato userprincipalname para o administrador de domínio garantirá uma tentativa de associação di RPC ao DC usando o Kerberos corretamente. Se os usuários estiverem no grupo de segurança Usuários protegidos no Active Directory, conclua estas etapas para resolver o problema: entre como outro usuário de domínio no ADConnect e não forneça "-domainCredential". O tíquete do Kerberos do usuário que está conectado no momento é usado. Você pode confirmar executando whoami /groups para validar se o usuário tem as permissões necessárias no Active Directory para executar o comando anterior.

Propriedade Descrição
ID A ID exclusiva do objeto AD DS DC. Às vezes, essa ID é chamada de slot ou ID de branch.
DomainDnsName O nome de domínio DNS do Domínio do Active Directory.
ComputerAccount O objeto de conta de computador do objeto do servidor Kerberos do Microsoft Entra (o controlador de domínio).
UserAccount O objeto de conta de usuário desabilitado que contém a chave de criptografia TGT do servidor Kerberos do Microsoft Entra. O nome de domínio dessa conta é CN=krbtgt_AzureAD,CN=Users,<Domain-DN>.
KeyVersion A versão da chave de criptografia TGT do servidor Kerberos do Microsoft Entra. A versão é atribuída quando a chave é criada. Em seguida, a versão é incrementada toda vez que a chave é girada. Os incrementos são baseados nos metadados de replicação e são provavelmente maiores que um. Por exemplo, a KeyVersion inicial pode ser 192272. Na primeira vez que a chave é girada, a versão pode avançar para 212621. É importante verificar que o KeyVersion para o objeto local e o CloudKeyVersion para o objeto em nuvem são os mesmos.
KeyUpdatedOn A data e a hora em que a chave de criptografia TGT do servidor Kerberos do Microsoft Entra foi atualizada ou criada.
KeyUpdatedFrom O controlador de domínio em que a chave de criptografia TGT do servidor Kerberos do Microsoft Entra foi atualizada pela última vez.
CloudId A ID do objeto Microsoft Entra. Deve corresponder à ID da primeira linha da tabela.
CloudDomainDnsName O DomainDnsName do objeto Microsoft Entra. Deve corresponder ao DomainDnsName da segunda linha da tabela.
CloudKeyVersion A KeyVersion do objeto Microsoft Entra. Deve corresponder à KeyVersion da quinta linha da tabela.
CloudKeyUpdatedOn A KeyUpdatedOn do objeto Microsoft Entra. Deve corresponder à KeyUpdatedOn da sexta linha da tabela.

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.

Aviso

Há outras ferramentas que podem girar as chaves krbtgt. No entanto, você deve usar as ferramentas mencionadas neste documento para girar as chaves krbtgt do servidor Microsoft Entra Kerberos. Isso garante que as chaves sejam atualizadas no Active Directory local e na ID do Microsoft Entra.

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

Dica

As etapas neste artigo podem variar ligeiramente com base no portal do qual você começa.

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.

Observação

A opção /keylist no comando nltest está disponível no cliente Windows 10 v2004 e posterior.

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