Configuración de la autenticación basada en certificados de Microsoft Entra

Su organización puede implementar la autenticación sin contraseña, moderna y resistente a la suplantación de identidad mediante certificados X.509 de usuario mediante la autenticación basada en certificados (CBA) de Microsoft Entra.

En este artículo, aprenderá a configurar el inquilino de Microsoft Entra para permitir o requerir que los usuarios de inquilino se autentiquen mediante certificados X.509. Un usuario crea un certificado X.509 mediante una infraestructura de clave pública de empresa (PKI) para el inicio de sesión de la aplicación y el explorador.

Cuando se configura Microsoft Entra CBA, durante el inicio de sesión, un usuario ve una opción para autenticarse mediante un certificado en lugar de escribir una contraseña. Si hay varios certificados coincidentes en el dispositivo, el usuario selecciona el certificado correspondiente y el certificado se valida en la cuenta de usuario. Si la validación se realiza correctamente, el usuario inicia sesión.

Complete los pasos descritos en este artículo para configurar y usar Microsoft Entra CBA para los inquilinos en los planes de Office 365 Enterprise y us Government. Ya debe tener una PKI configurada.

Requisitos previos

Asegúrese de que se cumplan los siguientes requisitos previos:

• Al menos una entidad de certificación (CA) y las CA intermedias están configuradas en el identificador de Entra de Microsoft.
• El usuario tiene acceso a un certificado de usuario emitido desde una PKI de confianza configurada en el inquilino destinado a la autenticación de cliente en el id. de Microsoft Entra.
• Cada ENTIDAD de certificación tiene una lista de revocación de certificados (CRL) a la que se puede hacer referencia desde direcciones URL accesibles desde Internet. Si la entidad de certificación de confianza no tiene configurada una CRL, Microsoft Entra ID no realizará ninguna comprobación de CRL, la revocación de certificados de usuario no funcionará y la autenticación no se bloqueará.

Consideraciones

• Asegúrese de que la PKI es segura y no se puede poner en peligro fácilmente. Si se produce una infracción, el atacante puede crear y firmar certificados de cliente y poner en peligro a cualquier usuario del inquilino, incluidos los usuarios que se sincronizan desde el entorno local. Una estrategia de protección de claves sólida y otros controles físicos y lógicos puede proporcionar defensa en profundidad para evitar que atacantes externos o amenazas internas comprometan la integridad de la PKI. Para obtener más información, consulte Protección de PKI.

• Para conocer los procedimientos recomendados para la criptografía de Microsoft, incluida la elección del algoritmo, la longitud de clave y la protección de datos, consulte Recomendaciones de Microsoft. Asegúrese de usar uno de los algoritmos recomendados, una longitud de clave recomendada y curvas aprobadas por NIST.

• Como parte de las mejoras de seguridad en curso, los puntos de conexión de Azure y Microsoft 365 agregaron compatibilidad con TLS 1.3. Se espera que el proceso tarde unos meses en cubrir los miles de puntos de conexión de servicio en Azure y Microsoft 365. El punto de conexión de Microsoft Entra que usa CBA de Microsoft Entra se incluye en la actualización: *.certauth.login.microsoftonline.com y *.certauth.login.microsoftonline.us.

  TLS 1.3 es la versión más reciente del protocolo de seguridad más usado de Internet. TLS 1.3 cifra los datos para proporcionar un canal de comunicación seguro entre dos puntos de conexión. Elimina algoritmos criptográficos obsoletos, mejora la seguridad en versiones anteriores y cifra la mayor parte del protocolo de enlace posible. Se recomienda encarecidamente empezar a probar TLS 1.3 en sus aplicaciones y servicios.

• Al evaluar una PKI, es importante revisar las directivas de emisión de certificados y la aplicación. Como se ha descrito anteriormente, agregar entidades de certificación a una configuración de Microsoft Entra permite que los certificados emitidos por esas CA autentiquen a cualquier usuario en el identificador de Microsoft Entra.

  Es importante tener en cuenta cómo y cuándo pueden emitir certificados y cómo implementan identificadores reutilizables. Los administradores solo necesitan asegurarse de que se puede usar un certificado específico para autenticar a un usuario, pero deben usar exclusivamente enlaces de alta afinidad para lograr un mayor nivel de garantía de que solo un certificado específico puede autenticar al usuario. Para obtener más información, consulte Enlaces de afinidad alta.

Configurar y probar Microsoft Entra CBA

Debe completar algunos pasos de configuración antes de activar Microsoft Entra CBA.

Un administrador debe configurar las entidades de certificación de confianza que emiten certificados de usuario. Como se muestra en el diagrama siguiente, Azure usa el control de acceso basado en rol (RBAC) para asegurarse de que solo se requieren administradores con privilegios mínimos para realizar cambios.

