Análisis técnico de la autenticación basada en certificados de Microsoft Entra

  • Artículo

En este artículo se explica cómo funciona la autenticación basada en certificados (CBA) de Microsoft Entra y profundiza en los detalles técnicos sobre las configuraciones de CBA de Microsoft Entra.

Cómo funciona la autenticación basada en certificados de Microsoft Entra

En la imagen siguiente se describe lo que sucede cuando un usuario intenta iniciar sesión en una aplicación en un inquilino donde está habilitada la CBA de Microsoft Entra.

Ilustración con pasos sobre cómo funciona la autenticación basada en certificados de Microsoft Entra.

Ahora lo guiaremos por cada paso:

  1. El usuario intenta acceder a una aplicación, como el portal Aplicaciones.

  2. Si el usuario todavía no ha iniciado sesión, se le redirige a la página Inicio de sesión de usuario de Microsoft Entra ID en https://login.microsoftonline.com/.

  3. El usuario escribe su nombre de usuario en la página de inicio de sesión de Microsoft Entra y, a continuación, selecciona Siguiente. Microsoft Entra ID realiza la detección de dominios de inicio mediante el nombre del inquilino y el nombre de usuario se usa para buscar al usuario en el inquilino.

    Captura de pantalla del portal de inicio de sesión de MyApps.

  4. Microsoft Entra ID comprueba si la CBA está habilitada en el inquilino. Si la CBA está habilitada, el usuario ve un enlace a Usar un certificado o una tarjeta inteligente en la página de la contraseña. Si el usuario no ve el enlace de inicio de sesión, asegúrese de que la CBA está habilitada en el inquilino. Para obtener más información, consulte ¿Cómo puedo habilitar la CBA de Microsoft Entra?.

    Nota:

    Si el CBA está habilitado en el inquilino, todos los usuarios verán el enlace a Usar un certificado o una tarjeta inteligente en la página de la contraseña. Sin embargo, solo los usuarios del ámbito del CBA pueden autenticarse correctamente en una aplicación que usa Microsoft Entra ID como proveedor de identidades.

    Captura de pantalla de la sección Usar un certificado o una tarjeta inteligente.

    Si ha habilitado otros métodos de autenticación como inicio de sesión en el teléfono o claves de seguridad, es posible que los usuarios vean una pantalla de inicio de sesión diferente.

    Captura de pantalla del inicio de sesión si FIDO2 también está habilitado.

  5. Una vez que el usuario selecciona la autenticación basada en certificados, el cliente se redirige al punto de conexión de certauth, que es https://certauth.login.microsoftonline.com para el Entra ID público. Para Azure Government, el punto de conexión de autorización con certificado es https://certauth.login.microsoftonline.us.

    El punto de conexión realiza la autenticación mutua TLS, y solicita el certificado del cliente como parte del protocolo de enlace TLS. Aparece una entrada para esta solicitud en el registro de inicios de sesión.

    Nota:

    El administrador de red debe permitir el acceso a la página de inicio de sesión de usuario y al punto de conexión *.certauth.login.microsoftonline.com para el entorno en la nube del cliente. Deshabilite la inspección de TLS en el punto de conexión de autorización con certificado para asegurarse de que la solicitud de certificado de cliente se realice correctamente como parte del protocolo de enlace de TLS.

    Asegúrese de que la deshabilitación de inspección de TLS también funciona para la nueva dirección URL con sugerencias del emisor. No codifique la dirección URL con tenantId porque podría cambiar para los usuarios B2B. Use una expresión regular para permitir que la dirección URL antigua y nueva funcione para la deshabilitación de la inspección de TLS. Por ejemplo, en función del proxy, use *.certauth.login.microsoftonline.com o *certauth.login.microsoftonline.com. En Azure Government, use *.certauth.login.microsoftonline.us o *certauth.login.microsoftonline.us.

    A menos que se permita el acceso, se produce un error en la autenticación basada en certificados si habilita la próxima característica sugerencias de CA de confianza.

  6. Microsoft Entra ID solicita un certificado de cliente. El usuario elige el certificado de cliente y selecciona Aceptar.

    Nota:

    No se admiten sugerencias de CA de confianza, por lo que la lista de certificados no se puede limitar aún más. En el futuro, tenemos previsto agregar esta función.

    Captura de pantalla del selector de certificados.

  7. Microsoft Entra ID comprueba la lista de revocación de certificados para asegurarse de que el certificado no está revocado y es válido. Microsoft Entra ID identifica al usuario mediante el enlace del nombre de usuario configurado en el inquilino para asignar el valor del campo del certificado al valor del atributo del usuario.

  8. Si se encuentra un usuario único con una política de acceso condicional que requiere autenticación multifactor, y la regla de enlace de autenticación de certificados satisface la MFA, Microsoft Entra ID firma el usuario inmediatamente. Si se requiere MFA, pero el certificado solo satisface un solo factor, el inicio de sesión sin contraseña o FIDO2 se ofrece como segundo factor si ya están registrados.

  9. Microsoft Entra ID completa el proceso de inicio de sesión mediante el envío de un token de actualización principal para indicar que el inicio de sesión se ha realizado correctamente.

  10. Si el inicio de sesión del usuario se realiza correctamente, el usuario puede acceder a la aplicación.

La autenticación basada en certificados es compatible con MFA

La autenticación basada en certificados de Microsoft Entra es compatible con el método de autenticación multifactor (MFA). El CBA de Microsoft Entra puede ser de factor único (SF) o multifactor (MF) dependiendo de la configuración del inquilino. La habilitación del CBA hace que un usuario pueda completar la MFA. Es posible que un usuario necesite más configuración para completar MFA y realizar una prueba para registrar otros métodos de autenticación cuando el usuario está en el ámbito de CBA.

