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.
Lesen Sie als Einführung die Seite SourceAnchor und für weitere Details die Seiten SourceAnchor User und SourceAnchor Gruppen.
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".
- Setting the ImmutableID to $null
https://misstech.co.uk/2016/02/05/setting-the-immutableid-to-null/ - Azure AD Connect: Design concepts
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts - AAD Connect ms-DS-ConsistencyGuid as SourceAnchor
https://samilamppu.com/2017/09/10/aad-connect-ms-ds-consistencyguid-as-sourceanchor/ - Azure AD Connect: Design concepts
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-connect-design-concepts#using-msds-consistencyguid-as-sourceanchor
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:
Beachten Sie die Seite Move-ADObject für den Einsatz der PowerShell
Tool |
Move-ADObject |
MoveTree |
ClonePrincipal |
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. |
Unverändert |
Wird übernommen. |
Wird Synchronisiert. |
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:
- ADSync erkennt, dass der Benutzer im
Quell-Forest gelöscht wurde
Das wird bei der eingehenden Replikation entsprechend vermerkt. - 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. - 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. - 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:
- 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. - 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. - 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. - 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.
- ADMT Guide: Migrating and Restructuring Active Directory
Domains
https://technet.microsoft.com/en-us/library/12dd800a-7f70-4787-bc85-c474b2d304c7
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
- SourceAnchor
- SourceAnchor User
- SourceAnchor Gruppen
- Multi-Forest Identity
- Multiforest
- ADFS Multiforest
- ADSync Matching
- Domaintrusts
- LinkedMailbox
- Ressourceforest
-
Azure AD Connect: Design concepts
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-connect-design-concepts#using-msds-consistencyguid-as-sourceanchor -
ADMT Guide: Migrating and Restructuring
Active Directory Domains
https://technet.microsoft.com/en-us/library/12dd800a-7f70-4787-bc85-c474b2d304c7 - Custom installation of Azure AD Connect
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-get-started-custom/ -
Azure AD Connect: Design concepts
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-design-concepts/#sourceAnchor -
Office 365 – Why You Need to Understand
ImmutableID
http://blogs.perficient.com/microsoft/2015/04/office-365-why-you-need-to-understand-immutableid/ -
Setting the ImmutableID to $null
https://misstech.co.uk/2016/02/05/setting-the-immutableid-to-null/