Importante

Microsoft recomienda usar roles con el menor número de permisos. Esta práctica ayuda a mejorar la seguridad de su organización. El administrador global es un rol con privilegios elevados que debe limitarse a escenarios de emergencia o cuando no se puede usar un rol existente.

Opcionalmente, puede configurar enlaces de autenticación para asignar certificados a la autenticación de un solo factor o a la autenticación multifactor (MFA). Configure los enlaces de nombre de usuario para asignar el campo de certificado a un atributo del objeto de usuario. Un administrador de directivas de autenticación puede configurar las opciones relacionadas con el usuario.

Cuando finalicen todas las configuraciones, active Microsoft Entra CBA en el inquilino.

Paso 1: Configurar las CA con un almacén de confianza basado en PKI

Microsoft Entra tiene un nuevo almacén de confianza de CA basado en PKI. El almacén de confianza mantiene las CA dentro de un objeto contenedor para cada PKI. Los administradores pueden administrar ca en un contenedor basado en PKI más fácilmente de lo que pueden administrar una lista plana de CA.

El almacén de confianza basado en PKI tiene límites más altos que el almacén de confianza clásico para el número de CA y el tamaño de cada archivo de CA. Un almacén de confianza basado en PKI admite hasta 250 CA y 8 KB para cada objeto de CA.

Si usa el almacén de confianza clásico para configurar ca, se recomienda encarecidamente configurar un almacén de confianza basado en PKI. El almacén de confianza basado en PKI es escalable y admite nuevas funcionalidades, como sugerencias del emisor.

Un administrador debe configurar las entidades de certificación de confianza que emiten certificados de usuario. Solo se requieren administradores con privilegios mínimos para realizar cambios. A un almacén de confianza basado en PKI se le asigna el rol Administrador de autenticación con privilegios .

La característica de carga de PKI del almacén de confianza basado en PKI solo está disponible con una licencia P1 o P2 de Microsoft Entra ID. Sin embargo, con la licencia gratuita de Microsoft Entra, un administrador puede cargar todas las CA individualmente en lugar de cargar un archivo PKI. Después, pueden configurar el almacén de confianza basado en PKI y agregar sus archivos de CA cargados.

Configuración de caas mediante el Centro de administración de Microsoft Entra

Creación de un objeto de contenedor PKI (Centro de administración de Microsoft Entra)

Para crear un objeto de contenedor PKI:

1. Inicie sesión en el Centro de administración de Microsoft Entra con una cuenta que tenga asignado el rol Administrador de autenticación con privilegios .

2. Vaya a Entra ID>Identity Secure Score>Infraestructura de clave pública.

3. Seleccione Crear PKI.

4. En Nombre para mostrar, escriba un nombre.

5. Selecciona Crear.

   

6. Para agregar o eliminar columnas, seleccione Editar columnas.

7. Para actualizar la lista de PKIs, seleccione Actualizar.

Eliminar un objeto de contenedor de PKI

Para eliminar una PKI, seleccione la PKI y seleccione Eliminar. Si la PKI contiene CA, escriba el nombre de la PKI para confirmar la eliminación de todas las CA en la PKI. A continuación, seleccione Eliminar.

Carga de ca individuales en un objeto contenedor PKI

Para cargar una ENTIDAD de certificación en un contenedor PKI:

1. Seleccione Agregar entidad de certificación.

2. Seleccione el archivo de CA.

3. Si la ENTIDAD de certificación es un certificado raíz, seleccione Sí. De lo contrario, seleccione No.

4. En Dirección URL de lista de revocación de certificados, escriba la dirección URL accesible desde Internet para la CRL base de CA que contiene todos los certificados revocados. Si no se establece la dirección URL, no se produce un error al intentar autenticarse mediante un certificado revocado.

5. En Delta Certificate Revoke List URL (Dirección URL de lista de revocación de certificados delta), escriba la dirección URL accesible desde Internet para la CRL que contiene todos los certificados revocados desde que se publicó la última CRL base.

6. Si la ENTIDAD de certificación no debe incluirse en sugerencias del emisor, desactive las sugerencias del emisor. La marca Sugerencias del emisor está desactivada de forma predeterminada.

7. Selecciona Guardar.

8. Para eliminar una ENTIDAD de certificación, seleccione la ENTIDAD de certificación y seleccione Eliminar.

   

9. Para agregar o eliminar columnas, seleccione Editar columnas.

10. Para actualizar la lista de PKIs, seleccione Actualizar.

Inicialmente, se muestran 100 certificados de ENTIDAD de certificación. Aparecen más a medida que se desplaza hacia abajo en el panel.

Carga de todas las CA en un objeto contenedor PKI

