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.
Um usuário entra em um dispositivo Windows 10 com uma chave de segurança FIDO2 e autentica no Microsoft Entra ID.
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.
O TGT é retornado ao cliente junto com o token principal de atualização (PRT) do Microsoft Entra do usuário.
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.
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 começar os procedimentos deste artigo, sua organização deve concluir as instruções em Habilitar credenciais de chave de segurança sem senha em dispositivos com Windows 10.
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 que é membro da função Administradores Globais. Indicado como $cloudCred.
Os usuários devem ter os seguintes atributos de ID do Microsoft Entra preenchidos por meio do Microsoft Entra Connect:
- onPremisesSamAccountName (accountName no Entra Connect)
- onPremisesDomainName (domainFQDN no Entra Connect)
- onPremisesSecurityIdentifier (objectSID no Entra Connect)
O Entra Connect sincroniza esses atributos por padrão. Se você alterar quais atributos sincronizar, selecione accountName, domainFQDN e 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.
Abra um prompt do PowerShell utilizando a opção Executar como administrador.
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
- O módulo
AzureADHybridAuthenticationManagementusa o módulo do PowerShell do AzureADPreview para fornecer recursos avançados de gerenciamento do Microsoft Entra. Se o módulo PowerShell do Azure Active Directory já estiver instalado no computador local, a instalação descrita aqui poderá falhar devido a conflitos. Para evitar conflitos durante a instalação, certifique-se de incluir o sinalizador de opção "-AllowClobber". - Você pode instalar o
AzureADHybridAuthenticationManagementmó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
AzureADHybridAuthenticationManagementdo 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.
Execute as seguintes etapas em cada domínio e floresta em sua organização que contêm usuários do Microsoft Entra:
- Abra um prompt do PowerShell utilizando a opção Executar como administrador.
- 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 Azure AD
# 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 Azure AD.'
# 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 Azure AD 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 Azure AD
# 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 Azure AD 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 modernos, como a autenticação multifator, FIDO2 ou a tecnologia de cartão inteligente, você precisa usar o parâmetro -UserPrincipalName com o UPN (Nome UPN) de um administrador global.
- Substitua
contoso.corp.comno exemplo a seguir pelo seu nome de domínio do Active Directory local. - Substitua
administrator@contoso.onmicrosoft.comno exemplo a seguir pelo UPN de um administrador global.
# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN
# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"
# Enter a domain administrator username and password.
$domainCred = Get-Credential
# Create the new Azure AD 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 Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred
Prompt de exemplo 4 para todas as credenciais usando autenticação moderna
Observação
Se você está trabalhando em um computador conectado ao domínio com uma conta que tem privilégios do administrador de domínio e a organização protege a entrada baseada em senha e impõe métodos de autenticação modernos, como a autenticação multifator, o FIDO2 ou a tecnologia de cartão inteligente, você precisa usar o parâmetro -UserPrincipalName com nome UPN de um administrador global. E você pode ignorar o parâmetro "-DomainCredential".
> – Substitua administrator@contoso.onmicrosoft.com no exemplo a seguir pelo UPN de um administrador global.
# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN
# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"
# Create the new Azure AD 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 Azure AD.
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:
- Abra o Hub de Comentários e verifique se você está conectado.
- Envie os comentários selecionando as seguintes categorias:
- Categoria: Segurança e Privacidade
- Subcategoria: FIDO
- 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 /statusem 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.