Compartir vía


Migración de la federación a la autenticación basada en certificados de Microsoft Entra (CBA)

En este artículo se explica cómo migrar desde servidores federados en ejecución, como Servicios de federación de Active Directory (AD FS) (AD FS) local a la autenticación en la nube mediante la autenticación basada en certificados (CBA) de Microsoft Entra.

Lanzamiento preconfigurado

Un administrador de inquilinos podría cortar completamente el dominio federado a la CBA de Microsoft Entra sin pruebas piloto habilitando el método de autenticación de CBA en Microsoft Entra ID y convirtiendo todo el dominio en la autenticación administrada. Pero si el cliente quiere probar autenticar un pequeño lote de usuarios con la CBA de Microsoft Entra antes de la transición completa del dominio a administrado, pueden usar la característica de lanzamiento preconfigurado.

El lanzamiento preconfigurado para la autenticación basada en certificados (CBA) ayuda a los clientes a hacer la transición de realizar la CBA en un IdP federado a Microsoft Entra ID moviendo selectivamente un pequeño conjunto de usuarios para que usen la CBA en Microsoft Entra ID (sin redirigir al IdP federado) con grupos de usuarios seleccionados antes de convertir la configuración de dominio en Microsoft Entra ID de federada a administrada. La implementación preconfigurada no está diseñada para que el dominio permanezca federado durante largos periodos de tiempo o para grandes cantidades de usuarios.

Eche un vistazo a este vídeo breve sobre la migración desde la autenticación basada en certificados de ADFS a Microsoft Entra CBA

Nota:

Cuando se habilita el lanzamiento preconfigurado para un usuario, el usuario se considera un usuario administrado y toda la autenticación se realizará en Microsoft Entra ID. En el caso de un inquilino federado, si la autenticación basada en certificados está habilitada en el lanzamiento preconfigurado, la autenticación de contraseña solo funciona si PHS también está habilitado; de lo contrario, se producirá un error en la autenticación de contraseña.

Habilitación del lanzamiento preconfigurado para la autenticación basada en certificados en el inquilino

Sugerencia

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

Para configurar el lanzamiento preconfigurado, siga estos pasos:

  1. Inicie sesión en el Centro de administración de Microsoft Entra al menos como Administrador de usuarios.
  2. Busque y seleccione Microsoft Entra Connect.
  3. En la página Microsoft Entra Connect, en la sección lanzamiento preconfigurado de la autenticación en la nube, haga clic en Habilitar lanzamiento preconfigurado para el inicio de sesión de los usuarios administrados.
  4. En la página Habilitar característica de lanzamiento preconfigurado, haga clic en Activado para la opción Autenticación basada en certificados.
  5. Haga clic en Administrar grupos y agregue grupos que quiera formar parte de la autenticación en la nube. Para evitar tiempo de espera, asegúrese de que los grupos de seguridad no contengan más de 200 miembros inicialmente.

Para obtener más información, vea Lanzamiento preconfigurado.

Uso de Microsoft Entra Connect para actualizar el atributo certificateUserIds

Un administrador de AD FS puede usar el Editor de reglas de sincronización para crear reglas para sincronizar los valores de los atributos de AD FS con objetos de usuario de Microsoft Entra. Para obtener más información, vea Reglas de sincronización para certificateUserIds.

Microsoft Entra Connect requiere un rol especial denominado Administrador de identidades híbridas, que concede los permisos necesarios. Necesita este rol para poder escribir en el nuevo atributo de nube.

Nota:

Si un usuario utiliza atributos sincronizados, como el atributo onPremisesUserPrincipalName en el objeto de usuario para la vinculación del nombre de usuario, tenga en cuenta que cualquier usuario que tenga acceso administrativo al servidor de Microsoft Entra Connect puede cambiar la asignación de atributos sincronizados y cambiar el valor del atributo sincronizado. El usuario no necesita ser administrador de la nube. El administrador de AD FS debe asegurarse de que el acceso administrativo al servidor de Microsoft Entra Connect debe estar limitado y las cuentas con privilegios deben ser solo en la nube.