Para cargar de forma masiva todas las CA en un contenedor PKI:

1. Cree un objeto de contenedor PKI o abra un contenedor existente.

2. Seleccione Cargar PKI.

3. Escriba la dirección URL accesible desde Internet HTTP del .p7b archivo.

4. Escriba la suma de comprobación SHA-256 del archivo.

5. Seleccione la carga.

   El proceso de carga de PKI es asincrónico. A medida que se carga cada entidad de certificación, está disponible en la PKI. La carga completa de PKI puede tardar hasta 30 minutos.

6. Seleccione Actualizar para actualizar la lista de entidades de certificación.

7. Cada atributo de punto de conexión crL de CA cargado se actualiza con la primera dirección URL HTTP disponible del certificado de ENTIDAD de certificación que aparece como el atributo de puntos de distribución CRL . Debe actualizar manualmente los certificados hoja.

Para generar la suma de comprobación SHA-256 del archivo PKI .p7b , ejecute:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Edición de un PKI

1. En la fila PKI, seleccione ... y seleccione Editar.
2. Escriba un nuevo nombre PKI.
3. Selecciona Guardar.

Edición de una entidad de certificación

1. En la fila CA, seleccione ... y seleccione Editar.
2. Escriba nuevos valores para el tipo de CA (raíz o intermedio), la dirección URL de CRL, la dirección URL de CRL delta o la marca habilitada para sugerencias del emisor según sus requisitos.
3. Selecciona Guardar.

Edición masiva del atributo de sugerencias del emisor

1. Para editar varias CA y activar o desactivar el atributo Habilitado para sugerencias del emisor , seleccione varias CA.
2. Seleccione Editar y, a continuación, seleccione Editar sugerencias del emisor.
3. Active la casilla Sugerencias del emisor habilitadas para todas las CA seleccionadas o desactive la selección para desactivar la marca De sugerencias del emisor habilitadas para todas las CA seleccionadas. El valor predeterminado es Indeterminado.
4. Selecciona Guardar.

Restaurar una PKI

1. Seleccione la pestaña PKI eliminadas.
2. Seleccione la PKI y seleccione Restaurar PKI.

Restauración de una entidad de certificación

1. Seleccione la pestaña Entidades de certificación eliminadas.
2. Seleccione el archivo de CA y, a continuación, seleccione Restaurar entidad de certificación.

Configuración del atributo isIssuerHintEnabled para una CA

Las sugerencias del emisor envían un indicador de CA de confianza como parte del protocolo de enlace seguridad de la capa de transporte (TLS). La lista de CA de confianza se establece en el asunto de las CA que el inquilino carga en el almacén de confianza de Microsoft Entra. Para obtener más información, consulte Descripción de las sugerencias del emisor.

De manera predeterminada, los nombres de firmante de todas las CA del almacén de confianza de Microsoft Entra se envían como sugerencias. Si desea devolver una sugerencia solo para entidades de certificación específicas, establezca el atributo isIssuerHintEnabledtruede sugerencia del emisor en .

El servidor puede devolver al cliente TLS una respuesta máxima de 16 KB para las sugerencias del emisor (el nombre del firmante de la CA). Se recomienda establecer el isIssuerHintEnabled atributo true en solo para las CA que emiten certificados de usuario.

Si varias CA intermedias del mismo certificado raíz emiten certificados de usuario, de forma predeterminada, todos los certificados aparecen en el selector de certificados. Si establece isIssuerHintEnabled en true para ca específicas, solo los certificados de usuario pertinentes aparecen en el selector de certificados.

Configuración de entidades de certificación mediante las API de Microsoft Graph

En los ejemplos siguientes se muestra cómo usar Microsoft Graph para ejecutar operaciones De creación, lectura, actualización y eliminación (CRUD) a través de métodos HTTP para una PKI o ca.

Creación de un objeto de contenedor PKI (Microsoft Graph)

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

Obtener todos los objetos PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

Obtención de un objeto PKI por id. de PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/
ConsistencyLevel: eventual

Carga de CA mediante un archivo .p7b

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-id>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
     "uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
     "sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

Obtener todas las entidades de certificación de una PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities
ConsistencyLevel: eventual

Obtención de una entidad de certificación específica en una PKI por identificador de CA

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
ConsistencyLevel: eventual

Actualizar una marca de sugerencias de emisor de CA específica

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

Configuración de entidades de certificación mediante PowerShell

Para estos pasos, use Microsoft Graph PowerShell.

1. Inicie PowerShell mediante la opción Ejecutar como administrador .

2. Instale e importe el SDK de PowerShell de Microsoft Graph:

   Install-Module Microsoft.Graph -Scope AllUsers
   Import-Module Microsoft.Graph.Authentication
   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
   

