Opciones de infraestructura de identidades paralelas y combinadas

Microsoft ofrece una gama de tecnologías y soluciones para integrar entre sus diferentes componentes locales y en la nube de su infraestructura de identidades. A menudo, los clientes no tienen claro qué tecnologías son las más adecuadas y pueden pensar de forma equivocada que "la versión más reciente cubre todos los escenarios de las versiones de tecnología anteriores".

En este artículo se tratan los escenarios en los que su empresa se encuentra en medio de un escenario complejo que se describe a continuación y quiere combinar la información de las identidades. En una situación ideal, una organización con un único origen de RR. HH., un único bosque de Active Directory y un único inquilino de Microsoft Entra, todos integrados con las mismas personas en cada uno, tendrá la mejor experiencia de identidades para Microsoft Online Services. Sin embargo, en la práctica, es posible que un cliente empresarial no siempre se encuentre en una situación en la que eso sea posible. Por ejemplo, el cliente puede estar llevando a cabo una fusión o tener necesidad de aislamiento para algunos usuarios o aplicaciones. Un cliente que tiene varios orígenes de RR. HH., varios directorios de AD o varios inquilinos de Microsoft Entra debe decidir entre combinarlos en menos instancias de cada uno o mantenerlos en paralelo.

En función de los comentarios de nuestros clientes, estos son algunos de los escenarios y requisitos comunes.

Escenarios que surgen para identidades multinube y multiorganización

• Fusiones y adquisiciones (M&A): hace referencia a una situación en la que, normalmente, la empresa A compra la empresa B.
• Cambio de marca: un cambio de nombre de empresa o de marca y, normalmente, un cambio de nombre de dominio de correo electrónico.
• Consolidación de inquilinos de Microsoft Entra ID u Office 365. Es posible que las empresas con más de un inquilino de Office 365 quieran combinarlos debido a requisitos históricos o de cumplimiento.
• Consolidación de dominios de Active Directory o de bosques: empresas que evalúan para realizar una consolidación de dominios de Active Directory o de bosques.
• Desinversiones: donde una división o un grupo de negocios de una empresa se vende o se vuelve independiente.
• Privacidad de la información de usuario: cuando las empresas tienen requisitos para evitar que determinados datos (atributos) no sean visibles públicamente y solo los usuarios o grupos delegados adecuados puedan leer, cambiar y actualizar los datos.

Requisitos derivados de estos escenarios

• Lleve los datos de todos los usuarios y grupos a un único lugar, incluida la disponibilidad de correo electrónico y estado para la programación de reuniones mediante la creación de un directorio universal o central.
• Mantenga un único nombre de usuario y credenciales, a la vez que reduce la necesidad de escribir nombres de usuario y contraseñas en todas las aplicaciones mediante la implementación del inicio de sesión único.
• Optimice la incorporación de usuarios para que no tarde semanas ni meses.
• Prepare la organización para futuras adquisiciones y acceda a demandas de administración.
• Habilite y mejore la productividad y colaboración entre empresas.
• Reduzca la probabilidad de una brecha de seguridad o de una filtración de datos con directivas de seguridad implementadas de forma centralizada y coherente.

Escenarios que no se tratan en este artículo

• M&A. parcial. Por ejemplo, una organización compra parte de otra organización.
• Desinversión o división de organizaciones
• Cambio de nombre de organizaciones.
• Empresas conjuntas o asociados temporales

Este artículo describe varios entornos de identidad multinube o multiorganización, incluidos los escenarios M&A que admite Microsoft en la actualidad, y describe cómo una organización puede seleccionar las tecnologías adecuadas en función de cómo aborda la consolidación.

Opciones de consolidación para un escenario de M&A hipotético

Las secciones siguientes abarcan cuatro escenarios principales para un escenario de M&A hipotético:

Supongamos que Contoso es un cliente empresarial y que su departamento de TI tiene un único sistema de RR. HH. (local), un único bosque de Active Directory y un único inquilino de Microsoft Entra ID para sus aplicaciones, que funcionan según lo previsto. Los usuarios se incorporan desde su sistema de RR. HH. a Active Directory, se proyectan en Microsoft Entra ID y, desde ahí, en las aplicaciones SaaS. Este escenario se ilustra con el diagrama siguiente, con las flechas que muestran el flujo de información de identidad. El mismo modelo también se aplica a los clientes con un sistema de RR. HH. en la nube, como Workday o SuccessFactors que aprovisionan Active Directory, no solo a los clientes que usan Microsoft Identity Manager (MIM).

A continuación, Contoso ha empezado a fusionarse con Litware, que anteriormente llevaba su propio departamento de TI de forma independiente. El departamento de TI de Contoso controlará la fusión y espera que las aplicaciones de Contoso no sufran ningún cambio, pero quiere que los usuarios de Litware tengan acceso a ellas y colaboren en esas aplicaciones. En el caso de las aplicaciones de Microsoft, SaaS de terceros y aplicaciones personalizadas, el estado final debe ser que los usuarios de Contoso y Litware tengan acceso a los mismos datos, teóricamente.

La primera decisión de TI es hasta que punto desean combinar la infraestructura. Podrían optar por no depender de ninguna infraestructura de identidad de Litware. O bien, podrían considerar el uso de la infraestructura de Litware y fusionar a lo largo del tiempo, a la vez que minimizan las interrupciones en el entorno de Litware. En algunos casos, es posible que el cliente quiera mantener independiente la infraestructura de identidades existente de Litware y no fusionarla, mientras sigue usándose para proporcionar a los empleados de Litware acceso a las aplicaciones de Contoso.

Si el cliente decide mantener parte o toda la infraestructura de identidades de Litware, hay ciertas concesiones en cuanto a la cantidad de Active Directory Domain Services o Microsoft Entra ID de Litware que se usa para proporcionar a los usuarios de Litware acceso a los recursos de Contoso. En esta sección se examinan las opciones que pueden funcionar en función de lo que Contoso usaría para los usuarios de Litware:

• Escenario A: no usar ninguna infraestructura de identidades de Litware.
• Escenario B: Usar los bosques de Active Directory de Litware, pero no el entorno de Microsoft Entra ID de Litware (si lo tiene)
• Escenario C: Usar el entorno de Microsoft Entra ID de Litware.
• Escenario D: usar la infraestructura de identidades de Litware que no es de Microsoft (si Litware no usa Active Directory ni Microsoft Entra ID)

En la tabla siguiente se resume cada opción con las tecnologías para saber cómo el cliente podría lograr esos resultados, las restricciones y las ventajas de cada una.

Consideraciones	A1: RR. HH. único, IAM único e inquilino	A2: RR. HH. independiente, IAM único e inquilino	B3: Confianza de bosque de Active Directory, Microsoft Entra Connect único	B4: Microsoft Entra Connect, su Active Directory con un único inquilino	B5: Microsoft Entra Connect Cloud Sync con su Active Directory	C6: aprovisionar en paralelo varios inquilinos en aplicaciones	C7: leer de su inquilino e invitar a B2B a sus usuarios	C8: IAM único y usuarios B2B según sea necesario	D9: DF con su IdP que no es de Azure AD
Esfuerzo de migración	Alto	Esfuerzo medio	Menor esfuerzo	Esfuerzo bajo	Esfuerzo bajo	None	None	None	None
Esfuerzo de implementación	Menos esfuerzo	Esfuerzo medio	Esfuerzo medio	Esfuerzo medio	Bajo	Bajo	Alto	Alto	Muy alto
Afectación en el usuario final durante la migración	Alto	Alto	Media	Media	Media	None	None	None	None
Esfuerzo operativo	Bajo costo	Bajo costo	Bajo costo	Bajo costo	Bajo costo	Alto	Alto	Alto	Muy alto
Funcionalidades de privacidad y datos (ubicación geográfica/límites de datos)	Ninguno (obstáculo principal para escenarios de ubicación geográfica)	Aislamiento limitado, aunque complicado	Aislamiento limitado en local, pero no en la nube	Aislamiento limitado en local, pero no en la nube	Aislamiento limitado en local, pero no en la nube	Buen aislamiento tanto en local como en la nube	Aislamiento limitado tanto en local como en la nube	Aislamiento limitado tanto en local como en la nube	Aislamiento tanto en local como en la nube
Aislamiento (delegación independiente y configuración de diferentes modelos de administración) Nota: Tal y como se define en el sistema de origen (RR. HH.)	No es posible	Posibilidad	Posibilidad	Posibilidad	Posibilidad	Altamente posible	Altamente posible	Altamente posible	Posibilidad
Funcionalidades de colaboración	Excelente	Excelente	Excelente	Excelente	Excelente	Insuficiente	Media	Media	Poor
Modelo de administración de TI compatible (centralizado frente a independiente)	Centralizado	Centralizado	Centralizado	Centralizado	Centralizado	Descentralizado	Descentralizado	Descentralizado	Descentralizado activamente
Limitaciones	Sin aislamiento	Aislamiento limitado	Aislamiento limitado	Aislamiento limitado	Aislamiento limitado. Sin funcionalidades de escritura diferida	No funcionará para las aplicaciones de Microsoft Online Services. Altamente dependiente de la funcionalidad de la aplicación	Requiere que las aplicaciones sean compatibles con B2B	Requiere que las aplicaciones sean compatibles con B2B	Requieren que las aplicaciones sean compatibles con B2B. Incertidumbre en el funcionamiento conjunto