Si el usuario habilitado para CBA solo tiene un certificado de factor único (SF) y necesita completar la MFA:

  1. Use una contraseña y un certificado SF.
  2. Emita un Pase de acceso temporal.
  3. El administrador de directivas de autenticación agrega un número de teléfono y permite la autenticación de mensajes de voz y texto para la cuenta de usuario.

Si el usuario habilitado para CBA aún no ha emitido un certificado y debe completar la MFA:

  1. Emita un Pase de acceso temporal.
  2. El administrador de directivas de autenticación agrega un número de teléfono y permite la autenticación de mensajes de voz y texto para la cuenta de usuario.

Si el usuario habilitado para CBA no puede usar un certificado MF, como en un dispositivo móvil sin compatibilidad con tarjetas inteligentes, y necesita completar la MFA:

  1. Emita un Pase de acceso temporal.
  2. El usuario debe registrar otro método MFA (cuando el usuario puede usar el certificado MF).
  3. Use la contraseña y el certificado MF (cuando el usuario puede usar el certificado MF).
  4. El administrador de directivas de autenticación agrega un número de teléfono y permite la autenticación de mensajes de voz y texto para la cuenta de usuario.

MFA con autenticación basada en certificados de un solo factor (vista previa)

La CBA de Microsoft Entra puede usarse como segundo factor para cumplir con los requisitos de MFA con certificados de un solo factor. Algunas de las combinaciones admitidas son:

  1. CBA (primer factor) y inicio de sesión telefónico sin contraseña (inicio de sesión sin contraseña como segundo factor)
  2. CBA (primer factor) y claves de seguridad FIDO2 (segundo factor)
  3. Contraseña (primer factor) y CBA (segundo factor)

Los usuarios deben tener otra forma de obtener la MFA y registrar el inicio de sesión sin contraseña o FIDO2 con antelación para iniciar sesión con la CBA de Microsoft Entra.

Importante

Un usuario se considera capaz de MFA cuando se incluyen en la configuración del método de CBA. Esto significa que un usuario no puede usar la prueba como parte de su autenticación para registrar otros métodos disponibles. Asegúrese de que los usuarios sin un certificado válido no se incluyen en la configuración del método de CBA. Para obtener más información sobre cómo funciona la autenticación, consulte autenticación multifactor de Microsoft Entra.

Pasos para configurar el inicio de sesión telefónico sin contraseña (PSI) con CBA

Para que el inicio de sesión sin contraseña funcione, los usuarios deben deshabilitar la notificación heredada a través de su aplicación móvil.

  1. Inicie sesión en el Centro de administración de Microsoft Entra como Administrador de directivas de autenticación como mínimo.

  2. Siga los pasos que se indican en Habilitar métodos de autenticación de inicio de sesión en el teléfono sin contraseña.

    Importante

    En la configuración anterior, asegúrese de que eligió la opción de sin contraseña. Debe cambiar el modo de autenticación para los grupos agregados para PSI a sin contraseña. Si elige Cualquiera, CBA y PSI no funcionan.

  3. Seleccione Seguridad>Autenticación multifactor>Configuración adicional de la autenticación multifactor basada en la nube.

    Captura de pantalla de cómo configurar las opciones de la autenticación multifactor.

  4. En opciones de comprobación, desactive notificación a través de aplicación móvil y seleccione Guardar.

    Captura de pantalla de cómo quitar la notificación mediante la aplicación móvil.

Flujo de autenticación MFA mediante certificados de un solo factor e inicio de sesión sin contraseña

Echemos un vistazo a un ejemplo de un usuario que tiene un certificado de factor único y está configurado para el inicio de sesión sin contraseña.

  1. Escriba el nombre principal de usuario (UPN) y seleccione Siguiente.

    Captura de pantalla de cómo escribir un nombre principal de usuario.

  2. Seleccione Iniciar sesión con un certificado.

    Captura de pantalla de cómo iniciar sesión con un certificado.

    Si ha habilitado otros métodos de autenticación como inicio de sesión telefónico o claves de seguridad FIDO2, es posible que los usuarios vean otra pantalla de inicio de sesión.

    Captura de pantalla de una manera alternativa de iniciar sesión con un certificado.

  3. Elija el certificado de usuario correcto en el selector de certificados de cliente y seleccione Aceptar.

    Captura de pantalla de cómo seleccionar un certificado.

  4. Dado que el certificado está configurado para ofrecer la protección de la autenticación de un solo factor, el usuario necesita un segundo factor para cumplir los requisitos de la autenticación multifactor. El usuario ve los segundos factores disponibles, que en este caso es el inicio de sesión sin contraseña. Seleccione Aprobar una solicitud en la aplicación Microsoft Authenticator.

    Captura de pantalla de la solicitud del segundo factor.

  5. Recibirá una notificación en el teléfono. Seleccione ¿Desea aprobar el inicio de sesión?. Captura de pantalla de la solicitud de aprobación.

  6. Escriba el número que ve en el explorador o la pantalla de la aplicación en Microsoft Authenticator.

    Captura de pantalla de la coincidencia de números.

  7. Seleccione Sí y el usuario puede autenticarse e iniciar sesión.

Descripción de la directiva de enlace de autenticación

La directiva de enlace de autenticación ayuda a determinar la seguridad de la autenticación como factor único o multifactor. Un administrador puede cambiar el valor predeterminado de un solo factor a multifactor o configurar configuraciones de directiva personalizadas mediante el uso de campos OID de emisor o OID de directiva o emisor y OID de directiva en el certificado.

Puntos fuertes del certificado

Un administrador puede determinar si los certificados son de un solo factor o de resistencia multifactor. Para obtener más información, consulte la documentación que asigna los niveles de garantía de autenticación de NIST a los métodos de autenticación de Microsoft Entra, que se basan en NIST 800-63B SP 800-63B, directrices de identidad digital: autenticación y administración de ciclo de vida.

Autenticación de certificados multifactor

