SourceAnchor und ADMT

Diese Seite beschreibt, wie ADSync Objekte in mehreren lokalen AD-Forests mit einem Office 365 Tenant abgleicht und was dies in Bezug auf AD-Konsolidierungen  mit ADMT, ClonePricipal und MoveTree bedeutet.

ImmutableID

Dieses Feld wird auch als SourceAnchor oder CloudSourceAnchor beschrieben. Es handelt es sich immer um das gleiche Feld.

Für einen Verzeichnisabgleich, wie ADSync das nun mal ist, ist es unerlässlich einmal verknüpfte Objekte immer wieder zu finden. Bei der ersten Betrachtung mag der ein oder andere Admin hier an die SID, den DN, den UPN oder den SamAccountName denken, die zwar alle eindeutig und "einzigartig" sind aber sich durchaus ändern können. Alleine eine Heirat ändert meist den Namen und je nach Namenskonzept auch den SamAccountName, den UPN und CN. Die SID ist zwar in der Domäne nicht änderbar aber bei einer Reorganisation werden Benutzer auch schon mal in eine andere Domäne verschoben, wobei sich die primäre SID ändert. Die "alte SID" kann zwar über die SIDHistory noch mitgeführt werden., aber das Feld ist für die Pflege einer "Verknüpfung" zu einem anderen System auch nicht optimal.

Das Feld "ImmutableID" gibt es nicht im lokalen Active Directory und auch nicht direkt in der SQL-Datenbank der ADSync-Instanz, sondern in AzureID ihres Office 365 Tenant. Hier ein Auszug meines Test-Tenants:

PS C:\> Get-MsolUser | ft UserPrincipalName,immutableid,lastdirsync* 
UserPrincipalName                           ImmutableId                                LastDirSyncTime
-----------------                           -----------                                ---------------
User4@carius.onmicrosoft.com                7fYQXz7cz0yw1AoU5PML5g==                   10.03.2016 21:26:28
raum2@msxfaq.net 
User6@carius.de                             Faa6dG6hkUG13a+Pvqzk6A==                   23.05.2016 15:23:29 
User5@carius.onmicrosoft.com                jzvTkG2A8kmfizUCDSTbaw==                   10.03.2016 21:26:28 
User2@carius.onmicrosoft.com                AxwAYaSJZEKIuQ1gUndETA==                   10.03.2016 21:26:28 
User9@carius.de                             VuOFtgUp8k+Rmmf/bXj6bw==                   23.05.2016 14:07:22 
sUser1@msxfaq.net                           9PuWxEPKY0S9o18N1rN2LQ==                   19.03.2016 10:46:42
Shared1@msxfaq.net
adm@carius.onmicrosoft.com

Sie können hier recht einfach sehen, dass nur die Identitäten eine ImmutableID haben die über den ADSync verwaltet werden. Alles andere sind "CloudOnly"-User".

Multi Forest und Office 365

Das Schöne an den Defaults von ADSync und Active Directory ist, dass schon in der Standardinstallation alle Einstellungen auch "Multi Forest"-tauglich sind. Die ObjectGUID eines AD-Objekts ist vom Design her weltweit "einmalig" und sowohl Benutzer aber auch Gruppen und Computer und jedes andere Objekte im AD hat eine ObjectGUID und ist damit ein Kandidat für die Synchronisation mit Azure AD. Wurden Anfangs nur Benutzer und Gruppen in die Cloud repliziert werden heute auch Computerkonten (Strichwort InTune, DeviceManagement, SoftwareVerteilung) übertragen und es ist nicht ausgeschlossen, dass bald noch andere Objekte in den Fokus geraten.

Wer also mehrere Forests mit einem "Single Tenant" abgleichen will, kann das tun. Er muss dazu allerdings eine ADSync-Instanz nutzen. Siehe auch Office 365 Multiforest. Es ist nicht möglich mehrere Forests über jeweils eigene ADSync-Installationen in den gleichen Tenant zu replizieren.

Wer dann aber Benutzer aus mehreren Forests repliziert, muss über die "Custom Installation" von ADSync bestimmen, wie ADSync mit Objekten umgeht, die es in mehreren Forests gibt aber die gleichen Personen darstellen.

Denn leider verfolgen nicht alle Firmen den Ansatz, dass ein Benutzer nur genau ein Anmeldekonto hat und die Zugriffe auf Dienste im eigenen aber auch in anderen Forests dann über Domaintrusts abgebildet werden. Es gibt wirklich Situationen, in denen ein Anwender in mehreren Forests ein Benutzerkonto hat. Würde hier nun ADSync diese Forests mit dem gleichen Tenant replizieren und keine Rücksicht darauf nehmen, dann gäbe es für jeden Benutzer eine Office 365 Identität, d.h. der Benutzer ist mehrfach in Office 365 vorhanden. Jeder mit einer eigenen ImmutableID.