Detalles de tabla

• El esfuerzo de los empleados intenta predecir la experiencia necesaria y el trabajo adicional necesario para implementar la solución en una organización.
• El esfuerzo operativo intenta predecir el coste y el esfuerzo que se necesita para mantener la solución en ejecución.
• Las funcionalidades de privacidad y datos muestran si la solución permite la compatibilidad con la ubicación geográfica y los límites de datos.
• El aislamiento muestra si esta solución proporciona la capacidad de separar o delegar modelos de administración.
• Las funcionalidades de colaboración muestran el nivel de colaboración que admite la solución; las soluciones más integradas ofrecen una mayor fidelidad de trabajo en equipo.
• El modelo de administración de TI muestra si el modelo de administración requiere centralización o se puede descentralizar.
• Limitaciones: cualquier problema de desafío que vale la pena enumerar.

Árbol de decisión

Use el siguiente árbol de decisión para decidir qué escenario funcionaría mejor para su organización.

En el resto de este documento, se describen cuatro escenarios A-D con varias opciones al respecto.

Escenario A: si Contoso no desea confiar en la infraestructura de identidad existente de Litware

Para esta opción, es posible que Litware no tenga ningún sistema de identidades (por ejemplo, una pequeña empresa) o que el cliente quiera desactivar la infraestructura de Litware. O bien, quieren dejarla intacta para que la usen los empleados de Litware para autenticarse en las aplicaciones de Litware, pero proporcionar a los empleados de Litware nuevas identidades como parte de Contoso. Por ejemplo, si Alice Smith fuera una empleada de Litware, podría tener dos identidades: Alice@litware.com y ASmith123@contoso.com. Esas identidades serían completamente distintas entre sí.

Opción 1: combinar en un único sistema de RR. HH.

Normalmente, los clientes traerían a los empleados de Litware al sistema de RR. HH. de Contoso. Esta opción desencadenaría que esos empleados recibieran cuentas y el acceso correcto a las aplicaciones y directorios de Contoso. Entonces, un usuario de Litware tendría una nueva identidad de Contoso, que podría usar para solicitar acceso a las aplicaciones adecuadas de Contoso.

Opción 2: mantener el sistema de RR. HH. de Litware

A veces, puede que no sea posible converger los sistemas de RR. HH., al menos no a corto plazo. En su lugar, el cliente conectaría su sistema de aprovisionamiento, por ejemplo, MIM, para leer de ambos sistemas de RR. HH. En este diagrama, el sistema de RR. HH. superior es el entorno de Contoso existente y el segundo sistema de RR. HH. es la adición de Litware a la infraestructura general.