Cuando un usuario tiene un certificado multifactor, solo puede realizar la autenticación multifactor con certificados. Sin embargo, un administrador de directivas de autenticación debe asegurarse de que los certificados están protegidos con un PIN o biométrico para que se consideren multifactor.

Cómo resuelve Microsoft Entra ID varias reglas de enlace de directivas de autenticación

Dado que se pueden crear varias reglas de directiva de enlace de autenticación personalizadas con distintos campos de certificado, como el uso del emisor y el OID de directiva, o simplemente con el emisor. A continuación, se muestran los pasos que se usan para determinar el nivel de protección de autenticación cuando las reglas personalizadas se superponen. Los pasos son los siguientes:

  1. Las reglas OID de issuer+ policy tienen prioridad sobre las reglas OID de directiva. Las reglas del OID de directiva tienen prioridad sobre las reglas del emisor del certificado.
  2. Las reglas de OID de emisor y directiva se evalúan primero. Si tiene una regla personalizada con el emisor CA1 y la directiva OID 1.2.3.4.5 con MFA, solo el certificado A que satisfaga tanto el valor del emisor como el OID de la directiva recibirá MFA.
  3. A continuación, se evalúan las reglas personalizadas que usan los OID de directiva. Si tiene un certificado A con el OID de directiva 1.2.3.4.5 y una credencial derivada B basada en ese certificado tiene el OID de directiva 1.2.3.4.5.6 y la regla personalizada se define como OID de directiva con el valor 1.2.3.4.5 con MFA, solo el certificado A cumple con MFA y la credencial B solo cumple la autenticación de un solo factor. Si el usuario utilizó credenciales derivadas durante el inicio de sesión y estaba configurado para tener la MFA, se le pide un segundo factor para una autenticación correcta.
  4. Si hay un conflicto entre varios OD de directiva (por ejemplo, cuando un certificado tiene dos OD de directiva, donde uno se enlaza a la autenticación de un solo factor y el otro se enlaza a MFA), trate el certificado como una autenticación de un solo factor.
  5. A continuación, se evalúan las reglas personalizadas que usa la entidad emisora de certificados del emisor.
  6. Si en un certificado coinciden tanto el OID de directiva como las reglas del emisor, el OID de directiva siempre se comprueba primero y, si no se encuentra ninguna regla de directiva, se comprueban los enlaces del emisor. El OID de directiva tiene una prioridad de enlace de autenticación segura más alta que el emisor.
  7. Si una entidad de certificación se enlaza a MFA, todos los certificados de usuario que emita la entidad de certificación se califican como MFA. La misma lógica se aplica a la autenticación de un solo factor.
  8. Si un OID de directiva se enlaza a MFA, todos los certificados de usuario que incluyan este OID de directiva como uno de los OID (un certificado de usuario podría tener varios OID de directiva) se calificarán como MFA.
  9. Un emisor de certificado solo puede tener un enlace de autenticación segura válido (es decir, un certificado no se puede enlazar a factor único y MFA).

Importante

Hay un problema conocido por el que un administrador de inquilinos de Entra configura una regla de directivas de autenticación de CBA mediante emisores y OID de directivas que afecta a algunos escenarios de registro de dispositivos, entre los que se incluyen:

  • Inscripción de Windows Hello para empresas
  • Registro de clave de seguridad de Fido2
  • Inicio de sesión telefónico sin contraseña de Windows

El registro de dispositivos en los escenarios Workplace Join, Entra ID y Hybrid Entra ID no se ve afectado. Las reglas de directivas de autenticación CBA que utilicen OID de emisor o de política no se verán afectadas. Para mitigarlo, los administradores deben:

  • Editar las reglas de directivas de autenticación basada en certificados que usan actualmente las opciones de emisor y OID de directiva, y quitar el requisito de emisor u OID y guardar. O BIEN
  • Quitar la regla de directivas de autenticación que actualmente usa el emisor y el OID de directiva y crear reglas que utilicen únicamente el OID de emisor o de directiva

Estamos trabajando para solucionar el problema.

Descripción de la directiva de enlace de nombre de usuario

La directiva de enlace de nombre de usuario ayuda a validar el certificado del usuario. De manera predeterminada, el nombre principal del nombre alternativo del firmante (SAN) del certificado se asigna al atributo UserPrincipalName del objeto de usuario para determinar el usuario.

Lograr una mayor seguridad con enlaces de certificados

Hay siete métodos admitidos para los enlaces de certificado. En general, los tipos de asignación se consideran de alta afinidad si se basan en identificadores que no se pueden reutilizar (como identificadores de clave del firmante o clave pública SHA1). Estos identificadores transmiten una mayor garantía de que solo se puede usar un único certificado para autenticar al usuario respectivo.

Por lo tanto, todos los tipos de asignación basados en nombres de usuario y direcciones de correo electrónico se consideran de baja afinidad. Microsoft Entra ID implementa tres asignaciones consideradas de baja afinidad en función de identificadores reutilizables. Los demás se consideran enlaces de alta afinidad. Para obtener más información, consulte: certificateUserIds.

Campo de asignación de certificados Ejemplos de valores en certificateUserIds Atributos de objeto de usuario Tipo
Nombre principal X509:<PN>bob@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 afinidad baja
RFC822Name X509:<RFC822>user@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 afinidad baja
IssuerAndSubject (versión preliminar) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds afinidad baja
Firmante (versión preliminar) X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds afinidad baja
SKI X509:<SKI>123456789abcdef certificateUserIds afinidad alta
SHA1PublicKey X509:<SHA1-PUKEY>123456789abcdef certificateUserIds afinidad alta
IssuerAndSerialNumber (versión preliminar) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
Para obtener el valor correcto para el número de serie, ejecute este comando y almacene el valor que se muestra en CertificateUserIds:
Sintaxis:
Certutil –dump –v [~certificate path~] >> [~dumpFile path~]
Ejemplo:
certutil -dump -v firstusercert.cer >> firstCertDump.txt		 certificateUserIds afinidad alta

