Migrar a la autenticación multifactor de Microsoft Entra con federación

El cambio de la solución de autenticación multifactor (MFA) a Microsoft Entra ID es un excelente primer paso en el recorrido a la nube. Considere también la posibilidad de pasar a Microsoft Entra ID para la autenticación de usuarios en el futuro. Para obtener más información, consulte el proceso de migración a la autenticación multifactor de Microsoft Entra con autenticación en la nube.

Para migrar a la autenticación multifactor de Microsoft Entra con federación, el provedor de la autenticación multifactor de Microsoft Entra se instala en AD FS. La confianza de usuario autenticado de Microsoft Entra ID y otras confianzas de usuario están configuradas para usar la autenticación multifactor de Microsoft Entra para los usuarios migrados.

El siguiente diagrama muestra el proceso de migración.

Flow chart of the migration process. Process areas and headings in this document are in the same order

Creación de grupos de migración

Para crear directivas de acceso condicional, tendrá que asignarlas a grupos. Con este fin, puede usar grupos de seguridad de Azure AD o de Microsoft 365. También puede crear o sincronizar otros nuevos.

También necesitará un grupo de seguridad de Microsoft Entra para migrar usuarios de forma iterativa a la autenticación multifactor de Microsoft Entra. Estos grupos se usan en las reglas de notificaciones.

No reutilice los grupos que se usan para la seguridad. Use solo el grupo de seguridad para proteger un grupo de aplicaciones de alto valor con una directiva de acceso condicional.

Preparación de AD FS

Actualización de la granja de servidores de AD FS a 2019, FBL 4

En AD FS 2019, puede especificar métodos de autenticación adicionales para un usuario de confianza, como una aplicación. La pertenencia a grupos se usa para determinar el proveedor de autenticación. Al especificar un método de autenticación adicional, puede realizar la transición a la autenticación multifactor de Microsft Entra y mantener intacta otra autenticación durante la transición. Para obtener más información, vea Actualización a AD FS en Windows Server 2016 con una base de datos WID. En el artículo se describe tanto la actualización de la granja a AD FS 2019 como la actualización de FBL a 4.

Configuración de reglas de notificaciones para invocar la autenticación multifactor de Microsoft Entra

Ahora que la autenticación multifactor de Microsoft Entra es un método de autenticación adicional, puede asignar grupos de usuarios para usarlos. Para ello, configure reglas de notificaciones, también conocidas como relaciones de confianza para usuario autenticado. Mediante el uso de grupos, puede controlar qué proveedor de autenticación se llama de forma global o por aplicación. Por ejemplo, puede llamar a la autenticación multifactor de Microsoft Entra en el caso de usuarios que se han registrado para obtener información de seguridad combinada y llamar al servidor de MFA en el caso de aquellos que no lo han hecho.

Nota:

Las reglas de notificaciones necesitan un grupo de seguridad local. Antes de realizar cambios en las reglas de notificaciones, realice una copia de seguridad.

Reglas de copia de seguridad

Antes de configurar nuevas reglas de notificaciones, haga una copia de seguridad de las reglas. Tendrá que restaurar estas reglas como parte de los pasos de limpieza.

En función de la configuración, es posible que también tenga que copiar la regla y anexar las reglas que se crean para la migración.

Para ver las reglas globales, ejecute lo siguiente:

Get-AdfsAdditionalAuthenticationRule

Para ver las confianzas de un usuario de confianza, ejecute el siguiente comando y reemplace RPTrustName por el nombre de la regla de notificaciones de confianzas de un usuario de confianza:

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules 

Directivas de control de acceso

Nota:

Las directivas de control de acceso no se pueden configurar para que se invoque un proveedor de autenticación específico en función de la pertenencia a grupos.

Para realizar la transición de las directivas de control de acceso a reglas de autenticación adicionales, ejecute el siguiente comando para cada una de las relaciones de confianza para usuario autenticado mediante el proveedor de autenticación del servidor MFA:

Set-AdfsRelyingPartyTrust -TargetName AppA -AccessControlPolicyName $Null

Este comando moverá la lógica de la directiva de control de acceso actual a Reglas de autenticación adicionales.

Configuración del grupo y búsqueda del SID

Necesitará un grupo específico en el que colocar a los usuarios para los que quiera invocar la autenticación multifactor de Microsoft Entra. Necesitará el identificador de seguridad (SID) de ese grupo.

Para buscar el SID del grupo, use el comando siguiente, con el nombre del grupo.

Get-ADGroup "GroupName"

Image of screen shot showing the results of the Get-ADGroup script.

Configuración de reglas de notificaciones para llamar la autenticación multifactor de Microsoft Entra

Los cmdlets de PowerShell siguientes invocan la autenticación multifactor de Microsoft Entra para los usuarios del grupo cuando no están en la red corporativa. Reemplace "YourGroupSid" por el SID encontrado mediante la ejecución del cmdlet anterior.

Asegúrese de revisar Procedimiento para elegir proveedores de autenticación adicionales en 2019.

Importante

