ADSync GALSync

Eine AD-Instanz kann immer nur genau einen Tenant aber durchaus mehrere Forests verbinden. Da ADSync aber auch z.B. einige Felder in die lokalen Objekte zurückschreibt, durfte ein AD-Objekt selbst auch nur immer von einer AD-Sync-Instanz geschrieben werden. Nun gibt es aber Firmen, die in einem gemeinsamen AD-Forest z.B. Exchange nutzen aber ihrerseits in unterschiedliche Forests umgezogen werden oder sogar das klassische "GALSync"-Thema auf dem Papier steht: Die Postfachinformation eines AD-Forests soll nicht nur in den primären Tenant synchronisiert werden, sondern auch in einem anderen Tenant zumindest als "Empfänger" sichtbar sein.

ADSync 1:N

Statt einer N:1-Konfiguration ist nun eine 1:N-Topologie gefordert. Interessanterweise beschreibt Microsoft diese Konfiguration sogar:

Allerdings listet Microsoft dabei auch gleich alle Einschränkungen auf. Die wichtigste Aussage ist sicher folgende:

Only one Azure AD tenant sync can be configured to write back to Active Directory for the same object. This includes device and group writeback as well as Hybrid Exchange configurations – these features can only be configured in one tenant. The only exception here is Password Writeback...

Ehe ich so etwas bei einem Kunden einsetze, möchte ich natürlich schon wissen, was da im Hintergrund passiert. Zumal es ja noch andere Ansätze gibt.

Szenario Beschreibung

Lokaler GALSync

Firmen mit mehreren Forests haben oft schon On-Premises einen Art Verzeichnisabgleich etabliert. Speziell wenn Sie enger zusammen arbeiten aber auf der anderen Seite zwei separate Exchange Organisationen betreiben und eine gemeinsame GAL wünschen.

Wenn in dem Umfeld nun ein oder mehrere Umgebungen auch Exchange Online nutzen, dann sollten die Anwender in der Cloud das gleiche Adressbuch haben, wie die Anwender On-Premises. Dazu müssen die Kontakte aus der jeweils anderen Exchange Organisation auch in die Cloud übertragen werden.

ADSync kann dies aber beachten Sie, dass damit z.B. Benutzer aus A2 eventuell als Identitäten in T1 erscheinen. Das kann zu Konflikten in Verbindung mit Gastkonten kommen, die zwischen T2 und T1 angelegt werden.

CloudOnly Sync

Wenn es lokal keinen Abgleich gibt, weil z.B. beide Firmen komplett ein Exchange Online sind, dann ist es dennoch denkbar, dass die Empfänger in T2 auch im Tenant T1 als Kontakte angelegt werden sollen.

Auch hier ist auszuschließen, dass es die Identitäten im anderen Tenant schon als Gast oder reguläres "Zweitkonto" gibt.

 

Cross Sync

ADSync kann mittlerweile auch genutzt werden, um z.B. die Identitäten mehrerer Forests in einen gemeinsamen Tenant zu schreiben. Wenn natürlich die Objekte in 11 nicht nur von dem ADSync in A1 geschrieben werden, sondern eine weitere ADSync-Installation die gleichen Objekte aus A1 liest aber in T2 schreibt, dann muss zuverlässig verhindert werden, dass diese sekundären Synchronisationsprozesse in die Quelle zurückschreiben.

Der wichtigste Schutz ist hier aus meiner Sicht die Berechtigung des Dienstkontos zur Verzeichnissynchronisation, da jeder ADSync sein eigenes Dienstkonto hat und natürlich eine korrekte Konfiguration.

Allerdings habe ich noch keine Beschreibung gefunden, wie ich Writeback auf bestimmten Quellen separat abschalte. Microsoft schreibt nur, dass WriteBack nur auf einem Tenant aktiviert werden darf. Aber was soll T1 mit Writeback in A2 schreibe, wenn eigentlich T2 nach A2 schreiben soll.

Custom

