Habilitación del inicio de sesión con una clave de seguridad sin contraseña en recursos locales mediante Microsoft Entra ID

  • Artículo

En este tema, se muestra cómo habilitar la autenticación sin contraseña en recursos locales para entornos con dispositivos que ejecutan Windows 10 versión 2004 o posterior. Los dispositivos deben estar unidos a Microsoft Entra o tener una unión híbrida a Microsoft Entra. Esta funcionalidad de autenticación sin contraseña proporciona un inicio de sesión único (SSO) sin complicaciones a los recursos locales cuando se usan claves de seguridad compatibles con Microsoft o con Confianza en la nube de Windows Hello para empresas.

Uso del inicio de sesión único para iniciar sesión en recursos locales mediante claves FIDO2

Microsoft Entra ID puede emitir vales de concesión de vales (TGT) de Kerberos para uno o varios de los dominios de Active Directory. Con esta funcionalidad los usuarios pueden iniciar sesión en Windows con credenciales modernas, como claves de seguridad FIDO2, y luego acceder a recursos tradicionales basados en Active Directory. Los vales de servicio de Kerberos y la autorización se siguen controlando mediante los controladores de dominio locales de Active Directory.

Se crea un objeto de servidor de Kerberos de Microsoft Entra en la instancia local de Active Directory y luego se publica de forma segura en Microsoft Entra ID. El objeto no está asociado a ningún servidor físico. Simplemente es un recurso que se puede usar en Microsoft Entra ID para generar TGT de Kerberos para el dominio de Active Directory.

Diagrama que muestra cómo obtener un TGT de Microsoft Entra ID y Active Directory Domain Services.

  1. Un usuario inicia sesión en un dispositivo Windows 10 con una clave de seguridad FIDO2 y se autentica en Microsoft Entra ID.

  2. Microsoft Entra ID busca en el directorio una clave de servidor de Kerberos que coincida con el dominio de Active Directory local del usuario.

    Microsoft Entra ID genera un TGT de Kerberos para el dominio de Active Directory local del usuario. El TGT incluye solo el SID del usuario, sin ningún dato de autorización.

  3. El TGT se devuelve al cliente junto con el Token de actualización principal (PRT) de Microsoft Entra del usuario.

  4. La máquina cliente se pone en contacto con un controlador de Dominio de Active Directory local e intercambia el TGT parcial por un TGT completo.

  5. La máquina cliente tiene ahora un PRT de Microsoft Entra y un TGT de Active Directory completo y puede acceder a recursos locales y en la nube.

Requisitos previos

Antes de empezar con los procedimientos de este artículo, la organización debe completar las instrucciones de Habilitación del inicio de sesión con clave de seguridad sin contraseña en dispositivos Windows 10.

También debe cumplir los siguientes requisitos del sistema:

  • Los dispositivos deben ejecutar Windows 10, versión 2004 o posterior.

  • Los controladores de dominio de Windows Server deberán ejecutar Windows Server 2016 o versiones posteriores, además de tener instaladas las revisiones de los servidores siguientes:

  • AES256_HMAC_SHA1 debe habilitarse cuando la directiva Seguridad de red: configurar tipos de cifrado permitidos para Kerberos está configurada en controladores de dominio.

  • Tenga las credenciales necesarias para completar los pasos del escenario:

    • Un usuario de Active Directory que es miembro del grupo Administradores de dominio de un dominio y miembro del grupo Administradores de empresa de un bosque. Se denomina $domainCred.
    • Un usuario de Microsoft Entra que es miembro del rol Administradores globales. Se denomina $cloudCred.

  • Los usuarios deben tener los siguientes atributos de Microsoft Entra ID rellenados a través de Microsoft Entra Connect:

    • onPremisesSamAccountName (accountName en Entra Connect)
    • onPremisesDomainName (domainFQDN en Entra Connect)
    • onPremisesSecurityIdentifier (objectSID en Entra Connect)

    Entra Connect sincroniza estos atributos de forma predeterminada. Si cambia los atributos que se van a sincronizar, seleccione accountName, domainFQDN y objectSID para la sincronización.

Escenarios admitidos

El escenario de este artículo admite el inicio de sesión único en las dos instancias siguientes:

  • Recursos en la nube, como aplicaciones de Microsoft 365 y otras habilitadas para Lenguaje de marcado de aserción de seguridad (SAML).
  • Recursos locales, y autenticación integrada de Windows en sitios web. Los recursos pueden incluir sitios web y sitios de SharePoint que requieran autenticación de IIS o recursos que usen autenticación de NTLM.

