Nel precedente post vi ho parlato velocemente di Azure Active Directory Sync e abbiamo visto anche quali sono i principali passi per sincronizzare le utenze del vostro dominio on-premise, verso la piattaforma cloud di Microsoft.

Durante una delle migrazioni che abbiamo fatto, ci siamo scontrati con un problema che non è stato di immediata risoluzione. In pratica, ci siamo trovati nella situazione di aver un certo numero di utenti già sincronizzato con Azure AD/Office 365 e di dover gestire lo spostamento di questi utenti in un nuovo dominio, con successiva ri-sincronizzazione ovviamente.

Perché questo è un problema?
Active Directory ha un identificativo interno che rappresenta ogni utente. Questo identificativo però cambia il suo valore nel caso di uno spostamento dell'utente in una locazione diversa del dominio o nel caso di uno spostamento in un dominio totalmente nuovo.
Azure AD Sync può essere configurato per utilizzare questo identificativo come "ancora" per identificare a sua volta l'utente in maniera univoca (è l'opzione di default) e ovviamente, a fronte di una modifica di questo valore, l'utente che è stato precedentemente sincronizzato perde il suo collegamento con l'utente onpremise.

Quando si utilizzava l’utility DirSync questo problema era presente su ogni migrazione, in quanto DirSync non permetteva la configurazione dell’attributo di AD da utilizzare come ancora.

Se capitiamo in questa situazione, i sistemi automatici di Microsoft ci avvisano con la seguente e-mail.


L'errore che dobbiamo verificare è il seguente:

"Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [UserPrincipalName youusername@yourdomain.com;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values".

In poche parole l'utility Azure AD Sync, che è stata configurata per sincronizzare gli utenti sul nuovo dominio (o cmq sul dominio vecchio, ma con utenti spostati dalla loro locazione iniziale), prova ad aggiornare l’utente "testuser@dev4side.com", ma l'aggiornamento fallisce per i seguenti motivi:

  • Azure AD Sync cerca di aggiungere l'utente con il nuovo identificativo, al posto di modificare quello precedente. Questo accade perché l'identificativo dell'utente è cambiato e quindi per l'utility si tratta di un utente completamente nuovo.

  • L'utente ha però una mail uguale a quella di un altro utente (che sarebbe l'utente precedentemente sincronizzato) e noi abbiamo configurare Azure AD Sync in modo tale da utilizzare la mail come nome di login (samAccountName) su Azure AD/Office 365.

Come possiamo risolvere questo problema?
L'identificativo di cui vi parlavo, l'ObjectId dell'utente Active Directory, viene utilizzato per creare l'attributo "ImmutableId" su AzureAD/Office 365. L'attributo "ImmutableId" viene a sua volta utilizzato durante la sincronizzazione con AD on premise, per identificare l'utente già sincronizzato.
Questo attributo, nonostante il nome che gli hanno dato, è tutt'altro che "immutevole" e può essere modificato con il seguente script PowerShell:

$cred = Get-Credential
Connect-MsolService -Credential $cred
$guid = (get-Aduser testuser).ObjectGuid
$immutableID = [System.Convert]::ToBase64String($guid.tobytearray())
Set-MSOLuser -UserPrincipalName testuser@dev4side.com -ImmutableID $immutableID

Nota: questo comando lo potete lanciare una volta scaricato i commandlet Powershell per gestire Office 365.

Prima di lanciare questo script dovete però disabilitare la sincronizzazione tra Office 365 ed Active Directory on premise, altrimenti avrete a che fare con il seguente errore:

Set-MSOLuser : Unable to update parameter. Parameter name: SourceAnchor

Se l'esecuzione del commandlet Set-MSOLuser vi ritorna questo errore, l'unico modo di risolverlo è quello di disabilitare temporaneamente la sincronizzazione tra Office 365 ed Active Directory, rilanciare lo script (ovviamente è meglio che lo fate su tutti gli utenti) e riabilitarla.
Potete disabilitare (e riabilitare) la sincronizzazione lanciando il seguente script PowerShell:

$cred = Get-Credential
Connect-MsolService -Credential $cred
Set-MsolDirSyncEnabled -EnableDirSync $false

Fate solo conto che, una volta disabilitata, ci vorranno anche 72 ore per poterla riabilitare.

Durante questo tempo, tutti i vostri utenti risulteranno nel pannello di amministrazione di Office 365 come se fossero creati "nel cloud". Non spaventatevi, una volta riabilitata la sincronizzazione e rilanciato Azure AD Sync, ritorneranno con lo stato "sincronizzato con Active Directory".

Per fare le cose in automatico, mi sono preparato il seguente script:

$cred = Get-Credential
Connect-MsolService -Credential $cred
$users = get-aduser -ldapfilter "(&(sAMAccountName=*)(!userAccountControl:1.2.840.113556.1.4.803:=2))" -Properties ObjectGuid, mail | Select ObjectGuid, mail
foreach($user in $users) {
    if($user.mail -ne $null -and $user.mail -ne "") {
        Write-Host "Updating user:" $user.mail
        $immutableID = [System.Convert]::ToBase64String($user.ObjectGuid.tobytearray())
        Set-MSOLuser -UserPrincipalName $user.mail -ImmutableID $immutableID
    }
}

Come potete vedere, tramite questo script possiamo aggiornare la proprietà ImmutableId su tutti gli utenti del nostro dominio locale che hanno almeno la mail settata (visto che abbiamo utilizzato l’indirizzo e-mail come nome principale dell'utente una volta su Office 365).

Spero vi sia utile, che io ci ho messo un po' di tempo a capire come fare a muovermi in questo scenario.