3. Conéctese al inquilino y acepte todo:

      Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>
   

Priorización entre un almacén de confianza basado en PKI y un almacén de CA clásico

Si existe una ENTIDAD de certificación tanto en un almacén de CA basado en PKI como en un almacén de CA clásico, se prioriza el almacén de confianza basado en PKI.

En estos escenarios se prioriza un almacén de CA clásico:

• Una ENTIDAD de certificación existe en ambos almacenes, el almacén basado en PKI no tiene CRL, pero la CA de la tienda clásica tiene una CRL válida.
• Existe una ENTIDAD de certificación en ambos almacenes y la CRL del almacén basado en PKI es diferente de la CRL de CA de la tienda clásica.

Registro de inicio de sesión

Una entrada interrumpida del registro de inicio de sesión de Microsoft Entra tiene dos atributos en Detalles adicionales para indicar si el almacén de confianza clásico o heredado se usó en absoluto durante la autenticación.

• Is Legacy Store Used tiene un valor de 0 para indicar que se usa un almacén basado en PKI. Un valor de 1 indica que se usa un almacén clásico o heredado.
• La información de uso del almacén heredado muestra el motivo por el que se usa el almacén clásico o heredado.

Registro de auditoría

Las operaciones CRUD que ejecute en una PKI o CA dentro del almacén de confianza aparecen en los registros de auditoría de Microsoft Entra.

Migración de un almacén de CA clásico a un almacén basado en PKI

Un administrador de inquilinos puede cargar todas las CA en el almacén basado en PKI. A continuación, el almacén de ca de PKI tiene prioridad sobre un almacén clásico y toda la autenticación de CBA se produce a través del almacén basado en PKI. Un administrador de inquilinos puede quitar las CA de un almacén clásico o heredado después de confirmar que no hay ninguna indicación en los registros de inicio de sesión que se usó el almacén clásico o heredado.

Preguntas más frecuentes

¿Por qué se produce un error en la carga de PKI?

Compruebe que el archivo PKI es válido y que se puede acceder a él sin problemas. El tamaño máximo del archivo PKI es de 2 MB (250 CA y 8 KB para cada objeto de CA).

¿Cuál es el contrato de nivel de servicio para la carga de PKI?

La carga de PKI es una operación asincrónica y puede tardar hasta 30 minutos en finalizar.

¿Cómo se genera una suma de comprobación SHA-256 para un archivo PKI?

Para generar la suma de comprobación SHA-256 del archivo PKI .p7b , ejecute este comando:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Paso 2: Activar CBA para el inquilino

Importante

Un usuario se considera capaz de completar MFA cuando el usuario se designa como en el ámbito de CBA en la directiva de métodos de autenticación. Este requisito de directiva significa que un usuario no puede usar la prueba de identidad como parte de su autenticación para registrar otros métodos disponibles. Si el usuario no tiene acceso a los certificados, está bloqueado y no puede registrar otros métodos para MFA. Los administradores a los que se les asigna el rol Administrador de directivas de autenticación deben activar CBA solo para los usuarios que tengan certificados válidos. No incluya Todos los usuarios para CBA. Use solo grupos de usuarios que tengan certificados válidos disponibles. Para más información, consulte Autenticación multifactor de Microsoft Entra.

Para activar CBA a través del Centro de administración de Microsoft Entra:

1. Inicie sesión en el Centro de administración de Microsoft Entra con una cuenta asignada al menos el rol Administrador de directivas de autenticación .

2. Vaya a Grupos>todos los grupos.

3. Seleccione Nuevo grupo y cree un grupo para los usuarios de CBA.

4. Vaya aMétodos> de autenticación de Entra ID>Autenticación basada en certificados.

5. En Habilitar y destino, seleccione Habilitar y, a continuación, active la casilla Confirmación .

6. Elija Seleccionar grupos>Agregar grupos.

7. Elija grupos específicos, como el que creó y, a continuación, elija Seleccionar. Use grupos específicos en lugar de Todos los usuarios.

8. Selecciona Guardar.

   

Después de activar CBA para el inquilino, todos los usuarios del inquilino ven la opción de iniciar sesión con un certificado. Solo los usuarios que son capaces de usar CBA pueden autenticarse mediante un certificado X.509.

Nota

El administrador de red debe permitir el acceso al punto de conexión de autenticación de certificados para el entorno en la nube de la organización además del login.microsoftonline.com punto de conexión. Desactive la inspección de TLS en el punto de conexión de autenticación de certificados para asegurarse de que la solicitud de certificado de cliente se realiza correctamente como parte del protocolo de enlace TLS.

Paso 3: Configurar una directiva de enlace de autenticación

