Habilitar entrada de chave de segurança sem senha para recursos locais usando o Azure AD

Este documento discute como habilitar a autenticação sem senha para recursos locais em ambientes com dispositivos ingressado no Azure AD (Azure Active Directory) e ingressado no Azure AD híbrido do Windows 10. Essa funcionalidade de autenticação sem senha fornece SSO (logon único) contínuo para 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 Azure AD pode emitir TGTs (tíquetes de concessão de tíquete Kerberos) para um ou mais dos seus domínios do Microsoft 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 do Servidor Kerberos do Azure AD é criado em sua instância do Active Directory local e publicado com segurança no Azure Active Directory. O objeto não está associado a nenhum servidor físico. Ele é simplesmente um recurso que pode ser usado pelo Azure Active Directory para gerar TGTs Kerberos para seu domínio do Active Directory.

Diagrama mostrando como obter um TGT do Azure AD e do Active Directory Domain Services.

  1. Um usuário entra em um dispositivo Windows 10 com uma chave de segurança FIDO2 e se autentica no Azure AD.

  2. O Azure AD verifica o diretório em busca de uma chave de servidor Kerberos que corresponda ao domínio do Active Directory local do usuário.

    O Azure AD 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 é devolvido ao cliente junto com o PRT (token de atualização principal) do Azure AD 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. O computador cliente agora tem um PRT do Azure AD e um TGT do Active Directory completo e pode acessar recursos em nuvem e locais.

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 Windows Server devem 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 Azure Active Directory que é membro da função Administradores Globais. Indicado como $cloudCred.

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 do PowerShell do Kerberos do Azure AD

O PowerShell do Kerberos do Azure AD fornece recursos de gerenciamento de FIDO2 para administradores.

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

  2. Instale o módulo do PowerShell do Kerberos do Azure AD:

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

Observação

  • O módulo do PowerShell do Kerberos do Azure AD usa o módulo do PowerShell do AzureADPreview para fornecer recursos avançados de gerenciamento do Azure Active Directory. Se o módulo do PowerShell do AzureAD já estiver instalado no computador local, a instalação descrita aqui poderá falhar devido a um conflito. Para evitar conflitos durante a instalação, certifique-se de incluir o sinalizador de opção "-AllowClobber".
  • Você pode instalar o módulo do PowerShell do Kerberos do Azure AD em qualquer computador do qual você possa acessar seu Controlador de Domínio do Active Directory local, sem dependência na solução do Azure AD Connect.
  • O módulo do PowerShell do Kerberos do Azure AD é distribuído por meio da 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 do PowerShell do Kerberos do Azure AD para criar um objeto de servidor Kerberos do Azure AD em seu diretório local.

Execute as seguintes etapas em cada domínio e floresta em sua organização que contenha usuários do Azure AD:

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

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-prem 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.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 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 Kerberos do Azure AD

Você pode exibir e verificar o servidor Kerberos do Azure AD criado recentemente usando o seguinte comando:

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

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

Observação

Executar em outro domínio fornecendo a credencial fará a conexão por NTLM e, em seguida, falhará. 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 de servidor Kerberos do Azure AD (o DC).
UserAccount O objeto de conta de usuário desabilitado que contém a chave de criptografia de TGT do servidor Kerberos do Azure AD. O nome de domínio dessa conta é CN=krbtgt_AzureAD,CN=Users,<Domain-DN>.
KeyVersion A versão de chave da chave de criptografia de TGT do servidor Kerberos do Azure AD. 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 de TGT do servidor Kerberos do Azure AD foi atualizada ou criada.
KeyUpdatedFrom O controlador de domínio em que a chave de criptografia TGT do servidor Kerberos do Azure AD foi atualizada pela última vez.
CloudId A ID do objeto do Azure AD. Deve corresponder à ID da primeira linha da tabela.
CloudDomainDnsName O DomainDnsName do objeto do Azure AD. Deve corresponder ao DomainDnsName da segunda linha da tabela.
CloudKeyVersion A KeyVersion do objeto do Azure AD. Deve corresponder à KeyVersion da quinta linha da tabela.
CloudKeyUpdatedOn A KeyUpdatedOn do objeto do Azure AD. Deve corresponder à KeyUpdatedOn da sexta linha da tabela.

Girar a chave do servidor Kerberos do Azure AD

As chaves krbtgt de criptografia de servidor Kerberos do Azure AD 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 seu servidor Kerberos do Azure AD. Isso garante que as chaves sejam atualizadas tanto no Active Directory local quanto no Azure AD.

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

Remover o servidor Kerberos do Azure AD

Se você quiser reverter o cenário e remover o servidor Kerberos do Azure AD do Active Directory local e Azure AD, 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 do servidor Kerberos do Azure AD é representado no Azure AD como um objeto KerberosDomain. Cada domínio de Active Directory local é representado como um único objeto KerberosDomain no Azure AD.

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 Azure AD emita o TGTs Kerberos para toda a floresta, haverá dois objetos KerberosDomain no Azure AD, um objeto KerberosDomain para contoso.com e 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 de servidor Kerberos em cada domínio e floresta em sua organização que contenha usuários do Azure AD.

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.

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 no portal do Azure e vá para a página Informações de segurança.

O que posso fazer se eu não conseguir usar a chave de segurança FIDO imediatamente depois de criar um computador ingressado no Azure AD híbrido?

Se você limpar a instalação de um computador ingressado no Azure AD híbrido, após o processo de ingresso e reinicialização do domínio, você deverá entrar com uma senha e aguardar a sincronização da política antes de poder usar a chave de segurança do 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