Escenarios no admitidos

No se admiten los escenarios siguientes:

  • Implementación unida a Active Directory Domain Services (AD DS) de Windows Server (solo dispositivos locales).
  • Escenarios de Protocolo de Escritorio remoto (RDP), infraestructura de escritorio virtual (VDI) y Citrix mediante una clave de seguridad.
  • S/MIME con una clave de seguridad.
  • Ejecutar como con una clave de seguridad.
  • Inicio de sesión en un servidor con una clave de seguridad.

Instalación del módulo AzureADHybridAuthenticationManagement

El módulo AzureADHybridAuthenticationManagement proporciona características de administración de FIDO2 para administradores.

  1. Abra un símbolo del sistema de PowerShell con la opción Ejecutar como administrador.

  2. Instalación del 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

Nota:

  • El módulo AzureADHybridAuthenticationManagement usa el módulo de PowerShell de AzureADPreview para proporcionar características avanzadas de administración de Microsoft Entra. Si el módulo de PowerShell de Azure Active Directory ya está instalado en el equipo local, la instalación descrita aquí podría generar un error debido a un conflicto. Para evitar conflictos durante la instalación, asegúrese de incluir la marca de opción "-AllowClobber".
  • Puede instalar el módulo AzureADHybridAuthenticationManagement en cualquier equipo desde el que pueda acceder al controlador de Dominio de Active Directory local, sin dependencia en la solución de Microsoft Entra.
  • El módulo AzureADHybridAuthenticationManagement se distribuye con la Galería de PowerShell. La Galería de PowerShell es el repositorio central del contenido de PowerShell. En ella puede encontrar módulos útiles de PowerShell que contienen comandos de PowerShell y recursos de Desired State Configuration (DSC).

Creación de un objeto de servidor de Kerberos

Los administradores usan el módulo AzureADHybridAuthenticationManagement para crear un objeto de servidor Kerberos de Microsoft Entra en su directorio local.

Estos pasos deben ejecutarse en todos los dominios y bosques de la organización que contengan usuarios de Microsoft Entra:

  1. Abra un símbolo del sistema de PowerShell con la opción Ejecutar como administrador.
  2. Ejecute los siguientes comandos de PowerShell para crear un nuevo objeto de servidor de Kerberos de Microsoft Entra en el dominio de Active Directory local y en el inquilino de Microsoft Entra.

Seleccione nube de Azure (el valor predeterminado es Azure Commercial)

De forma predeterminada, el cmdlet Set-AzureADKerberosSever usará los puntos de conexión de nube comercial. Si va a configurar Kerberos en otro entorno de nube, debe establecer el cmdlet para usar la nube especificada.

Para obtener una lista de las nubes disponibles y el valor numérico necesario para cambiar, ejecute lo siguiente:
Get-AzureADKerberosServerEndpoint

Salida de ejemplo:

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

Anote el valor numérico junto al entorno de nube deseado.

Para establecer el entorno de nube deseado, ejecute lo siguiente:
(Ejemplo: para la nube del Gobierno de EE. UU.)
Set-AzureADKerberosServerEndpoint -TargetEndpoint 2

Ejemplo 1: solicitud de todas las credenciales

# 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

Ejemplo 2: solicitud de credencial en la nube

Nota:

Si trabaja en una máquina unida a dominio con una cuenta con privilegios de administrador de dominio, puede omitir el parámetro "-DomainCredential". Si no se proporciona el parámetro "-DomainCredential", se usa la credencial de inicio de sesión de Windows actual para acceder al controlador de dominio de 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

Ejemplo 3: solicitud de todas las credenciales mediante la autenticación moderna

Nota:

Si la organización protege el inicio de sesión basado en contraseña y aplica métodos de autenticación moderna, como autenticación multifactor, FIDO2 o tecnología de tarjeta inteligente, debe usar el parámetro -UserPrincipalName con el nombre principal de usuario (UPN) de un administrador global.

  • Reemplace contoso.corp.com del ejemplo siguiente por el nombre de dominio de Active Directory local.
  • Reemplace administrator@contoso.onmicrosoft.com en el ejemplo siguiente por el UPN de un 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

Ejemplo 4: solicitud de credenciales en la nube mediante la autenticación moderna

Nota

Si está trabajando en una máquina de dominio compartido con una cuenta que tiene privilegios de administrador de dominio y su organización protege el inicio de sesión basado en contraseña y aplica métodos de autenticación moderna, como autenticación multifactor, FIDO2 o tecnología de tarjeta inteligente, debe usar el parámetro -UserPrincipalName con el nombre principal de usuario (UPN) de un administrador global. Y puede omitir el parámetro «-DomainCredential». >: reemplace administrator@contoso.onmicrosoft.com en el ejemplo siguiente por el UPN de un 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