Niemand hindert sie natürlich daran, die Objekte in den Tenants durch eigene Prozesse zu verwalten. Sie können mit ADSync ja einfach ihre eigenen Benutzer replizieren und mit anderen Lösungen die zusätzlichen Konten aus einem anderen Forest laden und bei sich verwalten.

Der Zugriff auf die lokalen Quellen könnte per LDAP oder AD-PowerShell erfolgen oder sogar andere Datenquellen wie Personalabteilung etc. kommen oder durch Prozesse angestoßen werden können.

Der Schreibzugriff in das AzureAD kann per AzureAD-PowerShell oder besser direkt per Graph erfolgen.

Eine direkte Nutzung des AzureAD-Connect-Backend ist ausgeschlossen, wie Microsoft deutlich beschreibt:

Bei all den Varianten dürfen Sie nicht vergessen, dass sie damit die Benutzer eines Active Directory bzw. Tenants auch in einem anderen Tenant anlegen. Es gibt hier jede Menge Abhängigkeiten, die über die reine Sichtbarkeit in einem Exchange/Outlook-Adressbuch hinaus gehen. So kann ein Wert im Feld "Mail" nur genau einem Objekt innerhalb des Tenants zugewiesen werden und damit mit einem bestehenden Gastbenutzer in Konflikt geraten. Je nach Konfiguration können die Anwender auch in Teams als "Kontakte" gefunden werden und vielleicht Federation stören oder zumindest die Anwender verwirren.

Sie sollten so eine komplexe Konfiguration nicht auf die leichte Schulter nehmen. Identity-Management und Verzeichnisabgleich sind komplexe und fehleranfällige Prozesse, die eine gute Planung, Verifikation, Implementierung und Betrieb erfordern

Testumgebung

Um ein paar Basisfunktionen besser kennenzulernen und natürlich Tests für Kunden und Entwicklung von Skripten durchführen zu können, ist mein Lab mittlerweile erweitert worden. Neben meinem Standard-Tenant "MSXFAQLAB", welcher mit dem lokalen Forest "uclabor.de" per ADSync verbunden ist, gibt es einen zweiten Forest mit einem zweiten Tenants.

Ich habe mich erst einmal darauf beschränkt, dass der mit vollen Lizenzen ausgestattete MSXFAQLAB-Tenant zusätzlich die Anwender aus dem zweiten Forest importieren soll. In der Standardvoraussetzung habe ich allerdings alle "Writeback"-Funktionen deaktiviert. Damit ist weiterhin ein Hybrid-Mode zwischen UCLABOR und MSXFAQLAB möglich.

Damit kann ich wunderbar die Situation nachstellen, dass zwei Firmen mit eigenen Tenants als 1:1 Beziehung arbeiten und eine Firma auch die Kontakte/Empfänger der anderen Firma in ihrem Tenant haben möchte.

Die Einrichtung ist einfach über den Setup-Assistenten von ADSync möglich. Siehe dazu ADSync Multi Forest. Zuerst habe ich danach natürlich die Berechtigungen in DOM2016 angeschaut. Hier sind dann beide ADSync-Dienstkonten, erkennbar am Prefix "MSOL_*", mit identischen Berechtigungen eingetragen:.

Das ist nur eine Teilmenge der Berechtigungen. Die Dienstkonten haben auch "Reset Password" und "Replicate Directory Changes" etc. und sind daher entsprechend sensibel zu betrachten.

Das ist besonders zu bedenken, da immer nur ein ADSync per Writeback auch diese Rechte ausnutzen darf.

Erster Sync

In meiner Umgebung war ADSync zur Verbindung von "UCLABOR.DE" mit dem "msxfaqlab"-Tenant schon länger aktiv und daher im "Delta"-Mode. Nachdem ich dann die zweite Verbindung zum DOM2016-Frest aufgebaut habe, ist die erste Synchronisation besonders interessant.

Die erste Aktion für diese neue Konfiguration ist natürlich ein "Full Import, in dem ADSync fünf neue Objekte lernt:

Ein Blick in die Details verrät, dass ADSync die beiden Testbenutzer und eine Gruppe importiert aber auch die OUs.

Das habe ich auch so erwartet, denn ADSync importiert immer auch die "Placeholder" zu einem Objekt. und auch die Felder eines Benutzers sind nicht überraschend.

Der DOM2016-Forest hat aktuell kein Exchange. ADSync nimmt aber nur nur Objekte mit, in denen das Feld "Mail" gefüllt ist.

Erster Export

Nach der "Full Synchronization" stand der erste Export in meinen Tenant an. Hier hat ADSync zwei Benutzer und eine Gruppe angelegt.

 Das "Update" kommt durch die Nachverarbeitung der Gruppenmitgliedschaften, die ADSync erst umsetzen kann, wenn alle Benutzer im Ziel vorhanden sind.

Sichtbarkeit im AzureAD

Neu neuen Objekte erscheinen natürlich in dem neuen Tenant. allerdings haben Sie natürlich einen anderen UPN o.ä. so dass diese Benutzer etwas anders angelegt wurden:

# Nur Ausgabe von Feldern mit Werten
PS C:\> Get-AzureADUser -SearchString ADUserA1 | fl *

ObjectId                       : da650362-86b0-4c88-9fc8-b9e9c941b741
ObjectType                     : User
AccountEnabled                 : True
AssignedLicenses               : {}
AssignedPlans                  : {}
DirSyncEnabled                 : True
DisplayName                    : ADUserA1
GivenName                      : ADUserA1
ImmutableId                    : AdMmxQtWG0K6dmf8O3St8g==
LastDirSyncTime                : 02.04.2022 15:51:55
Mail                           : aduserA1@dom2016.msxfaq.de
MailNickName                   : aduserA1
On-PremisesSecurityIdentifier   : S-1-5-21-2342664329-2581643318-3890112866-1112
OtherMails                     : {}
PasswordProfile                : class PasswordProfile {
                                   Password:
                                   ForceChangePasswordNextLogin: True
                                   EnforceChangePasswordPolicy: False
                                 }
ProxyAddresses                 : {SMTP:aduserA1@dom2016.msxfaq.de}
Surname                        : ADUserA1
UserPrincipalName              : aduserA1@msxfaqlab.onmicrosoft.com
UserType                       : Member

Es sind ganz normale Benutzer aber ohne Lizenz. Ich habe mal ausgewählte interessante Felder zwischen den beiden Tenants verglichen:

Feld/Tenant Haupttenant FCARIUS Zweittenant MSXFAQLAB
Mail
aduserA1@dom2016.msxfaq.de
aduserA1@dom2016.msxfaq.de
UserPrincipalName
aduserA1@fcarius.onmicrosoft.com
aduserA1@msxfaqlab.onmicrosoft.com
On-PremisesSecurityIdentifier
S-1-5-21-2342664329-2581643318-3890112866-1112
S-1-5-21-2342664329-2581643318-3890112866-1112
ImmutableId
AdMmxQtWG0K6dmf8O3St8g==
AdMmxQtWG0K6dmf8O3St8g==

Für mich interessant ist hierbei, dass mein Konto in dem zweiten Tenant, zu dem er eigentlich nicht gehört, einen Benutzer mit gleicher Mailadresse einer nicht registrierten Domain und identischen Daten in "On-PremisesSecurityIdentifier" und "ImmutableId" gefüllt sind. Microsoft scheint hier also nicht zu verhindern, dass Mailadressen und andere Felder über alle Tenants hinweg "eineindeutig" sind.

Sichtbarkeit in Produkten

Die nun im Zweittenant vorhandenen Benutzer sind natürlich in der in oder anderen Software sichtbar und adressierbar.

Produkt Beschreibung

Microsoft Teams

 

Die Benutzer können direkt in Teams gefunden werden und Anwender können den Benutzer auch anschreiben. Wenn der Benutzer denn wüsste, dass er ein aktives Anmeldekonto in den anderen Tenant hat und den UPN erraten könnte, wäre eine Anmeldung mit seinem Kennwort sogar möglich.

