Utilizzare l’attributo mS-DS-ConsistencyGuid per risolvere i problemi di sincronizzazione ad Office 365/AAD
Avevamo affrontato l’argomento, anche nel seguente post di qualche anno fa:
Come mappare utenti OnPremise Active Directory a utenti Office365 esistenti.
Oggi parliamo di una modalità molto interessante per effettuare il troubleshoot delle problematiche di sincronizzazione ad Office 365 (Azure Active Directory). Il metodo consiste nell’utilizzare l’attributo “mS-DS-ConsistencyGuid”.
Come molti di voi sapranno, storicamente, AD Connect utilizzava “ObjectGUID” come attributo sourceAnchor per sincronizzare gli oggetti con il cloud.
A partire dalla versione 1.1.524.0, possiamo invece utilizzare mS-DS-ConsistencyGuid.
Quale è il bello di questo attributo? A differenza dell’ObjectGuid, quest’attributo è scrivibile.
Questo significa che possiamo manipolare gli oggetti sincronizzati in maniera più semplice. Recentemente, i clienti hanno iniziato a creare ticket relativamente a questa tematica. Siamo in grado di risolvere questo problema senza causare interruzioni di servizio agli utenti finali, gli scenari possono variare da:
– Ho un ambiente multi-foresta sincronizzato e l’utente è stato migrato tra queste;
– Un utente è stato eliminato dall’Active Directory per errore mentre AD Connect non lavorava e l’abbiamo re-installato;
– Ho perso l’unico DC nella mia foresta, perciò ho dovuto ri-costruire completamente il mio AD foresta.
Vi consigliamo di creare SEMPRE due domain controller!!
Prerequisiti: dovrete avere accesso ad AAD Powershell connesso al vostro tenant (con i permessi di global admin), all’AD Connect Server e al Domain Controller..
Scenario 1
Un utente viene eliminato per errore dall’Active Directory mentre l’AD Connect non stava funzionando. Viene creato un nuovo account poiché non è possibile recuperare quello vecchio e, successivamente, viene re-installato l’AD Connect ma i cambiamento apportati sull’Active Directory non sono sincronizzati con l’account cloud.
NOTE: Ci sono poi molti altri scenari possibili, questo è quello che abbiamo portato come esempio.
Capire il problema
– Poiché AD Connect era giù, la rimozione dell’utente non è stata rilevata da AD Connect.
– Di conseguenza, questa eliminazione non è avvenuta in AAD. Questo significa che l’account è orfano in AAD.
– Il nuovo account ha un nuovo attributo ImmutableID (originato da ObjectGUID) on-prem. Quest’attributo non può essere modificato nel cloud per gli account sincronizzati.
Per riprodurre questo comportamento, abbiamo disinstallato AD Connect, eliminato l’account utente dall’Active Directory e re-installato l’AD Connect.
Per avere conferma del fatto che il problema sia con il differente ImmutableID, potete seguire i seguenti passaggi:
1. Recuperare l’attributo ImmutableID degli account nel cloud affetti dal problema.
Get-MsolUser -UserPrincipalName john@cesarhara.com | select ImmutableID
ImmutableID: kKfL2wwI+0W+rN0kfeaboA==
2. Effettuare una ricerca metaverso per il nuovo utente creato in AD (o convertire l’ObjectGUID preso dall’AD in formato base64 con lo strumento GUID2ImmutableID) per confermare il nuovo ImmutableID.
3. Se avete la resilienza degli attributi, AD Connect non mostrerà alcun errore. Potete recarvi sul Portale o su PowerShell per identificare l’errore.
In sostanza, qualsiasi cambiamento apportiate su quest’oggetto on-premise, non si rifletterà nel cloud.
Passaggi da risolvere
1. Confermare che l’attributo utilizzato dall’AD Connect come “SourceAnchor” sia il “mS-DS-ConsistencyGuid”. Semplicemente, eseguite l’AD e scegliete la voce “View Current Configuration”.
2. Assicuratevi che gli attributi “UPN” e “ProxyAddresses” siano gli stessi su Office 365 e sugli account di AD: potete scaricare il report degli utenti nel Portale di Amministrazione o utilizzare PowerShell per estrarre queste informazioni. Questi attributi sono essenziali, se conoscete altri mancanti, aggiungetevi all’account nel vostro AD locale.
3. Prendete il valore ImmutableID dell’account cloud/originale.
Qui sotto il comando PowerShell:
Get-MsolUser -UserPrincipalName john@cesarhara.com | select ImmutableID
ImmutableID: kKfL2wwI+0W+rN0kfeaboA==
4. Dobbiamo convertire il valore dell’“ImmutableID” in formato HEX per poterlo aggiungere all’account on-prem:
[system.convert]::FromBase64String(“kKfL2wwI+0W+rN0kfeaboA==”) | %{$a += [System.String]::Format(“{0:X}”, $_) + ” “};$result = $null;$result = $a.trimend();$result
L’output è:
90 A7 CB DB C 8 FB 45 BE AC DD 24 7D E6 9B A0
5. Ora torniamo al server AD Connect ed interrompiamo il task schedulato (è una buona tecnica poichè impedisce che la sincronizzazione dei task continui mentre stiamo effettuando il troubleshooting di:
Set-ADSyncScheduler -SyncCycleEnabled $false
6. Spostiamo l’account ad OU non sincronizzato ed eseguiamo un delta sync (richiesto per il match che accadrà in seguito).
Start-ADSyncSyncCycle -PolicyType Delta
7. Nell’account creato in ADDS, modificate il suo attributo.
Fatelo localizzando l’mS-DS-ConsistencyGuid e aggiungendo il valore HEX dallo steo 2 (se c’è un valore, l’AD Connect aggiunge l’attuale valore ObjectGUID come comportamento di default, procedete ad aggiungere quello nuovo):
8. Riportare l’account alla OU sincronizzato ed eseguite nuovamente un delta sync: se tutto funziona come desiderato, significa che la sincronizzazione è avvenuta in maniera corretta.
9. Aggiungete o modificate un attributo in AD per assicurarvi che la sincronizzazione funzioni come deve. Infine, controllate il portale e l’errore sarà sparito.
Conclusioni
Con questa nuova funzionalità, è possibile risolvere i problemi precedentemente molto complicati quando si utilizzava l’“ObjectGUID”.
Indipendentemente dallo scenario, dovremmo sempre utilizzare l’originale ImmutableID (già impostato sul cloud), convertirlo in valore HEX ed aggiungerlo all’ “mS-DS-ConsistencyGuid” per far sì che avvenga la corrispondenza.
Se state per migrare account tra diverse foreste, assicuratevi di popolare l’oggetto “mS-DS-ConsistencyGuid” della foresta desiderata con il valore dell’oggetto sorgente “ObjectGUID”.