Definición del enlace de afinidad en el nivel de inquilino e invalidación con reglas personalizadas (versión preliminar)

Con esta característica, un administrador de directivas de autenticación puede configurar si un usuario se puede autenticar mediante la asignación de enlaces de nombre de usuario de afinidad baja o de alta afinidad. Puede establecer enlace de afinidad obligatorio para el inquilino, que se aplica a todos los usuarios. También puede invalidar el valor predeterminado de todo el inquilino mediante la creación de reglas personalizadas basadas en emisor y OID de directiva, o OID de directiva o emisor.

Cómo resuelve Microsoft Entra ID varias reglas de enlace de directivas de nombre de usuario

Utilice el enlace de prioridad más alta (número más bajo).

  1. Busque el objeto de usuario mediante el nombre de usuario o el nombre principal de usuario.
  2. Obtenga la lista de todos los enlaces de nombre de usuario configurados por el administrador de inquilinos en la configuración del método de autenticación de CBA ordenada por el atributo "priority". En la actualidad, el concepto de prioridad no se expone en la experiencia del usuario del portal. Graph le devolverá el atributo priority para cada enlace y se usan en el proceso de evaluación.
  3. Si el inquilino tiene habilitado un enlace de afinidad alto o si el valor del certificado coinciden con una regla personalizada que requería un enlace de afinidad alto, quita todos los enlaces de afinidad bajos de la lista.
  4. Evalúe cada enlace de la lista hasta que se produzca una autenticación correcta.
  5. Si el campo de certificado X.509 del enlace configurado está en el certificado presentado, Microsoft Entra ID coincide el valor del campo certificado con el valor del atributo de objeto de usuario.
    1. Si se encuentra una coincidencia, la autenticación de usuario se realiza correctamente.
    2. Si no se encuentra una coincidencia, vaya al siguiente enlace de prioridad.
  6. Si el campo del certificado X.509 no está en el certificado presentado, pase al siguiente enlace de prioridad.
  7. Valide todos los enlaces de nombre de usuario configurados hasta que uno de ellos produzca una coincidencia y la autenticación del usuario se realice correctamente.
  8. Si no se encuentra una coincidencia en ninguno de los enlaces de nombre de usuario configurados, se produce un error en la autenticación del usuario.

Protección de la configuración de Microsoft Entra con varios enlaces de nombre de usuario

Cada uno de los atributos de objeto de usuario de Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) disponibles para enlazar certificados a cuentas de usuario de Microsoft Entra tiene una restricción única para asegurarse de que un certificado solo coincide con una sola cuenta de usuario de Microsoft Entra. Sin embargo, Microsoft Entra CBA admite varios métodos de enlace en la directiva de enlace de nombre de usuario que permite a un administrador acomodar un certificado a varias configuraciones de cuentas de usuario de Entra.

Importante

Si configura varios enlaces, la autenticación de CBA de Microsoft Entra solo es tan segura como el enlace de afinidad más bajo porque CBA valida cada enlace para autenticar al usuario. Para evitar un escenario en el que un único certificado coincide con varias cuentas de Microsoft Entra, un administrador de directivas de autenticación puede:

  • Configure un único método de enlace en la directiva de enlace de nombre de usuario.
  • Si un inquilino tiene varios métodos de enlace configurados y no quiere permitir que un certificado se asigne a varias cuentas, el administrador de directivas de autenticación debe asegurarse de que todos los métodos permitidos configurados en la asignación de directivas a la misma cuenta de Microsoft Entra. Todas las cuentas de usuario deben tener valores que coincidan con todos los enlaces.
  • Si un inquilino tiene varios métodos de enlace configurados, el administrador de directivas de autenticación debe asegurarse de que no tienen más de un enlace de afinidad baja.

Por ejemplo, supongamos que tiene dos enlaces de nombre de usuario en PrincipalName asignados a UPN y SubjectKeyIdentifier (SKI) a certificateUserIds. Si desea que un certificado solo se use para una sola cuenta, un administrador de directivas de autenticación debe asegurarse de que la cuenta tenga el UPN que está presente en el certificado e implementar la asignación ski en el atributo certificateUserId de la misma cuenta.

Compatibilidad con varios certificados con una cuenta de usuario Entra (M:1)

Hay escenarios en los que una organización emite varios certificados para una sola identidad. Normalmente, esto podría ser una credencial derivada para un dispositivo móvil o también puede ser para un dispositivo compatible con el titular de credenciales x509 o una tarjeta inteligente secundaria, como Yubikey.

Cuentas solo en la nube Para las cuentas solo en la nube, puede asignar varios certificados (hasta 5) para su uso rellenando el campo certificateUserIds (información de autorización en el Portal de usuarios) con valores únicos que identifican cada certificado. Si la organización usa enlaces de afinidad alta, por ejemplo, Issuer + SerialNumber, los valores de CertificateUserIds pueden tener un aspecto similar al siguiente:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

En este ejemplo, el primer valor representa X509Certificate1 y el segundo valor representa X509Certificate2. El usuario puede presentar cualquiera de los certificados en el inicio de sesión y siempre que el enlace de nombre de usuario de CBA esté establecido para que apunte al campo certificateUserIds para buscar el tipo de enlace determinado (es decir, Issuer+SerialNumber en este ejemplo), el usuario iniciará sesión correctamente.

Cuentas sincronizadas híbridas Para las cuentas sincronizadas, puede asignar varios certificados para usarlos rellenando el campo altSecurityIdentities en AD con los valores que identifican cada certificado. Si la organización usa enlaces de alta afinidad (es decir, autenticación segura), por ejemplo, Issuer + SerialNumber, esto podría ser similar al siguiente:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

En este ejemplo, el primer valor representa X509Certificate1 y el segundo valor representa X509Certificate2. Estos valores deben sincronizarse con el campo certificateUserIds de Azure AD.