Neben der "Fehlkonfiguration", bei der ein Anwender mehrere aktive Konten in unterschiedlichen Forests hat, gibt es aber zwei Szenarien, bei denen es dauerhaft oder temporär sinnvoll ist, mehrere AD-Konten zu pflegen:

  • AD-Konsolidierung mit Migration
    Wenn Sie gerade dabei sind, einen Forest durch Migration der Konten in einen neuen Forest abzulösen, dann werden Sie die Anmeldekonten im Ziel schon anlegen aber in der Quelle vielleicht noch nicht löschen.
  • Ressource Forest
    Ein zweites Szenario ist der Betrieb von Exchange und Skype for Business in einem eigenen Ressource Forest. Der Anwender meldet sich in seinem eigenen "Anmeldeforest" an, während die Postfächer in einem separaten Forest als "LinkedMailbox" mit einem deaktivierten Konto angelegt wurden..
    Siehe dazu auch Office 365 Multiforest, LinkedMailbox und Ressourceforest

Ich bin aber sicher, dass ich auch zukünftig immer mal wieder Umgebungen mit mehreren Domänen und Forests finde, in denen ein Benutzer eigene Konten pro Forest hat, z.B. weil ein Trust nicht eingerichtet werden kann (IP-Adressprobleme, Namensauflösung, Firewall, Sicherheitsbedenken (DMZ Forest)). Dann sollten Sie immer die "Custom Installation" durchführen um hier die richtige "Globale Betriebsart" für ADSync einzustellen.

AD-Migrationen mit aktivem ADSync

Ich empfehle eigentlich immer, dass eine AD-Konsolidierung abgeschlossen sein sollte, ehe Office 365 und ADSync zum Einsatz kommen. Die Erfahrung zeigt aber, dass ein Kunde nicht immer die Zeit hat, die AD-Migration abzuschließen und zumindest einen Office 365 Piloten starten möchte, der dann auch gleich mit ADSync und ADFS funktionieren soll. Wenn Sie in der Umgebung mit den "Standardeinstellungen" für ADSync arbeiten, dann müssen Sie abhängig vom Migrationstool einige zusätzliche Schritte durchführen. Dabei kommt meint eines der vier Tools zum Einsatz:

Tool

Move-ADObject

MoveTree
(Same Forest)

ClonePrincipal
(Cross Forest)

ADMT

ADMT

Quest Migrator

Einsatzbereich

Same Forest

Same Forest

Cross Forest

Same Forest

Cross Forest

Cross Forest

Objekt Aktion

Verschiebt

Verschiebt

Kopiert

Verschiebt

Kopiert

Kopiert / Synchronisiert

ObjectGUID

Neu

Erhalten

Neu

Erhalten

Neu

Neu

Kennwort

Erhalten

Erhalten

Neu

Erhalten

Neu, Optional übertragen

Neu, Optional übertragen

SID

Neu mit SID History

Neu, Optional mit SID History

Neu

Erhalten

Neu, Optional mit SID History

Neu, Optional mit SID History

Gruppenmitgliedschaften

Ja

?

Nur UniversalGroups

?

Kopieren

Synchronisiert

UPN

Unverändert

Unverändert

Kann übernommen werden.
ADFS kann aber nur einen Forest bedienen. Siehe Office 365:ADFS Multiforest

Unverändert

Wird übernommen.
ADFS kann aber nur einen Forest bedienen. Siehe Office 365:ADFS Multiforest

Wird Synchronisiert.
ADFS kann aber nur einen Forest bedienen. Siehe Office 365:ADFS Multiforest

Quellobjekt

Entfernt

Entfernt

Bleibt

Entfernt

Bleibt

Bleibt

Lokales Benutzerprofil

Bleibt

Bleibt

Neu

Bleibt

Anpassbar

Anpassbar

Das hier relevante Feld ist natürlich die "ObjectGUID", die sich bei Verlagerungen innerhalb eines Forests nicht ändert. ADSync wird also in diesem Fall das neue Objekt wiedererkennen und problemlos weiter verwenden. In Office 365 ändert sich nichts, d.h. Lizenzen aber auch Postfächer u.a. bleiben erhalten.

Interessanter wird es bei einer "Cross Forest"-Migration, da hierbei sich die ObjectGUID, aber auch die SID ändert. Wenn Sie einen Benutzer von einem Forest in einen anderen Forest ohne Vorkehrungen verschieben, passiert das folgende:

  1. ADSync erkennt, dass der Benutzer im Quell-Forest gelöscht wurde
    Das wird bei der eingehenden Replikation entsprechend vermerkt.
  2. ADSync erkennt, dass ein neue Benutzer im Ziel-Forest angelegt wurde
    Bei dem Benutzer sind zwar vermutlich viele Felder wie DisplayName, Mailadresse, UPN etc. gleich, aber es ist ein neues Objekt.
  3. ADSync löscht den Quellbenutzer in der Cloud
    Der Anwender ist in der Cloud zwar nicht "sofort" weg sondern nur im "Papierkorb", aber er kann nicht mehr arbeiten und auch sein Postfach und alle anderen Datentöpfe sind nicht mehr erreichbar.
  4. ADSync legt den Zielbenutzer neu an
    Ohne Lizenz hat er nicht mal eine Mailbox. Es ist aber ein neuer User ohne Zugriff auf die alten Daten. Auch der UPN übernommen wurde, kann er sich vermutlich nicht anmelden, da der ADFS-Service noch auf den alten Forest verweist.

