Selección del método de autenticación adecuado para la solución de identidad híbrida de Microsoft Entra.
La elección del método de autenticación correcto es la primera preocupación para las organizaciones que desean mover sus aplicaciones a la nube. Esta decisión no debe tomarse a la ligera por las razones siguientes:
Es la primera decisión de una organización que quiere trasladarse a la nube.
El método de autenticación es un componente esencial de la presencia de una organización en la nube. Esto es debido a que controla el acceso a todos los datos y recursos que hay en ella.
Es la base de todas las demás características avanzadas de seguridad y experiencia de usuario en Microsoft Entra ID.
La identidad es el nuevo plano de control de la seguridad de TI, de modo que la autenticación se convierte en el guardián de acceso de una organización al nuevo mundo de la nube. Las organizaciones necesitan un plano de control de identidad que fortalezca su seguridad y mantenga las aplicaciones en la nube a salvo de intrusos.
Nota:
Cambiar el método de autenticación requiere planeación, pruebas y un posible tiempo de inactividad. El lanzamiento preconfigurado es una excelente forma de probar la migración de usuarios desde la federación hasta la autenticación en la nube.
Fuera de ámbito
Las organizaciones que no tienen una superficie de directorio local existente no entran en el ámbito de este artículo. Por lo general, esas empresas crean identidades solo en la nube, lo que no requiere una solución de identidad híbrida. Las identidades que solo se usan en la nube existen únicamente en la nube y no están asociadas a sus identidades locales correspondientes.
Métodos de autenticación
Cuando la solución de identidad híbrida de Microsoft Entra sea el nuevo plano de control, la autenticación será la base del acceso a la nube. La elección del método de autenticación correcto es una primera decisión fundamental en la configuración de una solución de identidad híbrida de Microsoft Entra. El método de autenticación que elija que se configura mediante Microsoft Entra Connect, y que también aprovisiona a los usuarios en la nube.
Para elegir un método de autenticación, es necesario tener en cuenta el tiempo, la infraestructura existente, la complejidad y el costo de implementar cada opción. Estos factores varían con cada organización y pueden cambiar con el tiempo.
Microsoft Entra ID admite los siguientes métodos de autenticación en soluciones de identidad híbrida.
Autenticación en la nube
Cuando se elige este método de autenticación, Microsoft Entra ID administra el proceso de inicio de sesión de los usuarios. Junto con el inicio de sesión único (SSO), los usuarios pueden iniciar sesión en las aplicaciones en la nube sin tener que volver a escribir sus credenciales. Con la autenticación en la nube puede elegir entre dos opciones:
Sincronización de hash de contraseñas de Microsoft Entra. Es la manera más sencilla de habilitar la autenticación para los objetos de directorio local en Microsoft Entra ID. Gracias a ella, los usuarios pueden usar el mismo nombre de usuario y contraseña que en el entorno local sin tener que implementar ninguna otra infraestructura. Algunas características premium de Microsoft Entra ID, como Protección de id. de Microsoft Entra o Microsoft Entra Domain Services, requieren la sincronización de hash de contraseñas con independencia del método de autenticación seleccionado.
Nota:
Las contraseñas nunca se almacenan en texto no cifrado o cifradas con un algoritmo reversible en Microsoft Entra ID. Para obtener más información sobre el proceso real de sincronización de hash de contraseñas, consulte Implementación de la sincronización de hash de contraseña con los servicios de Microsoft Entra Connect Sync.
Autenticación de paso a través de Microsoft Entra. Proporciona una validación de contraseñas simple para los servicios de autenticación de Microsoft Entra mediante un agente de software que se ejecuta en uno o más servidores locales. Los servidores validan a los usuarios directamente con la instancia local de Active Directory, lo que garantiza que la validación de la contraseña no se realiza en la nube.
Las empresas con un requisito de seguridad para aplicar de inmediato los estados de cuenta de los usuarios locales, las directivas de contraseña y las horas de inicio de sesión pueden usar este método de autenticación. Para obtener más información sobre el proceso real de autenticación de paso a través, consulte Inicio de sesión del usuario con la autenticación de paso a través de Microsoft Entra.
Autenticación federada
Cuando se elige este método de autenticación, Microsoft Entra ID deja el proceso de autenticación en manos de un sistema de autenticación de confianza como, por ejemplo, una instancia local de Servicios de federación de Active Directory (AD FS) para validar la contraseña del usuario.
El sistema de autenticación puede proporcionar requisitos de autenticación avanzados, por ejemplo, la autenticación multifactor de terceros.
En la siguiente sección encontrará un árbol de decisión que le ayudará a decidir qué método de autenticación es más adecuado en su caso. Gracias a este árbol podrá determinar si debe implementar la autenticación en la nube o la autenticación federada para la solución híbrida de Microsoft Entra.
Árbol de decisión
Detalles sobre las preguntas de decisión:
- Microsoft Entra ID puede controlar el inicio de sesión de los usuarios sin tener que depender de los componentes locales para comprobar las contraseñas.
- Microsoft Entra ID puede entregar el inicio de sesión de usuario a un proveedor de autenticación de confianza como AD FS de Microsoft.
- Si tiene que aplicar directivas de seguridad de Active Directory a nivel de usuario, como la cuenta expirada, cuenta deshabilitada, contraseña expirada, cuenta bloqueada y horas de inicio de sesión de cada usuario, Microsoft Entra ID requiere algunos componentes locales.
- Las características de inicio de sesión no son compatibles de forma nativa con Microsoft Entra ID:
- Inicio de sesión con una solución de autenticación de terceros.
- Solución de autenticación local de varios sitios.
- Microsoft Entra ID Protection requiere la sincronización del hash de contraseña, independientemente de qué método de inicio de sesión elija, para proporcionar el informe Usuarios con credenciales filtradas. Las organizaciones pueden conmutar por error a la sincronización del hash de contraseña si se produce un error en su método principal de inicio de sesión y se ha configurado antes del evento de error.
Nota:
Microsoft Entra ID Protection requiere licencias de Microsoft Entra ID P2.
Consideraciones detalladas
Autenticación en la nube: Sincronización de hash de contraseña
Esfuerzo. La sincronización de hash de contraseñas requiere un esfuerzo mínimo en cuanto a la implementación, el mantenimiento y la infraestructura. Este nivel de esfuerzo se aplica normalmente a organizaciones que solo necesitan que sus usuarios inicien sesión en Microsoft 365, aplicaciones SaaS y otros recursos basados en Microsoft Entra ID. Cuando se habilita, la sincronización de hash de contraseñas forma parte del proceso de los servicios de Microsoft Entra Connect Sync y se ejecuta cada dos minutos.
Experiencia del usuario. Para mejorar la experiencia de inicio de sesión de los usuarios, use dispositivos unidos a Microsoft Entra o dispositivos híbridos unidos a Microsoft Entra. Si no puede unir los dispositivos Windows a Microsoft Entra ID, se recomienda implementar el inicio de sesión único sin problemas con la sincronización de hash de contraseñas. El SSO de conexión directa elimina las solicitudes innecesarias cuando los usuarios inician sesión.
Escenarios avanzados. Si las organizaciones lo eligen, es posible usar información de identidades con informes de Microsoft Entra ID Protection con Microsoft Entra ID P2. Por ejemplo, el informe de credenciales filtradas. Windows Hello para empresas tiene requisitos específicos cuando se usa la sincronización de hash de contraseñas. Microsoft Entra Domain Services requiere sincronización de hash de contraseñas para aprovisionar a los usuarios con sus credenciales corporativas en el dominio administrado.
Las organizaciones que requieren una autenticación multifactor con sincronización de hash de contraseñas tienen que usar la autenticación multifactor o los controles personalizados de acceso condicional de Microsoft Entra. Esas organizaciones no pueden usar métodos de autenticación multifactor de terceros o locales que se basen en la federación.
Nota:
Acceso condicional a Microsoft Entra requiere licencias de Microsoft Entra ID P1.
Continuidad del negocio. La sincronización de hash de contraseñas tiene una alta disponibilidad como servicio en la nube que se puede escalar a todos los centros de datos de Microsoft. Para asegurarse de que la sincronización de hash de contraseña no deja de funcionar durante períodos prolongados, implemente un segundo servidor de Microsoft Entra Connect de modo provisional en una configuración en espera.
Consideraciones. Actualmente, la sincronización de hash de contraseñas no aplica inmediatamente los cambios en los estados de la cuenta local. En esta situación, un usuario tendrá acceso a las aplicaciones en la nube hasta que el estado de la cuenta del usuario se sincronice con Microsoft Entra ID. Si las organizaciones quieren superar esta limitación, es recomendable ejecutar un nuevo ciclo de sincronización después de que los administradores realicen actualizaciones masivas en los estados de las cuentas de los usuarios locales. Por ejemplo, pueden deshabilitar las cuentas.
Nota:
La contraseña ha expirado y los estados bloqueados de la cuenta no están sincronizados con Microsoft Entra ID con Microsoft Entra Connect. Al cambiar la contraseña de un usuario y establecer la marca El usuario debe cambiar la contraseña en el siguiente inicio de sesión, el hash de contraseña no se sincronizará con Microsoft Entra ID mediante Microsoft Entra Connect hasta que el usuario cambie la contraseña.
Para ver los pasos de implementación, consulte Implementación de la sincronización de hash de contraseñas.
Autenticación en la nube: Autenticación de paso a través
Esfuerzo. Para realizar la autenticación de paso a través, necesita uno o más (recomendamos tres) agentes livianos instalados en los servidores existentes. Estos agentes deben tener acceso a la instancia local de Active Directory Domain Services, incluidos los controladores de dominio locales de AD. Estos agentes necesitan acceso saliente a Internet y tener acceso a los controladores de dominio. Por esta razón, no se pueden implementar los agentes en una red perimetral.
Este tipo de autenticación de paso a través necesita que los controladores de dominio le proporcionen acceso a la red sin restricciones. Todo el tráfico de red se cifra y se limita a las solicitudes de autenticación. Para obtener más información sobre este proceso, consulte Información de seguridad detallada sobre la autenticación de paso a través.
Experiencia del usuario. Para mejorar la experiencia de inicio de sesión de los usuarios, use dispositivos unidos a Microsoft Entra o dispositivos híbridos unidos a Microsoft Entra. Si no puede unir los dispositivos Windows a Microsoft Entra ID, se recomienda implementar el inicio de sesión único sin problemas con la sincronización de hash de contraseñas. El SSO de conexión directa elimina las solicitudes innecesarias cuando los usuarios inician sesión.
Escenarios avanzados. La autenticación de paso a través aplica la directiva de cuenta local al iniciar sesión. Por ejemplo, se deniega el acceso cuando el estado de la cuenta de un usuario local indica que está deshabilitada, bloqueada, con su contraseña expirada o que el intento de inicio de sesión se encuentra fuera de las horas de inicio de sesión del usuario.
Las organizaciones que requieren una autenticación multifactor con una autenticación de paso a través deben usar la autenticación multifactor de Microsoft Entra o los controles personalizados de acceso condicional. Esas organizaciones no pueden usar métodos de autenticación multifactor de terceros o locales que se basen en la federación. Las funciones avanzadas requieren que se implemente la sincronización de hash de contraseñas sin importar si elige o no la autenticación transferida. Un ejemplo es la detección de credenciales filtradas de Protección de id. de Microsoft Entra.
Continuidad del negocio. Es recomendable que implemente dos agentes de autenticación de paso a través adicionales. Estos extras son adicionales al primer agente en el servidor de Microsoft Entra Connect. Esta implementación garantiza una alta disponibilidad de solicitudes de autenticación. Cuando hay tres agentes implementados, un agente puede dejar de funcionar cuando otro agente está inactivo por mantenimiento.
Existe otro beneficio al implementar la sincronización de hash de contraseñas además de la autenticación de paso a través. Actúa como un método de autenticación de respaldo cuando el método de autenticación principal ya no está disponible.
Consideraciones. Puede utilizar la sincronización de hash de contraseñas como método de autenticación de respaldo para la autenticación de paso a través, cuando los agentes no puedan asegurarse de las credenciales de un usuario debido a un error local importante. La conmutación por error de la sincronización de hash de contraseñas no sucede automáticamente y debe usar Microsoft Entra Connect para cambiar el método de inicio de sesión manualmente.
Para ver más detalles sobre la autenticación de paso a través, incluida la compatibilidad con identificadores alternativos, consulte las preguntas más frecuentes.
Para obtener información sobre los pasos de implementación, consulte Implementación de la autenticación de paso a través.
Autenticación federada
Esfuerzo. El uso de un sistema de autenticación federada se basa en un sistema externo de confianza para autenticar a los usuarios. Algunas empresas desean reutilizar sus inversiones existentes en sistemas federados con su solución de identidad híbrida de Microsoft Entra. El mantenimiento y la administración del sistema federado no entra en el control de Microsoft Entra ID. Es responsabilidad de la organización que usa el sistema federado asegurarse de que se implementa de forma segura y de que puede administrar la carga de autenticación.
Experiencia del usuario. La experiencia de usuario de la autenticación federada depende de la implementación de las características, la topología y la configuración de la granja de servidores de federación. Algunas organizaciones necesitan esta flexibilidad para adaptar y configurar el acceso a la granja de servidores de federación a fin de satisfacer sus requisitos de seguridad. Por ejemplo, es posible configurar usuarios y dispositivos conectados internamente para iniciar la sesión de los usuarios automáticamente, sin pedirles las credenciales. Esta configuración funciona porque ya han iniciado sesión en sus dispositivos. Por otro lado, si es necesario, algunas características de seguridad avanzadas pueden dificultar el proceso de inicio de sesión del usuario.
Escenarios avanzados. Se requiere una solución de autenticación federada cuando los clientes tienen un requisito de autenticación que Microsoft Entra ID no admite de forma nativa. Puede consultar información detallada que le ayudará a elegir la opción de inicio de sesión correcta. Considere los siguientes requisitos comunes:
- Proveedores de autenticación multifactor de terceros que requieren un proveedor de identidades federadas.
- Un método de autenticación con una solución de autenticación de terceros. Consulte la lista de compatibilidad de la federación de Microsoft Entra.
- Un inicio de sesión que requiera un elemento sAMAccountName, como DOMAIN\username, en lugar de usar el nombre principal de usuario (UPN); por ejemplo, user@domain.com.
Continuidad del negocio. Los sistemas federados generalmente requieren una matriz de servidores de carga equilibrada, conocida como granja de servidores. Esta granja de servidores está configurada en una red interna y en una topología de red perimetral para garantizar una alta disponibilidad de las solicitudes de autenticación.
La sincronización de hash de contraseñas se puede implementar en combinación con la autenticación federada como método de autenticación de reserva cuando el método de autenticación principal ya no esté disponible. Por ejemplo, cuando los servidores locales no están disponibles. Algunas organizaciones empresariales de gran tamaño requieren una solución de federación para admitir varios puntos de entrada a Internet con DNS geográfico para solicitudes de autenticación de baja latencia.
Consideraciones. Normalmente, los sistemas federados requieren una inversión más importante en infraestructura local. La mayoría de las organizaciones eligen esta opción si ya han invertido en una federación local. También la escogerán si es un requisito de negocios importante usar un proveedor de identidades únicas. Es más difícil usar la federación y solucionar sus problemas en comparación con las soluciones de autenticación en la nube.
Si hay un dominio no enrutable que no se puede verificar en Microsoft Entra ID, debe realizar una configuración adicional para implementar el inicio de sesión de un id. de usuario. Este requisito se conoce como compatibilidad con identificadores de inicio de sesión alternativos. Para conocer los requisitos y las limitaciones, consulte Configurar un identificador de inicio de sesión alternativo. Si decide usar un proveedor de autenticación multifactor de terceros con federación, asegúrese de que el proveedor admite WS-Trust para permitir que los dispositivos se unan a Microsoft Entra ID.
Para conocer los pasos de implementación, consulte Deploying Federation Servers (Implementación de los servidores de federación).
Nota:
Al implementar la solución de identidad híbrida de Microsoft Entra, debe implementar una de las topologías admitidas de Microsoft Entra Connect. Aprenda más sobre las configuraciones admitidas y no admitidas en Topologías de Microsoft Entra Connect.
Diagramas de arquitectura
En los siguientes diagramas se describen los componentes de arquitectura de alto nivel que requiere cada método de autenticación que se puede usar con la solución de identidad híbrida de Microsoft Entra. Proporcionan información general para comparar las diferencias entre las soluciones.
Simplicidad de una solución de sincronización de hash de contraseñas:
Requisitos del agente para la autenticación transferida, con el uso de dos agentes para la redundancia:
Componentes necesarios para la federación en la red perimetral e interna de la organización:
Comparación de métodos
| Consideración | Sincronización de hash de contraseñas | Autenticación de paso a través | Federación con AD FS |
|---|---|---|---|
| ¿Dónde se realiza la autenticación? | En la nube | En la nube, después de un intercambio de comprobación de contraseña segura con el agente de autenticación local | Local |
| ¿Cuáles son los requisitos de servidor local más allá del sistema de aprovisionamiento (Microsoft Entra Connect)? | Ninguno | Un servidor para cada agente de autenticación adicional | Dos o más servidores de AD FS Dos o más servidores WAP en la red perimetral o DMZ |
| ¿Cuáles son los requisitos de redes e Internet locales más allá del sistema de aprovisionamiento? | Ninguno | Acceso saliente a Internet desde los servidores que ejecutan los agentes de autenticación | Acceso entrante a Internet para los servidores WAP del perímetro Acceso entrante de red para los servidores de AD FS desde los servidores WAP del perímetro Equilibrio de carga de red |
| ¿Hay algún requisito de certificado TLS/SSL? | No | No | Sí |
| ¿Hay alguna solución de supervisión de estado? | No se requiere | Estado del agente proporcionado por el Centro de administración de Microsoft Entra | Microsoft Entra Connect Health |
| ¿Los usuarios realizan el inicio de sesión único en los recursos de nube desde dispositivos unidos a un dominio de la red de la empresa? | Sí, con dispositivos unidos a Microsoft Entra,dispositivos híbridos unidos a Microsoft Entra, el complemento Microsoft Enterprise SSO para dispositivos Apple o SSO de conexión directa | Sí, con dispositivos unidos a Microsoft Entra,dispositivos híbridos unidos a Microsoft Entra, el complemento Microsoft Enterprise SSO para dispositivos Apple o SSO de conexión directa | Sí |
| ¿Qué tipos de inicio de sesión se admiten? | UserPrincipalName + contraseña Autenticación integrada de Windows con SSO de conexión directa Identificador de inicio de sesión alternativo Dispositivos unidos a Microsoft Entra Dispositivos híbridos unidos a Microsoft Entra Autenticación de certificados y tarjetas inteligentes |
UserPrincipalName + contraseña Autenticación integrada de Windows con SSO de conexión directa Identificador de inicio de sesión alternativo Dispositivos unidos a Microsoft Entra Dispositivos híbridos unidos a Microsoft Entra Autenticación de certificados y tarjetas inteligentes |
UserPrincipalName + contraseña sAMAccountName + contraseña Autenticación integrada de Windows Autenticación de certificados y tarjetas inteligentes Identificador de inicio de sesión alternativo |
| ¿Se admite Windows Hello para empresas? | Modelo de confianza de clave Confianza en la nube híbrida |
Modelo de confianza de clave Confianza en la nube híbrida Requieren el nivel funcional de dominio de Windows Server 2016 |
Modelo de confianza de clave Confianza en la nube híbrida Modelo de confianza de certificado |
| ¿Cuáles son las opciones de autenticación multifactor? | Autenticación multifactor de Microsoft Entra Controles personalizados con acceso condicional* |
Autenticación multifactor de Microsoft Entra Controles personalizados con acceso condicional* |
Autenticación multifactor de Microsoft Entra MFA de terceros Controles personalizados con acceso condicional* |
| ¿Qué estados de cuenta de usuario se admiten? | Cuentas deshabilitadas (retraso de hasta 30 minutos) |
Cuentas deshabilitadas Cuenta bloqueada Cuenta expirada Contraseña expirada Horas de inicio de sesión |
Cuentas deshabilitadas Cuenta bloqueada Cuenta expirada Contraseña expirada Horas de inicio de sesión |
| ¿Cuáles son las opciones de acceso condicional? | Acceso condicional a Microsoft Entra, con Microsoft Entra ID P1 o P2 | Acceso condicional a Microsoft Entra, con Microsoft Entra ID P1 o P2 | Acceso condicional a Microsoft Entra, con Microsoft Entra ID P1 o P2 Reglas de notificaciones de AD FS |
| ¿Se admite el bloqueo de protocolos heredados? | Sí | Sí | Sí |
| ¿Se puede personalizar el logotipo, la imagen y la descripción en las páginas de inicio de sesión? | Sí, con Microsoft Entra ID P1 o P2 | Sí, con Microsoft Entra ID P1 o P2 | Sí |
| ¿Qué escenarios avanzados se admiten? | Smart Password Lockout (Bloqueo inteligente de contraseñas) Informes de credenciales filtradas, con Microsoft Entra ID P2 |
Smart Password Lockout (Bloqueo inteligente de contraseñas) | Sistema de autenticación multisitio de baja latencia Bloqueo de extranet de AD FS Integración con sistemas de identidad de terceros |
Nota:
Actualmente, los controles personalizados del acceso condicional a Microsoft Entra no admiten el registro de dispositivos.
Recomendaciones
El sistema de identidad garantiza que los usuarios tengan acceso a aplicaciones que se migran y están disponibles en la nube. Use o habilite la sincronización de hash de contraseña con independencia del método de autenticación que elija, por las razones siguientes:
Alta disponibilidad y recuperación ante desastres. La autenticación de paso a través y la federación se basan en la infraestructura local. En la autenticación de paso a través, la superficie local incluye las redes y el hardware del servidor que requieren los agentes de autenticación de paso a través. En el caso de la federación, la superficie local es aún mayor. Esto es debido a que se requieren servidores en la red perimetral para las solicitudes de autenticación de proxy y los servidores de federación internos.
Para evitar los únicos puntos de errores, implemente servidores redundantes. A continuación, las solicitudes de autenticación siempre se atenderán si se produce un error en alguno de los componentes. Tanto la autenticación de paso a través como la de federación están sujetas a los controladores de dominio para responder a las solicitudes de autenticación, que también pueden producir un error. Muchos de estos componentes deben mantenerse para permanecer en buen estado. Las interrupciones son más probables cuando el mantenimiento no se planifica ni se implementa correctamente.
Subsistencia a interrupciones locales. Las consecuencias de una interrupción local debida a un ataque cibernético o a un desastre pueden ser de gran envergadura; desde daños en la reputación de la marca hasta la paralización de organizaciones que se ven incapaces de hacer frente al ataque. Últimamente muchas organizaciones han sido víctimas de ataques de malware, como ransomware dirigido, que provocaron que sus servidores locales se desconectaran. A la hora de ayudar a los clientes a tratar con estos tipos de ataques, Microsoft observó dos categorías de organizaciones:
Las organizaciones que también activaron previamente la sincronización de hash de contraseñas sobre la autenticación federada o la autenticación de paso a través, cambiaron su método de autenticación principal para usar la sincronización de hash de contraseñas. Gracias a esto, volvieron a estar en línea en cuestión de horas. Al usar el acceso al correo electrónico a través de Microsoft 365, pudieron trabajar para resolver los problemas y acceder a otras cargas de trabajo basadas en la nube.
Las organizaciones que no habilitaron previamente la sincronización de hash de contraseñas, tuvieron que recurrir a sistemas de correo electrónico de consumidor externos que no son de confianza para las comunicaciones, con el fin de resolver los problemas. En esos casos, tardaron semanas en restaurar su infraestructura de identidad en el entorno local, antes de que los usuarios pudieran volver a iniciar sesión en aplicaciones basadas en la nube.
Protección de identificadores: Una de las mejores maneras de proteger a los usuarios en la nube consiste en usar Protección de id. de Microsoft Entra con Microsoft Entra ID P2. Microsoft examina continuamente Internet en busca de listas de usuarios y contraseñas que los usuarios malintencionados venden y proporcionan en la Internet oscura. Microsoft Entra ID puede usar esta información para comprobar si algunos de los nombres de usuario y contraseñas de su organización están en peligro. Por lo tanto, es fundamental habilitar la sincronización de hash de contraseñas, con independencia de qué método de autenticación se use, ya sea autenticación federada o de paso a través. Las credenciales filtradas se presentan como un informe. Use esta información para bloquear o exigir que los usuarios cambien sus contraseñas cuando intenten iniciar sesión con contraseñas filtradas.
Conclusión
En este artículo se describen distintas opciones de autenticación que las organizaciones pueden configurar e implementar para admitir el acceso a las aplicaciones en la nube. Para satisfacer los diversos requisitos de negocios, técnicos y de seguridad, las organizaciones pueden elegir entre la sincronización de hash de contraseñas, la autenticación de paso a través y la federación.
Revise con atención cada método de autenticación interno. ¿Los esfuerzos para implementar la solución, así como la experiencia del usuario en el proceso de inicio de sesión responden a los requisitos de su negocio? También debe valorar si su organización necesita las características de escenarios avanzados y continuidad empresarial de cada método de autenticación. Por último, sopese los detalles de cada método de autenticación. ¿Alguno de ellos le impide implementar su elección?
Pasos siguientes
En la actualidad, las amenazas están presentes 24 horas al día y proceden de cualquier lugar. La implementación del método de autenticación correcto le ayudará a mitigar los riesgos de seguridad y a proteger las identidades.
Comience a trabajar con Microsoft Entra ID e implemente la solución de autenticación adecuada para su organización.
Si está pensando cambiar de la autenticación federada a la autenticación en la nube, consulte la información acerca de cómo cambiar el método de inicio de sesión. Para ayudarle a planear e implementar la migración, use estos planes de implementación de proyectos o considere la posibilidad de usar la nueva característica de lanzamiento por fases para migrar usuarios federados al uso de la autenticación en la nube en un enfoque por fases.