Copia de seguridad de las reglas de notificaciones

Configuración de la regla de notificaciones global

Ejecute el siguiente cmdlet de PowerShell:

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules

El comando devuelve las reglas de autenticación adicionales actuales para la relación de confianza para usuario autenticado. Anexe las reglas siguientes a las reglas de notificación actuales:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

En el ejemplo siguiente se da por supuesto que las reglas de notificación actuales están configuradas para solicitar MFA cuando los usuarios se conectan desde fuera de la red. En este ejemplo se incluyen las reglas adicionales que debe anexar.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == 
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"http://schemas.microsoft.com/claims/multipleauthn" );
 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Establecimiento de la regla de notificaciones en cada aplicación

En este ejemplo se modifican las reglas de notificación en una relación de confianza para usuario autenticado (aplicación) concreta y se incluye la información que se debe anexar.

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == 
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"http://schemas.microsoft.com/claims/multipleauthn" );
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Configurar la autenticación multifactor de Microsoft Entra como proveedor de autenticación en AD FS

Para configurar la autenticación multifactor de Microsoft Entra para AD FS, debe configurar cada servidor AD FS. Si tiene varios servidores de AD FS en la granja, puede configurarlos de forma remota mediante Azure AD PowerShell.

Para obtener instrucciones paso a paso sobre este procedimiento, vea Configuración de los servidores de AD FS en el artículo Configurar la autenticación multifactor de Microsoft Entra como proveedor de autenticación con AD FS.

Cuando haya configurado los servidores, puede agregar la autenticación multifactor de Microsoft Entra como un método de autenticación adicional.

Screen shot showing the Edit authentication methods screen with Microsoft Entra multifactor authentication and Azure Multi-Factor Authentication Server selected

Preparación de Microsoft Entra ID e implementación de la migración

En esta sección se describen los pasos finales antes de migrar la configuración de MFA.

Establezca federatedIdpMfaBehavior en enforceMfaByFederatedIdp

En los dominios federados, MFA se puede aplicar mediante el acceso condicional de Microsoft Entra o por medio del proveedor de federación local. Cada dominio federado tiene una configuración de seguridad de PowerShell de Microsoft Graph denominada federatedIdpMfaBehavior. Puede establecer federatedIdpMfaBehavior en enforceMfaByFederatedIdp para que Microsoft Entra ID acepte la MFA que realiza el proveedor de identidades federado. Si el proveedor de identidades federado no ha ejecutado la MFA, Microsoft Entra ID redirige la solicitud al proveedor de identidades federado para ejecutar la MFA. Para obtener más información, consulte federatedIdpMfaBehavior.

Nota

El parámetro federatedIdpMfaBehavior es una nueva versión de la propiedad SupportsMfa del cmdlet New-MgDomainFederationConfiguration.

En el caso de los dominios que establecen la propiedad SupportsMfa, estas reglas determinan cómo federatedIdpMfaBehavior y SupportsMfa funcionan conjuntamente:

  • No se admite el cambio entre federatedIdpMfaBehavior y SupportsMfa.
  • Una vez configurada la propiedad federatedIdpMfaBehavior, Microsoft Entra ID omite el valor de configuración SupportsMfa.
  • Si nunca se configura la propiedad federatedIdpMfaBehavior, Microsoft Entra ID sigue cumpliendo el valor de configuración SupportsMfa.
  • Si no se configura federatedIdpMfaBehavior ni SupportsMfa, Microsoft Entra ID tendrá como valor predeterminado el comportamiento acceptIfMfaDoneByFederatedIdp.

Puede comprobar el estado de federatedIdpMfaBehavior mediante Get-MgDomainFederationConfiguration.

Get-MgDomainFederationConfiguration –DomainID yourdomain.com

También puede comprobar el estado de la marca SupportsMfa con Get-MgDomainFederationConfiguration:

Get-MgDomainFederationConfiguration –DomainName yourdomain.com

En el ejemplo siguiente se muestra cómo establecer federatedIdpMfaBehavior en enforceMfaByFederatedIdp mediante PowerShell de Graph.

Solicitud

PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

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": "enforceMfaByFederatedIdp"
}

Configuración de directivas de acceso condicional si son necesarias

Si usa el acceso condicional para determinar cuándo se solicita a los usuarios MFA, no es necesario cambiar las directivas.

Si en los dominios federados SupportsMFA está establecido en false, analice las reglas de notificaciones en la relación de confianza para usuario autenticado de Microsoft Entra ID y cree directivas de acceso condicional que admitan los mismos objetivos de seguridad.

Después de crear directivas de acceso condicional para aplicar los mismos controles que AD FS, puede realizar una copia de seguridad y quitar las personalizaciones de las reglas de notificación en el usuario de confianza de Microsoft Entra ID.

Para obtener más información, consulte los siguientes recursos:

Registro de usuarios para la autenticación multifactor de Microsoft Entra

En esta sección se explica cómo los usuarios pueden registrarse para la seguridad combinada (MFA y el autoservicio de restablecimiento de contraseña) y cómo migrar su configuración de MFA. Microsoft Authenticator se puede usar en el modo sin contraseña. También se puede usar como segundo factor para MFA con cualquier método de registro.