Es ist also kein "Lookup" auf eine Federation Adresse im anderen Tenant und damit eigentlich unerwünscht.

Eine ChatNachricht wird auf jeden Fall zugestellt. Solange der Anwender sich aber nicht anmeldet, wird Teams ihm diese Nachricht per Mail an die hinterlegte Adresse zustellen.

Outlook/Exchange

Etwas anders sieht es in Outlook aus. Der Benutzer ist im AzureAD definiert aber aus Sicht von Exchange ohne entsprechende Lizenz kein valider Exchange Empfänger. Er taucht auch im Exchange Admin Center oder der Exchange Online PowerShell erst einmal nicht auf.

Exchange Online weiß also gar nicht, dass es sich hier um einen "Kontakt" handelt.

Das ist auch verständlich, denn für ADSync hat das Quell-Objekt noch keine Exchange Properties.

SharePoint

Auch im SharePoint Admin Center kann ich diese Benutzer direkt verwenden. Ich habe dazu eine neue Teamsite angelegt und versucht die Benutzer als Mitglied zu addieren. Sie waren sofort nutzbar.

Das hat mich auch nicht überrascht, da es ja "normale Anwender" sind. Es fehlt ihnen allerdings die Lizenz.

Die Synchronisation eines Benutzers aus einem anderen fremden Forest in den eigenen Tenant scheint einfach zu sein. Fraglich ist aber die Sinnhaftigkeit dieser Lösung, da es keine Kontakte oder Gäste sind, sondern zusätzliche reguläre Anmeldekonten.

Erste Rückimport

Spätestens seit meinem Artikel ADSync Bidirektional wissen Sie aber auch, dass ADSync nicht nur Daten aus dem AD ausliest, sondern auch wieder in das AD zurückschreibt. Das passiert automatisch z.B. für das Feld "msdsconsistencyGUID", in dem sich ADSync die ImmutableID (Siehe auch SourceAnchor User) speichert.

Daher ganz mein zweiter Augenmerk auf die nächste Rückreplikation, die mit dem "Delta Import" aus dem Tenant startet:

Hier wurden die vorher neu angelegten drei Objekte gefunden.

Erster Rückexport

Diese drei Objekte werden über das Metaverse dann wieder synchronisiert und letztlich über einen "Delta Export" in das lokale AD geschrieben. Hier verhält sich dann ADSync anders, als bei der primären Domäne.

Zumindest in meinem Lab hat ADSync nicht in den zweiten Forest exportiert. Für mich bedeutet das auch:

  • ProxyAddresses
    Die Benutzer sind keine Exchange Empfänger im anderen Tenant und damit gibt es dort auch keine Änderungen an den ProxyAddressen, die wieder zurückgeschrieben werden müssten
  • ImmutableID/msdsConsistencyGUID
    Hier übernimmt ADSync den schon vorhandenen SourceAnchor des Quell-Forest. Es wird also kein eigener SourceAnchor durch die Cloud gebildet, sondern die ObjectGUID bzw. die msdsConsistencyGUID genutzt.

Sonderfall: Reihenfolge

Ausgehend von diesen Erkenntnissen stellen sich mir natürlich einige Sonderfälle eingefallen. Wenn ich ein Objekt in einem Forest anlege, dann habe ich erst einmal keine Kontrolle, welcher ADSync zuerst gewinnt. Es kann also passieren, das der "falsche" ADSync das Objekt zuerst findet. Also habe ich den ADSync in "FCARIUS" angehalten und einen neuen Benutzer angelegt. Der aktive ADSync zum Tenant "msxfaqlab" hat den Benutzer wie erwartet importiert  und diesmal beim zweiten Sync auch wieder in das lokale AD zurückgeschrieben.

Die Rechte dazu hat er, obwohl Microsoft davor warnt, wenn zwei ADSync-Instanzen ein "Writeback" machen. Hier ist es aber unkritisch, denn der "falsche" ADSync schreibt auch nur die msdsConsistencyGUID zurück, die auf der ObjektGUID basiert.