Una directiva de enlace de autenticación ayuda a establecer la intensidad de la autenticación en un solo factor o en MFA. El nivel de protección predeterminado para todos los certificados del inquilino es la autenticación de un solo factor.

El enlace de afinidad predeterminado en el nivel de inquilino es una afinidad baja. Un administrador de directivas de autenticación puede cambiar el valor predeterminado de autenticación de un solo factor a MFA. Si cambia el nivel de protección, todos los certificados del inquilino se establecen en MFA. Del mismo modo, el enlace de afinidad en el nivel de inquilino se puede establecer en afinidad alta. A continuación, todos los certificados se validan mediante el uso de solo atributos de afinidad alta.

Importante

Un administrador debe establecer el valor predeterminado del inquilino en un valor aplicable a la mayoría de los certificados. Cree reglas personalizadas solo para certificados específicos que necesiten un enlace de afinidad o nivel de protección diferente al predeterminado del inquilino. Todas las configuraciones del método de autenticación se encuentran en el mismo archivo de directiva. La creación de varias reglas redundantes puede superar el límite de tamaño del archivo de directiva.

Las reglas de enlace de autenticación asignan atributos de certificado como Issuer, Policy Object ID (OID) y Issuer y Policy OID a un valor especificado. Las reglas establecen el nivel de protección predeterminado y el enlace de afinidad para esa regla.

Para modificar la configuración predeterminada del inquilino y crear reglas personalizadas a través del Centro de administración de Microsoft Entra:

1. Inicie sesión en el Centro de administración de Microsoft Entra con una cuenta asignada al menos el rol Administrador de directivas de autenticación .

2. Vaya a Directivas demétodos> de autenticación de Entra ID>.

3. En Administrar migraciones, seleccione Métodos> deautenticación Autenticación autenticación basada en certificados.

   

4. Para configurar el enlace de autenticación y el enlace de nombre de usuario, seleccione Configurar.

5. Para cambiar el valor predeterminado a MFA, seleccione Autenticación multifactor. El atributo de nivel de protección tiene un valor predeterminado de Autenticación de factor único.

   Nota

   El nivel de protección predeterminado está en vigor si no se agrega ninguna regla personalizada. Si agrega una regla personalizada, se respeta el nivel de protección definido en el nivel de regla en lugar del nivel de protección predeterminado.

   

6. También puede configurar reglas de enlace de autenticación personalizadas para ayudar a determinar el nivel de protección de los certificados de cliente que necesitan valores diferentes de nivel de protección o enlace de afinidad, distintos a los valores predeterminados del inquilino. Puede configurar las reglas mediante el asunto del emisor o el OID de directiva, o ambos campos, en el certificado.

   Las reglas de enlace de autenticación asignan los atributos de certificado (emisor o OID de directiva) a un valor. El valor establece el nivel de protección predeterminado para esa regla. Se pueden crear varias reglas. En el ejemplo siguiente, supongamos que el valor predeterminado del inquilino es Autenticación multifactor y Bajo para el enlace de afinidad.

   Para agregar reglas personalizadas, seleccione Agregar regla.

   

   Para crear una regla por emisor de certificado:

   1. Seleccione Emisor de certificados.

   2. En Identificador del emisor de certificados, seleccione un valor relevante.

   3. En Seguridad de la autenticación, seleccione Autenticación multifactor.

   4. En Enlace de afinidad, seleccione Bajo.

   5. Selecciona Agregar.

   6. Cuando se le solicite, active la casilla Confirmación para agregar la regla.

      

   Para crear una regla por OID de directiva:

   1. Seleccione OID de directiva.

   2. En OID de directiva, escriba un valor.

   3. En Seguridad de la autenticación, seleccione Autenticación de un solo factor.

   4. En Enlace de afinidad, seleccione Bajo para el enlace de afinidad.

   5. Selecciona Agregar.

   6. Cuando se le solicite, active la casilla Confirmación para agregar la regla.

      

   Para crear una regla por emisor y OID de directiva:

   1. Seleccione Emisor de certificados y OID de directiva.

   2. Seleccione un emisor y escriba el OID de directiva.

   3. En Seguridad de la autenticación, seleccione Autenticación multifactor.

   4. En Enlace de afinidad, seleccione Bajo.

   5. Selecciona Agregar.

      

      

   6. Autentíquese con un certificado que tenga un OID de directiva de 3.4.5.6 y lo emite CN=CBATestRootProd. Compruebe que la autenticación pasa para una notificación multifactor.

   Para crear una regla por emisor y número de serie:

   1. Agregue una directiva de enlace de autenticación. La directiva requiere que cualquier certificado emitido por CN=CBATestRootProd con un OID de directiva de solo necesite enlace de 1.2.3.4.6 alta afinidad. Se usan el emisor y el número de serie.

      

   2. Seleccione el campo certificado. En este ejemplo, seleccione Emisor y número de serie.

      

   3. El único atributo de usuario admitido es certificateUserIds. Seleccione certificateUserIds y seleccione Agregar.

      

   4. Selecciona Guardar.

      El registro de inicio de sesión muestra qué enlace se usó para el inicio de sesión y los detalles del certificado.

      

