Office 365 SourceAnchor, ImmutableId 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

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
user1@msxfaq.net                            9PuWxEPKY0S9o18N1rN2LQ==                   19.03.2016 10:46:42
Shared1@msxfaq.net
carius.admin@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

MoveTree (Same Forest)

ClonePrincipal (Cross Forest

ADMT

ADMT

Quest Migrator

Einsatzbereich

Same Forest

Cross Forest

Same Forest

Cross Forest

Cross Forest

Objekt Aktion

Verschiebt

Kopiert

Verschiebt

Kopiert

Kopiert / Synchronisiert

Object GUID

Erhalten

Neu

Erhalten

Neu

Neu

Kennwort

Erhalten

Neu

Erhalten

Neu, Optional übertragen

Neu, Optional übertragen

SID

Erhalten

Neu

Erhalten

Neu, Optional mit SID History

Neu, Optional mit SID History

Gruppenmitgliedschaften

?

Nur UniversalGroups

?

Kopieren

Synchronisiert

UPN

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

Bleibt

Entfernt

Bleibt

Bleibt

Lokales Profil (An der GUID)

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 ObjectGUI, 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 "OnPremise" bestimmte Änderungen an den anderen Anwendern und Gruppen vornehmen, aber sie werden nicht in die Cloud repliziert. Sie haben faktisch eine "FrozenZone" 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 OnPremise 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.

Eigener SourceAnchor

Es gibt aber noch einen zweiten Weg, eine AD-Migration mit Office 365 vielleicht eleganter zu lösen. Office 365 und ADSync nutzt per Default die ObjectGUID des Quellobjekts und da es sich dabei um keinen String handelt, codiert ADSync den Inhalt BASE64. Sie haben auch die Grenzen der ObjectGUID im Hinblick auf AD-Migrationen kennengelernt. Da kommt schon der Wunsch auf, ob ADSync nicht auch ein anderes Feld nutzen könnte. Das ist sogar möglich, wenn bei der Installation von ADSync die "Custom Installation" gewählt wird. Wenn Sie ADSync aber schon mal installiert haben, dann können Sie das Feld nicht mehr mit dieser Installation ändern. Die Einrichtung des Quellfelds für die "ImutableID" ist beim "Custom Setup" des ADSync-Services hier möglich:

Achtung: Dieses Feld kann nur während der initialen Installation gesetzt werden und kann nachträglich nur durch eine Neuinstallation von ADSync geändert werden. Beachten Sie dann auch die Hinweise auf ADSync Matching.

Die Einstellung ist auch genau dafür gedacht, wenn in einer Umgebung die ObjectGUID nicht das optimale Feld darstellt.

Source Anchor - The attribute sourceAnchor is an attribute that is immutable during the lifetime of a user object. It is the primary key linking the on-premises user with the user in Azure AD. Since the attribute cannot be changed, you must plan for a good attribute to use. A good candidate is objectGUID. This attribute is not changed, unless the user account is moved between forests/domains. In a multi-forest environment where you move accounts between forests, another attribute must be used, such as an attribute with the employeeID. Avoid attributes that would change when a person marries or change assignments. You cannot use attributes with an @-sign, so email and userPrincipalName cannot be used. The attribute is also case-sensitive so when you move an object between forests, make sure to preserve the upper/lower case. Binary attributes are base64-encoded, but other attribute types remain in its unencoded state. In federation scenarios and some Azure AD interfaces, this attribute is also known as immutableID. More information about the source anchor can be found in the design concepts.
Quelle: Custom installation of Azure AD Connect" (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-get-started-custom/)

Ehe Sie nun vorschnell hier etwas ändern, sollten Sie sich genau überlegen, welches Feld denn "geeignet" ist. Es gibt da nämlich durchaus einige Vorausetzungen, von denen Microsoft einige auf der Seite "Azure AD Connect: Design concepts" (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-design-concepts/#sourceAnchor) beschreibt. Es sollte unter anderem folgende Voraussetzungen erfüllen:

Kriterium Erfüllt ?

In allen Forests vorhanden
Es darf nur eine ADSync Instanz pro Tenant geben, die aber mehrere Forests bedienen kann. Das von ihnen als "SourceAnchor" ausgewählte Feld muss also in allen Quellen vorhanden sein.

 

Typ: String, Integer oder Binary
Maximal 60 Zeichen lang
Keine Sonderzeichen wie ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ' ; : , [ ] " @ _
Achtung: Case-Sensibel, d.h. Groß/Kleinschreibung werden unterschieden.

 

Eineindeutig, d.h. es darf nie zwei Objekte mit dem gleichen Inhalt geben. Diese Eindeutigkeit muss über alle Forests gelten

 

Darf nicht leer sein, wenn das Objekt für Office 365 relevant ist

 

Muss auf allen relevanten Objekte vorhanden sein
Denken Sie dabei nicht nur an "Benutzer". Auch Gruppen und sogar Computerobjekte werden mit ADSync abgeglichen. Auch wenn vielerorts eine "EmployeeID" als alternatives Feld vorgeschlagen wird, müssen Sie dieses auch bei anderen Objekten pflegen.

 

Aber auch die Verwendung andere bekannter und naheliegender Felder wie UPN, Mail, targetAddress etc. funktioniert nicht. Diese Felder haben z.B. ein "@" als Wert, was nicht erlaubt ist. Auch andere Felder können problematisch sein, weil diese vielleicht durch einen Synchronisationsprozess, z.B. GalSync, zwischen den Forests übertragen werden und damit nicht mehr "eineindeutig" sind.

Die Wahl eines alternativen Feldes ist alles andere als einfach, da die eingebauten Vorkehrungen zur Eindeutigkeit (ObjectGUID) nicht genutzt werden können. Neben dem passenden LDAP-Feld ist es vielmehr eine Frage des Provisioning, dass dieses Feld auch immer in allen Forests korrekt gesetzt und fortlaufend gepflegt wird, aber bei AD-Migrationen eben nur einmal im Forest vorhanden ist.

Wechsel des SourceAnchor

Die Konfiguration von ADSync verbietet eine Änderung des SourceAnchors nach der Installation. Eine Konfiguration ist nur bei der ersten Installation selbst über ein "Custom Setup" möglich. Wenn Sie daher bereits ADSync installiert haben und nun mit der Änderung des SourceAnchors liebäugeln, dann kommen Sie um eine Neuinstallation nicht herum.

Ehe Sie nun aber ADSync deinstallieren und gleich neu installieren müssen Sie im Tenant ggfls, noch etwas anpassen, Dort haben die die Objekte in der Cloud schon das Feld "ImmutableID", indem die ObjkectGUID als BASE64-codierter String enthalten ist. Damit gibt es für ADSync keinen Grund mehr neu zu "matchen". Sie haben hier zwei Optionen

  • ImmutableID in der Cloud leeren und neu matchen
    Dazu müssen Sie im Tenant, wie oben bei der Kontenmigration mit ADMT und Co beschrieben, den DirSync deaktivieren und über die Mailadresse beim ersten Lauf ein Matching erreichen. So können Sie z.B. als Inhalt eine Objektkennung ihres Identity Managment Systems wie eine Personalnummer, HR-Stammdatensatznummer o.ä. nutzen. Dies ist vielleicht auch "sprechend" und erleichtert ihnen später die Verwaltung
  • SourceAnchor-Inhalt = ObjectGUID
    Ein anderer Weg besteht darin, die bisher genutzten Werte des alten SourceAnchor in das neu zu nutzende Feld zu kopieren. Dann nutzt die neu installierte ADSync-Instanz diese Information und findet das bestehende Zielobjekt.

In beiden Fällen sehe ich die Komplexität aber eher in der späteren Verwaltung, die einen korrekten Inhalt in diesem Feld sicherstellen muss. Denkbar ist natürlich auch, dass sie diesen "Sonderweg" nur so lange beschreiten, bis ihre AD-Migration abgeschlossen ist und alle Konten in dem einem zentralen Forest gelandet sind. Dann können Sie natürlich ebenfalls wieder ADSync auf die ObjectGUID umstellen.

Weitere Links