Opciones de infraestructura de identidad en paralelo y combinada

Microsoft ofrece una gama de tecnologías y soluciones para integrar entre sus diferentes componentes locales y en la nube de su infraestructura de identidad. A menudo, los clientes no están claros sobre qué tecnologías son más correctas y pueden pensar incorrectamente que "la versión más reciente cubre todos los escenarios de versiones de tecnología anteriores".

En este artículo se describen las situaciones en las que su empresa enfrenta un caso complejo, como se detalla a continuación, y busca combinar la información de identidad. Idealmente, una organización con un único origen de RR. HH., un único bosque de Active Directory y una única entidad de Microsoft Entra, todas ellas integradas con las mismas personas, tendrá la mejor experiencia de identidad para sus Servicios en línea de Microsoft. Sin embargo, en la práctica, es posible que un cliente empresarial no siempre esté en una situación en la que sea posible. Por ejemplo, el cliente puede estar pasando por una fusión o tener una necesidad de aislamiento para algunos usuarios o aplicaciones. Un cliente que tenga varios sistemas de RRHH, varios AD o varias entidades de Microsoft Entra debe decidir si reducir a menos instancias de cada uno o mantenerlos en paralelo.

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

Escenarios que surgen para identidades multinube y de varias organizaciones

• 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 o marca de la empresa y, normalmente, un cambio de nombre de dominio de correo electrónico.
• Consolidación de identidades de Microsoft Entra ID u Office 365: es posible que las empresas con más de una identidad de Office 365 quieran fusionarse debido a los requisitos históricos o de cumplimiento.
• Consolidación de dominios o bosques de Active Directory: empresas que evalúan realizar la consolidación de dominios o bosques de Active Directory.
• Desinversiones: donde se vende una división o un grupo empresarial de una empresa o se convierte en independiente.
• Privacidad de la información del usuario: cuando las empresas tienen requisitos para evitar que determinados datos (atributos) no sean visibles públicamente y solo los grupos delegados correctos o los usuarios pueden leer, cambiar y actualizarlos.

Requisitos que se derivan de estos escenarios

• Ponga todos los datos de los usuarios y grupos en un solo lugar, incluida la disponibilidad de correo electrónico y estado para la programación de reuniones mediante la creación de un directorio central o universal.
• Mantenga un único nombre de usuario y credenciales al tiempo 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 lleve semanas o meses.
• Prepare la organización para futuras adquisiciones y demandas de administración de acceso.
• Habilite y mejore la colaboración y la productividad entre empresas.
• Reduzca la probabilidad de una vulneración de seguridad o 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
• Cambiar el nombre de las organizaciones.
• Empresas conjuntas o socios temporales

En este artículo se describen varios entornos de identidad multinube o de varias organizaciones, incluidos escenarios de M&A que Microsoft admite hoy y se describe cómo una organización puede seleccionar las tecnologías adecuadas en función de cómo se aproximan a la consolidación.

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

En las secciones siguientes se tratan cuatro escenarios principales para un escenario hipotético de M&A:

Supongamos que Contoso es un cliente de nivel empresarial y su departamento de TI tiene un único sistema de RR. HH. local, un único bosque de Active Directory, y un único identificador de Microsoft Entra para sus aplicaciones, funcionando según lo esperado. Los usuarios se incorporan desde su sistema de RR. HH. a Active Directory y se proyectan en el identificador de Entra de Microsoft y desde allí en aplicaciones SaaS. Este escenario se muestra 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 sistema de RR. HH. en la nube, como Workday o SuccessFactors, aprovisionando Active Directory, no solo los clientes que usan Microsoft Identity Manager (MIM).

A continuación, Contoso ha empezado a combinarse con Litware, que anteriormente ha estado ejecutando su propia TI de forma independiente. El departamento de TI de Contoso controlará la fusión y espera que el departamento de TI de Contoso siga teniendo aplicaciones de Contoso sin cambios, pero quiere que los usuarios de Litware reciban acceso a ellos y colaboren dentro de esas aplicaciones. Para las aplicaciones de Microsoft, SaaS de terceros y aplicaciones personalizadas, el estado final debe ser que los usuarios de Contoso y Litware tengan acceso conceptualmente a los mismos datos.

