Migración del servidor MFA a la autenticación multifactor de Microsoft Entra

Artículo
10/14/2024

La autenticación multifactor es importante para proteger su infraestructura y sus activos frente a los actores malintencionados. El Servidor Multi-Factor Authentication (Servidor MFA) de Azure no está disponible para nuevas implementaciones y entrará en desuso. Los clientes que usan el servidor MFA deben pasar al uso de la autenticación multifactor basada en la nube de Microsoft Entra.

En este artículo, se da por supuesto que tiene un entorno híbrido en el que:

Usa el Servidor MFA para la autenticación multifactor.
Está usando la federación en Microsoft Entra ID con Servicios de federación de Active Directory (AD FS) u otro producto de federación de proveedores de identidad.
- Aunque este artículo está limitado a AD FS, se aplican pasos similares a otros proveedores de identidades.
La instancia de Servidor MFA está integrada con AD FS.
Es posible que tenga aplicaciones que usan AD FS para la autenticación.

Hay varios estados finales posibles para la migración, en función de su objetivo.

	Objetivo: retirar SOLO el Servidor MFA	Objetivo: retirar el servidor MFA y pasar a la autenticación de Microsoft Entra	Objetivo: retirar el servidor MFA y AD FS
Proveedor de MFA	Cambie el proveedor de MFA del servidor MFA a la autenticación multifactor de Microsoft Entra.	Cambie el proveedor de MFA del servidor MFA a la autenticación multifactor de Microsoft Entra.	Cambie el proveedor de MFA del servidor MFA a la autenticación multifactor de Microsoft Entra.
Autenticación de usuarios	Seguir usando la federación para la autenticación de Microsoft Entra.	Pasar a Microsoft Entra ID con sincronización de hash de contraseñas (preferido) o autenticación transferida e inicio de sesión único (SSO) sin interrupciones.	Cambiar a Microsoft Entra ID con sincronización de hash de contraseñas (preferido) o autenticación transferida y SSO.
Autenticación de la aplicación	Seguir usando la autenticación de AD FS en las aplicaciones.	Seguir usando la autenticación de AD FS en las aplicaciones.	Mover aplicaciones a Microsoft Entra ID antes de migrar a la autenticación multifactor de Microsoft Entra.

Si es posible, mueva tanto la autenticación multifactor como la autenticación de usuario a Azure. Para obtener una guía paso a paso, vea Migración a la autenticación multifactor de Microsoft Entra y Autenticación de usuarios de Microsoft Entra.

Si no puede mover su autenticación de usuario, vea la guía paso a paso para Migrar a la autenticación multifactor de Microsoft Entra con federación.

Requisitos previos

Entorno AD FS (obligatorio si no va a migrar todas las aplicaciones a Microsoft Entra antes de migrar el servidor MFA)
- Actualice a AD FS para Windows Server 2019, nivel de comportamiento de granja (FBL) 4. Esta actualización le permite seleccionar el proveedor de autenticación en función de la pertenencia a grupos para lograr una transición de usuarios más fluida. Aunque es posible realizar la migración mientras se está en AD FS para Windows Server 2016 FBL 3, no es tan fácil para los usuarios. Durante la migración, se pide a los usuarios que seleccionen un proveedor de autenticación (servidor MFA o autenticación multifactor Microsoft Entra) hasta que se complete la migración.
Permisos
- Rol de administrador de empresa en Active Directory para configurar la granja AD FS para la autenticación multifactor Microsoft Entra
- Se necesita un administrador global para administrar esta característica.

Consideraciones para todas las rutas de migración

La migración del servidor MFA a la autenticación multifactor de Microsoft Entra implica algo más que mover los números de teléfono registrados de MFA. El servidor MFA de Microsoft puede integrarse con muchos sistemas, y deberá evaluar cómo usan estos sistemas el servidor MFA para comprender las mejores formas de integrarlo con la autenticación multifactor de Microsoft Entra.

Migración de la información de usuario de MFA

A la hora de mover usuarios en lotes, normalmente el camino elegido es moverlos por regiones, departamentos o roles, por ejemplo, administradores. Debe mover las cuentas de usuario de forma iterativa, empezando por los grupos piloto y de prueba; asegúrese de que tiene un plan de reversión implementado.

Puede utilizar la Utilidad de migración del servidor MFA para sincronizar los datos MFA almacenados en el servidor Azure MFA local con la autenticación multifactor de Microsoft Entra y usar el Lanzamiento preconfigurado para redirigir a los usuarios a Azure MFA. El lanzamiento preconfigurado le ayuda a probar sin realizar cambios en la configuración de federación de dominio.