Visualización y comprobación del servidor Kerberos de Microsoft Entra

Para ver y comprobar el servidor Kerberos de Microsoft Entra recién creado, use el siguiente 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 genera las propiedades del servidor Kerberos de Microsoft Entra. Puede revisar las propiedades para comprobar que todo está en orden.

Nota:

La ejecución en otro dominio tras suministrar la credencial en formato dominio\nombre de usuario da lugar a que se conecte por medio de NTLM y a que luego genere un error. Sin embargo, el uso del formato userprincipalname para el administrador de dominio garantizará que al enlazar RPC al controlador de dominio se intente usar Kerberos correctamente. Si los usuarios están en el grupo de seguridad Usuarios protegidos de Active Directory, siga estos pasos para resolver el problema: inicie sesión como otro usuario de dominio en ADConnect y no proporcione "-domainCredential". Se usa el vale de Kerberos del usuario que ha iniciado la sesión. Para confirmarlo, ejecute whoami /groups a fin de validar si el usuario tiene los permisos necesarios en Active Directory para ejecutar el comando anterior.

Propiedad Descripción
ID Identificador único del objeto controlador de dominio de AD DS. A veces a este identificador se le conoce como su ranura o su id. de rama.
DomainDnsName Nombre de dominio DNS del dominio de Active Directory.
ComputerAccount Objeto de cuenta de equipo del objeto de servidor Kerberos de Microsoft Entra (el controlador de dominio).
UserAccount Objeto de cuenta de usuario deshabilitado que contiene la clave de cifrado del TGT del servidor Kerberos de Microsoft Entra. El nombre de dominio de esta cuenta es CN=krbtgt_AzureAD,CN=Users,<Domain-DN>.
KeyVersion Versión de la clave de cifrado del TGT del servidor Kerberos de Microsoft Entra. La versión se asigna cuando se crea la clave. Luego se incrementa cada vez que se rota la clave. Los incrementos se basan en los metadatos de replicación y probablemente sean mayores que uno. Por ejemplo, el valor inicial de KeyVersion podría ser 192272. La primera vez que se gira la clave, la versión podría avanzar hasta 212621. Lo importante es comprobar que el valor de KeyVersion del objeto local y el valor de CloudKeyVersion del objeto de nube sean los mismos.
KeyUpdatedOn Fecha y hora en que se actualizó o creó la clave de cifrado del TGT del servidor Kerberos de Microsoft Entra.
KeyUpdatedFrom Controlador de dominio en el que se actualizó por última vez la clave de cifrado del TGT del servidor Kerberos de Microsoft Entra.
CloudId El id. del objeto de Microsoft Entra. Debe coincidir con el identificador de la primera línea de la tabla.
CloudDomainDnsName El DomainDnsName del objeto de Microsoft Entra. Debe coincidir con el elemento DomainDnsName de la segunda línea de la tabla.
CloudKeyVersion La KeyVersion del objeto de Microsoft Entra. Debe coincidir con el elemento KeyVersion de la quinta línea de la tabla.
CloudKeyUpdatedOn La KeyUpdatedOn del objeto de Microsoft Entra. Debe coincidir con el elemento KeyUpdatedOn de la sexta línea de la tabla.

Rotación de la clave de servidor Kerberos de Microsoft Entra

Las claves krbtgt de cifrado del servidor Kerberos de Microsoft Entra se deben rotar periódicamente. Se recomienda seguir la misma programación que se emplea para rotar todas las demás claves krbtgt del controlador de dominio de Active Directory.

Advertencia

Aunque hay otras herramientas que podrían rotar las claves krbtgt, Sin embargo, debe usar las herramientas que se mencionan en este documento para rotar las claves krbtgt del servidor de Kerberos de Microsoft Entra. Esto garantiza que las claves se actualicen tanto en Active Directory local como en Microsoft Entra ID.

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

Eliminación del servidor de Kerberos de Microsoft Entra

Si quiere revertir el escenario y quitar el servidor de Kerberos de Microsoft Entra de Active Directory local y Microsoft Entra ID, ejecute el siguiente comando:

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

Escenarios de varios bosques y varios dominios

El objeto del servidor Kerberos de Microsoft Entra se representa en Microsoft Entra ID como un objeto KerberosDomain. Cada dominio de Active Directory local se representa como un único objeto KerberosDomain en Microsoft Entra ID.

