Descripción de usuarios y contactos en Azure Active Directory Sync
Actualizado: 22 de julio de 2015
Importante
Este tema se archivará pronto.
Hay un nuevo producto denominado "Azure Active Directory Connect" que reemplaza AADSync y DirSync.
Azure AD Connect incorpora los componentes y la funcionalidad publicados anteriormente como Dirsync y AAD Sync.
En algún momento del futuro, finalizará la compatibilidad con Dirsync y AAD Sync.
Estas herramientas ya no se actualizan individualmente con mejoras de características y todas las mejoras futuras se incluirán en las actualizaciones de Azure AD Connect.
Hay varias razones diferentes por las que tendría varios bosques de Active Directory y hay varias topologías de implementación diferentes. Los modelos comunes incluyen una implementación de recursos de cuenta y bosques sincronizados con GAL después de una fusión & adquisición. Pero incluso si hay modelos puros, los modelos híbridos también son comunes. La configuración predeterminada en AADSync no supone ningún modelo determinado, pero dependiendo de cómo se seleccionó la coincidencia de usuarios en la guía de instalación, se pueden observar distintos comportamientos.
En este documento veremos cómo se comporta la configuración predeterminada en determinadas topologías. Pasaremos por la configuración y el Editor de reglas de sincronización se puede usar para examinar la configuración.
Hay algunas reglas generales que supone la configuración:
Independientemente del orden en que se lean los directorios activos de origen, el resultado final siempre debe ser el mismo.
Una cuenta activa siempre contribuirá a la información de inicio de sesión, incluido userPrincipalName y sourceAnchor.
Una cuenta deshabilitada contribuirá a userPrincipalName y sourceAnchor, a menos que sea un buzón vinculado.
Nunca se usará una cuenta con un buzón vinculado para userPrincipalName y sourceAnchor. Se supone que se encontrará una cuenta activa más adelante.
Un objeto de contacto se puede aprovisionar en Azure AD como contacto o como usuario. Realmente no sabe hasta que se hayan procesado todos los bosques de Active Directory de origen.
Contactos
Los contactos que representan a un usuario de un bosque diferente son comunes después de una fusión & adquisición en la que una solución GALSync está puenteando dos o más bosques de Exchange. El objeto de contacto siempre se une desde el espacio del conector al metaverso mediante el atributo mail. Si ya hay un objeto de contacto o un objeto de usuario con la misma dirección de correo, los objetos se unen. Esto se configura en la regla In from AD – Contact Join. También hay una regla denominada in from AD – Contact Common with an attribute flow to the metaverse attribute sourceObjectType with the constant Contact. Esta regla tiene prioridad muy baja, por lo que si algún objeto de usuario está unido al mismo objeto de metaverso, la regla In from AD – User Common contribuirá al valor User a este atributo. Con esta regla, este atributo tendrá el valor Contact si no se ha unido ningún usuario y el valor Usuario si se ha encontrado al menos un usuario.
Para aprovisionar un objeto en AAD, la regla de salida Out to AAD – Contact Join creará un objeto contact si el atributo metaverso sourceObjectType está establecido en Contact. Si este atributo se establece en Usuario, la regla Out to AAD – User Join creará un objeto de usuario en su lugar. Es posible que un objeto se promueva de Contact a User cuando se importan y sincronizan más directorios activos de origen.
Por ejemplo, en una topología GALSync, buscaremos objetos de contacto para todos los usuarios del segundo bosque cuando importemos el primer bosque. Esto almacenará provisionalmente nuevos objetos de contacto en el conector de AAD. Cuando más adelante importemos y sincronicemos el segundo bosque, buscaremos los usuarios reales y los uniremos a los objetos de metaverso existentes. A continuación, eliminaremos el objeto de contacto en AAD y crearemos un nuevo objeto de usuario en su lugar.
Si tiene una topología en la que los usuarios y se representan como contactos, asegúrese de seleccionar para que coincida con los usuarios en el atributo de correo en la guía de instalación. Si selecciona otra opción, tendrá una configuración dependiente del pedido. Los objetos de contacto siempre se unirán en el atributo mail, pero los objetos de usuario solo se unirán al atributo mail si esta opción se seleccionó en la guía de instalación. A continuación, podría terminar con dos objetos diferentes en el metaverso con el mismo atributo de correo si el objeto de contacto se importó antes del objeto de usuario. Durante la exportación a Azure AD, se producirá un error. Este comportamiento es por diseño y indicaría datos incorrectos o que la topología no se identificó correctamente durante la instalación.
Cuentas deshabilitadas
Las cuentas deshabilitadas también se sincronizan con Azure AD. Las cuentas deshabilitadas son habituales para representar recursos en Exchange, por ejemplo, salas de conferencias. La excepción es usuarios con un buzón vinculado; como se mencionó anteriormente, estos nunca aprovisionarán una cuenta en Azure AD.
La suposición es que si se encuentra una cuenta de usuario deshabilitada, no encontraremos otra cuenta activa más adelante y el objeto se aprovisiona en Azure AD con userPrincipalName y sourceAnchor encontrados. En caso de que otra cuenta activa se una al mismo objeto de metaverso, se usará su userPrincipalName y sourceAnchor.
Chaning sourceAnchor
Cuando se exporta un objeto a Azure AD, ya no se permite cambiar sourceAnchor. Cuando el objeto se ha exportado el atributo metaverso cloudSourceAnchor se establece con el valor sourceAnchor aceptado por Azure AD. Si sourceAnchor se cambia y no coincide con cloudSourceAnchor, la regla Out to AAD – User Join producirá el error atributo sourceAnchor ha cambiado. En este caso, la configuración o los datos deben corregirse para que el mismo sourceAnchor esté presente de nuevo en el metaverso antes de que el objeto se pueda sincronizar de nuevo.