Migración de MFA Server
En este tema se explica cómo migrar la configuración de MFA para usuarios de Microsoft Entra desde un servidor Azure MFA local a la autenticación multifactor de Microsoft Entra.
Información general de la solución
La utilidad de migración del servidor MFA ayuda a sincronizar los datos de autenticación multifactor almacenados en el servidor de Azure MFA local directamente con la autenticación multifactor de Microsoft Entra. Después de migrar los datos de autenticación a Microsoft Entra ID, los usuarios pueden realizar MFA basado en la nube sin problemas sin tener que volver a registrarse ni confirmar métodos de autenticación. Los administradores pueden usar la utilidad de migración del servidor MFA para dirigirse a usuarios individuales o grupos de usuarios para probar y controlar el lanzamiento sin tener que realizar cambios en todo el inquilino.
Vídeo: cómo usar la utilidad de migración del servidor MFA
Eche un vistazo a nuestro vídeo para obtener información general sobre la utilidad de migración del servidor MFA y cómo funciona.
Limitaciones y requisitos
La Utilidad de migración del servidor MFA requiere una nueva compilación de la solución servidor MFA que se va a instalar en el servidor MFA principal. La compilación realiza actualizaciones en el archivo de datos del servidor MFA e incluye la nueva utilidad de migración del servidor MFA. No es necesario actualizar el Portal de usuarios o WebSDK. La instalación de la actualización no inicia la migración automáticamente.
Nota:
La utilidad de migración del servidor MFA se puede ejecutar en un servidor MFA secundario. Para más información, consulte Ejecutar un servidor MFA secundario (opcional).
La Utilidad de migración del servidor MFA copia los datos del archivo de base de datos en los objetos de usuario de Microsoft Entra ID. Durante la migración, los usuarios pueden dirigirse a la autenticación multifactor de Microsoft Entra con fines de prueba mediante el lanzamiento preconfigurado. La migración preconfigurada permite probar sin realizar ningún cambio en la configuración de federación de dominio. Una vez completadas las migraciones, debes finalizar la migración realizando cambios en la configuración de federación de dominio.
Se requiere AD FS que ejecute Windows Server 2016 o superior para proporcionar autenticación MFA en cualquier usuario de confianza de AD FS, no incluidos Microsoft Entra ID y Office 365.
Revisa las directivas de control de acceso de AD FS y asegúrate de que ninguna requiere que MFA se realice de forma local como parte del proceso de autenticación.
El lanzamiento preconfigurado puede tener como destino un máximo de 500 000 usuarios (10 grupos que contienen un máximo de 50 000 usuarios cada uno).
Guía de migración
Una migración del servidor MFA suele incluir los pasos descritos en el siguiente proceso:
Algunos puntos importantes:
La fase 1 debe repetirse al agregar usuarios de prueba.
- La herramienta de migración usa grupos de Microsoft Entra para determinar los usuarios para los que se deben sincronizar los datos de autenticación entre el servidor MFA y la autenticación multifactor de Microsoft Entra. Una vez que se hayan sincronizado los datos del usuario, ese usuario estará listo para usar la autenticación multifactor de Microsoft Entra.
- El lanzamiento preconfigurado permite volver a enrutar a los usuarios a la autenticación multifactor de Microsoft Entra, también mediante grupos de Microsoft Entra. Si bien es cierto que podría utilizar los mismos grupos para ambas herramientas, no lo recomendamos, ya que los usuarios podrían ser redirigidos a la autenticación multifactor de Microsoft Entra antes de que la herramienta haya sincronizado sus datos. Recomendamos configurar grupos de Microsoft Entra para sincronizar datos de autenticación mediante la utilidad de migración del servidor MFA y otro conjunto de grupos para el lanzamiento preconfigurado para dirigir a los usuarios específicos a la autenticación multifactor de Microsoft Entra en lugar de hacerlo localmente.
La fase 2 debe repetirse a medida que migre la base de usuarios. Al final de la fase 2, toda la base de usuarios debe usar la autenticación multifactor de Microsoft Entra para todas las cargas de trabajo federadas con Microsoft Entra ID.
Durante las fases anteriores, puede quitar usuarios de las carpetas de lanzamiento preconfigurado para sacarlos del ámbito de la autenticación multifactor de Microsoft Entra y enrutarlos de nuevo al servidor de Azure MFA local para todas las solicitudes de MFA que se originan en Microsoft Entra ID.
La fase 3 requiere mover todos los clientes que se autentican en el servidor MFA local (VPN, administradores de contraseñas, etc.) a la federación de Microsoft Entra a través de SAML/OAUTH. Si no se admiten los estándares de autenticación modernos, es necesario que se instalen servidores NPS con la extensión de la autenticación multifactor de Microsoft Entra instalada. Una vez migradas las dependencias, los usuarios ya no deben usar el Portal de usuarios en el servidor MFA, sino que deben administrar sus métodos de autenticación en Microsoft Entra ID (aka.ms/mfasetup). Una vez que los usuarios empiecen a administrar sus datos de autenticación en Microsoft Entra ID, esos métodos no se sincronizarán con el servidor MFA. Si reviertes al servidor MFA local después de que los usuarios hayan realizado cambios en sus métodos de autenticación en Microsoft Entra ID, estos cambios se perderán. Una vez completadas las migraciones de usuario, cambia la configuración de federación de dominio federatedIdpMfaBehavior. El cambio indica a Microsoft Entra ID que ya no realice MFA localmente y que realice todas las solicitudes de MFA con la autenticación multifactor de Microsoft Entra, independientemente de la pertenencia a grupos.
En las secciones siguientes se explican los pasos de migración con más detalle.
Identificación de las dependencias del Servidor Microsoft Azure Multi-Factor Authentication
Hemos trabajado duro para garantizar que la migración a nuestra solución de autenticación multifactor de Microsoft Entra basada en la nube mantendrá e incluso mejorará su posición de seguridad. Hay tres categorías generales que se deben usar para agrupar las dependencias:
Para ayudar a la migración, hemos usado ampliamente las características del servidor MFA con el equivalente funcional de la autenticación multifactor de Microsoft Entra para cada categoría.
Métodos de MFA
Abre el servidor MFA y haz clic en Configuración de la empresa:
| Servidor MFA | Autenticación multifactor de Microsoft Entra |
|---|---|
| Pestaña General | |
| Sección de parámetros predeterminados por el usuario | |
| Llamada telefónica (Estándar) | No se requiere ninguna acción |
| Mensaje de texto (OTP)* | No se requiere ninguna acción |
| Aplicación móvil (Estándar) | No se requiere ninguna acción |
| Llamada de teléfono (PIN)* | Habilitar OTP de Voz |
| Mensaje de texto (OTP + PIN)** | No se requiere ninguna acción |
| Aplicación móvil (PIN)* | Habilitar la coincidencia de números |
| Llamada telefónica/mensaje de texto/aplicación móvil/idioma del token OATH | La configuración de idioma se aplicará automáticamente a un usuario en función de la configuración regional en su explorador |
| Sección reglas de PIN predeterminadas | No aplicable; consulta los métodos actualizados en la captura de pantalla anterior |
| Pestaña Resolución de nombre de usuario | No aplicable; la resolución de nombres de usuario no es necesaria para la autenticación multifactor de Microsoft Entra |
| Pestaña Mensaje de texto | No aplicable; la autenticación multifactor de Microsoft Entra usa un mensaje predeterminado para los mensajes de texto |
| Texto de token OATH | No aplicable; la autenticación multifactor de Microsoft Entra usa un mensaje predeterminado para los tokens de OATH |
| Informes | Informes de actividad de métodos de autenticación de Microsoft Entra |
*Cuando se usa un PIN para proporcionar funcionalidad de prueba de presencia, el equivalente funcional se proporciona anteriormente. Los PIN que no están vinculados criptográficamente a un dispositivo no protegen lo suficientemente frente a escenarios en los que un dispositivo se ha puesto en peligro. Para protegerse frente a estos escenarios, incluidos los ataques de intercambio de SIM, mueve a los usuarios a métodos más seguros según los procedimientos recomendados de métodos de autenticación de Microsoft.
**La experiencia predeterminada de MFA de Texto en la autenticación multifactor de Microsoft Entra envía a los usuarios un código, que es necesario para entrar en la ventana de inicio de sesión como parte de la autenticación. El requisito de ida y vuelta del código proporciona funcionalidad de prueba de presencia.
Portal de usuarios
Abre el servidor MFA y haz clic en Portal de usuarios:
| Servidor MFA | Autenticación multifactor de Microsoft Entra |
|---|---|
| Pestaña Configuración | |
| URL del Portal de usuarios | aka.ms/mfasetup |
| Permitir inscripción de usuario | Consulta Registro de información de seguridad combinado |
| - Solicitar teléfono de respaldo | Consulta Configuración del servicio MFA |
| - Solicitar token OATH de terceros | Consulta Configuración del servicio MFA |
| Permite a los usuarios iniciar una omisión por única vez | Consulte Funcionalidad TAP de Microsoft Entra ID |
| Permitir a los usuarios seleccionar el método | Consulta Configuración del servicio MFA |
| - Llamada telefónica | Consulta la documentación de llamadas telefónicas |
| - Mensaje de texto | Consulta Configuración del servicio MFA |
| - Aplicación móvil | Consulta Configuración del servicio MFA |
| - Token OATH | Consulta la documentación del token OATH |
| Permitir a los usuarios seleccionar el idioma | La configuración de idioma se aplicará automáticamente a un usuario en función de la configuración regional en su explorador |
| Permitir a los usuarios activar la aplicación móvil | Consulta Configuración del servicio MFA |
| - Límite de dispositivo | Microsoft Entra ID limita los usuarios a cinco dispositivos acumulativos (instancias de aplicación móvil + token OATH de hardware + token OATH de software) por usuario |
| Usar preguntas de seguridad para la reserva | Microsoft Entra ID permite a los usuarios elegir un método de reserva en el momento de la autenticación si se produce un error en el método de autenticación elegido |
| - Preguntas que se deben responder | Las preguntas de seguridad de Microsoft Entra ID solo se pueden usar para SSPR. Consulta más detalles para preguntas de seguridad personalizadas de Microsoft Entra |
| Permitir a los usuarios asociar el token OATH de terceros | Consulta la documentación del token OATH |
| Usar token OATH para la reserva | Consulta la documentación del token OATH |
| Tiempo de espera de sesión | |
| Pestaña Preguntas de seguridad | Las preguntas de seguridad en el servidor MFA se usaron para obtener acceso al portal de usuarios. La autenticación multifactor de Microsoft Entra solo admite preguntas de seguridad para el autoservicio de restablecimiento de contraseña. Consulta la documentación de preguntas de seguridad. |
| Pestaña Sesiones superadas | Todos los flujos de registro de métodos de autenticación se administran mediante Microsoft Entra ID y no requieren configuración |
| IP de confianza | Direcciones IP de confianza de Microsoft Entra ID |
Todos los métodos de MFA disponibles en el servidor MFA deben estar habilitados en la autenticación multifactor de Microsoft Entra mediante la configuración del servicio MFA. Los usuarios no pueden probar sus métodos de MFA recién migrados a menos que estén habilitados.
Servicios de autenticación
El servidor Azure MFA puede proporcionar funcionalidad de MFA para soluciones de terceros que usan RADIUS o LDAP actuando como proxy de autenticación. Para detectar dependencias RADIUS o LDAP, haga clic en Opciones de autenticación RADIUS y autenticación LDAP en el servidor MFA. Para cada una de estas dependencias, determina si estos terceros admiten la autenticación moderna. Si es así, considere la posibilidad de federación directamente con Microsoft Entra ID.
En el caso de las implementaciones RADIUS que no se pueden actualizar, deberás implementar un servidor NPS e instalar la extensión NPS de la autenticación multifactor de Microsoft Entra.
En el caso de las implementaciones LDAP que no se pueden actualizar o mover a RADIUS, determine si se puede usar Microsoft Entra Domain Services. En la mayoría de los casos, LDAP se implementó para admitir cambios de contraseña en línea para los usuarios finales. Una vez migrados, los usuarios finales pueden administrar sus contraseñas mediante el autoservicio de restablecimiento de contraseña en Microsoft Entra ID.
Si habilitó el proveedor de autenticación del servidor MFA en AD FS 2.0 en cualquier relación de confianza para usuario autenticado, excepto para la confianza de usuario autenticado Office 365, deberá actualizar a AD FS 3.0 o federar a esos usuarios de confianza directamente en Microsoft Entra ID si admiten métodos de autenticación modernos. Determina el mejor plan de acción para cada una de las dependencias.
Copia de seguridad del archivo de datos del Servidor Microsoft Azure Multi-Factor Authentication
Haz una copia de seguridad del archivo de datos del servidor MFA ubicado en %programfiles%\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata (ubicación por defecto) en tu servidor MFA primario. Asegúrate de que tienes una copia del instalador para la versión instalada actualmente en caso de que tengas que revertir. Si ya no tienes una copia, ponte en contacto con los servicios de soporte técnico al cliente.
En función de la actividad del usuario, el archivo de datos puede quedar obsoleto rápidamente. Cualquier cambio realizado en el Servidor MFA, o cualquier cambio de usuario final realizado a través del portal después de la copia de seguridad no será capturado. Si reviertes, los cambios realizados después de este punto no se restaurarán.
Instalar la actualización del servidor MFA
Ejecuta el programa de instalación nuevo en el Servidor MFA Principal. Antes de actualizar un servidor, elimínalo del equilibrio de carga o del tráfico compartido con otros servidores MFA. No tienes que desinstalar el Servidor MFA actual antes de ejecutar el programa de instalación. El instalador realiza una actualización local mediante la ruta de instalación actual (por ejemplo, C:\Archivos de programa\Servidor Multi-Factor Authentication). Si se le solicita que instale un paquete de actualización de Microsoft Visual C++ 2015 Redistributable, acepte. Se instalan las versiones x86 y x64 del paquete. No es necesario instalar actualizaciones para el portal de usuarios, el SDK web o el adaptador de AD FS.
Nota:
Después de ejecutar el instalador en el servidor principal, los servidores secundarios pueden empezar a registrar entradas SB no controladas. Esto se debe a los cambios de esquema realizados en el servidor principal que los servidores secundarios no reconocerán. Se esperan estos errores. En entornos con 10 000 usuarios o más, la cantidad de entradas de registro puede aumentar significativamente. Para mitigar este problema, puedes aumentar el tamaño de archivo de los registros del servidor MFA o actualizar los servidores secundarios.
Configura la utilidad de migración del servidor MFA
Después de instalar la actualización del servidor MFA, abra un símbolo del sistema de PowerShell con privilegios elevados: mantén el puntero sobre el icono de PowerShell, haz clic con el botón derecho y haz clic en Ejecutar como administrador. Ejecute el script .\Configure-MultiFactorAuthMigrationUtility.ps1 que se encuentra en el directorio de instalación del servidor MFA (C:\Archivos de programa\Servidor Multi-Factor Authentication de manera predeterminada).
Este script requerirá que proporciones credenciales para un administrador de aplicaciones en el inquilino de Microsoft Entra. A continuación, el script creará una nueva aplicación de la utilidad de migración de servidores MFA en Microsoft Entra ID, que se usará para escribir métodos de autenticación de usuario en cada objeto de usuario de Microsoft Entra.
Para los clientes de la nube gubernamental que deseen realizar migraciones, reemplaza las entradas «.com» en el script por «.us». A continuación, este script escribirá las entradas del Registro HKLM:\SOFTWARE\WOW6432Node\Positive Networks\PhoneFactor\ StsUrl y GraphUrl, e indicará a la Utilidad de migración que usa los puntos de conexión de GRAPH adecuados.
También necesitarás tener acceso a las siguientes direcciones URL:
https://graph.microsoft.com/*(ohttps://graph.microsoft.us/*para los clientes de la nube gubernamental)https://login.microsoftonline.com/*(ohttps://login.microsoftonline.us/*para los clientes de la nube gubernamental)
El script te indicará que concedas consentimiento del administrador a la aplicación recién creada. Navegue a la dirección URL proporcionada, o dentro del centro de administración de Microsoft Entra, haga clic en Registros de aplicaciones, busque y seleccione la aplicación Utilidad de migración del servidor MFA, haga clic en Permisos de API, y luego conceda los permisos adecuados.
Una vez completado, diríjase a la carpeta Servidor Multi-Factor Authentication y abra la aplicación MultiFactorAuthMigrationUtilityUI. Deberías ver la siguiente pantalla:
Has instalado correctamente la utilidad de migración.
Nota
Para asegurarte de que no haya cambios en el comportamiento durante la migración, si el servidor MFA está asociado con un proveedor de MFA sin referencia de arrendatario, deberás actualizar la configuración predeterminada de MFA (como los saludos personalizados) para el arrendatario que estás migrando para que coincida con el configuración en el proveedor de MFA. Se recomienda hacerlo antes de migrar a los usuarios.
Ejecutar un servidor MFA secundario (opcional)
Si la implementación del servidor MFA tiene un gran número de usuarios o un servidor MFA principal ocupado, es posible que quieras considerar la posibilidad de implementar un servidor MFA secundario dedicado para ejecutar los servicios de sincronización de migración y utilidad de migración del servidor MFA. Después de actualizar el servidor MFA principal, actualiza un servidor secundario existente o implementa un nuevo servidor secundario. El servidor secundario que elijas no debe controlar otro tráfico MFA.
El script Configure-MultiFactorAuthMigrationUtility.ps1 debe ejecutarse en el servidor secundario para registrar un certificado con el registro de la aplicación de utilidad de migración del servidor MFA. El certificado se usa para autenticarse en Microsoft Graph. La ejecución de la utilidad de migración y los servicios de sincronización en un servidor MFA secundario debería mejorar el rendimiento de las migraciones de usuarios manuales y automáticas.
Migración de datos de usuario
La migración de datos de usuario no quita ni modifica ningún dato en la base de datos del servidor Multi-Factor Authentication. Del mismo modo, este proceso no cambiará donde un usuario realiza MFA. Este proceso es una copia unidireccional de datos desde el servidor local al objeto de usuario correspondiente en Microsoft Entra ID.
La utilidad MFA Server Migration tiene como destino un único grupo de Microsoft Entra para todas las actividades de migración. Puedes agregar usuarios directamente a este grupo o agregar otros grupos. También puedes agregarlos en fases durante la migración.
Para comenzar el proceso de migración, escribe el nombre o el GUID del grupo de Microsoft Entra que quieres migrar. Una vez completado, presiona Tab o haz clic fuera de la ventana para comenzar a buscar el grupo adecuado. Todos los usuarios del grupo se rellenan. Un grupo grande puede tardar unos minutos en finalizar.
Para ver los datos de atributo de un usuario, resalte el usuario y seleccione Ver:
En esta ventana se muestran los atributos del usuario seleccionado en Microsoft Entra ID y en el servidor MFA local. Puedes usar esta ventana para ver cómo se escribieron los datos en un usuario después de migrarlos.
La opción de Configuración permite cambiar la configuración del proceso de migración:
Migrar: hay tres opciones para migrar los métodos de autenticación predeterminados de los usuarios:
- Migrar siempre
- Migración solo si aún no se ha establecido en Microsoft Entra ID
- Establecer en el método más seguro disponible si aún no está establecido en Microsoft Entra ID
Estas opciones proporcionan flexibilidad al migrar el método predeterminado. Además, la directiva de métodos de autenticación se comprueba durante la migración. Si la directiva no permitiera el método predeterminado que se fuera a migrar, se establecerá en el método más seguro disponible en su lugar.
Coincidencia de usuario: permite especificar un atributo de Active Directory local diferente para la coincidencia con el UPN de Microsoft Entra, en lugar de la coincidencia predeterminada con userPrincipalName:
- La utilidad de migración intenta buscar coincidencias directas con UPN antes de usar el atributo de Active Directory local.
- Si no se encuentra ninguna coincidencia, llama a una API de Windows para buscar el UPN de Microsoft Entra y obtener el SID, que usa para buscar en la lista de usuarios del servidor MFA.
- Si la API de Windows no encuentra el usuario o el SID no se encuentra en el servidor de MFA, usará el atributo de Active Directory configurado para buscar al usuario en el Active Directory local y, después, usará el SID para buscar en la lista de usuarios del servidor de MFA.
Sincronización automática: inicia un servicio en segundo plano que supervisará continuamente los cambios en los métodos de autenticación a los usuarios del servidor MFA local y los escribirá en Microsoft Entra ID en el intervalo de tiempo especificado definido.
Servidor de sincronización: permite que el servicio de sincronización de migración del servidor MFA se ejecute en un servidor MFA secundario en lugar de ejecutarse solo en el servidor principal. Para configurar el servicio de sincronización de migración para que se ejecute en un servidor secundario, el script de
Configure-MultiFactorAuthMigrationUtility.ps1debe ejecutarse en el servidor para registrar un certificado con el registro de la aplicación de la utilidad de migración del servidor MFA. El certificado se usa para autenticarse en Microsoft Graph.
El proceso de migración puede ser automático o manual.
Los pasos del proceso manual son:
Para comenzar el proceso de migración de un usuario o selección de varios usuarios, mantén presionada la tecla Ctrl mientras seleccionas cada uno de los usuarios que desea migrar.
Después de seleccionar los usuarios deseados, haz clic en Migrar usuarios>Seleccionados>OK.
Para migrar todos los usuarios del grupo, haz clic en Migrar usuarios>Todos los usuarios en el grupo de Microsoft Entra>Aceptar.
Puede migrar usuarios aunque no hayan cambiado. De forma predeterminada, la utilidad se establece en Solo migrar usuarios que han cambiado. Haga clic en Migrar todos los usuarios para volver a migrar usuarios migrados previamente sin cambios. La migración de usuarios sin cambios puede ser útil durante las pruebas si un administrador necesita restablecer la configuración de Azure MFA de un usuario y desea volver a migrarlos.
Para el proceso automático, haz clic en Sincronización automática en Configuración y, a continuación, selecciona si deseas que todos los usuarios se sincronicen o solo los miembros de un grupo de Microsoft Entra determinado.
En la tabla siguiente se muestra la lógica de sincronización de los distintos métodos.
| Método | Lógica |
|---|---|
| Teléfono | Si no hay ninguna extensión, actualiza el teléfono MFA. Si hay una extensión, actualiza el teléfono de Office. Excepción: si el método predeterminado es Text Message, quita la extensión y actualiza el teléfono MFA. |
| Teléfono de reserva | Si no hay ninguna extensión, actualiza el teléfono alternativo. Si hay una extensión, actualiza el teléfono de Office. Excepción: si tanto Phone como Backup Phone tienen una extensión, omite Backup Phone. |
| Aplicación móvil | Se migrarán un máximo de cinco dispositivos o sólo cuatro si el usuario también tiene un token OATH de hardware. Si hay varios dispositivos con el mismo nombre, solo migra el más reciente. Los dispositivos se ordenarán de más reciente a más antiguo. Si los dispositivos ya existen en Microsoft Entra ID, haga coincidir la clave secreta del token OATH y actualice. - Si no hay coincidencia en la clave secreta del token OATH, coincide en el dispositivo -- Si se encuentra, crea un token OATH de software para el dispositivo servidor MFA para permitir que el método token OATH funcione. Las notificaciones seguirán funcionando con el dispositivo de autenticación multifactor existente de Microsoft Entra. -- Si no se encuentra, crea un nuevo dispositivo. Si agregar un nuevo dispositivo superará el límite de cinco dispositivos, se omitirá el dispositivo. |
| Token OATH | Si los dispositivos ya existen en Microsoft Entra ID, haga coincidir la clave secreta del token OATH y actualice. - Si no se encuentra, agrega un nuevo dispositivo token OATH de hardware. Si al añadir un nuevo dispositivo se supera el límite de cinco dispositivos, se omitirá el token OATH. |
Los métodos MFA se actualizarán en función de lo que se migró y se establecerá el método predeterminado. El servidor MFA realizará un seguimiento de la última marca de tiempo de migración y solo migrará al usuario de nuevo si la configuración de MFA del usuario cambia o un administrador modifica lo que se va a migrar en el cuadro de diálogo Configuración.
Durante las pruebas, se recomienda realizar primero una migración manual y probar para asegurarse de que un número determinado de usuarios se comporta según lo previsto. Una vez que las pruebas se realicen correctamente, activa la sincronización automática para el grupo de Microsoft Entra que deseas migrar. A medida que agregues usuarios a este grupo, su información se sincronizará automáticamente con Microsoft Entra ID. La utilidad de migración de servidores MFA tiene como destino un grupo de Microsoft Entra, pero ese grupo puede abarcar usuarios y grupos anidados de usuarios.
Una vez completado, una confirmación te informará de las tareas completadas:
Como se mencionó en el mensaje de confirmación, los datos migrados pueden tardar varios minutos en aparecer en objetos de usuario dentro de Microsoft Entra ID. Los usuarios pueden ver sus métodos migrados navegando a aka.ms/mfasetup.
Sugerencia
Puede reducir el tiempo necesario para mostrar grupos si no necesita ver los métodos MFA de Microsoft Entra. Haga clic en Ver>Métodos de Azure AD MFA para alternar la presentación de columnas de AAD predeterminado, Teléfono de AAD, Alternativa de AAD, Oficina de AAD, Dispositivos de AADy Token OATH de AAD. Cuando las columnas están ocultas, se omiten algunas llamadas API de Microsoft Graph, lo que mejora considerablemente el tiempo de carga del usuario.
Visualización de los detalles de la migración
Puede usar registros de auditoría o Log Analytics para ver los detalles del servidor MFA a las migraciones de usuario de Azure MFA.
Uso de registros de auditoría
Para acceder a los registros de auditoría en el centro de administración de Microsoft Entra para ver detalles las migraciones de usuario del servidor MFA a Azure MFA, siga estos pasos:
Inicie sesión en el Centro de administración de Microsoft Entra como Administrador de autenticación como mínimo.
Vaya a Identidad>Supervisión y estado>Registros de auditoría. Para filtrar los registros, haga clic en Agregar filtros.
Seleccione Iniciado por (actor) y haga clic en Aplicar.
Escriba Administración de Azure MFA y haga clic en Aplicar.
Este filtro muestra solo los registros de la Utilidad de migración del servidor MFA. Para ver los detalles de una migración de usuario, haga clic en una fila y, a continuación, elija la pestaña Propiedades modificadas. En esta pestaña se muestran los cambios en los métodos de MFA registrados y los números de teléfono.
En la tabla siguiente se muestra el método de autenticación para cada código.
Código Método 0 Móvil de voz 2 Oficina de voz 3 Móvil alternativo de voz 5 sms 6 Notificación de inserción de Microsoft Authenticator 7 OTP de token de hardware o software Si se migraron dispositivos de usuario, hay una entrada de registro independiente.
Uso de Log Analytics
También se pueden consultar los detalles de las migraciones de usuario del servidor MFA a Azure MFA mediante Log Analytics.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| extend Upn = tostring(TargetResources[0]["userPrincipalName"])
| extend ModifiedProperties = TargetResources[0]["modifiedProperties"]
| project ActivityDateTime, InitiatedBy, UserObjectId, Upn, ModifiedProperties
| order by ActivityDateTime asc
En esta captura de pantalla se muestran los cambios de la migración de usuarios:
En esta captura de pantalla se muestran los cambios para la migración de dispositivos:
Log Analytics también se puede usar para resumir la actividad de migración de usuarios.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)
Validación y prueba
Una vez que hayas migrado con éxito los datos de los usuarios, puedes validar la experiencia de los usuarios finales utilizando el despliegue por etapas antes de realizar el cambio de inquilino global. El siguiente proceso te permitirá dirigirte a grupos específicos de Microsoft Entra para el lanzamiento preconfigurado de MFA. El lanzamiento preconfigurado indica a Microsoft Entra ID que realice la MFA utilizando la autenticación multifactor de Microsoft Entra para los usuarios de los grupos seleccionados, en lugar de enviarlos a las instalaciones para realizar la MFA. Puede validar y probar: recomendamos usar el centro de administración de Microsoft Entra, pero si lo prefiere, también puede usar Microsoft Graph.
Habilitación del lanzamiento preconfigurado
Navega a la siguiente dirección URL: Habilitación de las características de lanzamiento preconfigurado: Microsoft Azure.
Cambie la autenticación multifactor de Azure a Activado y haga clic en Administrar grupos.
Haz clic en Agregar grupos y agrega los grupos que contienen los usuarios que quieres habilitar para Azure MFA. Los grupos seleccionados aparecen en la lista mostrada.
Nota:
Los grupos a los que te diriges mediante el método de Microsoft Graph siguiente también aparecerán en esta lista.
Habilitación del lanzamiento preconfigurado mediante Microsoft Graph
Creación de featureRolloutPolicy
Dirígete a aka.ms/ge e inicia sesión en Graph Explorer mediante una cuenta de administrador de identidades híbridas en el inquilino que deseas configurar para el lanzamiento preconfigurado.
Asegúrate de que POST está seleccionado como destino el siguiente punto de conexión:
https://graph.microsoft.com/v1.0/policies/featureRolloutPoliciesEl cuerpo de la solicitud debe contener lo siguiente (cambia la directiva de lanzamiento de MFA por un nombre y una descripción para tu organización):
{ "displayName": "MFA rollout policy", "description": "MFA rollout policy", "feature": "multiFactorAuthentication", "isEnabled": true, "isAppliedToOrganization": false }
Realiza una operación GET con el mismo punto de conexión y anota el valor de identificador (tachado en la imagen siguiente):
Diríjase a los grupos de Microsoft Entra que contienen los usuarios que desea probar
Crea una solicitud POST con el siguiente punto de conexión (reemplaza {ID de directiva} por el valor de identificador que copiaste del paso 1d):
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$refEl cuerpo de la solicitud debe contener lo siguiente (reemplaza {ID de grupo} por el identificador de objeto del grupo al que quieres dirigirte para el lanzamiento preconfigurado):
{ "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}" }Repite los pasos a y b para cualquier otro grupo al que desees dirigirte con el lanzamiento preconfigurado.
Para ver la directiva actual, realiza una operación GET con la siguiente dirección URL:
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesToEl proceso anterior usa el recurso featureRolloutPolicy. La documentación pública aún no se ha actualizado con la nueva característica multifactorAuthentication, pero tiene información detallada sobre cómo interactuar con la API.
Confirma que la experiencia de MFA del usuario final. A continuación se indican algunas cosas que puede comprobar:
- ¿Los usuarios ven sus métodos en aka.ms/mfasetup?
- ¿Los usuarios reciben llamadas telefónicas o mensajes de texto?
- ¿Pueden autenticarse correctamente mediante los métodos anteriores?
- ¿Los usuarios reciben correctamente notificaciones de Authenticator? ¿Pueden aprobar estas notificaciones? ¿La autenticación es correcta?
- ¿Los usuarios pueden autenticarse correctamente mediante tokens OATH de hardware?
Educación de los usuarios
Asegúrate de que los usuarios saben qué esperar cuando se mueven a Azure MFA, incluidos los nuevos flujos de autenticación. También puedes indicar a los usuarios que usen el portal de registro combinado de Microsoft Entra ID (aka.ms/mfasetup) para administrar sus métodos de autenticación en lugar del Portal de usuarios una vez completadas las migraciones. Los cambios realizados en los métodos de autenticación en Microsoft Entra ID no se propagarán de nuevo al entorno local. En una situación en la que tengas que retroceder a MFA Server, cualquier cambio que los usuarios hayan hecho en Microsoft Entra ID no estará disponible en el portal de usuario de MFA Server.
Si usa soluciones de terceros que dependen del servidor Azure MFA para la autenticación (vea Servicios de autenticación), querrá que los usuarios sigan realizando cambios en sus métodos de MFA en el Portal de usuarios. Estos cambios se sincronizarán automáticamente con Microsoft Entra ID. Una vez que hayas migrado estas soluciones de terceros, puedes mover usuarios a la página de registro combinado de Microsoft Entra ID.
Completar la migración de usuarios
Repite los pasos de migración que se encuentran en las secciones Migración de datos de usuario y Validación y prueba hasta que se migren todos los datos de usuario.
Migrar dependencias del servidor MFA
Con los puntos de datos recopilados en los servicios de autenticación, empieza a realizar las distintas migraciones necesarias. Una vez completado esto, considera la posibilidad de que los usuarios gestionen sus métodos de autenticación en el portal de registro combinado, en lugar de en el portal de usuario del servidor MFA.
Actualizar la configuración de federación de dominio
Una vez que haya completado las migraciones de usuario y haya movido todos los servicios de autenticación fuera del servidor MFA, es el momento de actualizar la configuración de federación de dominio. Después de la actualización, Microsoft Entra ya no envía la solicitud de MFA al servidor de federación local.
Para configurar Microsoft Entra ID para omitir las solicitudes de MFA en el servidor de federación local, instala el SDK de PowerShell de Microsoft Graph y establece federatedIdpMfaBehavior en rejectMfaByFederatedIdp, como se muestra en el ejemplo siguiente.
Solicitud
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Response
Note: El objeto de respuesta que se muestra aquí se puede acortar para mejorar la legibilidad.
HTTP/1.1 200 OK
Content-Type: application/json
{
"@odata.type": "#microsoft.graph.internalDomainFederation",
"id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
"issuerUri": "http://contoso.com/adfs/services/trust",
"metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
"signingCertificate": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
"passiveSignInUri": "https://sts.contoso.com/adfs/ls",
"preferredAuthenticationProtocol": "wsFed",
"activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
"signOutUri": "https://sts.contoso.com/adfs/ls",
"promptLoginBehavior": "nativeSupport",
"isSignedAuthenticationRequestRequired": true,
"nextSigningCertificate": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
"signingCertificateUpdateStatus": {
"certificateUpdateResult": "Success",
"lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
},
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Los usuarios ya no se redirigirán al servidor de federación local para MFA, ya sea que estén dirigidos por la herramienta lanzamiento preconfigurado o no. Ten en cuenta que esto puede tardar hasta 24 horas en surtir efecto.
Nota:
La actualización de la configuración de federación de dominio puede tardar hasta 24 horas en surtir efecto.
Deshabilitar el portal de usuarios del servidor MFA
Una vez que hayas completado la migración de todos los datos de los usuarios, los usuarios finales pueden empezar a utilizar las páginas de registro combinadas de Microsoft Entra ID para gestionar los métodos MFA. Hay un par de maneras de evitar que los usuarios usen el portal de usuarios en el servidor MFA:
- Redirigir la dirección URL del portal de usuarios del servidor MFA a aka.ms/mfasetup
- Desactiva la casilla Permitir que los usuarios inicien sesión en la pestaña Configuración de la sección Portal de usuarios del servidor MFA para impedir que los usuarios inicien sesión en el portal por completo.
Retirar el servidor MFA
Cuando ya no necesites el servidor Azure MFA, sigue los procedimientos de desuso del servidor normal. No se requiere ninguna acción especial en Microsoft Entra ID para indicar la retirada del servidor MFA.
Plan de reversión
Si la actualización tiene problemas, sigue estos pasos para revertir:
Desinstala MFA Server 8.1.
Reemplaza PhoneFactor.pfdata por la copia de seguridad realizada antes de actualizar.
Nota:
Cualquier cambio desde que se hizo la copia de seguridad se perderá, pero debería ser mínimo si la copia de seguridad se hizo justo antes de la actualización y ésta no se realizó correctamente.
Ejecuta el instalador para la versión anterior (por ejemplo, 8.0.x.x).
Configura Microsoft Entra ID para aceptar solicitudes de MFA en el servidor de federación local. Usa Graph PowerShell para establecer federatedIdpMfaBehavior en
enforceMfaByFederatedIdp, como se muestra en el ejemplo siguiente.Solicitud
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc Content-Type: application/json { "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }El siguiente objeto de respuesta se acorta para mejorar la legibilidad.
Respuesta
HTTP/1.1 200 OK Content-Type: application/json { "@odata.type": "#microsoft.graph.internalDomainFederation", "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc", "issuerUri": "http://contoso.com/adfs/services/trust", "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex", "signingCertificate": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI", "passiveSignInUri": "https://sts.contoso.com/adfs/ls", "preferredAuthenticationProtocol": "wsFed", "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed", "signOutUri": "https://sts.contoso.com/adfs/ls", "promptLoginBehavior": "nativeSupport", "isSignedAuthenticationRequestRequired": true, "nextSigningCertificate": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI", "signingCertificateUpdateStatus": { "certificateUpdateResult": "Success", "lastRunDateTime": "2021-08-25T07:44:46.2616778Z" }, "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }
Establece el lanzamiento preconfigurado de Azure MFA en Desactivado. Los usuarios volverán a redirigirse al servidor de federación local para MFA.