Preguntas frecuentes sobre la migración de AD FS a Microsoft Entra ID

¿Podemos tener cuentas con privilegios con un servidor de AD FS federado?

Aunque es posible, Microsoft recomienda que las cuentas con privilegios sean solo en la nube. Uso de cuentas solo en la nube para limitar la exposición de los límites de acceso con privilegios en Microsoft Entra ID desde un entorno local en peligro. Para más información, vea el artículo Protección de Microsoft 365 contra ataques locales.

Si una organización es un híbrido que ejecuta AD FS y Azure CBA, ¿siguen siendo vulnerables al riesgo de AD FS?

Microsoft recomienda que las cuentas con privilegios sean solo en la nube. Esta práctica limitará la exposición en Microsoft Entra ID desde un entorno local en peligro. El mantenimiento de cuentas con privilegios solo en la nube es fundamental para este objetivo.

Para cuentas sincronizadas:

  • Si están en un dominio administrado (no federado), no hay ningún riesgo del IdP federado.
  • Si están en un dominio federado, pero un subconjunto de cuentas se mueve a Microsoft Entra CBA mediante el lanzamiento preconfigurado, están sujetos a riesgos relacionados con el Idp federado hasta que el dominio federado se cambie completamente a la autenticación en la nube.

¿Las organizaciones deben eliminar servidores federados como AD FS para evitar la capacidad de dinamizar desde AD FS a Azure?

Con la federación, un atacante podría suplantar a cualquier usuario, como un CIO, incluso si no puede obtener un rol solo en la nube, como la cuenta de administrador global.

Cuando un dominio está federado en Microsoft Entra ID, se coloca un alto nivel de confianza en el IdP federado. AD FS es un ejemplo, pero la noción es verdadera para cualquier IdP federado. Muchas organizaciones implementan un IdP federado como AD FS exclusivamente para realizar la autenticación basada en certificados. Microsoft Entra CBA quita completamente la dependencia de AD FS en este caso. Con Microsoft Entra CBA, los clientes pueden mover su patrimonio de aplicaciones a Microsoft Entra ID para modernizar su infraestructura de IAM y reducir los costos con mayor seguridad.

Desde una perspectiva de seguridad, no hay ningún cambio en la credencial, incluido el certificado X.509, CAC, PIV, etc. o a la PKI que se usa. Los propietarios de PKI conservan el control completo del ciclo de vida y la directiva de emisión y revocación de certificados. La comprobación de revocación y la autenticación se producen en Microsoft Entra ID en lugar de en Idp federado. Estas comprobaciones habilitan la autenticación sin contraseña y resistente a suplantación de identidad directamente en Microsoft Entra ID para todos los usuarios.

¿Cómo funciona la autenticación con la autenticación federada de AD FS y la autenticación en la nube de Microsoft Entra con Windows?

Microsoft Entra CBA requiere que el usuario o la aplicación proporcionen el nombre principal de usuario (UPN) de Microsoft Entra del usuario que inicia sesión.

En el ejemplo del explorador, el usuario suele escribir en su UPN de Microsoft Entra. El UPN de Microsoft Entra se usa para la detección de usuarios y dominios. Después, el certificado usado debe coincidir con este usuario mediante uno de los enlaces de nombre de usuario configurados en la directiva.

En el inicio de sesión de Windows, la coincidencia depende de si el dispositivo es híbrido o está unido a Microsoft Entra. Pero en ambos casos, si se proporciona la sugerencia de nombre de usuario, Windows enviará la sugerencia como un UPN de Microsoft Entra. Después, el certificado usado debe coincidir con este usuario mediante uno de los enlaces de nombre de usuario configurados en la directiva.

Pasos siguientes