Continuando con las configuraciones iniciadas en el post [AD Connect – Parte 1] Instalación y configuración Custom (sin iniciar la sincronización), el objetivo será desplegar la sincronización de identidades desde un Dominio de ADDS ubicado en una VM en Azure (Madsblog.local) hacia el Azure AD en un Tenant CDX ya existente (Madsblog.net).
Esta tarea la realizaremos a través de un Soft Match a través del UPN (UserPrincipalName).
¿Qué es el Match?
El proceso de Match en Active Directory, implica el “merge” de identidades en Azure AD y ADDS y realizar el cambio de Source of Authority sobre las identidades.
Tipos de Match
Existen 2 tipos de Match:
- Hard Match: a través del SourceAnchor (tambien llamada Immutable ID). Este atributo no cambia durante la vigencia de un objeto y es el indicador de que un objeto es el mismo tanto on-prem como en la nube.
- ¿Cuando se utiliza? Cuando un nuevo servidor de motor de sincronización se genera, o regenera, después de una situación de recuperación ante desastres, este atributo vincula los objetos existentes en Azure AD con los objetos locales.
- Tambien será utilizado como luego de realizar un Soft Match para el matcheo a largo plazo de los objetos. Es decir, que este es el tipo “definitivo” de match para nuestras identidades.
- El atributo SourceAnchor/ImmutableID puede ser elegido pero normalmente dejaremos que AD Connect se encarge de elegirlo. En ese caso, será el msDS-ConsistencyGuid (basado en el objectGUID).
- Una vez que se haya importado un objeto de AD local en Azure AD Connect, ya no se puede cambiar su valor para SourceAnchor. Para especificar el valor de SourceAnchor para un objeto de AD local, es necesario configurar el atributo ms-DS-ConsistencyGuid antes de importarlo a Azure AD Connect.
2. Soft Match: a través de proxyAddress (“SMTP:…”) o UserPrincipalName (en ese orden).
¿Cuando se utiliza? Cuando tenemos un tenant de Azure AD con identidades y al mismo tiempo tenemos un ADDS on-prem con las mismas identidades pero no están sincronizadas a través de AD Connect.
Consideraciones importantes del Soft Match
- SMTP vs UPN Matching
El Soft Match está habilitado por defecto en AD Connect desde el 30 de marzo de 2016, es decir, que para que funcione en las versiones utilizadas hoy en día no es necesario configurar nada en la herramienta.
Se realiza en orden 1) AD Connect intentará realizar el SMTP (proxyAddresses), en caso de que NINGUN usuario tenga matcheo a través de este atributo la herramientá procederá a realizar el soft mach a través de 2) UPN (UserPrincipalName). Para poder realizar el matcheo a través del UPN debemos asegurarnos que no exista ninguna matcheo de SMTP en las identidades a sincronizar.
El atributo a utilizar para el soft match debe ser correctamente planificado segun el escenario en de la organización en el que estemos trabajando.
2. Overwrite de Atributos
Es MUY IMPORTANTE, entender que al realizar un soft match estaremos cambiando el Source of Authority de las identidades. Esto quiere decir que: cuando el merge ocurra TODOS los atributos de las identidades on-prem serán SOBREESCRITOS sobre los usuarios cloud based. Ademas dichos usuarios cloud pasaran a figurar en nube como usuarios “on-prem Synced”.
En este sentido, debemos preparar y revisar todos los atributos de nuestras identidades y asegurarnos que nose perderá ningun dato de los usuarios a sincronizar.
De cara al usuario, es MUY IMPORTANTE notificarlos sobre el cambio a realizar y indicarles que a partir de X fecha deberán comenzar a utilizar la contraseña de su usuario on-prem para logearse tanto a los recursos locales como en nube.
En caso de tener atributos en nube que deseamos mantener, debemos planificar una forma de popularlos on-prem.
Caso practico
Escenario
En este caso, tenemos el siguiente escenario:
- Tenant de Azure AD con identidades full cloud. Sin sincronización de identidades a través de AD Connect.
- Bosque de ADDS con sigle domain con identidades de los usuarios on-prem.
- En este escenario, los usuarios tienen identidades duplicadas: utilizan 2 usuarios distintos, uno para ingresar a Microsoft 365 y consumir los usuarios de la nube. Y otra identidad distinta (con otro usuario y contraseña) para consumir los recursos on-prem a través de ADDS.
Nuestro objetivo al preparnos para realizar el match de identidades será “mergear” (fucionar) estas identidades para que, los usuarios finales, dispongan de una sola (1 usuario y contraseña unica) para consumir ambos recursos: on-prem y cloud (M365) y cambiar el Source of Authority a ADDS.
Comenzamos con las pruebas:
En nuestra nota de blog anterior realizamos la instalación de Azure AD Connect en nuestro bosque de ADDS.
- En este escenario, simularemos el Soft Match a través de UPN Address ya que en nuestra organizacion on-prem no tenemos Exchange Server.
- Nos conectamos con el modulo de ExchangeOnline de PowerShell y verificamos el atributo UserPrincipalName de nuestros usuarios cloud.
Luego verificaremos lo mismo en nuestros usuarios on-prem en ADDS
- Ahora configuraremos el filtrado de Dominios y OUs en nuestro AD Connect. Para este caso, solo sincronizaremos una OU destinada a alojar los usuarios sincronizados “AD Connect Sync Test”.
- En casos practicos reales puede ser necesario realizar este estadio de “Prueba piloto” para asegurarnos que la sync funcione correctamente antes de realizar el matcheo para la totalidad de los usuarios.
- Una vez que finalizamos nos aseguramos que el check “Start the synchronization process when configuration completes” este tildado
- Una vez activa la sincronización podremos mover el usuario piloto para realizar la prueba. En este caso, seleccionamos al usuario JoniS
- Realizamos un Delta de la sincronización.
Verificamos a través del Syncronization Service verificamos la sincronización del usuario.
- Verificamos en Cloud que el usuario fue sincronizado: no existen identidades duplicadas y el atributo “on-premises Sync enable” esta en “Yes”.
- Realizamos una nueva prueba con otros usuarios y verificamos que se realiza correctamente:
Leave a Reply