Compatibilidad con un certificado con varias cuentas de usuario de Entra (1:M)

Hay escenarios en los que una organización necesita que el usuario use el mismo certificado para autenticarse en varias identidades. Normalmente, esto es para las cuentas administrativas. También puede ser para cuentas de desarrollador o cuentas de derechos temporales. En AD tradicional, el campo altSecurityIdentities se usa para rellenar los valores del certificado y se usa una sugerencia durante el inicio de sesión para dirigir AD a la cuenta deseada para comprobar el inicio de sesión. Con Microsoft Entra CBA esto es diferente y no hay ninguna sugerencia. En su lugar, la detección de dominios de inicio identifica la cuenta deseada para comprobar los valores del certificado. La otra diferencia clave es que Microsoft Entra CBA aplica unicidad en el campo certificateUserIds. Esto significa que dos cuentas no pueden rellenar los mismos valores de certificado.

Importante

No es una configuración muy segura usar la misma credencial para autenticarse en diferentes cuentas de Entra ID y se recomienda no permitir un certificado para varias cuentas de usuario de Entra.

Cuentas solo en la nube Para las cuentas solo en la nube, debe crear varios enlaces de nombre de usuario y tener que asignar valores únicos a cada cuenta de usuario que va a usar el certificado. Cada cuenta se autenticará en mediante un enlace de nombre de usuario diferente. Esto se aplica dentro del límite de un único directorio o inquilino (es decir, el administrador de inquilinos puede asignar el certificado para su uso en otro directorio o inquilino, siempre y cuando los valores sigan siendo únicos por cuenta también).

Rellene el campo certificateUserIds (información de autorización en el Portal de usuarios) con un valor único que identifique el certificado deseado. Si la organización usa enlaces de afinidad alta (es decir, autenticación segura), los enlaces dicen Issuer + SerialNumber y SKI, esto podría ser similar al siguiente:

Enlaces de nombre de usuario:

  • Emisor y número de serie:> CertificateUserIds
  • SKI -> CertificateUserIds

Valores certificateUserIds de la cuenta de usuario:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Ahora, cuando cualquiera de los usuarios presenta el mismo certificado al iniciar sesión, el usuario iniciará sesión correctamente porque su cuenta coincide con un valor único en ese certificado. Una cuenta se autenticará mediante Issuer+SerialNumber y la otra mediante el enlace SKI.

Nota:

El número de cuentas que se pueden usar de esta manera está limitada por el número de enlaces de nombre de usuario configurados en el inquilino. Si la organización usa solo enlaces de afinidad alta, el número de cuentas admitidas se limitará a 3. Si la organización también usa enlaces de afinidad baja, este número aumenta a 7 cuentas (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Cuentas sincronizadas híbridas Para las cuentas sincronizadas, el enfoque será diferente. Aunque el administrador de inquilinos puede asignar valores únicos a cada cuenta de usuario que va a usar el certificado, la práctica común de rellenar todos los valores en cada cuenta en Entra ID dificultaría esto. En su lugar, Azure AD Connect debe filtrar los valores deseados por cuenta a valores únicos rellenados en la cuenta en Entra ID. La regla de unicidad se aplica dentro del límite de un único directorio o inquilino (es decir, el administrador de inquilinos puede asignar el certificado para su uso en otro directorio o inquilino, siempre y cuando los valores sigan siendo únicos por cuenta). Además, la organización puede tener varios bosques de AD que contribuyen a los usuarios a un único inquilino de Entra ID. En este caso, Azure AD Connect aplicará el filtro a cada uno de estos bosques de AD con el mismo objetivo para rellenar solo un valor único deseado en la cuenta de nube.

Rellene el campo altSecurityIdentities en AD con los valores que identifican el certificado deseado e incluya el valor de certificado deseado para ese tipo de cuenta de usuario (por ejemplo, empleado, adminstrador, desarrollador, etc.). Seleccione un atributo clave en AD que indicará a la sincronización qué tipo de cuenta de usuario está evaluando el usuario (por ejemplo, msDS-cloudExtensionAttribute1). Rellene este atributo con el valor de tipo de usuario que desee, como empleado, administrador o desarrollador. Si se trata de la cuenta principal del usuario, el valor puede dejarse vacío o nulo.

Las cuentas podrían tener el siguiente aspecto:

Bosque 1 - Cuenta1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Bosque 1 - Cuenta2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Bosque 2: ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Estos valores deben sincronizarse con el campo certificateUserIds en Entra ID.

Pasos para sincronizar con certificateUserIds

  1. Configuración de la conexión de Azure AD para agregar el campo alternativeSecurityIds al metaverso
  2. Para cada bosque de AD, configure una nueva regla de entrada personalizada con una prioridad alta (número bajo por debajo de 100). Agregue una transformación expresión con el campo altSecurityIdentities como origen. La expresión de destino usará el atributo clave que ha seleccionado y rellenado, así como la asignación a los tipos de usuario que ha definido.
  3. Por ejemplo:
IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

En el ejemplo anterior, altSecurityIdentities y el atributo clave msDS-cloudExtensionAttribute1is se comprueban primero para ver si se rellenan. Si no es así, se comprueba altSecurityIdentities para ver si se rellena. Si está vacío, se establece en NULL. De lo contrario, la cuenta entra en el caso predeterminado y en este ejemplo se filtra solo la asignación Issuer+SerialNumber. Si se rellena el atributo clave, se comprueba el valor para ver si es igual a uno de nuestros tipos de usuario definidos. En este ejemplo, si ese valor es detallado, filtramos por el valor SHA1PublicKey de altSecurityIdentities. Si el valor es desarrollador, filtramos por el valor SubjectKeyIssuer de altSecurityIdentities. Puede haber varios valores de certificado de un tipo específico. Por ejemplo, varios valores principalName o varios valores SKI o SHA1-PUKEY. El filtro obtendrá todos los valores y se sincronizará con Entra ID, no solo el primero que encuentre.

  1. A continuación se muestra un segundo ejemplo que muestra cómo introducir un valor vacío si el atributo de control está vacío.
IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
)