Para ayudar a los usuarios a diferenciar la cuenta recién agregada de la cuenta antigua vinculada al Servidor MFA, asegúrese de que el nombre de cuenta de la aplicación móvil en dicho servidor sea diferente para que se distingan las dos cuentas. Por ejemplo, el nombre de cuenta que aparece en Mobile App en Servidor MFA se ha cambiado a Servidor MFA local. El nombre de cuenta de Microsoft Authenticator cambiará con la siguiente notificación push al usuario.

La migración de números de teléfono también puede provocar la migración de números obsoletos y hacer que los usuarios se queden con la autenticación MFA basada en teléfono en lugar de configurar métodos más seguros, como Microsoft Authenticator en modo sin contraseña. Por lo tanto, se recomienda que, independientemente de la ruta de migración que elija, todos los usuarios se registren para obtener información de seguridad combinada.

Migración de las claves de seguridad de hardware

Microsoft Entra ID proporciona compatibilidad con tokens de hardware OATH. Puede utilizar la Utilidad de Migración del Servidor MFA para sincronizar la configuración MFA entre el Servidor MFA y la autenticación multifactor Microsoft Entra y usar el Lanzamiento preconfigurado para probar las migraciones de usuarios sin cambiar la configuración de federación de dominios.

Si solo quiere migrar tokens de hardware OATH, debe cargar los tokens en Microsoft Entra ID mediante un archivo CSV, denominado normalmente "archivo de provisión". El archivo de provisión contiene las claves secretas y los números de serie del token, así como otra información necesaria para cargar los tokens en Microsoft Entra ID.

Si ya no tiene el archivo de provisión con las claves secretas, no es posible exportar las claves secretas desde el Servidor MFA. Si ya no tiene acceso a las claves secretas, póngase en contacto con el proveedor de hardware para obtener ayuda.

Para exportar el número de serie de cualquiera de los tokens OATH asignados a un usuario dado se puede usar el SDK del servicio web del Servidor MFA. Puede utilizar esta información, junto con el archivo de provisión, para importar los tokens en Microsoft Entra ID y asignar el token OATH al usuario especificado en función del número de serie. También es necesario ponerse en contacto con el usuario en el momento de la importación para proporcionar información de OTP desde el dispositivo a fin de completar el registro. Consulte el tema del archivo de Ayuda GetUserInfo>userSettings>OathTokenSerialNumber del Servidor Multi-Factor Authentication que se encuentra en dicho servidor.

Más migraciones

La decisión de migrar del servidor MFA a la autenticación multifactor de Microsoft Entra abre la puerta a otras migraciones. La realización de migraciones adicionales depende de muchos factores, entre los que se incluyen específicamente:

Su disposición a utilizar la autenticación Microsoft Entra para los usuarios
Su disposición a mover las aplicaciones a Microsoft Entra ID

Dado que el Servidor MFA está profundamente integrado con las aplicaciones y la autenticación de usuario, puede considerar la posibilidad de mover ambas funciones a Azure como parte de la migración de MFA para, finalmente, retirar AD FS.

Nuestras recomendaciones:

Usar Microsoft Entra ID para la autenticación, ya que permite una seguridad y una gobernanza más sólidas
Mover aplicaciones a Microsoft Entra ID si es posible

Para seleccionar el mejor método de autenticación de usuarios para su organización, vea Elección del método de autenticación adecuado para su solución de identidad híbrida de Microsoft Entra. Se recomienda utilizar la sincronización de hash de contraseña (PHS).

Autenticación sin contraseñas

Como parte de la inscripción de usuarios para que usen Microsoft Authenticator como segundo factor, se recomienda habilitar el inicio de sesión telefónico sin contraseña como parte de su registro. Para más información, incluidos otros métodos sin contraseña, como claves de seguridad FIDO2 y Windows Hello para empresas, visite Planeamiento de una implementación de autenticación sin contraseña con Microsoft Entra ID.

Autoservicio de restablecimiento de contraseña de Microsoft Identity Manager

SSPR de Microsoft Identity Manager (MIM) puede utilizar el Servidor MFA para invocar códigos de acceso de un solo uso por SMS como parte del flujo de restablecimiento de contraseña. MIM no se puede configurar para utilizar la autenticación multifactor de Microsoft Entra. Se recomienda evaluar el traslado del servicio SSPR a Microsoft Entra SSPR. Puede aprovechar la oportunidad de que los usuarios se registren para la autenticación multifactor de Microsoft Entra para utilizar la experiencia de registro combinado para registrarse en Microsoft Entra SSPR.