Wer also Benutzer zwischen Forests verschiebt, die zusätzlich mit Office 365 abgeglichen werden, muss hier eine Ehrenrunde drehen. An vielen Stellen im Internet finden sich Beschreibungen zur Lösung des Problems, die alle derart funktionieren, dass das Konto in der Cloud nach dem Move mit dem neuen Konten der Zieldomäne "gematched" wird. Das geht aber nur, wenn die ImmutableID in der Cloud leer ist und das Zielkonten über das Feld "Mail" wieder zugeordnet werden kann. Siehe ADSync Matching. Leider kann man die ImmutableID aber nicht einfach löschen, solange der DirSync noch aktiv ist ist. Daher sind die Schritte zur Lösung auf diesem Weg:

  1. DirSync im Tenant komplett abschalten
    Es reicht nicht den ADSync-Service einfach zu stoppen. Sie müssen wirklich die Konfiguration des Tenant bezüglich DirSync zurückbauen. Das kann durchaus bis zu 72h dauern, bis diese Einstellung aktiv ist. Während dieser Zeit können Sie zwar On-Premises bestimmte Änderungen an den anderen Anwendern und Gruppen vornehmen, aber sie werden nicht in die Cloud repliziert. Sie haben faktisch eine "Frozen-Zone" was das Provisioning von Benutzern betrifft. Dies betrifft insbesondere das Feld Mail, welches Sie bis zum Abschluss nicht ändern sollten.
    Die Anmeldung ist dank ADFS und dem UPN natürlich weiter möglich und selbst mit "Kennwort Sync" können sich die Anwender weiter anmelden, solange Sie nicht ihre Kennwort ändern. Denn Änderungen am Kennwort werden bis zum Abschluss dieses Prozesses ebenfalls nicht in die Cloud repliziert.
  2. Benutzer zu "Cloud User" konvertieren
    Die Benutzer, welche zwischen den Forests verlagert werden, müssen dann in der Cloud "entbunden" werden. Der Schlüssel dazu ist die ImmutableID, welche per Set-MSOLUser auf "$null" gesetzt werden kann.
  3. AD-Konto verschieben
    In der Zwischenzeit können Sie das AD-Konto natürlich On-Prem mit einem Tool ihrer Wahl entsprechend "umziehen", damit es im Ziel auftaucht. Wichtig ist natürlich, dass das Feld "Mail" mit übertragen wird, da dieses zum späteren Matching benötigt wird und mit dem bisherigen Benutzer in der Cloud übereinstimmen muss.
  4. ADSync/DirSync neu einrichten
    Nun richten Sie wieder wie gewohnt den Office 365 Verzeichnisabgleich ein und wie auf ADSync Matching beschrieben, sollten die verschobenen Konten im Ziel anhand der Mail-Adresse mit dem vorhandenen Konto in der Cloud "gemachted" werden. Natürlich sollte dieses Matching auch für alle bestehenden unveränderten Benutzer ebenfalls wieder erfolgreich verlaufen. In der Regel ist das "sicher" aber es bleibt natürlich ein Risiko.

Sie werden nun selbst sehen, dass diese Schritte immer durchzuführen sind, wenn Benutzer zwischen Forests verschoben werden. Wer nun seine AD-Konsolidierung "schrittweise" in kleinen Gruppen durchführt, muss mit viel Mehrarbeit und Einschränkungen rechnen.

Multi-Forest und ADFS?

Ehe ich aber auf eine andere Lösung komme, sollten Sie noch die Authentifizierung berücksichtigen. Ein Benutzer wird in der Cloud über den "UserPrincipalName" eindeutig identifiziert und dieser Wert ist zugleich auch der Wegweiser zum ADFS-Server. Leider kann eine UPN-Domain immer nur einem Forest zugeordnet werden. Wer also eine Teilmenge der Anwender in einen anderen Forest verschiebt, hängt einen Teil von der Authentifizierung ab. Das Problem ist nicht vorhanden, wenn Sie auf einen Schlag alle Anwender in den Zielforest verschieben und in Office 365 dann auch den UPN auf den neuen ADFS-Server im Ziel anders konfigurieren.

Wer aber "schrittweise" in Gruppen migrieren will, sollte z.B.: überlegen auf ADFS für diese UPN-Domain zu verzichten und stattdessen die Kennwort zu synchronisieren. Damit wird aus dem "Single SignOn" allerdings eine "Same SignOn"-Anmeldung, d.h. der Anwender muss für den Zugriff auf Dienste in der Cloud seine Anmeldeinformationen erneut eingeben. Es ist aber der gleiche UPN und das identische Kennwort. Er kann die Daten in der Regel auch "speichern", so dass die Anmeldung nur einmal je Ressource erforderlich ist. Aber zumindest ist die Konfiguration von ADFS und Anmeldungen in Office 365 pro UPN-Domain möglich und nicht global für den kompletten Tenant zu betrachten.

Weitere Links