7. Seleccione Aceptar para guardar las reglas personalizadas.

Importante

Escriba el OID de directiva mediante el formato de identificador de objeto. Por ejemplo, si la directiva de certificado indica Todas las directivas de emisión, escriba el OID de directiva como 2.5.29.32.0 cuando agregue la regla. La cadena Todas las directivas de emisión no es válida para el editor de reglas y no surte efecto.

Paso 4: Configurar la directiva de enlace de nombre de usuario

La directiva de enlace de nombre de usuario ayuda a validar el certificado de un usuario. De forma predeterminada, para determinar el usuario, asigne el nombre principal del certificado al userPrincipalName objeto de usuario.

Un administrador de directivas de autenticación puede invalidar el valor predeterminado y crear una asignación personalizada. Para obtener más información, consulte Funcionamiento del enlace de nombre de usuario.

Para ver otros escenarios que usan el certificateUserIds atributo, consulte Identificadores de usuario de certificado.

Importante

Si una directiva de enlace de nombre de usuario usa atributos sincronizados como certificateUserIds, onPremisesUserPrincipalNamey el userPrincipalName atributo del objeto de usuario, las cuentas que tienen permisos administrativos en Windows Server Active Directory local pueden realizar cambios que afecten a estos atributos en microsoft Entra ID. Por ejemplo, las cuentas que tienen derechos delegados en objetos de usuario o un rol de administrador en Microsoft Entra Connect Server pueden realizar estos tipos de cambios.

1. Cree el enlace de nombre de usuario; para ello, seleccione uno de los campos del certificado X.509 para enlazar con uno de los atributos de usuario. El orden de enlace de nombre de usuario representa el nivel de prioridad del enlace. El primer enlace de nombre de usuario tiene la prioridad más alta, etc.

   

   Si el campo de certificado X.509 especificado se encuentra en el certificado, pero microsoft Entra ID no encuentra un objeto de usuario que tenga un valor correspondiente, se produce un error en la autenticación. A continuación, Microsoft Entra ID intenta el siguiente enlace de la lista.

2. Selecciona Guardar.

La configuración final tiene un aspecto similar al de este ejemplo:

Paso 5: Probar la configuración

En esta sección se describe cómo probar el certificado y las reglas de enlace de autenticación personalizadas.

Prueba del certificado

En la primera prueba de configuración, intente iniciar sesión en el portal MyApps mediante el explorador del dispositivo.

1. Escriba el nombre principal de usuario (UPN).

   

2. Seleccione Next (Siguiente).

   

   Si hizo que otros métodos de autenticación estuvieran disponibles, como el inicio de sesión telefónico o FIDO2, los usuarios podrían ver un cuadro de diálogo de inicio de sesión diferente.

   

3. Seleccione Iniciar sesión con un certificado.

4. Seleccione el certificado de usuario correcto en la interfaz de usuario del selector de certificados de cliente y seleccione Aceptar.

   

5. Compruebe que ha iniciado sesión en el portal MyApps.

Si el inicio de sesión se realiza correctamente, sabrá que:

• El certificado de usuario se aprovisiona en el dispositivo de prueba.
• El identificador de Entra de Microsoft está configurado correctamente para usar ca de confianza.
• El enlace de nombre de usuario está configurado correctamente. El usuario se encuentra y autentica.

Prueba de reglas de enlace de autenticación personalizadas

A continuación, complete un escenario en el que valide la autenticación segura. Cree dos reglas de directiva de autenticación: una mediante un emisor sujeto para satisfacer la autenticación de un solo factor y otra mediante el OID de directiva para satisfacer la autenticación multifactor.

1. Cree una regla de asunto del emisor con un nivel de protección de autenticación de un solo factor. Establezca el valor en el valor del firmante de la entidad de certificación.

   Por ejemplo:

   CN=WoodgroveCA

2. Cree una regla de OID de directiva que tenga un nivel de protección de autenticación multifactor. Establezca el valor en uno de los IDENTIFICADORes de directiva del certificado. Un ejemplo es 1.2.3.4.

   

3. Cree una directiva de acceso condicional de Microsoft Entra para que el usuario requiera MFA. Complete los pasos descritos en Acceso condicional: requerir MFA.

4. Vaya al portal MyApps. Escriba el UPN y seleccione Siguiente.

   

