Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Su organización puede implementar una autenticación moderna, resistente al phishing y sin contraseña mediante certificados X.509 de usuario utilizando la autenticación basada en certificados de Microsoft Entra (CBA).
En este artículo, aprenderá a configurar el inquilino de Microsoft Entra para permitir o requerir que los usuarios del 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 inquilinos en planes de Office 365 Enterprise y administración pública de ESTADOS Unidos. 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 se configuran en Microsoft Entra ID.
- 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 Microsoft Entra ID.
- 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 realiza ninguna comprobación de CRL, la revocación de certificados de usuario no funciona y no se bloquea la autenticación.
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 Microsoft recomendaciones. 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 han agregado compatibilidad con TLS 1.3. Se espera que el proceso tarde unos meses en cubrir miles de puntos de conexión de servicio entre Azure y Microsoft 365. El punto de conexión de Microsoft Entra que utiliza Microsoft Entra CBA está incluido en la actualización:
*.certauth.login.microsoftonline.comy*.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 comparación con las versiones anteriores y cifra la mayor parte del intercambio 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 Microsoft Entra ID.
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.
Configuración y prueba de 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 los permisos más mínimos. 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 gestionar las AC en un contenedor basado en PKI más fácilmente de lo que pueden manejar una lista plana de AC.
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 fiduciario basado en PKI soporta hasta 250 CAs y 8 KB para cada objeto CA.
Si utiliza el almacén de confianza clásico para configurar CAs, recomendamos encarecidamente que configure 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 de Microsoft Entra ID P1 o P2. Sin embargo, con la Microsoft Entra licencia gratuita, un administrador puede cargar todos los 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 entidades de certificación mediante el Microsoft Entra admin center
Creación de un objeto de contenedor PKI (Microsoft Entra admin center)
Para crear un objeto de contenedor PKI:
Inicie sesión en el centro de administración de Microsoft Entra con una cuenta que tenga asignado el rol de Administrador de Autenticación con Privilegios.
Ve a Entra>ID Identity Secure Score>infraestructurade clave pública.
Seleccione Crear PKI.
En Nombre para mostrar, escriba un nombre.
Selecciona Crear.
Para agregar o eliminar columnas, seleccione Editar columnas.
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 CAs individuales en un objeto contenedor PKI
Para cargar una Entidad de Certificación (CA) en un contenedor de Infraestructura de Clave Pública (PKI):
Seleccione Agregar entidad de certificación.
Seleccione el archivo de CA.
Si la autoridad de certificación es un certificado raíz, seleccione Sí. De lo contrario, seleccione No.
Para la URL de la Lista de Revocación de Certificados, introduzca la URL orientada a internet para la CRL base de la 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.
Para la URL de la Lista de Revocación de Certificados Delta, introduzca la URL de acceso a internet para la CRL que contiene todos los certificados revocados desde que se publicó la última CRL base.
Si la CA no debería incluirse en las pistas del emisor, desactiva las pistas del emisor. La marca Sugerencias del emisor está desactivada de forma predeterminada.
Selecciona Guardar.
Para eliminar una ENTIDAD de certificación, seleccione la ENTIDAD de certificación y seleccione Eliminar.
Para agregar o eliminar columnas, seleccione Editar columnas.
Para actualizar la lista de PKIs, seleccione Actualizar.
Inicialmente, se muestran 100 certificados de autoridad de certificación. Aparecen más a medida que usted 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:
Cree un objeto de contenedor PKI o abra un contenedor existente.
Seleccione Cargar PKI.
Escriba la dirección URL accesible desde Internet HTTP del
.p7barchivo.Escriba la suma de comprobación SHA-256 del archivo.
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.
Seleccione Actualizar para actualizar la lista de entidades de certificación.
Cada atributo final CRL de CA subido se actualiza con la primera URL HTTP disponible del certificado de CA listada como el atributo de puntos de distribución CRL. Debes actualizar manualmente cualquier certificado de 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
- En la fila PKI, seleccione ... y seleccione Editar.
- Escriba un nuevo nombre PKI.
- Selecciona Guardar.
Edición de una entidad de certificación
- En la fila CA, seleccione ... y seleccione Editar.
- Introduce nuevos valores para el tipo de CA (raíz o intermedia), la URL CRL, la URL delta CRL o la bandera habilitada para hints del emisor según tus necesidades.
- Selecciona Guardar.
Editar en bloque el atributo de hints del emisor
- Para editar varias CAs y activar o desactivar el atributo Hints del Emisor, selecciona varias CAs.
- Seleccione Editar y, a continuación, seleccione Editar sugerencias del emisor.
- 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.
- Selecciona Guardar.
Restaurar una PKI
- Seleccione la pestaña PKI eliminadas.
- Seleccione la PKI y seleccione Restaurar PKI.
Restauración de una entidad de certificación
- Seleccione la pestaña Entidades de certificación eliminadas.
- Seleccione el archivo de CA y, a continuación, seleccione Restaurar entidad de certificación.
Configuración del atributo isIssuerHintEnabled para una CA
Las pistas del emisor envían de vuelta un indicador de CA confiable como parte del handshake de Seguridad de la Capa de Transporte (TLS). La lista de CA confiable se establece como sujeto de las CAs que el inquilino sube a la tienda fiduciaria 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 de sugerencia del emisor isIssuerHintEnabled a true.
El servidor puede enviar al cliente TLS una respuesta máxima de 16 KB para las pistas del emisor (el nombre del asunto de la CA). Recomendamos que establezca el atributo isIssuerHintEnabled en true solo para las autoridades de certificación 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
Obtener un objeto PKI por ID de PKI
GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/
ConsistencyLevel: eventual
Sube las CAs usando 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
Consigue una CA específica en una PKI por ID de CA
GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
ConsistencyLevel: eventual
Actualizar una bandera específica de indicaciones del emisor de la CA
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.
Inicie PowerShell mediante la opción Ejecutar como administrador .
Instale e importe el Microsoft Graph PowerShell SDK:
Install-Module Microsoft.Graph -Scope AllUsers Import-Module Microsoft.Graph.Authentication Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserConéctate con el inquilino y acepta 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 Autoridad 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:
- Existe una CA en ambas tiendas, la tienda basada en PKI no tiene CRL, pero la CA clásica de la tienda tiene una CRL válida.
- Existe una CA en ambas tiendas, y el CRL de la tienda basada en PKI es diferente del CRL clásico de la tienda CA.
Registro de inicio de sesión
Una entrada interrumpida en el registro de inicio de sesión de Microsoft Entra tiene dos atributos bajo Detalles adicionales para indicar si se utilizó la memoria de confianza clásica o antigua 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.
- Información de uso de la tienda heredada muestra el motivo por el que se utiliza la tienda clásica o heredada.
Registro de auditoría
Las operaciones CRUD que se ejecutan 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 inquilino puede subir todas las CAs a la tienda basada en PKI. Entonces, el almacén de CA de PKI tiene prioridad sobre un almacén tradicional y toda la autenticación de CBA se produce a través del almacén basado en la PKI. Un administrador de cliente puede quitar las CA de una tienda clásica o heredada después de confirmar que no hay ninguna indicación en los registros de inicio de sesión de que se usó la tienda clásica o heredada.
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
Se considera que un usuario es capaz de completar MFA cuando se designa como parte del alcance de CBA en la política 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 obtener más información, consulte Microsoft Entra autenticación multifactorial.
Para activar CBA a través del Microsoft Entra admin center:
Inicie sesión en el Microsoft Entra admin center con una cuenta asignada al menos al rol Administrador de directivas de autenticación.
Vaya a Grupos>todos los grupos.
Seleccione Nuevo grupo y cree un grupo para los usuarios de CBA.
Vaya a Entra ID>Métodos de autenticación>Autenticación basada en certificados.
En Habilitar y destino, seleccione Habilitar y, a continuación, active la casilla Confirmación .
Elija Seleccionar grupos>Agregar grupos.
Elija grupos específicos, como el que creó y, a continuación, elija Seleccionar. Use grupos específicos en lugar de Todos los usuarios.
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 punto de conexión login.microsoftonline.com. Desactiva la inspección TLS en el endpoint de autenticación del certificado para asegurarte de que la solicitud de certificado del cliente tenga éxito como parte del handshake TLS.
Paso 3: Configurar una política de enlace de autenticación
Una política de vinculación de autenticación ayuda a establecer la fuerza de la autenticación a un solo factor o a MFA. El nivel de protección predeterminado para todos los certificados del inquilino es la autenticación de un solo factor.
El enlace de afiliación predeterminado a nivel de arrendatario es baja afinidad. 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 configuran en MFA. Del mismo modo, la vinculación de afinidad a nivel de entidad 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 por defecto del inquilino a 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 mediante el Microsoft Entra admin center:
Inicie sesión en el Microsoft Entra admin center con una cuenta asignada al menos al rol Administrador de directivas de autenticación.
Vaya a Entra ID>Métodos de autenticación>Políticas.
En Administrar migraciones, seleccione Métodos de autenticación> deautenticación basada en certificados.
Para configurar el enlace de autenticación y el enlace de nombre de usuario, seleccione Configurar.
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.
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. Puedes configurar las reglas usando el sujeto del emisor o el OID de la política, o ambos campos, en el certificado.
Las reglas de vinculación 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 siguiente ejemplo, supongamos que el valor predeterminado del inquilino es autenticación multifactor y Bajo para la vinculación de afinidad.
Para agregar reglas personalizadas, seleccione Agregar regla.
Para crear una regla por emisor de certificado:
Seleccione Emisor de certificados.
En Identificador del emisor de certificados, seleccione un valor relevante.
En Seguridad de la autenticación, seleccione Autenticación multifactor.
En Enlace de afinidad, seleccione Bajo.
Selecciona Agregar.
Cuando se le solicite, active la casilla Confirmación para agregar la regla.
Para crear una regla utilizando el OID de la directiva:
Seleccione OID de directiva.
En OID de directiva, escriba un valor.
En Seguridad de la autenticación, seleccione Autenticación de un solo factor.
Enlace de afinidad, seleccione bajo para el enlace de afinidad.
Selecciona Agregar.
Cuando se le solicite, active la casilla Confirmación para agregar la regla.
Para crear una norma por emisor y OID de póliza:
Seleccione Emisor de certificados y OID de directiva.
Seleccione un emisor y escriba el OID de directiva.
En Seguridad de la autenticación, seleccione Autenticación multifactor.
En Enlace de afinidad, seleccione Bajo.
Selecciona Agregar.
Autentíquese con un certificado que tenga un OID de directiva de
3.4.5.6y que sea emitido porCN=CBATestRootProd. Verifique que la autenticación sea válida para una reclamación multifactor.
Para crear una regla por emisor y número de serie:
Agregue una directiva de enlace de autenticación. La directiva requiere que cualquier certificado emitido por
CN=CBATestRootProdcon un OID de política de1.2.3.4.6necesite solo un enlace de alta afinidad. Se usan el emisor y el número de serie.
Seleccione el campo certificado. En este ejemplo, seleccione Emisor y número de serie.
El único atributo de usuario admitido es
certificateUserIds. SeleccionecertificateUserIdsy seleccione Agregar.
Selecciona Guardar.
El registro de inicio de sesión muestra qué vinculación se usó durante el inicio de sesión y los detalles del certificado.
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 política 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 Cómo funciona la vinculación de nombre de usuario.
Para otros escenarios que usan el atributo certificateUserIds, consulte Identificadores de usuario del certificado.
Importante
Si una directiva de enlace de nombre de usuario usa atributos sincronizados como certificateUserIds, onPremisesUserPrincipalName y el atributo userPrincipalName del objeto de usuario, las cuentas que tienen permisos administrativos en Windows Server Active Directory locales 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.
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. La primera vinculación del nombre de usuario tiene la prioridad más alta, y así sucesivamente.
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 producirá un error en la autenticación. A continuación, Microsoft Entra ID intenta la siguiente vinculación de la lista.
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.
Escriba el nombre principal de usuario (UPN).
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.
Seleccione Iniciar sesión con un certificado.
Seleccione el certificado de usuario correcto en la interfaz de usuario del selector de certificados de cliente y seleccione Aceptar.
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 ha sido aprovisionado en el dispositivo de prueba.
- Microsoft Entra ID está configurado correctamente para usar ca de confianza.
- La vinculación de nombre de usuario está configurada correctamente. El usuario ha sido localizado y autenticado.
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 política de autenticación: una utilizando un sujeto emisor para cumplir con la autenticación de un solo factor y otra mediante el OID de política para cumplir con la autenticación multifactor.
Crea una regla de sujeto del emisor con un nivel de protección de autenticación de un solo factor. Establece el valor en el valor de tu CA.
Por ejemplo:
CN=WoodgroveCACrea una regla de OID de política que tenga un nivel de protección de autenticación multifactor. Establece el valor en uno de los OIDs de la póliza en tu certificado. Un ejemplo es
1.2.3.4.
Crea una política de Acceso Condicional de Microsoft Entra para que el usuario requiera MFA. Complete los pasos descritos en Acceso condicional: requerir MFA.
Vaya al portal MyApps. Escriba el UPN y seleccione Siguiente.
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.
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.
Para ver los valores de OID de directiva, seleccione Detalles.
Seleccione el certificado de cliente y seleccione Aceptar.
El OID de política en el 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 OID de la política 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 la política de vinculación del nombre de usuario
La directiva de enlace de nombre de usuario ayuda a validar el certificado del usuario. Se admiten tres vinculaciones para la política de vinculación de nombre de usuario.
IssuerAndSerialNumber>certificateUserIdsIssuerAndSubject>certificateUserIdsSubject>certificateUserIds
De forma predeterminada, Microsoft Entra ID asigna Nombre Principal en el certificado a userPrincipalName en el 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 prepararlos, deben asegurarse de que los valores correctos para las asignaciones de nombre de usuario correspondientes se actualicen en el atributo certificateUserIds del objeto de usuario.
- Para los usuarios solo en la nube, use las API de Microsoft Entra admin center o 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 Microsoft Entra Connect Rules o sincronizando el valor de
AltSecId.
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 .
Mapeo manual del emisor y del número de serie
El siguiente ejemplo demuestra el mapeo manual del emisor y del 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 del 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
Mapeo del manual del emisor y del tema
El siguiente ejemplo demuestra el mapeo manual del emisor y del sujeto.
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
El siguiente ejemplo demuestra el mapeo manual de materias.
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
Inicie sesión en el Microsoft Entra admin center con una cuenta asignada al menos al rol Administrador de directivas de autenticación.
Vaya a Entra ID>Métodos de autenticación>Políticas.
En Administrar, seleccione Métodos> deautenticación Autenticación basada en certificados.
Seleccione Configurar.
Establezca Enlace de afinidad requerido en el nivel de inquilino.
Importante
Tenga cuidado con la configuración de afinidad para todo el inquilino. Podrías bloquear todo el tenant si cambias el valor de Vinculación de Afinidad Requerida para el tenant y no tienes los valores correctos en el objeto de usuario. De manera similar, si creas una regla personalizada que se aplique a todos los usuarios y requiera una vinculación de alta afinidad, los usuarios del tenant podrían quedar bloqueados.
Para probarlo, en Enlace de afinidad obligatorio, seleccione Bajo.
Añade una asignación de alta afinidad, como el identificador de clave de sujeto (SKI). En Enlace de nombre de usuario, seleccione Agregar regla.
Seleccione SKI y seleccione Agregar.
Cuando haya finalizado, la regla tendrá un aspecto similar al de este ejemplo:
Para todos los objetos de usuario, actualice el
certificateUserIdsatributo con el valor SKI correcto del certificado de usuario.Para obtener más información, consulte Patrones admitidos para CertificateUserIDs.
Cree una regla personalizada para la vinculación de autenticación.
Selecciona Agregar.
Compruebe que la regla completada tiene un aspecto similar al de este ejemplo:
Actualiza el valor de usuario
certificateUserIdscon el valor SKI correcto del OID de certificado y política de9.8.7.5.Prueba usando un certificado con el OID de política de
9.8.7.5. Compruebe que el usuario esté autenticado con la vinculación SKI y que se le solicite iniciar sesión con MFA y únicamente con el certificado.
Configurar CBA mediante las API de Microsoft Graph
Para establecer CBA y configurar asociaciones de nombre de usuario mediante las APIs de Microsoft Graph:
Vaya a Microsoft Graph Explorer.
Selecciona Iniciar sesión en Graph Explorer e iniciar sesión con tu inquilino.
Siga los pasos para dar su consentimiento al
Policy.ReadWrite.AuthenticationMethodpermiso delegado.Obtenga todos los métodos de autenticación:
GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicyObtenga la configuración del método de autenticación de certificados X.509:
GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509CertificateDe 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
PATCHsolicitud.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 } ] }Compruebe que se devuelve un
204 No contentcódigo de respuesta. Vuelva a ejecutar laGETsolicitud para asegurarse de que las directivas se actualizan correctamente.Pruebe la configuración iniciando sesión con un certificado que cumpla la directiva.
Configuración de CBA mediante Microsoft PowerShell
Abra PowerShell.
Conéctese a Microsoft Graph:
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"Cree una variable que se usará para definir un grupo para los usuarios de CBA:
$group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"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 5Ejecute la
PATCHsolicitud: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 de Microsoft Entra CBA
- Conceptos técnicos de Microsoft Entra CBA
- Limitaciones de uso de Microsoft Entra CBA
- Inicio de sesión con tarjeta inteligente en Windows mediante Microsoft Entra CBA
- Microsoft Entra CBA en dispositivos móviles (Android e iOS)
- Identificadores de usuario de certificado
- Migración de usuarios federados
- Preguntas más frecuentes