La primera decisión de TI es cuánto desean combinar la infraestructura. Podrían optar por no confiar en ninguna de las infraestructuras de identidad de Litware. O bien, podrían considerar utilizar la infraestructura de Litware y converger con el tiempo, minimizando al mismo tiempo la interrupción del entorno de Litware. En algunos casos, es posible que el cliente quiera mantener la infraestructura de identidad existente de Litware independiente y no convergándola, mientras sigue usándola para conceder a los empleados de Litware acceso a las aplicaciones contoso.

Si el cliente decide mantener parte o toda la infraestructura de identidad de Litware, hay compromisos respecto a cuánto se usan los Servicios de Dominio de Active Directory de Litware o Microsoft Entra ID para proporcionar a los usuarios de Litware acceso a los recursos de Contoso. En esta sección se examinan opciones viables, basado en lo que Contoso usaría para los usuarios de Litware.

• Escenario A: no use ninguna de las infraestructuras de identidad de Litware.
• Escenario B: usar los bosques de Active Directory de Litware, pero no el identificador de Microsoft Entra de Litware (si tienen uno)
• Escenario C - Use Microsoft Entra ID de Litware.
• Escenario D: Usar la infraestructura de identidad que no es de Microsoft de Litware (si Litware no usa Active Directory o Microsoft Entra ID)

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

Consideraciones	A1: RR. HH. único, IAM único e inquilino	A2: Recursos humanos independientes, IAM único e inquilino	B3: Confianza de bosque de Active Directory, Microsoft Entra Connect único	B4: Microsoft Entra Connect conecta su Active Directory a un entorno único	B5: Microsoft Entra Connect sincroniza en la nube su Active Directory.	C6: aprovisionar en paralelo varios inquilinos en aplicaciones	C7: leer de su entorno y en B2B invitar a sus usuarios	C8: usuarios individuales de IAM y 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	Ninguno	Ninguno	Ninguno	Ninguno
Esfuerzo de implementación	Menor esfuerzo	Esfuerzo medio	Esfuerzo medio	Esfuerzo medio	Bajo nivel	Bajo nivel	Alto	Alto	Muy alto
Impacto del usuario final durante la migración	Alto	Alto	Mediana	Mediana	Mediana	Ninguno	Ninguno	Ninguno	Ninguno
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 o límites de datos)	Ninguno (gran obstáculo para escenarios de geolocalización)	Aislamiento limitado aunque sea difícil	Aislamiento limitado local, pero no en la nube	Aislamiento limitado local, pero no en la nube	Aislamiento limitado local, pero no en la nube	Buen aislamiento tanto local como en la nube	Aislamiento limitado tanto local como en la nube	Aislamiento limitado tanto local como en la nube	Aislamiento tanto local como en la nube
Aislamiento (delegación independiente y configuración de diferentes modelos de administración) Nota: tal como se define en el sistema de origen (HR)	No es posible	Posible	Posible	Posible	Posible	Altamente posible	Altamente posible	Altamente posible	Posible
Funcionalidades de colaboración	Excellent	Excellent	Excellent	Excellent	Excellent	Pobre	Promedio	Promedio	Pobre
Modelo de administración de TI soportado (centralizado frente a descentralizado)	Centralizado	Centralizado	Centralizado	Centralizado	Centralizado	Decentralized	Decentralized	Decentralized	Descentralizado activamente
Limitaciones	Sin aislamiento	Aislamiento limitado	Aislamiento limitado	Aislamiento limitado	Aislamiento limitado. Sin funcionalidades de reescritura	No funcionará para aplicaciones de Microsoft Online Services. Altamente dependiente de la funcionalidad de la aplicación	Requiere que las aplicaciones sean conscientes de B2B.	Requiere que las aplicaciones sean compatibles con B2B.	Requerir que las aplicaciones sean diseñadas para B2B. Incertidumbre en cómo funciona todo juntos