Beide ADSync-Installationen kommen bei dieser Aktivität auf das gleiche Ergebnis. Der Fall ist also unkritisch.

Sonderfall Gast ist vorhanden

Es gibt zwei Konfliktfälle mit Gästen. Im ersten Fall gibt es in einem Tenant schon einen Gast und erst danach wird ADSync mit dem anderen AD-Forest eingerichtet.

Um dies nachzustellen, habe ich

  1. ADSync gestoppt
    Zuerst habe ich den sekundären ADSync mit "Set-ADSyncScheduler -SyncCycleEnabled $true" gestoppt, damit er den Testbenutzer nicht replizieren kann
  2. Testbenutzer angelegt
    Dieser Anwender wurde dann durch den primären ADSync in seinen Heimattenant repliziert.
  3. Darauf wurde der Benutzer als Gast im sekundären Tenant eingeladen.
  4. ADSync gestartet
    Nach diesen Vorarbeiten habe ich dann den angehaltenen ADSync wieder gestartet. Beim Export in den Tenant konnte das Objekt nicht angelegt werden.

    In den Details wird direkt gemeldet, dass hier die Proxy-Adresse nicht eindeutig ist.

Die Replikation des gleichen AD-Objekts mit ADSync in zwei Tenants blockiert erst einmal die Nutzung der Gast-Benutzer-Funktion.

Über Änderungen an den ADSync-Regeln könnten Sie diesen Konflikt aber verhindern.

Sonderfall Gast einladen

Der zweite Fall ist die umgekehrte Situation, dass die Identität schon durch eine ADSync-Synchronisation im Tenant vorhanden ist und nun der gleiche Benutzer als "Gast" eingeladen werden soll. Mein Testfeld hat dazu ja schon alles geliefert, so dass ich in einem Tenant einfach einen Benutzer als Gast aus einem anderen Tenant addieren wollte

Der Versuch einen Benutzer eines anderen Tenants als Gast einzuladen, scheitert aber mit der gleichen Mailadresse.

Hier blockiert der GALSync-Ansatz mit ADSync die Nutzung von Gästen zur Zusammenarbeit.

Solche Einschränkungen machen die Nutzung von ADSync zum bereitstellen von Identitäten in einem zweiten Tenant wenig interessant.

Sonderfall Feldinhalte

ADSync überträgt die Objekte aus dem lokalen AD direkt 1:1: in das Ziel. Das bedeutet natürlich, dass mit den Standardmitteln keine Anpassungen umsetzbar sind. Es wäre ja schon interessant, wenn ich als abgebendes Active Directory oder aufnehmender Tenant die Inhalte transformieren könnte.

Ich denke da z.B. an eine Änderung des Displaynamens aus "Nachname, Vorname " zu "Nachname, Vorname (Firmenname)", um auch im Adressbuch sofort als "Extern" sichtbar zu werden. Auch andere Felder könnten eine Transformation erfahren. Es gibt sicher einige Firmen, die z.B.: das Feld "company" nicht korrekt füllen. Hier könnte ich als Admin im Zieltenant einfach das Feld vorbelegen.

Solche Anpassungen sind mit dem "Synchronization Rule Editor" im ADSync durchaus möglich. Allerdings sind dies nicht die einfachsten Einstellungen.

Gruppenmitgliedschaften

Ein Benutzer aus dem ADForest 1 kann nur dann Mitglied in einer Gruppe von ADForest2 sein, wenn es dazwischen eine Vertrauensstellung gibt. Dies ist der aber kein übliche Konfiguration zwischen zwei unabhängigen Firmen sondern eher zwischen Firmengruppen, Ressource Forests oder Migrationen der Fall. Ohne Trust verwaltet jeder Forest seine Gruppen und Mitgliedschaften eigenständig. Zudem sind natürlich in einer per ADSync verwalteten Gruppe die Mitglieder durch ADSync vorgegeben. Ich kann einen Benutzer, der von ADSync aus Forest2 geladen wird, nicht direkt eine ein Gruppe von Forest1 addieren.

