ADSync Matching

ADSync pflegt für jedes Objekt des lokalen Active Directory Forest ein Konto in der Cloud. Oft startet eine Firma aber erst einmal mit einem "Test" oder "Piloten" in der Cloud und möchte erst später diesen dann produktiv nehmen. Diese Seite beschreibt, wie ADSync auf bestehende Objekte reagiert.

Ausgangsituation

Wir nehmen an, dass ein Office 365 Kunde folgende Schritte durchgeführt hat

  • Office 365 Tenant gekauft
    Damit kann er die entsprechende Anzahl an Benutzer in der Cloud mit Exchange Postfächern, Skype for Business Konten, SharePoint, Yammer etc. versorgen
  • Offizielle Domain
    Da die Nutzung der "%tenantname%.onmicrosoft.com"-Adresse nicht gerade schick ist, kann der Kunde auch schon eine öffentliche DNS-Domäne für Office 365 registriert haben. Das ist auch nur ein Eintrag in der Cloud und ein DNS-Eintrag. Schon können Sie den Anwender in der Cloud einen "schönen" Anmeldenamen verpassen. Wenn der Name dann schon mit dem lokalen UPN übereinstimmt, fällt dem Anwender der Zugang gleich einfacher.
  • Optional ADFS
    Der Kunde könnte sogar schon ADFS installiert haben. Allein der richtige UPN in der Cloud reicht dazu aus. Das ist dann aber schon eher eine Ausnahme. Bei den meisten Installationen ist ADFS eher das Ende.

Das Ergebnis könnte sich im Admin Center dann wie folgt darstellen:

Es gibt in der Cloud einen User mit einem Benutzernamen und ggfls. einem Postfach.

Weiter unten komme ich auf das Feld "ImmutableID" zu sprechen. Das normale Matching erfolgt nur , wenn die Zielobjekte nicht durch einen früheren DirSync mit einer ImmutableID versehen sind.

Kein Match per UPN (Bis Feb 2015)

Mittlerweile wird auch der UPN  zum Matching genutzt. Dies muss aber aktiviert werden

  • 3164442 How to use UPN matching for identity synchronization in Office 365, Azure, or Intune
Set-MsolDirSyncFeature `
   -Feature EnableSoftMatchOnUpn `
   -Enable $True

Die Beschreibung gilt daher für ältere Tenants oder solche, wo diese Einstellung nicht aktiv ist. In meinem Beispiel habe ich natürlich im lokalen Active Directory ebenfalls einen Benutzer angelegt, der den gleichen UPN hatte. Der Import gelingt noch aber beim Export gibt es einen Fehler "AttributeValueMustbeUnique"

Bleibt als "Pending Export" stehen:

mit der folgenden Fehlermeldung

Das Objekt kann nicht aktualisiert werden, weil die folgenden dem Objekt zugeordneten Attribute Werte
aufweisen, die möglicherweise bereits einem anderen Objekt in Ihren lokalen Verzeichnisdiensten zugeordnet 
sind: "UserPrincipalName frank@cariusxxx.de;". Korrigieren oder entfernen Sie die doppelt vorhandenen Werte 
in Ihrem lokalen Verzeichnis. Weitere Informationen zur Erkennung von Objekten mit doppelt vorhandenen 
Attributwerten finden Sie unter http://support.microsoft.com/kb/2647098.

Tracking Id: 571fb5c0-0a20-4d31-af1a-c3dfd75cfd94

ADSync und das Azure-AD beschweren sich zurecht, dass es im Ziel schon ein "anderes" Objekt gibt, welches diesen UPN hat.

Match mit SMTP-Adresse

ADSync kann Objekte "Matchen", aber dazu muss die SMTP-Adresse übereinstimmen:

Das ist aber nicht alles, denn auf "Custom installation of Azure AD Connect" (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-get-started-custom/) steht noch etwas mehr.