Detalles de la 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 costo y el esfuerzo que se tarda en mantener la solución en ejecución.
• Las funcionalidades de privacidad y datos muestran si la solución permite la compatibilidad con los límites de ubicación geográfica y 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 proporcionan mayor fidelidad del trabajo en equipo.
• El modelo de administración de TI muestra si el modelo de administración requiere centralizar o puede ser descentralizado.
• Limitaciones: cualquier problema de desafíos que merece la pena enumerar.

Árbol de decisión

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

El resto de este documento describirá cuatro escenarios A-D con varias opciones que los admiten.

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

Para esta opción, Litware puede no tener ningún sistema de identidad (por ejemplo, una pequeña empresa) o el cliente puede querer 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 proporcionan a los empleados de Litware nuevas identidades como parte de Contoso. Por ejemplo, si Alice Smith era un empleado 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 contoso HR. Esta opción desencadenaría que esos empleados reciban cuentas y el acceso adecuado a los directorios y aplicaciones de Contoso. Un usuario de Litware tendría una nueva identidad de Contoso, que podría usar para solicitar acceso a las aplicaciones de Contoso adecuadas.

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

A veces, puede que no sea posible converger los sistemas de Recursos Humanos, al menos 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 departamento de Recursos Humanos superior es el entorno que Contoso tiene actualmente, y el segundo departamento de Recursos Humanos es añadido por Litware a la infraestructura global.

El mismo escenario también sería posible utilizando Microsoft Entra Workday o SuccessFactors entrante: Contoso podría importar usuarios desde la fuente de RR. HH. de Workday de Litware junto con los empleados existentes de Contoso.

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

• Infraestructura de TI reducida, solo un sistema de identidad para administrar, sin requisitos de conectividad de red, excepto un sistema de RR. HH.
• Experiencia administrativa y de usuario final coherente

Restricciones de consolidación de toda la infraestructura de identidad

• Los datos que necesitan los empleados de Contoso que se originaron en Litware deben migrarse al entorno de Contoso.
• Todas las aplicaciones integradas de Active Directory o Microsoft Entra de Litware que se necesitarán para Contoso deben volver a configurarse en el entorno de Contoso. Esta reconfiguración puede requerir cambios en la configuración, en los grupos que utiliza 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 identificador de Microsoft Entra de Litware

Litware puede tener muchas aplicaciones basadas en Active Directory existentes en las que se basan, por lo que Contoso puede querer seguir haciendo que los empleados de Litware mantengan sus propias identidades en su AD existente. A continuación, un empleado de Litware usaría su identidad existente para su autenticación de sus recursos existentes y la autenticación de los recursos de Contoso. En este escenario, Litware no tiene identidades en la nube en Microsoft Online Services: o Litware no era un cliente de Microsoft Entra, nada de los activos en la nube de Litware se compartiría con Contoso, o Contoso migró los activos en la nube de Litware para formar parte del arrendatario de Contoso.

Opción 3: Fideicomiso forestal con el bosque adquirido

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

Resultado de la configuración de una relación de confianza en un bosque

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

Limitaciones para configurar un dominio de confianza forestal

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

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

Un cliente también puede configurar Microsoft Entra Connect para leer desde otro bosque. Esta configuración permite a los usuarios de Litware autenticarse en las aplicaciones integradas de Microsoft Entra de Contoso, pero no proporciona acceso a las aplicaciones integradas de Active Directory de Contoso 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 está en una máquina virtual IaaS de Contoso, también tendría que establecer un túnel en la red de Litware.

Resultado del uso de Microsoft Entra Connect para aprovisionar un inquilino

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

Restricciones de uso de Microsoft Entra Connect para aprovisionar un inquilino

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

Opción 5: Implementación de la sincronización en la nube de Microsoft Entra Connect en el bosque adquirido

El aprovisionamiento en la nube de Microsoft Entra Connect elimina la necesidad de conectividad de red, pero solo puede haber un enlace de Active Directory a Microsoft Entra ID para un usuario específico con sincronización en la nube. Los usuarios de Litware pueden autenticar las aplicaciones integradas con Microsoft Entra de Contoso, pero no las aplicaciones que están integradas con el Active Directory de Contoso. Esta topología no requiere ninguna conectividad TCP/IP entre Litware y los entornos locales de Contoso.

