Habilite a entrada sem senha de chave de segurança em recursos locais usando o ID do Microsoft Entra
Este tópico mostra como habilitar a autenticação sem senha para recursos locais para ambientes com dispositivos que executam o Windows 10 versão 2004 ou posterior. Os dispositivos podem ser associados ao Microsoft Entra ou híbridos do Microsoft Entra. Essa funcionalidade de autenticação sem senha fornece logon único (SSO) contínuo para recursos locais quando você usa chaves de segurança compatíveis com a Microsoft ou com a confiança do Windows Hello for Business Cloud.
Use o SSO para entrar em recursos locais usando chaves FIDO2
O Microsoft Entra ID pode emitir tíquetes de concessão de tíquetes (TGTs) Kerberos para um ou mais domínios do Ative Directory. Com essa funcionalidade, os usuários podem entrar no Windows com credenciais modernas, como chaves de segurança FIDO2 e, em seguida, acessar recursos tradicionais baseados no Ative Directory. Os tíquetes de serviço Kerberos e a autorização continuam a ser controlados pelos controladores de domínio (DCs) locais do Ative Directory.
Um objeto de servidor Kerberos do Microsoft Entra é criado em sua instância local do Ative 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 Ative Directory.
Um utilizador inicia sessão num dispositivo Windows 10 com uma chave de segurança FIDO2 e autentica-se no Microsoft Entra ID.
O Microsoft Entra ID verifica o diretório em busca de uma chave do Servidor Kerberos que corresponda ao domínio do Ative Directory local do usuário.
O Microsoft Entra ID gera um TGT Kerberos para o domínio do Ative 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 Microsoft Entra Primary Refresh Token (PRT) do usuário.
A máquina cliente entra em contato com um Controlador de Domínio Ative Directory local e troca o TGT parcial por um TGT totalmente formado.
A máquina cliente agora tem um Microsoft Entra PRT e um Ative Directory TGT completo e pode acessar recursos na nuvem e no local.
Pré-requisitos
Antes de iniciar os procedimentos neste artigo, sua organização deve concluir as instruções em Habilitar chaves de acesso (FIDO2) para sua organização.
Você também deve atender aos seguintes requisitos de sistema:
Os dispositivos devem estar executando o Windows 10 versão 2004 ou posterior.
Os controladores de domínio do Windows Server devem executar o Windows Server 2016 ou posterior e ter patches instalados para os seguintes servidores:
AES256_HMAC_SHA1 deve ser habilitado quando Segurança de rede: Configurar tipos de criptografia permitidos para a diretiva Kerberos estiver configurado em controladores de domínio.
Tenha as credenciais necessárias para concluir as etapas no cenário:
- Um usuário do Ative Directory que é membro do grupo Administradores do Domínio para um domínio e um membro do grupo Administradores Corporativos para uma floresta. Referido como $domainCred.
- Um usuário do Microsoft Entra que é membro da função Administradores Globais. Referido como $cloudCred.
Os usuários devem ter os seguintes atributos do Microsoft Entra preenchidos por meio do 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, certifique-se de selecionar
accountName
,domainFQDN
eobjectSID
para sincronização.
Cenários suportados
O cenário neste artigo oferece suporte a SSO em ambas as seguintes instâncias:
- Recursos de nuvem, como o Microsoft 365 e outros aplicativos habilitados para SAML (Security Assertion Markup Language).
- Recursos locais e autenticação integrada ao Windows para sites. Os recursos podem incluir sites e sites do SharePoint que exigem autenticação do IIS e/ou recursos que usam autenticação NTLM.
Cenários não suportados
Os seguintes cenários não são suportados:
- Implantação associada aos Serviços de Domínio Ative Directory (AD DS) do Windows Server (somente dispositivos locais).
- Cenários RDP (Remote Desktop Protocol), VDI (infraestrutura de área de trabalho virtual) e Citrix usando uma chave de segurança.
- S/MIME usando uma chave de segurança.
- Execute como usando uma chave de segurança.
- Faça login em um servidor usando uma chave de segurança.
Instalar o AzureADHybridAuthenticationManagement
módulo
O AzureADHybridAuthenticationManagement
módulo fornece recursos de gerenciamento FIDO2 para administradores.
Abra um prompt do PowerShell usando a opção Executar como administrador.
Instale o
AzureADHybridAuthenticationManagement
módulo:# 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
Nota
- O
AzureADHybridAuthenticationManagement
módulo usa o módulo AzureADPreview PowerShell para fornecer recursos avançados de gerenciamento do Microsoft Entra. Se o módulo PowerShell do Azure Ative Directory já estiver instalado no computador local, a instalação descrita aqui poderá falhar devido a conflito. Para evitar conflitos durante a instalação, certifique-se de incluir o sinalizador de opção "-AllowClobber". - Pode instalar o módulo em qualquer computador a partir do qual possa aceder ao
AzureADHybridAuthenticationManagement
Controlador de Domínio Ative Directory no local, sem depender da solução Microsoft Entra Connect. - O
AzureADHybridAuthenticationManagement
módulo é distribuído por meio da Galeria do PowerShell. A Galeria do PowerShell é o repositório central para o conteúdo do PowerShell. Nele, você pode encontrar módulos úteis do PowerShell que contêm comandos do PowerShell e recursos de Configuração de Estado Desejado (DSC).
Criar um objeto Kerberos Server
Os administradores usam o AzureADHybridAuthenticationManagement
módulo para criar um objeto de servidor Microsoft Entra Kerberos em 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 usando 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 local do Ative Directory e no locatário do Microsoft Entra.
Selecione Azure Cloud (o padrão é Azure Commercial)
Por padrão, o Set-AzureADKerberosSever
cmdlet usará os pontos de extremidade da 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
Saída de Exemplo:
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 o US Government Cloud)
Set-AzureADKerberosServerEndpoint -TargetEndpoint 2
Exemplo 1 solicitar 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
Exemplo 2 de solicitação de credencial de nuvem
Nota
Se estiver a trabalhar numa máquina associada a um domínio com uma conta com privilégios de administrador de domínio, pode ignorar o parâmetro "-DomainCredential". Se o parâmetro "-DomainCredential" não for fornecido, a credencial de login atual do Windows será usada para acessar o Controlador de Domínio Ative 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 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
Exemplo 3: solicitar todas as credenciais usando autenticação moderna
Nota
Se sua organização protege a entrada baseada em senha e impõe métodos de autenticação modernos, como autenticação multifator, FIDO2 ou tecnologia de cartão inteligente, você deve usar o -UserPrincipalName
parâmetro com o Nome Principal do Usuário (UPN) de um Administrador Global.
- Substitua
contoso.corp.com
no exemplo a seguir pelo nome de domínio do Ative Directory local. - Substitua
administrator@contoso.onmicrosoft.com
, no exemplo a seguir, pelo UPN de um administrador global.
# 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
Exemplo 4: solicitar credenciais de nuvem usando autenticação moderna
Nota
Se você estiver trabalhando em uma máquina associada a um domínio com uma conta que tenha privilégios de administrador de domínio e sua organização proteger a entrada baseada em senha e impor métodos de autenticação modernos, como autenticação multifator, FIDO2 ou tecnologia de cartão inteligente, você deverá usar o -UserPrincipalName
parâmetro com o Nome Principal do Usuário (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 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)
Este comando produz as propriedades do servidor Microsoft Entra Kerberos. Pode rever as propriedades para verificar se tudo está em ordem.
Nota
A execução em outro domínio fornecendo a credencial no formato domínio\nome de usuário se conectará por NTLM e, em seguida, falhará. No entanto, usar o formato userprincipalname para o administrador de domínio garantirá que a ligação RPC ao DC seja tentada usando Kerberos corretamente. Se os usuários estiverem no grupo de segurança Usuários Protegidos no Ative 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 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 Ative Directory para executar o comando anterior.
Property | Description |
---|---|
ID | A ID exclusiva do objeto AD DS DC. Esse ID às vezes é chamado de slot ou de filial. |
DomainDnsName | O nome de domínio DNS do domínio do Ative Directory. |
Conta de computador | O objeto de conta de computador do objeto de servidor Microsoft Entra Kerberos (o DC). |
Conta de Utilizador | O objeto de conta de usuário desabilitado que contém a chave de criptografia TGT do servidor Microsoft Entra Kerberos. O nome de domínio desta conta é CN=krbtgt_AzureAD,CN=Users,<Domain-DN> . |
Versão Chave | A versão de chave da chave de criptografia TGT do servidor Microsoft Entra Kerberos. A versão é atribuída quando a chave é criada. A versão é então incrementada sempre que a chave é girada. Os incrementos são baseados em metadados de replicação e provavelmente maiores que um. Por exemplo, o KeyVersion inicial pode ser 192272. Na primeira vez que a chave é girada, a versão pode avançar para 212621. A coisa importante a verificar é se o KeyVersion para o objeto local e o CloudKeyVersion para o objeto de nuvem são os mesmos. |
KeyUpdatedOn | A data e a hora em que a chave de criptografia TGT do servidor Microsoft Entra Kerberos foi atualizada ou criada. |
KeyUpdatedFrom | O DC onde a chave de criptografia TGT do servidor Microsoft Entra Kerberos foi atualizada pela última vez. |
CloudId | A ID do objeto Microsoft Entra. Deve corresponder ao ID da primeira linha da tabela. |
CloudDomainDnsName | O DomainDnsName do objeto Microsoft Entra. Deve corresponder ao DomainDnsName da segunda linha da tabela. |
CloudKeyVersion | O KeyVersion do objeto Microsoft Entra. Deve corresponder à KeyVersion da quinta linha da tabela. |
CloudKeyUpdatedOn | O KeyUpdatedOn do objeto Microsoft Entra. Deve corresponder ao KeyUpdatedOn da sexta linha da tabela. |
Gire a chave do servidor Microsoft Entra Kerberos
As chaves krbtgt de criptografia do servidor Microsoft Entra Kerberos devem ser alternadas regularmente. Recomendamos que você siga o mesmo cronograma usado para girar todas as outras chaves krbtgt DC do Ative Directory.
Aviso
Existem outras ferramentas que podem girar as teclas krbtgt . No entanto, você deve usar as ferramentas mencionadas neste documento para girar as chaves krbtgt do seu servidor Microsoft Entra Kerberos. Isso garante que as chaves sejam atualizadas no Ative Directory local e no Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey
Remova o servidor Microsoft Entra Kerberos
Se desejar reverter o cenário e remover o servidor Microsoft Entra Kerberos do Ative Directory local e da ID do Microsoft Entra, execute o seguinte comando:
Remove-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
Cenários multifloresta e multidomínio
O objeto de servidor Microsoft Entra Kerberos é representado no Microsoft Entra ID como um objeto KerberosDomain . Cada domínio do Ative Directory local é representado como um único objeto KerberosDomain no Microsoft Entra ID.
Por exemplo, digamos que sua organização tenha uma floresta do Ative 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, há dois objetos KerberosDomain no Microsoft Entra ID, um objeto KerberosDomain para contoso.com
e outro para fabrikam.com
. Se você tiver várias florestas do Ative 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 a sua palavra-passe tiver expirado, o início de sessão com FIDO será bloqueado. A expectativa é que os usuários redefina suas senhas antes de poderem fazer login usando FIDO. Esse comportamento também se aplica ao logon de usuário sincronizado local híbrido com a confiança kerberos na nuvem do Windows Hello for Business.
Solução de problemas e comentários
Se você encontrar problemas ou quiser compartilhar comentários sobre esse recurso de entrada de chave de segurança sem senha, compartilhe por meio do aplicativo Hub de Comentários do Windows fazendo o seguinte:
- Abra o Hub de Comentários e certifique-se de que tem sessão iniciada.
- Envie comentários selecionando as seguintes categorias:
- Categoria: Segurança e Privacidade
- Subcategoria: FIDO
- Para capturar logs, use a opção Recriar meu problema .
Perguntas frequentes sobre o início de sessão com chave de segurança sem palavra-passe
Gorjeta
As etapas neste artigo podem variar ligeiramente com base no portal a partir do qual você começou.
Eis algumas respostas a perguntas frequentes sobre o início de sessão sem palavra-passe:
O início de sessão com chave de segurança sem palavra-passe funciona no meu ambiente local?
O recurso não funciona em um ambiente AD DS local puro.
Minha organização requer autenticação de dois fatores para acessar recursos. O que posso fazer para apoiar este 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étrico como um segundo fator.
Os administradores podem configurar chaves de segurança?
Estamos trabalhando nesse recurso para a versão de disponibilidade geral (GA) desse recurso.
Onde posso encontrar chaves de segurança compatíveis?
Para obter informações sobre chaves de segurança compatíveis, consulte Chaves de segurança FIDO2.
O que posso fazer se perder a minha chave de segurança?
Para eliminar uma chave de segurança inscrita, inicie sessão no myaccount.microsoft.com e, em seguida, aceda à 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 associada ao Microsoft Entra?
Se você estiver instalando uma máquina híbrida associada ao 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 seu status atual executando
dsregcmd /status
em uma janela do Prompt de Comando e verifique se os status AzureAdJoined e DomainJoined estão aparecendo como YES. - 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 receber um prompt de credencial?
Certifique-se de que DCs suficientes são corrigidos para responder a tempo de atender sua solicitação de recurso. Para ver se um controlador de domínio está executando o recurso, execute nltest /dsgetdc:contoso /keylist /kdc
e revise a saída.
Nota
A /keylist
opção no nltest
comando está disponível no cliente Windows 10 v2004 e posterior.
As chaves de segurança FIDO2 funcionam em um login do Windows com RODC presente no ambiente híbrido?
Um login FIDO2 do Windows procura um DC gravável para trocar o TGT do usuário. Contanto que você tenha pelo menos um DC gravável por site, o login funciona bem.