Se recomienda que los usuarios se registren para la información de seguridad combinada, que es un único lugar para registrar sus métodos de autenticación y dispositivos para MFA y SSPR.

Microsoft ofrece plantillas de comunicación que puede proporcionar a los usuarios para guiarlos por el proceso de registro combinado. Estas incluyen plantillas para correo electrónico, pósteres, contenidos de tablas y otros recursos. Los usuarios registran su información en https://aka.ms/mysecurityinfo, desde donde acceden a la pantalla de registro de seguridad combinada.

Se recomienda proteger el proceso de registro de seguridad con acceso condicional, para lo que es necesario que el registro se produzca desde un dispositivo o ubicación de confianza. Para obtener información sobre el seguimiento de los estados de registro, consulte Actividad del método de autenticación para Microsoft Entra ID.

Nota:

Los usuarios que tienen que registrar su información de seguridad combinada desde una ubicación o dispositivo que no es de confianza pueden recibir un Pase de acceso temporal, o bien se les puede excluir temporalmente de la directiva.

Migración de la configuración de MFA desde el Servidor MFA

Puede usar la utilidad MFA Server Migration para sincronizar la configuración de MFA registrada para los usuarios entre el Servidor MFA y Microsoft Entra ID. Puede sincronizar números de teléfono, tokens de hardware y registros de dispositivos, como la configuración de Microsoft Authenticator.

Adición de usuarios a los grupos adecuados

  • Si ha creado directivas de acceso condicional, agregue los usuarios adecuados a esos grupos.

  • Si ha creado grupos de seguridad locales para reglas de notificaciones, agregue los usuarios adecuados a esos grupos.

No se recomienda reutilizar los grupos que se usan para la seguridad. Use solo el grupo de seguridad para proteger un grupo de aplicaciones de alto valor con una directiva de acceso condicional.

Supervisión

El registro de la autenticación multifactor de Microsoft Entra se puede supervisar por medio del informe de uso y conclusiones de los métodos de autenticación. Este informe se puede encontrar en Microsoft Entra ID. Seleccione Supervisión y después Uso y conclusiones.

En Uso y conclusiones, seleccione Métodos de autenticación.

Puede encontrar información detallada sobre el registro de la autenticación multifactor de Microsoft Entra en la pestaña Registro. Puede explorar en profundidad para ver una lista de usuarios registrados si selecciona el hipervínculo Usuarios compatibles con la autenticación multifactor de Azure.

Image of Authentication methods activity screen showing user registrations to MFA

Pasos de limpieza

Cuando haya completado la migración de la autenticación multifactor de Microsoft Entre y esté listo para retirar el servidor MFA, haga lo siguiente:

  1. Revierta las reglas de notificación en AD FS a su configuración previa a la migración y quite el proveedor de autenticación del servidor MFA.

  2. Quite el servidor MFA como proveedor de autenticación en AD FS. Esto garantizará que todos los usuarios usen la autenticación multifactor de Microsoft Entra, ya que será el único método de autenticación adicional habilitado.

  3. Retire el servidor MFA.

Reversión de las reglas de notificaciones en AD FS y eliminación del proveedor de autenticación del servidor MFA

Siga los pasos descritos en Configuración de reglas de notificaciones para invocar la autenticación multifactor de Microsoft Entra a fin de revertir las reglas de notificaciones de copia de seguridad y quitar las reglas de notificaciones AzureMFAServerAuthentication.

Por ejemplo, quite lo siguiente de las reglas:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"**YourGroupSID**"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'

Deshabilitación del servidor MFA como proveedor de autenticación en AD FS

Este cambio garantiza que solo se usa la autenticación multifactor de Microsoft Entra como proveedor de autenticación.

  1. Abra la consola de administración de AD FS.

  2. En Servicios, haga clic con el botón derecho en Métodos de autenticación y seleccione Editar métodos de autenticación multifactor.

  3. Desactive la casilla situada junto a Azure Multi-Factor Authentication Server.

Retirada del servidor MFA

Siga el proceso de retirada del servidor empresarial para quitar los servidores MFA del entorno.

Entre las posibles consideraciones al retirar los servidores MFA se incluyen las siguientes:

  • Revise los registros de los servidores MFA para asegurarse de que ningún usuario o aplicación lo usa antes de quitar el servidor.

  • Desinstalación del servidor Multi-Factor Authentication desde el panel de control en el servidor

  • Opcionalmente, limpie los registros y los directorios de datos restantes después de realizar primero una copia de seguridad.

  • Desinstale el SDK del servidor web de la autenticación multifactor si procede, incluidos los archivos que hayan quedado en los directorios etpub\wwwroot\MultiFactorAuthWebServiceSdk y MultiFactorAuth

  • Para las versiones del servidor MFA anteriores a la 8.0, también puede ser necesario quitar el servicio de la aplicación del teléfono de autenticación multifactor

Pasos siguientes