Si no puede mover el servicio SSPR o sacar provecho del servidor MFA para invocar solicitudes de MFA para escenarios de Privileged Access Management (PAM), se recomienda actualizar a una opción MFA alternativa de terceros.

Clientes RADIUS y autenticación multifactor de Microsoft Entra

El Servidor MFA admite RADIUS para invocar la autenticación multifactor en aplicaciones y dispositivos de red que admitan el protocolo. Si usa RADIUS con el servidor MFA, se recomienda mover las aplicaciones cliente a protocolos modernos, como SAML, OpenID Connect u OAuth en Microsoft Entra ID. Si no se puede actualizar la aplicación, se puede implementar el Servidor de directivas de red (NPS) con la extensión de autenticación multifactor de Microsoft Entra. La extensión del servidor de directivas de red (NPS) actúa como adaptador entre las aplicaciones basadas en RADIUS y la autenticación multifactor de Microsoft Entra para proporcionar un segundo factor de autenticación. Este "adaptador" le permite mover los clientes RADIUS a la autenticación multifactor de Microsoft Entra y retirar el servidor MFA.

Consideraciones importantes

Existen limitaciones al usar NPS con clientes RADIUS y se recomienda evaluar los clientes RADIUS para determinar si puede actualizarlos a protocolos de autenticación modernos. Consulte con el proveedor de servicios las versiones de producto admitidas y sus funcionalidades.

La extensión de NPS no usa las directivas de acceso condicional de Microsoft Entra. Si continúa con RADIUS y usa la extensión NPS, todas las solicitudes de autenticación que van a NPS requerirán que el usuario realice la autenticación MFA.
Los usuarios deben registrarse para la autenticación multifactor de Microsoft Entra antes de usar la extensión NPS. De lo contrario, la extensión no podrá autenticar al usuario, lo que puede generar llamadas al departamento de soporte técnico.
Cuando la extensión NPS invoca MFA, la solicitud MFA se envía al método MFA predeterminado del usuario.
- Dado que el inicio de sesión se produce en aplicaciones que no son de Microsoft, no es probable que el usuario vea una notificación de que se requiere la autenticación multifactor y que se ha enviado una solicitud a su dispositivo.
- Durante el requisito de la autenticación multifactor, el usuario debe tener acceso a su método de autenticación predeterminado para completar el requisito. No pueden elegir un método alternativo. Se utilizará su método de autenticación predeterminado incluso si se ha deshabilitado en los métodos de autenticación del inquilino y las directivas de autenticación multifactor.
- Los usuarios pueden cambiar su método de autenticación multifactor predeterminado en la página de información de seguridad (aka.ms/mysecurityinfo).
Los métodos MFA disponibles para los clientes RADIUS se controlan mediante los sistemas cliente que envían las solicitudes de acceso RADIUS.
- Los métodos MFA que requieren la entrada de usuario después de escribir una contraseña solo se pueden usar con sistemas que admiten respuestas de desafío de acceso con RADIUS. Los métodos de entrada pueden incluir OTP, tokens OATH de hardware o Microsoft Authenticator.
- Algunos sistemas pueden limitar los métodos de autenticación multifactor disponibles a las notificaciones de inserción y las llamadas telefónicas de Microsoft Authenticator.

Nota

El algoritmo de cifrado de contraseña usado entre el cliente RADIUS y el sistema NPS y los métodos de entrada que el cliente puede utilizar afectan a los métodos de autenticación que están disponibles. Para más información, consulte Determinación de los métodos de autenticación que pueden utilizar los usuarios.

Las integraciones comunes del cliente RADIUS incluyen aplicaciones como puertas de enlace de Escritorio remoto y servidores VPN. Otras pueden incluir:

Puerta de enlace de Citrix
- La puerta de enlace de Citrix admite la integración tanto de RADIUS como de la extensión NPS, así como una integración de SAML.
Cisco VPN
- Cisco VPN admite la autenticación tanto de RADIUS como de SAML para SSO.
- Al pasar de la autenticación de RADIUS a SAML, puede integrar Cisco VPN sin tener que implementar la extensión NPS.
Todas las VPN
- Si es posible, se recomienda federar la VPN como una aplicación SAML. Esta federación le permitirá utilizar el acceso condicional. Para obtener más información, vea una lista de proveedores de VPN que están integrados en la galería de aplicaciones de Microsoft Entra ID.

Compartir vía