5. Seleccione Usar un certificado o una tarjeta inteligente.

   

   Si ha hecho que otros métodos de autenticación estén disponibles, como el inicio de sesión telefónico o las claves de seguridad, es posible que los usuarios vean un cuadro de diálogo de inicio de sesión diferente.

   

6. Seleccione el certificado de cliente y, a continuación, seleccione Información de certificado.

   

   Aparece el certificado y puede comprobar los valores de OID del emisor y de la directiva.

   

7. Para ver los valores de OID de directiva, seleccione Detalles.

   

8. Seleccione el certificado de cliente y seleccione Aceptar.

El OID de directiva del certificado coincide con el valor configurado de 1.2.3.4 y satisface MFA. El emisor del certificado coincide con el valor configurado de CN=WoodgroveCA y satisface la autenticación de un solo factor.

Dado que la regla de OID de directiva tiene prioridad sobre la regla del emisor, el certificado satisface MFA.

La directiva de acceso condicional para el usuario requiere MFA y el certificado satisface MFA, para que el usuario pueda iniciar sesión en la aplicación.

Prueba de la directiva de enlace de nombre de usuario

La directiva de enlace de nombre de usuario ayuda a validar el certificado del usuario. Se admiten tres enlaces para la directiva de enlace de nombre de usuario:

• IssuerAndSerialNumber > certificateUserIds
• IssuerAndSubject > certificateUserIds
• Subject > certificateUserIds

De forma predeterminada, el identificador de Microsoft Entra asigna el nombre principal del certificado al userPrincipalName objeto de usuario para determinar el usuario. Un administrador de directivas de autenticación puede invalidar el valor predeterminado y crear una asignación personalizada como se describió anteriormente.

Un administrador de directivas de autenticación debe configurar los nuevos enlaces. Para prepararse, deben asegurarse de que los valores correctos para los enlaces de nombre de usuario correspondientes se actualizan en el certificateUserIds atributo del objeto de usuario:

• Para los usuarios solo en la nube, use el Centro de administración de Microsoft Entra o las API de Microsoft Graph para actualizar el valor en certificateUserIds.
• Para los usuarios sincronizados locales, use Microsoft Entra Connect para sincronizar los valores desde el entorno local siguiendo las reglas de Microsoft Entra Connect o sincronizando el AltSecId valor.

Importante

El formato de los valores de Issuer, Subject y Serial number debe estar en el orden inverso de su formato en el certificado. No agregue ningún espacio en los valores issuer o Subject .

Asignación manual de números de serie y emisor

En el ejemplo siguiente se muestra la asignación manual del emisor y el número de serie.

El valor del emisor que se va a agregar es:

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

Para obtener el valor correcto para el número de serie, ejecute el siguiente comando. Almacene el valor que se muestra en certificateUserIds.

La sintaxis del comando es la siguiente:

certutil –dump –v [~certificate path~] >> [~dumpFile path~] 

Por ejemplo:

certutil -dump -v firstusercert.cer >> firstCertDump.txt

Este es un ejemplo del certutil comando :

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48 

El valor de número de serie que se va a agregar certificateUserId es:

b24134139f069b49997212a86ba0ef48

El certificateUserIds valor es:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48

Asignación manual del emisor y del asunto

En el ejemplo siguiente se muestra la asignación manual del emisor y del asunto.

El valor del emisor es:

El valor subject es:

El certificateUserId valor es:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Asignación manual del asunto

En el ejemplo siguiente se muestra la asignación manual del asunto.

El valor subject es:

El certificateUserIds valor es:

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Prueba del enlace de afinidad

1. Inicie sesión en el Centro de administración de Microsoft Entra con una cuenta asignada al menos el rol Administrador de directivas de autenticación .

2. Vaya a Directivas demétodos> de autenticación de Entra ID>.

3. En Administrar, seleccione Métodos> deautenticación Autenticación basada en certificados.

4. Seleccione Configurar.

5. Establezca Enlace de afinidad requerido en el nivel de inquilino.

   Importante

   Tenga cuidado con la configuración de afinidad para todo el inquilino. Es posible que bloquee todo el inquilino si cambia el valor enlace de afinidad requerido para el inquilino y no tiene valores correctos en el objeto de usuario. De forma similar, si crea una regla personalizada que se aplica a todos los usuarios y requiere un enlace de alta afinidad, es posible que los usuarios del inquilino estén bloqueados.

   

6. Para probarlo, en Enlace de afinidad obligatorio, seleccione Bajo.

7. Agregue un enlace de alta afinidad, como el identificador de clave de asunto (SKI). En Enlace de nombre de usuario, seleccione Agregar regla.

8. Seleccione SKI y seleccione Agregar.

   

   Cuando haya finalizado, la regla tendrá un aspecto similar al de este ejemplo:

   