El mismo escenario también sería posible con Microsoft Entra Workday o SuccessFactors de entrada. Contoso podría traer usuarios del origen de RR. HH. de Workday de Litware junto con los empleados actuales de Contoso.

Resultados de la consolidación de toda la infraestructura de identidades

• Infraestructura de TI reducida, solo un sistema de identidad que administrar, ningún requisitos de conectividad de red, excepto un sistema de RR. HH.
• Experiencia de administración y usuarios finales coherente

Restricciones de la consolidación de toda la infraestructura de identidades

• Los datos que necesiten los empleados de Contoso que se originan en Litware deben migrarse al entorno de Contoso.
• Cualquier aplicación de Litware integrada con Active Directory o Microsoft Entra que sea necesaria para Contoso debe volver a configurarse en el entorno de Contoso. Esta reconfiguración puede requerir cambios en la configuración, en los grupos que usa para el acceso o, potencialmente, en las propias aplicaciones.

Escenario B: Si Contoso desea mantener los bosques de Active Directory de Litware, pero no usar el entorno de Microsoft Entra ID de Litware

Litware puede tener muchas aplicaciones existentes basadas en Active Directory en las que se basa, por lo que es posible que Contoso quiera que los empleados de Litware conserven sus propias identidades en su entorno de AD existente. Entonces, un empleado de Litware usaría su identidad existente para la autenticación de sus recursos existentes y la autenticación de los recursos de Contoso. En este escenario, Litware no tiene ninguna identidad en la nube en Microsoft Online Services, quizá porque Litware no era un cliente de Microsoft Entra, ningún recurso en la nube de Litware se iba a compartir con Contoso o Contoso migró los recursos en la nube de Litware para que formaran parte del inquilino de Contoso.

Opción 3: confianza de bosque con el bosque adquirido

Mediante una confianza de bosque de Active Directory, Contoso y Litware pueden conectar sus dominios de Active Directory. Esta confianza permite a los usuarios de Litware autenticar las aplicaciones de Contoso integradas en Active Directory. Microsoft Entra Connect puede leer también el bosque de Active Directory de Litware para que los usuarios de Litware se autentiquen en las aplicaciones de Contoso integradas en Microsoft Entra. Esta topología de implementación requiere una ruta de red configurada entre los dos dominios y conectividad de red TCP/IP entre cualquier usuario de Litware y la aplicación de Contoso integrada en Active Directory. También es sencillo configurar confianzas bidireccionales para que los usuarios de Contoso puedan acceder a las aplicaciones de Litwareintegradas en AD (si las hubiera).

Resultado de la configuración de una confianza de bosque

• Todos los empleados de Litware pueden autenticarse en las aplicaciones de Contoso integradas en Active Directory o Microsoft Entra, y Contoso puede usar las herramientas actuales basadas en AD para administrar la autorización.

Restricciones de la configuración de una confianza de bosque

• Requiere conectividad TCP/IP entre los usuarios que están unidos al dominio de un bosque y los recursos unidos al otro bosque.
• Requiere que las aplicaciones basadas en Active Directory en el bosque de Contoso sean compatibles con varios bosques

Opción 4: Configurar Microsoft Entra Connect para el bosque adquirido sin confianza de bosque

Un cliente también puede configurar Microsoft Entra Connect para leer otro bosque. Esta configuración permite que los usuarios de Litware se autentiquen en las aplicaciones de Contoso integradas en Microsoft Entra, pero no proporciona acceso a las aplicaciones de Contoso integradas en Active Directory al usuario de Litware. Esas aplicaciones de Contoso no reconocen a los usuarios de Litware. Esta topología de implementación requiere conectividad de red TCP/IP entre Microsoft Entra Connect y los controladores de dominio de Litware. Por ejemplo, si Microsoft Entra Connect se encuentra en una máquina virtual IaaS de Contoso, también tendría que establecer un túnel a la red de Litware.

Resultado de usar Microsoft Entra Connect para aprovisionar un inquilino

• Todos los empleados de Litware pueden autenticarse en las aplicaciones de Contoso integradas en Microsoft Entra.

Restricciones del uso de Microsoft Entra Connect para aprovisionar un inquilino

