Topologías de Azure AD Connect
En este artículo se describen diversas topologías locales y de Azure Active Directory (Azure AD) que usan Azure AD Connect Sync como solución de integración de claves. En este artículo se describen tanto las configuraciones admitidas como las no admitidas.
Esta es la leyenda de las imágenes del artículo:
Descripción | Símbolo |
---|---|
Bosque local de Active Directory | ![]() |
Instancia local de Active Directory con importación filtrada | ![]() |
Servidor de Azure AD Connect Sync | ![]() |
"Modo de ensayo" del servidor de Azure AD Connect Sync | ![]() |
GALSync con Forefront Identity Manager (FIM) 2010 o Microsoft Identity Manager (MIM) 2016 | ![]() |
Servidor de Azure AD Connect Sync, información detallada | ![]() |
Azure AD | ![]() |
Escenario no admitido | ![]() |
Importante
Microsoft no admite la modificación ni el funcionamiento de la sincronización de Azure AD Connect con configuraciones o acciones distintas a estas que se documentan formalmente. Cualquiera de estas configuraciones o acciones pueden provocar un estado incoherente o incompatible de sincronización de Azure AD Connect. Como resultado, Microsoft no ofrece soporte técnico para estas implementaciones.
Un único bosque, un único inquilino de Azure AD
La topología más común es un único bosque local, con uno o varios dominios y un único inquilino de Azure AD. Para la autenticación de Azure AD se utiliza la sincronización de hash de contraseñas. La instalación rápida de Azure AD Connect solo es compatible con esta topología.
Bosque único, varios servidores de sincronización con un inquilino de Azure AD
No se pueden tener varios servidores de Azure AD Connect Sync conectados al mismo inquilino de Azure AD (excepto si se trata de un servidor de ensayo). No se admite aunque los servidores estén configurados para sincronizarse con un conjunto de objetos que se excluyen mutuamente. Quizás haya pensado en esta topología si no puede acceder a todos los dominios del bosque desde un único servidor, o si desea distribuir la carga entre varios servidores. (No se producen errores cuando se configura un nuevo servidor de sincronización de Azure AD para un nuevo bosque de Azure AD y un nuevo dominio secundario verificado).
Varios bosques, un único inquilino de Azure AD
Muchas organizaciones tienen entornos con varios bosques de Active Directory locales. Existen varias razones para tener más de un bosque de Active Directory local. Los ejemplos más habituales son los diseños con bosques de cuenta-recurso o los que resultan de una fusión o adquisición.
Cuando hay varios bosques, todos los bosques deben ser accesibles mediante un único servidor de Azure AD Connect Sync. El servidor debe estar unido a un dominio. Si es necesario para llegar a todos los bosques, puede colocar el servidor en una red perimetral (también conocida como DMZ y subred filtrada).
El asistente para la instalación de Azure AD Connect ofrece varias opciones para consolidar los usuarios representados en varios bosques. El objetivo es que un usuario esté representado solo una vez en Azure AD. Hay algunas topologías habituales que puede configurar en la ruta de acceso de instalación personalizada del Asistente para instalación. En la página Identificación de forma exclusiva de usuarios, seleccione la opción correspondiente que representa su topología. La consolidación solo se configura para los usuarios. Los grupos duplicados no se consolidan con la configuración predeterminada.
Las topologías comunes se describen en las secciones acerca de topologías independientes, malla completa y la topología de cuenta-recurso.
En la configuración predeterminada de Azure AD Connect Sync se supone que:
- Los usuarios tienen solo una cuenta habilitada y el bosque donde se encuentra esta cuenta se usa para la autenticación del usuario. Esta suposición es aplicable para la sincronización de hash de contraseñas, la autenticación de paso a través y la federación. Los valores UserPrincipalName y sourceAnchor/immutableID proceden de este bosque.
- Cada usuario tiene un solo buzón de correo.
- El bosque que aloja el buzón de un usuario tiene la mejor calidad de datos para los atributos visibles en la lista global de direcciones (GAL) de Exchange. Si no hay ningún buzón para el usuario, se puede usar cualquiera de los bosques para aportar estos valores de atributo.
- Si tiene un buzón vinculado, también hay otra cuenta en otro bosque que se usa para el inicio de sesión.
Si su entorno no se ajusta a estos supuestos, ocurrirá lo siguiente:
- Si tiene más de una cuenta activa o más de un buzón, el motor de sincronización elegirá uno y pasará por alto los demás.
- No se exporta un buzón vinculado sin ninguna otra cuenta activa a Azure AD. La cuenta de usuario no se representa como miembro de ningún grupo. Un buzón vinculado en DirSync siempre se representa como un buzón normal. Este cambio es un comportamiento diferente intencionado para admitir mejor los escenarios de varios bosques.
Para más información, consulte la descripción de la configuración predeterminada.
Varios bosques, varios servidores de sincronización con un inquilino de Azure AD
No se puede tener más de un servidor de Azure AD Connect Sync conectado a un único inquilino de Azure AD. La excepción es el uso de un servidor provisional.
Esta topología difiere de la siguiente en que no se admiten varios servidores de sincronización conectados a una única instancia del inquilino de Azure AD. (Aunque eso no es compatible, sigue funcionando).
Varios bosques, un solo servidor de sincronización, los usuarios se representan en un único directorio.
En este entorno, todos los bosques locales se tratan como entidades independientes. Ningún usuario está presente en ningún otro bosque. Cada bosque tiene su propia organización de Exchange y no se produce la sincronización de las GAL entre los bosques. Esta topología podría darse después de una fusión o adquisición, o en una organización donde cada unidad de negocio funciona de forma independiente. En Azure AD, estos bosques estarán en la misma organización y aparecerán con una GAL unificada. En la imagen anterior, todos los objetos de cada bosque se representan una vez en el metaverso y se agregan al inquilino de Azure AD de destino.
Varios bosques: coincidencia de usuarios
Algo que es común a todos estos escenarios es que los grupos de distribución y de seguridad pueden contener una combinación de usuarios, contactos y entidades de seguridad externas (FSP). Las FSP se usan en Active Directory Domain Services para representar a miembros de otros bosques en un grupo de seguridad. Todas las FSP se resuelven en el objeto real en Azure AD.
Varios bosques: malla completa con GALSync opcional
Una topología de malla completa permite encontrar a los usuarios y recursos de cualquier bosque. Normalmente, hay una relación de confianza bidireccional entre los bosques.
Si Exchange está presente en más de un bosque, podría haber una solución GALSync local (opcional). Cada usuario se representaría como un contacto en todos los demás bosques. GALSync normalmente se implementa mediante FIM 2010 o MIM 2016. No se puede usar Azure AD Connect en GALSync local.
En este escenario, los objetos de identidad se unen mediante el atributo mail. Un usuario con un buzón en un bosque se une a los contactos de los demás bosques.
Varios bosques: bosque de cuenta-recurso
En una topología de bosque de cuenta-recurso, tiene uno o más bosques de cuentas con cuentas de usuario activas. También tiene uno o más bosques de recursos con las cuentas deshabilitadas.
En este escenario uno (o más) bosques de recursos confían en todos los bosques de cuentas. Normalmente, el bosque de recursos tiene un esquema de Active Directory extendido con Exchange y Lync. Todos los servicios de Exchange y Lync, así como otros servicios compartidos, se encuentran en este bosque. Los usuarios tienen una cuenta de usuario deshabilitada en este bosque y el buzón está vinculado al bosque de cuenta.
Consideraciones sobre la topología y Microsoft 365
Algunas cargas de trabajo de Microsoft 365 presentan ciertas restricciones en cuanto a las topologías compatibles:
Carga de trabajo | Restricciones |
---|---|
Exchange Online | Para más información sobre las topologías híbridas que se admiten en Exchange Online, consulte Implementaciones híbridas con varios bosques de Active Directory. |
Skype Empresarial | Cuando se usan varios bosques locales, solo se admite la topología de bosque de cuenta-recurso. Para más información, consulte los requisitos de entorno de Skype para Business Server 2015. |
Si su organización es más grande, debería considerar la posibilidad de utilizar la característica Microsoft 365 PreferredDataLocation. Esta característica le permite definir en qué región del centro de datos se encuentran los recursos del usuario.
Servidor provisional
Azure AD Connect admite la instalación de un segundo servidor en modo de ensayo. Un servidor en este modo puede leer los datos de todos los directorios conectados, pero no puede escribir nada en ellos. Utiliza el ciclo de sincronización normal y, por lo tanto, tiene una copia actualizada de los datos de identidades.
En caso de error del servidor principal, puede conmutar por error al servidor de ensayo. Puede hacerlo en el Asistente de Azure AD Connect. Este segundo servidor se puede ubicar preferiblemente en un centro de datos diferente porque no comparte ninguna infraestructura con el servidor principal. Cualquier cambio de configuración realizado en el servidor principal debe copiarlo manualmente en el segundo servidor.
Un servidor de ensayo se puede usar también para probar una nueva configuración personalizada y el efecto que tendrá en los datos. En este sentido, puede obtener una vista previa de los cambios y ajustar la configuración. Cuando esté satisfecho con la nueva configuración, puede hacer del servidor de ensayo el servidor activo y establecer el antiguo servidor activo en modo de ensayo.
Este método también se puede usar para reemplazar el servidor de sincronización activo. Prepare el nuevo servidor y establézcalo en modo de ensayo. Asegúrese de que está en buen estado, deshabilite el modo de ensayo (para activar el servidor) y apague el servidor actualmente activo.
Es posible tener más de un servidor provisional si desea tener varias copias de seguridad en distintos centros de datos.
Varios inquilinos de Azure AD
Recomendamos tener un único inquilino en Azure AD para una organización. Antes de planear el uso de varios inquilinos de Azure AD, vea el artículo Administración de unidades administrativas en Azure AD. Se ocupa de los escenarios comunes donde puede usar un solo inquilino.
Sincronización de objetos de AD con varios inquilinos de Azure AD
Esta topología implementa los siguientes casos de uso:
- AADConnect puede sincronizar los usuarios, grupos y contactos desde una única instancia de Active Directory a varios inquilinos de Azure AD. Estos inquilinos pueden estar en diferentes entornos de Azure, como el entorno de Azure China o el entorno Azure Government, pero también podrían estar en el mismo entorno de Azure, como dos inquilinos que están ambos en Azure Commercial. Para más información sobre las opciones, consulte [Planeamiento de la identidad para aplicaciones de Azure Government] (/azure/azure-government/documentation-government-plan-identity).
- El mismo delimitador de origen se puede usar para un único objeto en inquilinos independientes (pero no para varios objetos del mismo inquilino). (El dominio verificado no puede ser el mismo en dos inquilinos. Se necesitan más detalles para permitir que el mismo objeto tenga dos UPN).
- Tendrá que implementar un servidor de AADConnect para cada inquilino de Azure AD con el que quiera realizar la sincronización: un servidor de AADConnect no se puede sincronizar con más de un inquilino de Azure AD.
- Se admite tener otros ámbitos de sincronización y otras reglas de sincronización para distintos inquilinos.
- Solo se puede establecer una sincronización de inquilinos de Azure AD para reescribir en Active Directory para el mismo objeto. Esto incluye la reescritura de dispositivos y grupos, así como las configuraciones híbridas de Exchange; estas características solo pueden configurarse en un inquilino. La única excepción aquí es la escritura diferida de contraseñas; consulte a continuación.
- Se admite para configurar la sincronización de hash de contraseñas de Active Directory a varios inquilinos de Azure AD para el mismo objeto de usuario. Si la sincronización de hash de contraseñas está habilitada para un inquilino, también se puede habilitar la escritura diferida de contraseñas y esto se puede hacer en varios inquilinos: si se cambia la contraseña en un inquilino, la reescritura diferida de contraseñas la actualizará en Active Directory, y la sincronización de hash de contraseñas actualizará la contraseña en los demás inquilinos.
- No se admite agregar y comprobar el mismo nombre de dominio personalizado en más de un inquilino de Azure AD, incluso si estos inquilinos se encuentran en entornos de Azure diferentes.
- No se admite la configuración de experiencias híbridas que usan la configuración de nivel de bosque en AD, como SSO de conexión directa y Unión a Azure AD híbrido (enfoque que no sea de destino), con más de un inquilino. Si lo hace, sobrescribiría la configuración del otro inquilino y quedaría inutilizable. Puede encontrar información adicional en Planeamiento de la implementación de la unión a Azure Active Directory híbrido.
- Puede sincronizar objetos de dispositivo con más de un inquilino, pero un dispositivo puede unirse a Azure AD híbrido a un solo inquilino.
- Cada instancia de Azure AD Connect debe ejecutarse en una máquina unida a un dominio.
Nota:
La sincronización de la lista global de direcciones (GalSync) no se realiza automáticamente en esta topología y requiere otra implementación de MIM personalizada para garantizar que cada inquilino tiene una lista global de direcciones (GAL) completa en Exchange Online y Skype Empresarial Online.
GALSync mediante escritura diferida
GALSync con servidor de sincronización local
Puede usar FIM 2010 o MIM 2016 local para sincronizar los usuarios (mediante GALSync) entre dos organizaciones de Exchange. Los usuarios de una organización se mostrarán como usuarios o contactos externos en la otra organización. Estas instancias de Active Directory locales se pueden sincronizar después con sus propios inquilinos de Azure AD.
Uso de clientes no autorizados para acceder al back-end de Azure AD Connect
El servidor de Azure Active Directory Connect se comunica con Azure Active Directory a través del back-end de Azure Active Directory Connect. El único software que se puede usar para la comunicación con este back-end es Azure Active Directory Connect. No se admite la comunicación con el back-end de Azure Active Directory Connect mediante otro tipo de software o método.
Pasos siguientes
Para más información sobre cómo instalar Azure AD Connect en estos escenarios, consulte Instalación personalizada de Azure AD Connect.
Obtenga más información sobre la configuración de la Sincronización de Azure AD Connect .
Obtenga más información sobre la integración de las identidades locales con Azure Active Directory.