Si el valor de altSecurityIdentities no coincide con ninguno de los valores de búsqueda del atributo de control, se pasa una propiedad AuthoritativeNull. Esto garantiza que las reglas anteriores o posteriores que rellenan alternativeSecurityId se omitan y el resultado quede vacío en Entra ID.

  1. Configure una nueva regla de salida personalizada con una prioridad baja (un número alto por encima de 160 – al final de la lista).
  2. Agregue una transformación directa con el campo alternativeSecurityIds como origen y el campo certificateUserIds como destino.
  3. Ejecute un ciclo de sincronización para completar el rellenado de los datos en Entra ID.

Asegúrese de que CBA de cada inquilino está configurado con los enlaces de nombre de usuario que apuntan al campo certificateUserIds para los tipos de campo que ha asignado desde el certificado. Ahora cualquiera de estos usuarios puede presentar el certificado al iniciar sesión y después de validar el valor único del certificado con el campo certificateUserIds, ese usuario iniciará sesión correctamente.

Descripción del proceso de revocación de certificados

El proceso de revocación de certificados permite al administrador revocar el uso de un certificado emitido previamente para su uso en una autenticación futura. La revocación del certificado no revocará los tokens ya emitidos del usuario. Siga los pasos para revocar manualmente los tokens, como se describe en Configuración de la revocación.

Microsoft Entra ID descarga y almacena en caché la lista de revocación de certificados (CRL) de los clientes de su entidad de certificación para comprobar si los certificados se han revocado durante la autenticación del usuario.

Un administrador puede configurar el punto de distribución de la CRL durante el proceso de configuración de los emisores de confianza en el inquilino de Microsoft Entra. Cada emisor de confianza debe tener una CRL a la que se pueda hacer referencia mediante una dirección URL accesible desde Internet.

Importante

El tamaño máximo de una CRL para Microsoft Entra ID para descargar correctamente en un inicio de sesión interactivo y la memoria caché es de 20 MB en el id. de Entra público y 45 MB en nubes de Azure US Government, y el tiempo necesario para descargar la CRL no debe superar los 10 segundos. Si Microsoft Entra ID no puede descargar la lista de revocación de certificados, se produce un error en las autenticaciones basadas en certificados que usen certificados emitidos por la entidad de certificación correspondiente. Como procedimiento recomendado para mantener los archivos CRL dentro de los límites de tamaño, mantenga la vigencia de los certificados dentro de los límites razonables y limpie los certificados expirados. Para más información, consulte ¿Hay un límite para el tamaño de la CRL?

Cuando un usuario realiza un inicio de sesión interactivo con un certificado y la CRL supera el límite interactivo de una nube, se produce un error con el siguiente error:

"La lista de revocación de certificados (CRL) descargada de {uri} ha superado el tamaño máximo permitido ({tamaño} bytes) para las CRL en Microsoft Entra ID. Inténtelo de nuevo en unos minutos. Si el problema persiste, póngase en contacto con los administradores de inquilinos".

Después del error, Microsoft Entra ID intenta descargar la CRL sujeta a los límites del lado del servicio (45 MB en el id. de Entra público y 150 MB en nubes de Azure US Government).

Importante

Si el administrador omite la configuración de la CRL, Microsoft Entra ID no realiza ninguna comprobación de CRL durante la autenticación basada en certificados del usuario. Esto puede ser útil para la solución de problemas inicial, pero no se debe tener en cuenta para su uso en producción.

Por ahora, no se admite el Protocolo de estado de certificado en línea (OCSP) por motivos de rendimiento y confiabilidad. En lugar de descargar la lista de revocación de certificados en cada conexión mediante el explorador cliente para OCSP, Microsoft Entra ID la descarga una vez en el primer inicio de sesión y la almacena en caché, lo que mejora el rendimiento y la confiabilidad de la comprobación de la lista de revocación de certificados. También indexamos la memoria caché para que la búsqueda sea mucho más rápida cada vez. Los clientes deben publicar las CRL para la revocación de certificados.

Los pasos siguientes son un flujo típico de la comprobación de CRL:

  1. Microsoft Entra ID intenta descargar la CRL en el primer evento de inicio de sesión de cualquier usuario con un certificado del emisor de confianza o la entidad de certificación correspondientes.
  2. Microsoft Entra ID almacena en caché y reutiliza la CRL para cualquier uso posterior. Respeta la siguiente fecha de actualización y, si está disponible, la siguiente fecha de publicación de CRL (usada por las CA de Windows Server) del documento de la CRL.
  3. Se produce un error en la autenticación basada en certificados de usuario si:

    • Se ha configurado una CRL para el emisor de confianza y Microsoft Entra ID no puede descargar la CRL debido a restricciones de disponibilidad, tamaño o latencia.

    • El certificado del usuario aparece como revocado en la CRL.

      Captura de pantalla del certificado de usuario revocado en la CRL.

    • Microsoft Entra ID intenta descargar una nueva CRL desde el punto de distribución si el documento de la CRL almacenado en caché ha expirado.

Nota:

Microsoft Entra ID comprueba la CRL de la CA emisora y de otras CA en la cadena de confianza de la PKI hasta la CA raíz. Tenemos un límite de hasta 10 CA del certificado de cliente de hoja para la validación de CRL en la cadena PKI. La limitación es asegurarse de que un actor incorrecto no reduzca el servicio cargando una cadena PKI con un gran número de CA con un tamaño CRL mayor. Si la cadena PKI del inquilino tiene más de 5 CA y en caso de que una CA se vea comprometida, el administrador debe eliminar el emisor de confianza comprometido de la configuración del inquilino de Microsoft Entra.

