• Cloud, Guide, Microsoft 365
• 27 Gennaio 2020

Mi è capitato diverse volte di trovare aziende che stanno già utilizzando Microsoft 365 e che hanno creato utenti di tipo “Cloud only” e che dopo qualche mese di utilizzo hanno deciso di sincronizzare gli utenti on-premises utilizzando il tool Azure AD Connect.

Quando si installa Azure AD Connect e si avvia la sincronizzazione, il servizio di sincronizzazione di Azure AD esegue un controllo per ogni nuovo oggetto e prova a trovare un oggetto esistente da associare. Vengono usati tre attributi per questo processo: userPrincipalName, proxyAddresses e sourceAnchor/immutableID.

Se c’è corrispondenza tra userPrincipalName e proxyAddresses (viene considerato solo il valore che inizia per SMTP: in maiuscolo) si parla di Soft Match, mentre nel caso di corrispondenza del sourceAnchor si parla di Hard Match.

Quando Azure AD Connect sincronizza un oggetto in Azure AD, l’oggetto che si trova già in Azure AD e che era precedentemente gestito nel cloud sarà contrassegnato come gestito in locale (on-premises). Poiché tutti gli attributi in Azure AD verranno sovrascritti con il valore locale, accertatevi che i dati locali siano corretti.

Da quel momento in poi l’oggetto deve essere necessariamente gestito e modificato on-premises e successivamente sarà necessario sincronizzare con il tool Azure AD Connect per visualizzare
le modifiche online.

Può capitare a volte che qualche amministratore di sistema (o i clienti più smanettoni) non abbia preparato bene l’Active Directory locale, modificando lo userPrincipalName ed il proxyAddresses degli oggetti da sincronizzare con Azure AD oppure non abbia utilizzato IdFix per identificare gli errori, ad esempio i duplicati e problemi di formattazione nella directory.

Duplicate Attribute Resiliency è una funzionalità di Azure AD che elimina le problematiche create dai conflitti di UserPrincipalName e ProxyAddress che possono avvenire durante la sincronizzazione della directory. Questa funzionalità permette che gli oggetti vengano sincronizzati anche se non sono univoci.
Invece che impedire che un oggetto venga creato oppure venga aggiornato con un attributo duplicato, Azure AD mette in quarantena l’attributo duplicato. Per esempio, se lo UserPrincipaleName è già assegnato, Azure AD utilizza un valore di placeholder “+[4DigitNumber]@.onmicrosoft.com”.

Come si può vedere dalla figura sotto, in Azure AD era già presente un utente con la username [email protected] e al momento della sincronizzazione, grazie alla Duplicate Atttribute Resiliency, è stato creato un nuovo oggetto con una username [email protected] con 4 numeri in più, rispetto a quella già presente.

Figura 1: In Azure AD sono presenti account duplicati

.

Azure AD Hard Match

Anche modificando successivamente lo userPrincipalName ed il proxyAddresses ed inserendo i parametri corretti per poter fare matching (Soft Match) con l’utente presente in cloud, gli utenti rimangono duplicati. In questo caso è necessario ricorrere alle maniere forti ed eseguire le seguenti operazioni:

1. Rimozione tramite PowerShell dell’utente sincronizzato dall’Active Directory locale che ha generato l’oggetto duplicato, anche da cestino
2. Modifica dell’ImmutableID dell’oggetto presente in Azure AD con l’ObjectGUID dell’oggetto presente on-premises nell’Active Directory locale

Per eliminare l’utente duplicato (che ha una username generata dinamicamente, con dei numeri dopo il logon name, perchè è già presente la stessa username in Azure AD) è sufficiente lanciare i due comandi PowerShell

Figura 2: Eliminazione dell’utente duplicato

Come si può vedere dalla figura sotto, online in Azure AD è rimasto l’utente che già esisteva e che è di tipo “Cloud only”

Figura 3: In Azure AD è rimasto solo l’oggetto pre-esistente rispetto alle operazioni di sincronizzazione con Azure AD Connect

Mentre l’oggetto è rappresentato in Active Directory utilizzando l’objectGUID, quando viene sincronizzato con Azure AD con il tool Azure AD Connect il valore dell’objectGUID viene convertito in formato Base64 e conservato nell’Azure AD Connect metaverse in un nuovo attributo chiamato sourceAnchor. Dopo la sincronizzazione con Azure AD questo attributo viene copiato nell’attributo ImmutableID del corrispondente oggetto di Azure AD.

Figura 4: Conversione dell’attributo objectID in ImmutableID

Procuratevi l’objectGuid dell’utente locale di Active Directory che volete far corrispondere all’utente già presente in Azure AD. Utilizzate il comando PowerShell:

Figura 5: Recupero dell’objectGUID dell’utente di Active Directory

Nel mio caso l’ObjectGUID è e163ffcf-451b-45e0-bb4c-2e303ff7e555

Prima di modificare l’ImmutableID dell’utente già presente in Azure AD dobbiamo convertire l’ObjectGUID in un valore in formato Base64. Per farlo potete collegarvi alla pagina http://guid-convert.appspot.com/ ed incollare il GUID. Il risultato è mostrato nella figura sotto:

Figura 6: Utilizzo di un tool online per la conversione del GUID in formato B64

A questo punto potete collegarvi al vostro Azure AD utilizzando la PowerShell (Connect-MSOnline) ed utilizzare il comando mostrato sotto (modificate utilizzando i vostri parametri) per modificare l’ImmutableID dell’utente presente nel vostro tenant di Microsoft 365.

Figura 7: Modifica dell’ImmutableID dell’utente presente in Azure AD

In alternativa è possibile utilizzare i comandi di seguito per ottenere l’ObjectGuid direttamente in formato Base64

Figura 8: Modifica delli’mmutableID utilizzando PowerShell

Successivamente lanciate la sincronizzazione di Azure Ad Connect con il comando

Al termine del ciclo di sincronizzazione vedrete che il vostro utente locale sarà stato agganciato all’utente già presente in Azure AD e che il simbolo di Sync status mostrerà l’icona Synced with Active Directory.

Figura 9: L’utente presente nel Cloud è sincronizzato con l’utente on-premises

Conclusioni

Nel caso in cui abbiate già una sottoscrizione di Microsoft 365 e decidiate successivamente di sincronizzare gli oggetti on-premises con Azure AD potreste avere degli oggetti duplicati. L’Hard matching e l’attributo ImmutableID vi possono aiutare a risolvere facilmente questo problema e permettervi di sincronizzare ed associare gli utenti esistenti in Active Directory locale con quelli presenti in Azure AD.