SourceAnchor / ImmutableID
Wenn Objekte im Ziel schon eine ImmutableID haben, dann geht ADSync davon aus, dass das Objekt bereits mit einem OnPremise-Objekte verbunden ist. Damit ist auch ein "Hard Match" möglich um. z.B. eine Bindung zu erzwingen. Das ist nützlich, wenn Sie ADSync im Rahmen eines Recovery neu installieren müssen.

Entsprechend habe ich nun auf dem "OnPremise-Objekt" einfach eine SMTP-Adresse addiert und den DirSync erneut laufen lassen. Schon in der Listenansicht fallen zwei Änderungen auf. Einmal der neue Synchronisationstyp und auch der Anzeigename wurde aus dem lokalen AD übernommen

Beim Blick in den ADSync sind auch die Änderungen beim Schreiben zu sehen.

Sie sehen aber hier, dass von der "OnPremise"-Umgebung keine Exchange Properties geschrieben wurden. Der Benutzer war bisher "OnPremise" nicht für Exchange aktiviert aber hat ein Postfach in der Cloud. Da ADSync hier aber nur unidirektional arbeitet. sind diese Daten nicht aus der Cloud in das OnPremise Directory abgebildet worden. Das ist verständlich, da es in diesem Forest noch keine Exchange Erweiterungen gibt.

Ich wollte nun eigentlich sehen, was nun beim "Change" des UPN passiert. Dabei habe ich übersehen, dass bislang nur ein DirSync-Lauf passiert war. Zuerst komm ein DeltaImport aus beiden Connectoren, dann die Zusammenführung und erst dann der Export in die Ziele. Insofern konnte der Import noch gar nicht wissen, dass beim Export der User "Matched" und zusammen geführt wird.

Der nächste Lauf startet wieder mit einem Delta Import und hier "erkennt" ADSync nun das Objekt im Ziel und dass es noch eine ganze Menge weiterer Felder gibt, die sich da ändern müssen:

Neben dem "Modify" auf den UPN entfernt ADSync im Azure AD nun aber auch all die in der Cloud bislang manuell gepflegte Felder. Ich habe diese Felder aktuell noch nicht "OnPremise" gepflegt und daher müssen Sie auch in der Cloud raus. Auch hier ist aber sichtbar, dass keine Exchange Properties aus der Cloud in die lokale Umgebung repliziert werden. Das ist aber einzig der Tatsache zu verdanken, dass das Objekt im lokalen AD aus Sicht von ADSync gar nicht als "Exchange relevant" angesehen wird.

Störender finde ich hier aber die Tatsache, dass der geändert UPN, weswegen ich hier nachgeschaut habe, als "Change" auftaucht.

ImmutableID

Fast alle Felder in einem AD können sich ändern. Selbst der SAMAccountName, der UPN und der DN und CN. Auch die ObjectSID ist nicht zuverlässig, da Objekte auch in andere Domänen des gleichen Forest verschoben werden können. Die Mailadresse ist zwar auch ein Feld, welches durch die Kombination von einmaliger Internet-Domäne und einem LocalPart nur einmal weltweit vergeben werden kann, aber auch eine Mailadresse kann sich ändern und kennzeichnet nicht zwingend das Objekt über die ganze Laufzeit.

Ein "Cloud"-Anwender, der noch nie synchronisiert war, hat in der Regel ImmutableID.

Die ImmutableID sagt Office 365, dass dieses Objekt "synchronisiert" wird.

Es gibt aber doch wenige Felder, die bei korrekten Migrationen beibehalten werden, solange das Objekt innerhalb des Forest existiert. Eines der Felder ist die ObjectGUID, welche jedes Objekt bei der Anlage bekommt und idealerweise weltweit einmalig und eindeutig ist. Daher nutzt auch ADSync diese Feld, um damit das Objekt im lokalen Active Directory und in der Cloud eindeutig miteinander zu verbinden. Die ObjectGUID wird während des Imports zu einem "SourceAnchor" der in der Cloud dann unter dem Namen "ImmutableID zu finden ist. Den Wert der ImmutableID können Sie sehr einfach per Powershell ermitteln:

# ObjectGUID eines Users holen
$guid = (get-Aduser frankcarius).ObjectGuid

# ObjectGUID in einen BASE64-String umrechnen.
$immutableID = [System.Convert]::ToBase64String($guid.tobytearray())

Das Feld ImmutableID kann mit der Office 365 Powershell sogar beschrieben und gesetzt werden und es gibt auch keinen Fehler, wenn das Feld auf "$null" gesetzt wird:

set-MsolUser `
   -UserPrincipalName user1@carius.de ' 
   -ImmutableId $null

# Hinweis: Auch wenn dies keinen Fehler gibt, so wird die ImmutableID nicht entfernt, solange der DirSync aktiv ist.

Alle anderen Schreibweisen mit "$null" oder '$null" oder "" o.ä. führen alle zu einem "set-MsolUser : Unable to Update parameter. Parameter name: SourceAnchor." Die ImmutableID bleibt weiterhin auf dem alten Wert. Es soll aber möglich sein, über den Weg ein Object in der Cloud auf ein anderes OnPremise-Objekt umzuhängen. Damit dies aber fehlerfrei abläuft, müssen Sie eine Abfolge einhalten:

  1. DirSync anhalten
    Microsoft meinst damit aber nicht das Pausieren des ADSync sondern die Abschaltung des DirSync im kompletten Tenant
    Deactivate directory synchronization
    https://msdn.microsoft.com/en-us/library/azure/dn144760.aspx
    Es soll angeblich auch reichen, wenn das Objekt in der Quelle nicht mehr im "Scope" des DirSync ist und daher "entsynched" wird.
  2. ImmutableID des Zielobjekts anpassen
    Das AD-Object hat selbst nach dem Abschalten des DirSync noch eine ImmutableID. Mit Set-MSOLUser können Sie die neue ImmutableID setzen
  3. DirSync wieder aktivieren
    Danach können Sie den DirSync wieder neu einrichten.
    Activate directory synchronization
    http://technet.microsoft.com/en-us/library/dn144766.aspx

Dazu suchen Sie sich zuerst die ObjectGUID des gewünschten Objects im AD und rechnen diese BASE64um. Dann soll es möglich sein, diese ID mit Set-MSOLUser in der Cloud zu setzen und damit die Verknüpfung umzuhängen.

Unmatching

Ein Konto, welches durch den DirSync angelegt oder bei einem Match konvertiert wurde, ist sehr eingeschränkt in der Cloud verwaltbar. Es gibt keinen Weg, ein einzelnes Objekt wieder aus dem Status "Mit Active Directory synchronisiert" auf den Status "In Cloud" zurück zu drehen. Sie können natürlich den Benutzer "OnPremise" löschen oder durch einen Filter aus der Replikation ausschließen. Damit wird das Konto in der Cloud aber samt Daten gelöscht. Sie können dann natürlich wieder ein "Cloud-Objekt" mit dem gleichen UPN und allen anderen Daten anlegen. Aber Gruppenmitgliedschaften des OnPremise-Objekt sind durch das Löschen natürlich erst einmal verloren gegangen.

Der "saubere" Weg die Objekte in der Cloud wieder den "In der Cloud"-Status zu verpassen ist die Abschaltung des DirSync auf dem Tenant. das geht per Powershell, aber kann einige Stunden dauern.

#DirSync für den Tenant deaktivieren
Set-MsolDirSyncEnabled -EnableDirSync $false
# kann bis zu 72h dauern

# Kontrolle, ob die Einstellunge schon umgesetzt ist
(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

Danach sind alle Objekte wieder "In der Cloud" und per Admin Center oder Powershell änderbar. Und natürlich durch einen neuen DirSync auch wieder "matchbar"

  • 2619062 You can't manage or remove objects that were synchronized through the Azure Active Directory Sync tool 

Weitere Links