So etwas wäre allenfalls denkbar, wenn ADSync schon beim Import und Sync die beiden Gruppen der beiden Forests "matchen" würde

Wenn ich also auf beiden Seite eine Gruppe mit der gleichen Mailadresse aufbaue und bei der Installation von ADSync auch ein Matching anhand des Felds "mail" aktiviert habe, dann könne es passen. Leider hat dies aber nicht funktioniert, da ADSync im Ziel beide Gruppen mit den individuellen Mitgliedern angelegt hat. da die SMTP-Domain auch "ADMergeGroup@mergetest.msxfaq.de" lautete und damit keinen Tenant gehörte, hatten beide Gruppen auch eigene dynamische Mailadressen.

Wenn ich daher Empfänger aus beiden Forests in einer gemeinsamen AzureAD-Gruppe als Mitglieder haben möchte, muss ich entweder lokal die Forests mit einem Trust verbinden und dort die Gruppe pflegen oder ich legen den Verteiler als "Cloud Only"-Gruppen an und pflege manuell die Mitglieder. Das gibt dann aber Probleme im Exchange Hybrid Mode, da die lokale Exchange Installation diesen Verteiler nicht kennt.

Ein Matching von Gruppen passiert nur zwischen einem On-Premises-Objekt und einem vielleicht schon vorhandenen Cloud-Objekte aber ADSync macht keinen "Merge" von zwei lokalen Gruppen in unterschiedlichen Forests zu einer AzureAD-Gruppe.

Einschätzung

Als ich das erste mal von "GALSync" in Verbindung mit ADSync gelesen habe, war ich elektrisiert. In mehreren Umgebungen wäre es schon hilfreich, wenn Identitäten aus einem Tenant als Kontakte oder Empfänger in einem anderen Forest automatisiert verwaltet werden könnten. Die praktischen Tests im Labor haben aber zumindest im April 2022 gezeigt, dass die Umsetzung in den meisten Fällen nicht ausreichen dürfte.

  • Es gibt Konflikte mit Gast-Konten aufgrund ProxyAdresses
  • Meine Testbenutzer waren nicht in Exchange als Empfänger" sichtbar
  • Sichtbarkeit in Teams stört bei Federation, da die User nicht "extern" suchen
  • Gemische Gruppen nur mit Trusts möglich
  • Anpassungen von einzelnen Feldern sind kaum möglich
  • Der Betreiber des importierenden ADSync bestimmt den Umfang
  • Das Dienstkonto des importierenden ADSync hat viel zu viel Rechte für "ReadOnly"
  • Die "Writeback"-Vorgabe verhindert, dass jede Firma für sich mit Writeback arbeitet

Ich habe sicher noch weitere Punkte vergessen. Aber der Einsatz ist wohl besser für eine ADSync T2T-Migration gedacht und geeignet.

Ich würde das nicht als "Lösung" für eine GALSync-Problematik ansehen.

Geht es besser?

Sicher stellt Microsoft mit ADSync eine einfache und vor allem kostenfreie Möglichkeit bereit, Benutzer eines AD-Forest in mehr als einen Tenant zu replizieren. Allerdings müssen Sie sich überlegen, ob diese Umsetzung ihren Anforderungen entspricht. Irgendwie denke ich wieder an meine CSV2EX. Ein Admin könnte die Liste der Empfänger exportieren und im Ziel lege ich sie eben als Exchange Kontakte im AD an und lass ADSync diese im Exchange Hybrid Mode replizieren. Wenn ADSync dies nicht kann, weil die Umgebung eine 1-Forest/2-Tenant Umgebung ist, dann müsste ich die Empfänger eben im Exchange online des Ziel-Tenant eben nativ anlegen.

Eine fertige Lösung hierfür habe ich noch nicht gefunden.

Weitere Links