9. Para todos los objetos de usuario, actualice el certificateUserIds atributo con el valor SKI correcto del certificado de usuario.

   Para obtener más información, consulte Patrones admitidos para CertificateUserIDs.

10. Cree una regla personalizada para el enlace de autenticación.

11. Selecciona Agregar.

    

    Compruebe que la regla completada tiene un aspecto similar al de este ejemplo:

    

12. Actualice el valor de usuario certificateUserIds con el valor ski correcto del OID de certificado y directiva de 9.8.7.5.

13. Pruebe mediante un certificado con OID de directiva de 9.8.7.5. Compruebe que el usuario está autenticado con el enlace SKI y que se le pedirá que inicie sesión con MFA y solo el certificado.

Configuración de CBA mediante las API de Microsoft Graph

Para configurar CBA y configurar enlaces de nombre de usuario mediante las API de Microsoft Graph:

1. Vaya al Explorador de Microsoft Graph.

2. Seleccione Iniciar sesión en el Explorador de Graph e inicie sesión en el inquilino.

3. Siga los pasos para dar su consentimiento al Policy.ReadWrite.AuthenticationMethod permiso delegado.

4. Obtenga todos los métodos de autenticación:

   GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
   

5. Obtenga la configuración del método de autenticación de certificados X.509:

   GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
   

6. De forma predeterminada, el método de autenticación de certificados X.509 está desactivado. Para permitir que los usuarios inicien sesión mediante un certificado, debe activar el método de autenticación y configurar las directivas de enlace de autenticación y nombre de usuario a través de una operación de actualización. Para actualizar la directiva, ejecute una PATCH solicitud.

   Cuerpo de la solicitud

   PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
   Content-Type: application/json
   
   {
       "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
       "id": "X509Certificate",
       "state": "enabled",
       "certificateUserBindings": [
           {
               "x509CertificateField": "PrincipalName",
               "userProperty": "onPremisesUserPrincipalName",
               "priority": 1
           },
           {
               "x509CertificateField": "RFC822Name",
               "userProperty": "userPrincipalName",
               "priority": 2
           }, 
           {
               "x509CertificateField": "PrincipalName",
               "userProperty": "certificateUserIds",
               "priority": 3
           }
       ],
       "authenticationModeConfiguration": {
           "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
           "rules": [
               {
                   "x509CertificateRuleType": "issuerSubject",
                   "identifier": "CN=WoodgroveCA ",
                   "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
               },
               {
                   "x509CertificateRuleType": "policyOID",
                   "identifier": "1.2.3.4",
                   "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
               }
           ]
       },
       "includeTargets": [
           {
               "targetType": "group",
               "id": "all_users",
               "isRegistrationRequired": false
           }
       ]
   }
   

7. Compruebe que se devuelve un 204 No content código de respuesta. Vuelva a ejecutar la GET solicitud para asegurarse de que las directivas se actualizan correctamente.

8. Pruebe la configuración iniciando sesión con un certificado que cumpla la directiva.

Configuración de CBA mediante Microsoft PowerShell

1. Abra PowerShell.

2. Conectarse a Microsoft Graph:

   Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
   

3. Cree una variable que se usará para definir un grupo para los usuarios de CBA:

   $group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
   

4. Defina el cuerpo de la solicitud:

   $body = @{
   "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
   "id" = "X509Certificate"
   "state" = "enabled"
   "certificateUserBindings" = @(
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "SubjectKeyIdentifier"
           "userProperty" = "certificateUserIds"
           "priority" = 1
       },
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "PrincipalName"
           "userProperty" = "UserPrincipalName"
           "priority" = 2
       },
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "RFC822Name"
           "userProperty" = "userPrincipalName"
           "priority" = 3
       }
   )
   "authenticationModeConfiguration" = @{
       "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
       "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
       "rules" = @(
           @{
               "@odata.type" = "#microsoft.graph.x509CertificateRule"
               "x509CertificateRuleType" = "policyOID"
               "identifier" = "1.3.6.1.4.1.311.21.1"
               "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
           }
       )
   }
   "includeTargets" = @(
       @{
           "targetType" = "group"
           "id" = $group.Id
           "isRegistrationRequired" = $false
       }
   ) } | ConvertTo-Json -Depth 5
   

5. Ejecute la PATCH solicitud:

   Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"
   

Contenido relacionado

• Información general sobre la autenticación basada en certificados de Microsoft Entra
• Conceptos técnicos de CBA de Microsoft Entra
• Limitaciones del uso de Microsoft Entra CBA
• Inicio de sesión de tarjeta inteligente de Windows mediante Microsoft Entra CBA
• CBA de Microsoft Entra en dispositivos móviles (Android e iOS)
• Identificadores de usuario de certificado
• Migración de usuarios federados
• Preguntas más frecuentes