No se puede completar la sincronización de objetos utilizando la dirección SMTP (soft-match) o usando el ImmutableID (hard match) con Azure AD Connect

Por Adrian Kruss

Utilizar la herramienta Azure ADConnect para tratar de enlazar un objeto local con un existente en Office 365 puede causar problemas y generar errores al tratar de realizar el procedimiento para relacionarlos usando cualquiera de los métodos disponibles - La dirección SMTP o el ImmutableID

Las instrucciones para realizar el enlace por SMTP se puede encontrar en este enlace. Resumiendo, los pasos, luego de que la dirección SMTP primaria del objeto On-premises coincida con el objeto en la nube, el objeto de Office 365 quedará relacionado con el objeto del Directorio Activo por la dirección SMTP.

La otra alternativa para realizar este enlace, es convertir el atributo ObjectGUID On-premises a base 64 y estamparlo en Windows Azure Active Directory como se indica en este artículo

Al revisar los logs de sincronización ya sea desde la dirección de correo del contacto técnico asociado a nuestro tenant de Office 365 o desde el log de aplicación de la estación de trabajo de Windows Azure AD Connect, podremos ver si existe algún error en la sincronización. Los errores más comunes se pueden encontrar en este enlace, y sus respectivas soluciones en este. Hay un error que es poco frecuente y es el siguiente:

No se puede actualizar este objeto porque no se permite la actualización de los siguientes atributos asociados a este objeto por el directorio local: [accountEnabled,commonName,countryCode,displayName,dnsDomainName,givenName,lastPasswordChangeTimestamp,mail,netBiosName,onPremiseSecurityIdentifier,onPremisesSamAccountName,proxyAddresses,surname,userPrincipalName]. Póngase en contacto con el soporte técnico.

Esto se debe a que la función de User Writeback está habilitada en el tenant de Office 365 Esto es causado porque el origen de autoridad (SOA) no fue correctamente transferido al directorio local. Podemos ver si este es el caso desde Azure AD Connect localizado en el directorio "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe" y seleccionando la opción de “View current configuration” debajo de Tasks

Si muestra disabled podemos tratar de forzar el cambio del SOA al deshabilitar la opción de sincronización de directorios en el portal de Office 365 (https://technet.microsoft.com/es-es/library/dn635310.aspx):

1. Inicie sesión en la página del portal de Office 365.

2. Haga clic en Usuarios. Junto a la sincronización de Active Directory, haga clic en Configurar y, después, haga clic en Desactivar.

3. O usando PowerShell (https://msdn.microsoft.com/es-es/library/dn194097.aspx):

Set-MsolDirSyncEnabled -EnableDirSync $false

4. Dejar que esta se desactive completamente puede demorar hasta 72 horas y luego volver a activar DirSync vez más (esto también puede tomar otras 72 horas) Una vez activada la sincronización de directorios, podremos forzar una replicación y ver si el problema dejó de suceder. Si sigue fallando con el mismo error significa que el SOA no se transfirió correctamente y la función de User Writeback tiene que ser desactivada por el departamento de soporte de Microsoft. Si este es el caso por favor contacte al equipo de soporte entregando el mensaje de error (que sea el mismo reportado en este documento) y solicite que se deshabilite la opción de User Writeback en el tenant de Office 365.

 

Cuando un objeto se relaciona correctamente podrá visualizarlo utilizando la herramienta MIISClient, la cual se encuentra en C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe. Una vez abierta hay que seleccionar la pestaña de Metaverse Search y hacer una búsqueda por el atributo userPrincipalName del usuario con el cual estamos trabajando (se puede buscar por cualquier valor como por ejemplo la dirección SMTP pero a veces es más fácil utilizando el UPN) y esto debería devolver el usuario:

De ahí podemos ver las propiedades (Properties) y navegar a la pestaña de Connectors:

 

 

Lo cual muestra que el objeto tiene un conector local (jeltek.us en mi caso) y otro conector hacia Office 365 (akrusse.onmicrosoft.com – AAD en mi caso) y este fue relacionado usando el método SyncRule. Esto significa que el objeto fue ligado correctamente y el SOA le pertenece al directorio local.

Comments

• Anonymous
  March 09, 2016
  Excelente información, gracias por compartir información importante