• Requiere conectividad TCP/IP entre los dominios de Microsoft Entra Connect de Contoso y los dominios de Active Directory de Litware.
• No permite que los usuarios de Litware tengan acceso a las aplicaciones de Contoso basadas en Active Directory.

Opción 5: Implementar Microsoft Entra Connect Cloud Sync en el bosque adquirido

El aprovisionamiento en la nube de Microsoft Entra Connect elimina el requisito de conectividad de red, pero solo puede tener un vínculo entre Active Directory y Microsoft Entra ID para un usuario determinado con sincronización en la nube. Los usuarios de Litware pueden autenticarse en las aplicaciones de Contoso integradas en Microsoft Entra, pero no en las aplicaciones de Contoso integradas en Active Directory. Esta topología no requiere ninguna conectividad TCP/IP entre los entornos locales de Litware y Contoso.

Resultado de implementar Microsoft Entra Connect Cloud Sync en el bosque adquirido

• Todos los empleados de Litware pueden autenticarse en las aplicaciones de Contoso integradas en Microsoft Entra.

Restricciones de usar Microsoft Entra Connect Cloud Sync en el bosque adquirido

• No permite que los usuarios de Litware tengan acceso a las aplicaciones de Contoso basadas en AD.

Escenario C: Si Contoso desea mantener el entorno de Microsoft Entra ID de Litware

Puede que Litware sea un cliente de Microsoft Online Services o Azure, o que tenga una o varias aplicaciones basadas en Microsoft Entra ID de las que depende. Por lo tanto, es posible que Contoso quiera que los empleados de Litware conserven sus propias identidades para acceder a esos recursos. Entonces, un empleado de Litware usaría su identidad existente para la autenticación de sus recursos existentes y la autenticación de los recursos de Contoso.

Este escenario es adecuado en los casos en los que:

• Litware tiene una amplia inversión en Azure o Microsoft Online Services, incluidos varios inquilinos de Office 365 que serían costosos o lentos para migrar a otro inquilino.
• Litware podría escindirse en el futuro o es una asociación que funcionará de forma independiente.
• Litware no tiene infraestructura local

Opción 6: Mantener el aprovisionamiento paralelo y el inicio de sesión único para las aplicaciones de cada entorno de Microsoft Entra ID

Una opción es que cada entorno de Microsoft Entra ID proporcione inicio de sesión único de forma independiente y que aprovisione a los usuarios de su directorio en la aplicación de destino. Por ejemplo, si el equipo de TI de Contoso usa una aplicación como Salesforce, proporcionaría a Litware derechos administrativos para crear usuarios en la misma suscripción de Salesforce.

Resultado del aprovisionamiento paralelo

• Los usuarios pueden autenticar aplicaciones mediante su identidad existente, sin realizar cambios en la infraestructura de Contoso.

Restricciones del aprovisionamiento paralelo

• Si usa una federación, requiere que las aplicaciones admitan varios proveedores de federación para la misma suscripción.
• No es posible para las aplicaciones de Microsoft como Office o Azure
• Contoso no tiene visibilidad en su entorno de Microsoft Entra ID del acceso a las aplicaciones para los usuarios de Litware.

Opción 7: configurar cuentas B2B para usuarios del inquilino adquirido

Si Litware ha estado ejecutando su propio inquilino, Contoso puede leer los usuarios de ese inquilino y, a través de B2B API, invitar a cada uno de esos usuarios al inquilino de Contoso. Este proceso de invitación masiva puede realizarse a través del conector MIM Graph, por ejemplo. Si Contoso también tiene aplicaciones basadas en AD que desea que estén disponibles para los usuarios de Litware, MIM también podría crear usuarios en Active Directory que se asignarían a los UPN de los usuarios de Microsoft Entra, de modo que el proxy de aplicaciones podría realizar KCD en nombre de la representación de un usuario de Litware en el entorno de Active Directory de Contoso.

Entonces, cuando un empleado de Litware desee acceder a una aplicación de Contoso, podrá hacerlo mediante la autenticación en su propio directorio, con asignación de acceso al inquilino del recurso.