Por ejemplo, imagine que la organización tiene un bosque de Active Directory con dos dominios: contoso.com y fabrikam.com. Si opta por permitir que Microsoft Entra ID emita TGT de Kerberos para todo el bosque, hay dos objetos KerberosDomain en Microsoft Entra ID: un objeto KerberosDomain para contoso.com y el otro para fabrikam.com. Si tiene varios bosques de Active Directory, tendrá un objeto KerberosDomain para cada dominio de cada bosque.

Siga las instrucciones de Creación de un objeto de servidor de Kerberos en cada dominio y bosque de la organización que contiene usuarios de Microsoft Entra.

Comportamiento conocido

Si la contraseña ha expirado, se bloquea el inicio de sesión con FIDO. La expectativa es que los usuarios restablezcan sus contraseñas para poder iniciar sesión mediante FIDO. Este comportamiento también se aplica al inicio de sesión de usuario sincronizado local híbrido con la confianza kerberos en la nube de Windows Hello para empresas.

Solución de problemas y comentarios

Si tiene problemas o quiere compartir comentarios sobre esta característica de inicio de sesión con clave de seguridad sin contraseña, hágalo por medio de la aplicación Centro de opiniones de Windows de este modo:

  1. Abra Centro de opiniones y asegúrese de que ha iniciado sesión.
  2. Para enviar comentarios, seleccione las siguientes categorías:
    • Categoría: Seguridad y privacidad
    • Subcategoría: FIDO
  3. Para capturar registros, use la opción Volver a crear mi problema.

Preguntas frecuentes sobre el inicio de sesión con clave de seguridad sin contraseña

Sugerencia

Los pasos de este artículo pueden variar ligeramente en función del portal desde donde comienza.

Estas son algunas respuestas a preguntas frecuentes sobre el inicio de sesión sin contraseña:

¿Funciona el inicio de sesión con clave de seguridad sin contraseña en mi entorno local?

La característica no funciona en un entorno de AD DS local puro.

Mi organización exige autenticación en dos fases para acceder a los recursos. ¿Qué puedo hacer para admitir este requisito?

Las claves de seguridad tienen varios factores de forma. Póngase en contacto con el fabricante del dispositivo para ver cómo se pueden habilitar sus dispositivos con un PIN o reconocimiento biométrico como segundo factor.

¿Pueden los administradores configurar claves de seguridad?

Se está trabajando en esta capacidad para la versión de disponibilidad general (GA) de esta característica.

¿Dónde puedo encontrar claves de seguridad compatibles?

Para obtener información sobre claves de seguridad compatibles, vea Claves de seguridad FIDO2.

¿Qué puedo hacer si pierdo mi clave de seguridad?

Para eliminar una clave de seguridad inscrita, inicie sesión en myaccount.microsoft.com y luego vaya a la página Información de seguridad.

¿Qué puedo hacer si no puedo usar la clave de seguridad FIDO inmediatamente después de crear una máquina unida a Microsoft Entra híbrido?

Si está realizando una instalación limpia de una máquina unida a Microsoft Entra híbrido, después del proceso de unión al dominio y reinicio, debe iniciar sesión con una contraseña y esperar a que se sincronice la directiva para poder usar la clave de seguridad FIDO para iniciar sesión.

  • Compruebe el estado actual mediante la ejecución de dsregcmd /status en una ventana del símbolo del sistema y asegúrese de que los estados AzureAdJoined y DomainJoinedaparezcan como SÍ.
  • Este retraso de la sincronización es una limitación conocida de los dispositivos unidos a dominio y no es específico de FIDO.

¿Qué ocurre si no puedo lograr el inicio de sesión único en mi recurso de red de NTLM después de iniciar sesión con FIDO y obtener un símbolo del sistema de credenciales?

Asegúrese de que se hayan revisado suficientes controladores de dominio para responder a tiempo y atender la solicitud de recursos. Para ver si un controlador de dominio ejecuta la característica, ejecute nltest /dsgetdc:contoso /keylist /kdc y revise la salida.

Nota:

El modificador /keylist del comando nltest está disponible en el cliente Windows 10, v2004 y posterior.

¿Funcionan las claves de seguridad FIDO2 en un inicio de sesión de Windows con RODC presente en el entorno híbrido?

Un inicio de sesión de Windows FIDO2 busca un controlador de dominio grabable para intercambiar el TGT del usuario. Siempre que tenga al menos un controlador de dominio grabable por sitio, el inicio de sesión funciona bien.

Pasos siguientes

Más información sobre la autenticación sin contraseña