Importante

Debido a la naturaleza de los ciclos de publicación y almacenamiento en caché de las CRL, se recomienda en el caso de una revocación de certificados revocar también todas las sesiones del usuario afectado en Microsoft Entra ID.

A partir de ahora, no hay forma de forzar o volver a intentar manualmente la descarga de la CRL.

Configuración de la revocación

Para revocar un certificado de cliente, Microsoft Entra ID recupera la lista de revocación de certificados (CRL) de las direcciones URL cargadas como parte de la información de la entidad de certificación y la almacena en caché. La última marca de tiempo de publicación (propiedadEffective Date ) de la CRL se utiliza para garantizar que esta es aún es válida. De forma periódica, se hace referencia a la CRL para revocar el acceso a los certificados que forman parte de la lista.

Si se requiere realizar una revocación más instantánea (por ejemplo, si un usuario pierde un dispositivo), se puede invalidar el token de autorización del usuario. Para ello, establezca el valor del campo StsRefreshTokenValidFrom de este usuario concreto mediante Windows PowerShell. Tiene que actualizar el campo StsRefreshTokenValidFrom para cada usuario cuyo acceso desee revocar.

Para asegurarse de que la revocación persiste, debe establecer la fecha de vigencia de la CRL en una fecha posterior al valor que establece StsRefreshTokenValidFrom y asegurarse de que el certificado en cuestión se encuentra en la CRL.

Nota:

Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lea la actualización de desuso. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.

Se recomienda migrar a PowerShell de Microsoft Graph para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulte las Preguntas más frecuentes sobre migración. Nota: Las versiones 1.0.x de MSOnline podrían experimentar interrupciones después del 30 de junio de 2024.

En los siguientes pasos se describe el proceso de actualización e invalidación del token de autorización mediante el establecimiento del campo StsRefreshTokenValidFrom .

  1. Conexión a PowerShell:

    Connect-MgGraph

  2. Recupere el valor actual de StsRefreshTokensValidFrom de un usuario:

            $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
        $user.StsRefreshTokensValidFrom

  3. Configure que el campo StsRefreshTokensValidFrom del usuario tenga el mismo valor que la marca de tiempo actual.

            Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")

La fecha establecida debe ser futura. De lo contrario, no se establece la propiedad StsRefreshTokensValidFrom . Si la fecha es futura, el valor de StsRefreshTokensValidFrom se establece en la hora actual (no la fecha que indica el comando Set-MsolUser).

Funcionamiento de la autenticación basada en certificados con una directiva de acceso condicional de intensidad de autenticación

Los clientes pueden crear una directiva de acceso condicional de intensidad de autenticación para especificar que se debe usar la autenticación basada en certificados (CBA) para acceder a un recurso.

Puede usar la intensidad de autenticación integrada MFA resistente a suplantación de identidad. Esta directiva solo permite métodos de autenticación resistentes a la suplantación de identidad, tales como CBA, claves de seguridad FIDO2 y Windows Hello para empresas.

También puede crear una intensidad de autenticación personalizada para que solo se pueda acceder a recursos confidenciales mediante CBA. Puede permitir la CBA como factor único, multifactor o ambos. Para obtener más información, consulte Intensidad de autenticación de acceso condicional.

Intensidad de autenticación de CBA con opciones avanzadas

En la directiva de métodos de autenticación de CBA, un administrador puede determinar la intensidad del certificado mediante la directiva de enlace de autenticación en el método CBA. Ahora puede configurar opciones avanzadas al crear una intensidad de autenticación personalizada para requerir que se use un certificado específico, basado en los OID de emisor y directiva, cuando los usuarios realicen la CBA para acceder a determinados recursos confidenciales. Esta característica proporciona una configuración más precisa para determinar los certificados y usuarios que pueden acceder a los recursos. Para obtener más información, consulte Opciones avanzadas de intensidad de autenticación de acceso condicional.

Descripción de los registros de inicio de sesión

Los registros de inicio de sesión proporcionan información sobre los inicios de sesión y sobre la forma en la que los usuarios emplean los recursos. Para obtener más información sobre los registros de inicio de sesión, consulte Registros de inicio de sesión en Microsoft Entra ID.

Veamos dos escenarios, uno en el que el certificado cumple con la autenticación de un solo factor y otro en el que el certificado cumple con MFA.

Para los escenarios de prueba, elija un usuario con una directiva de acceso condicional que requiera MFA. Configure la directiva de enlace de usuario mediante la asignación del nombre principal de SAN a UserPrincipalName.

El certificado de usuario se debe configurar como en esta captura de pantalla:

Captura de pantalla del certificado de usuario.

Solución de problemas de inicio de sesión con variables dinámicas en los registros de inicio de sesión

Aunque los registros de inicio de sesión proporcionan toda la información para depurar los problemas de inicio de sesión de un usuario, hay ocasiones en las que se necesitan valores específicos y, como los registros de inicio de sesión no admiten variables dinámicas, falta información en dichos registros de inicio de sesión. Por ejemplo, el motivo del error en el registro de inicio de sesión sería algo parecido a "Error de validación de firmas en la lista de revocación de certificados (CRL). El identificador de clave del firmante esperado {expectedSKI} no coincide con la clave de autoridad de CRL {crlAK}. Solicite al administrador de inquilinos que compruebe la configuración de la CRL". En este caso, {expectedSKI} y {crlAKI} no se sustituirían por los valores correctos.

Cuando se produzca un error en el inicio de sesión de los usuarios con CBA, copie los detalles del registro del vínculo "Más detalles" de la página de error. Para obtener información más detallada, consulte la página de error de CBA.

Prueba de la autenticación de un solo factor

Para el primer escenario de prueba, configure una directiva de autenticación en la que la regla del firmante del emisor cumpla con la autenticación de un solo factor.