Resultado de la configuración de cuentas B2B para usuarios del otro inquilino

• Los usuarios de Litware pueden autenticar las aplicaciones de Contoso y Contoso controla dicho acceso en su inquilino.

Restricciones de la configuración de cuentas B2B para usuarios del otro inquilino

• Requiere una cuenta duplicada para cada usuario de Litware que requiera acceso a los recursos de Contoso.
• Requiere que las aplicaciones sean compatibles con B2B para el inicio de sesión único.

Opción 8: configurar B2B, pero con una fuente de RR. HH. común para ambos directorios

En algunas situaciones, después de la adquisición, la organización puede converger en una sola plataforma de RR. HH., pero aún así ejecutar los sistemas de administración de identidades existentes. En este escenario, MIM podría aprovisionar usuarios en varios sistemas de Active Directory, en función de la parte de la organización a la que esté asociado el usuario. Podrían seguir usando B2B para que los usuarios autenticaran su directorio existente y tuvieran una lista global de direcciones unificada.

Resultado de la configuración de usuarios invitados B2B desde una fuente de sistemas de RR. HH. común

• Los usuarios de Litware pueden autenticarse en las aplicaciones de Contoso y Contoso controla dicho acceso en su inquilino.
• Litware y Contoso tienen una lista global de direcciones unificada.
• No hay ningún cambio en el entorno de Active Directory o Microsoft Entra ID de Litware

Restricciones de la configuración de usuarios invitados B2B desde una fuente de sistemas de RR. HH. común

• Requiere cambios en el aprovisionamiento de Contoso para enviar también a los usuarios al entorno de Active Directory de Litware y en la conectividad entre los dominios de Litware y Contoso.
• Requiere que las aplicaciones sean compatibles con B2B para el inicio de sesión único.

Escenario D: si Litware usa una infraestructura que no es de Active Directory

Por último, si Litware usa otro servicio de directorio, ya sea local o en la nube, el equipo de TI de Contoso todavía puede configurar que los empleados de Litware se autentiquen y puedan obtener acceso a los recursos de Contoso con su identidad existente.

Opción 9: usar la federación directa B2B (versión preliminar pública)

En este escenario, se supone que Litware tiene:

• Algunos directorios existentes, como OpenLDAP o incluso una base de datos SQL o un archivo plano de usuarios con sus direcciones de correo electrónico que pueden compartir periódicamente con Contoso.
• Un proveedor de identidades que admite SAML, como PingFederate u OKTA.
• Un dominio DNS enrutado públicamente, como Litware.com, y usuarios con direcciones de correo electrónico en ese dominio

En este enfoque, Contoso configuraría una relación de federación directa desde su inquilino para ese dominio con el proveedor de identidades de Litware y, a continuación, leería periódicamente las actualizaciones de los usuarios de Litware de su directorio para invitar a los usuarios de Litware al entorno de Microsoft Entra ID de Contoso. Esta actualización se puede realizar con un conector MIM Graph. Si Contoso también tiene aplicaciones basadas en Active Directory que desea que estén disponibles para los usuarios de Litware, MIM también podría crear usuarios en Active Directory que se asignarían a los UPN de los usuarios de Microsoft Entra, de modo que el proxy de aplicaciones podría realizar KCD en nombre de una representación de un usuario de Litware en el entorno de Active Directory de Contoso.

Resultado del uso de la federación directa B2B

• Los usuarios de Litware se autentican en el entorno de Microsoft Entra ID de Contoso con su proveedor de identidades actual y acceden a las aplicaciones web de Contoso del entorno local y en la nube.

Restricciones del uso de la federación directa B2B

• Requiere que las aplicaciones de Contoso puedan admitir el inicio de sesión único de los usuarios B2B.

Pasos siguientes

• ¿Qué es la sincronización en la nube de Microsoft Entra Connect?
• Planeamiento de la aplicación de RR. HH. en la nube para el aprovisionamiento de usuarios de Microsoft Entra ID
• Configuración de la federación directa B2B
• Opciones de administración de usuarios multiinquilino
• ¿Qué es el aprovisionamiento de aplicaciones?