Resultado de la implementación de la sincronización en la nube de Microsoft Entra Connect en el bosque adquirido

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

Restricciones del uso de la sincronización en la nube de Microsoft Entra Connect en el bosque adquirido

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

Escenario C: si Contoso quiere mantener el identificador de Microsoft Entra de Litware

Litware puede ser un cliente de Microsoft Online Services o Azure o puede tener una o varias aplicaciones basadas en identificadores de Microsoft Entra en las que se basan. Por lo tanto, Contoso puede querer seguir haciendo que los empleados de Litware mantengan sus propias identidades para acceder a esos recursos. A continuación, un empleado de Litware usaría su identidad existente para su 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 tenants de Office 365 que serían costosos o requerirían mucho tiempo para migrar a otro tenant.
• Litware podría separarse en el futuro o ser una asociación que operará 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 en cada identificador de Microsoft Entra

Una opción es que cada ID de Microsoft Entra proporcione independientemente el inicio de sesión único y aprovisione usuarios desde su directorio en la aplicación de destino. Por ejemplo, si Contoso IT usa una aplicación como Salesforce, proporcionarían 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 la federación, requiere que las aplicaciones admitan varios proveedores de federación para la misma suscripción.
• No es posible para aplicaciones de Microsoft como Office o Azure
• Contoso no tiene visibilidad en la Microsoft Entra ID del acceso a las aplicaciones por parte de los usuarios de Litware.

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

Si Litware ha estado gestionando su propia entidad, Contoso puede leer a los usuarios de esa entidad y, a través de la API B2B, invitar a cada uno de esos usuarios al tenant de Contoso. (Este proceso de invitación masiva se puede realizar a través del conector de grafos de MIM, por ejemplo). Si Contoso también tiene aplicaciones basadas en AD que desean poner a disposición de 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, para que el proxy de la aplicación pudiera realizar KCD en nombre de una representación de un usuario de Litware en Active Directory de Contoso.

A continuación, cuando un empleado de Litware desea acceder a una aplicación de Contoso, puede hacerlo autenticándose en su propio directorio, con la asignación de acceso al tenant de recursos.

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 esos accesos en su propio entorno.

Restricciones de 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 SSO (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 adquirir la organización puede converger en una sola plataforma de RR. HH., pero seguir ejecutando 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 con la que esté afiliado el usuario. Podrían seguir usando B2B para que los usuarios autentiquen su directorio existente y tengan una GAL unificada.

Resultado de la configuración de usuarios invitados B2B a partir de una fuente común de un sistema de RR.HH.

• Los usuarios de Litware pueden autenticarse en aplicaciones de Contoso y Contoso controla ese acceso en su entorno.
• Litware y Contoso tienen una GAL unificada.
• Ningún cambio en Active Directory o Microsoft Entra ID de Litware

Restricciones en la implementación de usuarios invitados B2B desde la fuente común de un sistema de recursos humanos.

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

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

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

Opción 9: Uso de 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 los usuarios con sus direcciones de correo electrónico que pueden compartir periódicamente con Contoso.
• Proveedor de identidades que admite SAML, como PingFederate o 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 tenant para ese dominio al proveedor de identidad de Litware, y luego leería periódicamente las actualizaciones de los usuarios de Litware desde su directorio para invitar a los usuarios de Litware en Microsoft Entra ID de Contoso. Esta actualización se puede realizar con un conector de MIM Graph. Si Contoso también tiene aplicaciones basadas en Active Directory que desean poner a disposición de 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 la aplicación pudiera realizar KCD en nombre de una representación de un usuario de Litware en Active Directory de Contoso.

Resultado del uso de la federación directa B2B

• Los usuarios de Litware se autentican en el identificador de Entra de Microsoft de Contoso con su proveedor de identidades existente y acceden a las aplicaciones web locales y en la nube de Contoso,

Restricciones de uso de la federación directa B2B

• Requerir que las aplicaciones de Contoso puedan soportar el inicio de sesión único para usuarios B2B.

Pasos siguientes

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