Captura de pantalla de la configuración de la política de autenticación que muestra la autenticación de factor único requerida.

  1. Inicie sesión en el Centro de administración de Microsoft Entrar como usuario de prueba mediante el ACB. La directiva de autenticación se establece donde la regla del sujeto del emisor satisface la autenticación de un solo factor.

  2. Busque y seleccione Registros de inicio de sesión.

    Echemos un vistazo más de cerca a algunas de las entradas que puede encontrar en los registros de inicio de sesión.

    La primera entrada solicita el certificado X.509 al usuario. El estado Interrumpido significa que Microsoft Entra ID ha validado que la CBA está habilitada en el inquilino y se solicita un certificado para la autenticación.

    Captura de pantalla de la entrada de autenticación de factor único en los registros de inicio de sesión.

    Los Detalles de la actividad muestran que esto es solo parte del flujo de inicio de sesión esperado en el que el usuario selecciona un certificado.

    Captura de pantalla de los detalles de la actividad en los registros de entrada.

    Los detalles adicionales muestran la información del certificado.

    Captura de pantalla de los detalles adicionales del multifactor en los registros de inicio de sesión.

    Estas entradas adicionales muestran que la autenticación se ha completado, se envía un token de actualización primario al navegador y se da al usuario acceso al recurso

    Captura de pantalla de la entrada del token de actualización en los registros de inicio de sesión.

Prueba de la autenticación multifactor

Para el siguiente escenario de prueba, configura la política de autenticación en la que la regla policyOID cumpla con la autenticación multifactor.

Captura de pantalla de la configuración de la política de autenticación que muestra la autenticación multifactor requerida.

  1. Iniciar sesión Centro de administración de Microsoft Entra utilizando el ACB. Puesto que la directiva se estableció para cumplir con la autenticación multifactor, el inicio de sesión de usuario se realiza correctamente sin un segundo factor.

  2. Busque y seleccione información de inicio de sesión.

    Verá varias entradas en los registros de inicio de sesión, incluida una entrada con estado Interrumpido.

    Captura de pantalla de varias entradas en los registros de entrada.

    Los Detalles de la actividad muestran que esto es solo parte del flujo de inicio de sesión esperado en el que el usuario selecciona un certificado.

    Captura de pantalla de los detalles de inicio de sesión del segundo factor en los registros de inicio de sesión.

    La entrada con estado Interrumpido proporciona más información de diagnóstico en la pestaña Detalles adicionales.

    Captura de pantalla de los detalles del intento interrumpido en los registros de entrada.

    En la tabla siguiente, se incluye una descripción de cada campo.

    Campo Descripción
    Nombre del firmante del certificado de usuario Hace referencia al campo de nombre del firmante en el certificado.
    Enlace de certificado de usuario Certificado: nombre principal; Atributo de usuario: userPrincipalName; Clasificación: 1
    Esto muestra qué campo de certificado SAN PrincipalName se asignó al atributo de usuario userPrincipalName y tenía prioridad 1.
    Nivel de autenticación del certificado de usuario multiFactorAuthentication
    Tipo de nivel de autenticación del certificado de usuario PolicyId
    Esto muestra que se usó el OID de directiva para determinar el nivel de autenticación.
    Identificador de nivel de autenticación del certificado de usuario 1.2.3.4
    Esto muestra el valor del OID de la directiva de identificador del certificado.

Reconocimiento de la página de error de autenticación basada en certificados

La autenticación basada en certificados puede producir un error por motivos como que el certificado no es válido o el usuario seleccionó el certificado incorrecto o un certificado expirado, o debido a un problema de lista de revocación de certificados (CRL). Cuando se produce un error en la validación del certificado, el usuario ve este error:

Captura de pantalla de un error de validación de certificado.

Si se produce un error en CBA en un explorador, incluso si el error se debe a que cancela el selector de certificados, debe cerrar la sesión del explorador y abrir una nueva sesión para volver a intentar CBA. Se requiere una nueva sesión porque los exploradores almacenan en caché el certificado. Cuando se reintenta CBA, el explorador envía el certificado almacenado en caché durante el desafío TLS, lo que provoca un error de inicio de sesión y el error de validación.

Seleccione Más detalles para obtener información de registro que se puede enviar a un administrador, que a su vez puede obtener más información de los registros de inicio de sesión.

Captura de pantalla de los detalles del error.

Seleccione Otras formas de iniciar sesión para probar otros métodos disponibles para que el usuario inicie sesión.

Nota:

Si vuelve a intentar CBA en un explorador, seguirá dando error debido al problema del almacenamiento en caché del navegador. Los usuarios deben abrir una nueva sesión del explorador e iniciar sesión de nuevo.

Captura de pantalla de un nuevo intento de inicio de sesión.

Autenticación basada en certificados en métodos MostRecentlyUsed (MRU)

Una vez que un usuario se autentica correctamente mediante CBA, el método de autenticación MostRecentlyUsed (MRU) del usuario se establece en CBA. La próxima vez, cuando el usuario escribe su UPN y selecciona Siguiente, el usuario se lleva directamente al método CBA y no necesita seleccionar Usar el certificado o la tarjeta inteligente.

Para restablecer el método MRU, el usuario debe cancelar el selector de certificados, seleccione Otras formas de iniciar sesióny seleccione otro método disponible para el usuario y autentíquese correctamente.

Compatibilidad con identidades externas

Una identidad externa no puede realizar la autenticación multifactor (MFA) en el inquilino de recursos con la CBA de Microsoft Entra. En su lugar, haga que el usuario realice MFA mediante CBA en el inquilino principal y configure la configuración entre inquilinos para que el inquilino de recursos confíe en MFA desde el inquilino principal.

Para obtener más información sobre cómo habilitar la Autenticación multifactor de confianza desde inquilinos de Microsoft Entra, consulte Configuración del acceso entre inquilinos para la colaboración B2B.

Pasos siguientes