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. Idealmente, una organización con un único origen de RR. HH., un único bosque de Active Directory y un único inquilino de Azure Active Directory (Azure AD), todos integrados con las mismas personas en cada uno, es la que tendrá la mejor experiencia de identidades para Microsoft Online Services. Sin embargo, en la práctica, es posible que un cliente empresarial no siempre esté en una situación en la que esto 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 tenga varios RR. HH., varios AD o varios inquilinos de Azure AD debe decidir si combinar en menos instancias de cada uno o mantenerlas en paralelo.

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

Escenarios presentes en las identidades de varias nubes y 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 de empresa o de marca y, normalmente, un cambio de nombre de dominio de correo electrónico.
  • Consolidación de inquilinos de Azure AD o Office 365: es posible que las empresas con más de un inquilino de Office 365 quieran combinar 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

En este artículo se describen distintos entornos de identidad de varias nubes u organizaciones, incluidos los escenarios de M&A que Microsoft admite hoy en día, y se describe cómo una organización puede seleccionar las tecnologías adecuadas en función de cómo enfoque 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 entorno de Azure AD de un único inquilino para sus aplicaciones, que se ejecutan según lo previsto. Los usuarios se incorporan desde su sistema de RR. HH. a Active Directory y se proyectan en Azure AD y desde allí en 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).

single instance of each component

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, existen contrapartidas en cuanto a la cantidad de Active Directory Domain Services o Azure AD 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 Azure AD de Litware (si tienen uno)
  • Escenario C: usar el entorno de Azure AD de Litware.
  • Escenario D: usar la infraestructura de identidades de Litware que no es de Microsoft (si Litware no usa Active Directory ni Azure AD)

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 & inquilino A2: RR. HH. independiente, IAM único e inquilino B3: confianza del bosque de Active Directory, Azure AD Connect único B4: Azure AD Conectar su Active Directory al inquilino único B5: Azure AD Connect Cloud Sync 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.

decision tree.

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

Escenario A: si Contoso no quiere confiar en la infraestructura de identidades 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.

Retain Litware HR system

El mismo escenario también sería posible mediante instancias de Azure AD Workday o SuccessFactors entrantes: Contoso podría traer usuarios del origen de RR. HH. de Workday de Litware junto con los empleados de Contoso existentes.

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 en Active Directory o Azure AD que sea necesarias para Contoso deberá 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 Azure AD 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: o bien Litware no era un cliente de Azure AD, ningún recurso en la nube de Litware se compartiría con Contoso o bien Contoso migró los recursos en la nube de Litware para formar 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. También Azure AD Connect puede leer desde el bosque de Active Directory de Litware para que los usuarios de Litware se autentiquen con las aplicaciones de Contoso integradas en Azure AD. 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).

forest trust with single tenant

Resultado de la configuración de una confianza de bosque

  • Todos los empleados de Litware pueden autenticar las aplicaciones de Contoso integradas en Active Directory o Azure AD, 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 Azure AD Conectar al bosque adquirido sin confianza de bosque

Un cliente también puede configurar Azure AD Conectar para leer desde otro bosque. Esta configuración permite que los usuarios de Litware se autentiquen en las aplicaciones de Contoso integradas en Azure AD, 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 Azure AD Conectar y los controladores de dominio de Litware. Por ejemplo, si Azure AD 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.

Azure AD Connect two forests

Resultado del uso de Azure AD Connect para aprovisionar un inquilino

  • Todos los empleados de Litware pueden autenticar las aplicaciones de Contoso integradas en Azure AD.

Restricciones del uso de Azure AD Connect para aprovisionar un inquilino

  • Requiere conectividad TCP/IP entre los dominios de Azure AD 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 Azure AD Connect Cloud Sync en el bosque adquirido

El aprovisionamiento en la nube de Azure AD Connect elimina el requisito de conectividad de red, pero solo puede tener un Active Directory para Azure AD para un usuario determinado con sincronización en la nube. Los usuarios de Litware pueden autenticar las aplicaciones de Contoso integradas en Azure AD, pero no 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.

Deploy Azure AD Connect cloud sync in the acquired forest

Resultado de implementar Azure AD Connect Cloud Sync en el bosque adquirido

  • Todos los empleados de Litware pueden autenticar las aplicaciones de Contoso integradas en Azure AD.

Restricciones de usar Azure AD 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 Azure AD de Litware

Litware puede ser un cliente de Microsoft Online Services o Azure o puede tener una o varias aplicaciones basadas en Azure AD 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 Azure AD

Una opción es que cada entorno de Azure AD proporcione de forma independiente el inicio de sesión único y que aprovisione usuarios desde 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.

parallel provisioning for apps

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 Azure AD del acceso a la aplicación 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 Azure AD, de modo que el proxy de aplicación pudiera realizar KCD en nombre de una 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.

configure B2B accounts for user from the other tenant

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, dependiendo 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.

Configure B2B users but with a common HR system feed

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 ni Azure AD 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 al proveedor de identidades de Litware y, a continuación, leería periódicamente las actualizaciones de los usuarios de Litware desde su directorio para invitar a los usuarios de Litware al entorno de Azure AD 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 Azure AD, de modo que el proxy de aplicación pudiera realizar KCD en nombre de una representación de un usuario de Litware en el entorno de Active Directory de Contoso.

Use B2B direct federation

Resultado del uso de la federación directa B2B

  • Los usuarios de Litware se autentican en el entorno de Azure AD de Contoso con su proveedor de identidades existente y acceden a las aplicaciones web locales y en la nube de Contoso.

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