Group Writeback

Mit Exchange Online und Microsoft Teams gibt es Empfänger in der Cloud, die nicht durch EntraID Connect oder EntraID CloudConnect aus einem lokalen Active Directory repliziert werden. Um allerdings ein abgeglichenes Adressbuch für Exchange anbieten zu können, sollten die Exchange Empfänger in der Cloud und OnPremises synchron sein. Diese Seite beschreibt die Geschichte von "Group Writeback" mit Microsoft 365.

Grundlagen

In der Einleitung habe ich es schon geschrieben: Bei einer Koexistenz von Exchange Online und Exchange OnPremises ist es wichtig, dass beide Exchange Systeme das gleiche Wissen über die verfügbaren Empfänger haben. Lange Zeit war es dazu ausreichend, wenn der damalige ADSync einfach alle lokalen Exchange Empfänger gelesen und in der Cloud provisioniert hat. Primär waren es Postfächer und Verteiler, die ADSync übertragen hat. Seltener waren auch Kontakte und Mailaktivierte öffentliche Ordner dabei. Die Exchange Online Administratoren haben sich damit abgefunden, dass Sie die Objekte nicht in Exchange Online verwalten konnten, sondern alle Änderungen im lokalen AD zu erfolgen hatten.

Und dann kamen Office 365 Groups, Microsoft Teams Teams und von unvorsichtigen Administratoren in der Cloud angelegte Verteiler, die von Anwendern als "Besitzer" mit Exchange Online und Outlook sogar selbst gepflegt werden konnten. Schade nur, dass Exchange Online von all dem nichts mitbekommen hat und die Empfänger im lokalen AD nicht bekannt waren. Exchange OnPremises hat zum Teil Mails an diese Adressen gar nicht angekommen oder in die falsche Richtung weitergesendet oder mit einer Unzustellbarkeitsquittung beantwortet.

Gruppen synchronisieren

ADSync hat anfangs keine Replikation von Gruppen und insbesondere deren Mitglieder aus Entra ID ins lokale AD erlaubt. Wenn Sie jetzt schnell mal ein "Da lesen wir die Gruppe mal schnell aus und legen diese im lokalen AD an" ausrufen wollen, dann warne ich davor, denn das ist alles andere als einfach. Das Auslesen per Graph API ist noch einfach und das Schreiben per LDAP/ADSI im lokalen AD ist auch kein Hexenwerk aber die Probleme sind im Detail. Hier ein paar offensichtliche Beispiele:

  • CloudOnly und Namen
    Natürlich können Sie als Administrator in EntraID einfach eine Gruppe anlegen. EntraID ist ja eher eine "flache NT4-Domain" und stellt schon sicher, dass Namen eindeutig sind. Aber das bedeutet nicht automatisch, dass der Name auch OnPremises nutzbar ist. Sie können ja nicht sicher sein, dass wirklich alle lokalen Identitäten auch in der Cloud sind.
  • CloudOnly und ADSync
    Neben wir an, wie finden eine neue Gruppe in der Cloud und kopieren diese in das lokale AD. Sie müssen sehr genau sicherstellen, dass die nun im lokalen AD bekannte Gruppe nicht durch EntraID-Sync gesehen und in die Cloud synchronisiert wird. Wenn Sie dank ADSync - Gruppen matchen zugeordnet wird, dann wird aus der "Cloud Only"-Gruppe eine DirSync-Gruppe und das Management in der Cloud wird unterbunden oder stark eingeschränkt. Wird sie nicht "gematched", dann haben Sie EntraID nun zwei Gruppen, deren Displayname vielleicht gleich ist. Das möchten Sie auch nicht.
  • Ziel-OU und Matching
    In EntraID gibt es keine OUs. Meine Lösung zum Anlegen der lokalen Gruppen sollte eine Ziel-OU für neue Gruppen nutzen, die nicht von ADSync gesehen wird. Ggfls. muss man später dann die Gruppen wieder anderweitig umsortieren aber die Lösung muss Sie dann auch wieder finden, denn nochmal mit gleichem Namen anlegen, geht auch nicht.
  • Mitglieder
    Die größter Herausforderung ist aber der Abgleich der Mitglieder. In EntraID können nämlich auch Gäste und CloudOnly-User als Mitglied addiert sein, die es aber OnPremises gar nicht gibt. Die Gruppe im lokalen AD kann daher nicht die gleichen "Member" enthalten. Sie kann sogar weitere lokale Objekte und Computer enthalten, das sie ja nicht wirklich gegen Veränderungen durch lokale Administratoren geschützt wird. Warnt der Abgleich dann oder löscht er die überzähligen Objekte im Ziel aus der Member-Liste?

Das sind nur einmal die Sonderfälle und Probleme, die mir sofort eingefallen sind und die bei einer Rückreplikation aus EntraID in ein lokales AD so alles auftreten können. Aber dennoch gibt es einen Bedarf und sogar Lösungen hierfür. Denkbar ist oder waren, z.B.:

  • CloudOnlyGruppen und EntraID Cloud Connect Group Writeback
    Die zweite Option sind Gruppen, die direkt in EntraID als "CloudOnly" angelegt werden aber dann durch EntraID Cloud Connect in das lokale AD übertragen werden. Es gibt hier keine ADSync-Replikation, die lokale Änderungen wieder in die Cloud überträgt, da dann die Cloud Gruppe per ADSync - Gruppen matchen wieder zu einer DirSync-Gruppe und damit aktuell wieder ReadOnly wird
    Testen und wie oft, Parallel zu ADSync mit Scope, Konflikte, Member für User ohne Sync?
  • CloudOnly Gruppe mit eigenem Skript, SCIM oder Provisioning
    Niemand zwingt sie zum Einsatz von ADSync oder Cloud Connect. Sie können durchaus auch mit eigenen Skripte, Microsoft Graph, ADSI/LDAP sich einen eigenen Sync schreiben. Das ist sicher keine allgemeine Lösung für alle Fälle aber ich habe schon solche Lösungen z.B. für Schulen mit lokalem OpenLDAP/SAMBA entwickelt, wo ADSync nicht nutzbar ist. Die Objekte in der Cloud sind dann zwar auch durch eine lokale Quelle "managed" aber aus Sicht von AzureAD nicht "DirSynched" und damit nicht ReadOnly. Die gleichen Prozesse können dann natürlich auch Änderungen in der Cloud erfassen und in lokale Verzeichnisse übertragen.

Aber Microsoft hat natürlich auch erkannt, dass die Exchange Online Empfänger in Form von Office 365 Groups bei einer Exchange Online - Hybrid-Bereitstellung auch dem lokalen Exchange bekannt gegeben werden müssen.

Lösungswege

Exchange Online und ADSync gab es seit ca. 2007, damals noch unter dem Namen "BPOS - Business Productivity Online Suite", aber es hat noch ein paar Jahre gedauert, bist der erste "WriteBack" in ADSync addiert wurde. Wer schon viele Jahre mit ADSync und Exchange Online arbeitet, kennt vermutlich mehrere Optionen, die bis Ende 2024 in der ein oder anderen Form installiert wurden:

Optionen Beschreibung  

Handarbeit/Skript

Es hat einige Zeit gedauert, bis Microsoft überhaupt den Bedarf erkannt hat. Bis dahin habe ich tatsächlich verschiedene PowerShell-Skripte auf Basis der Exchange Online PowerShell und der lokalen PowerShell gebaut, um all diese "Unified Groups" aus der Cloud zu lesen und lokal anzulegen und zu verwalten. Die Skripte sind heute nicht mehr im Einsatz

EOL

Group Writeback V1

Dann hat Microsoft mit ADSync eine Version 1 von "Groups WriteBack" geliefert. ADSync hat die entsprechenden Gruppen aus der Cloud ausgelesen und im lokalen AD "Platzhalterobjekte" angelegt. Das waren keine richtige Gruppen aber auch keine AD-Kontakte sondern spezielle Objekte, damit Exchange OnPremises wusste, welche Mailadressen schon verwendet werden.

EOL

Group Writeback V2

Seit Jul 2022 gab es dann eine neue Version, die im lokalen AD sogar richtige "Universal Distribution Groups" mit den Informationen aus Microsoft 365 samt Mitgliedern angelegt hat. Diese Funktion ist aber nie "RTM" gegangen, sondern war immer eine "Preview". Anfang 2024 wurde diese Funktion dann abgekündigt und kann seit dem nicht mehr neu eingerichtet werden.

EOL

Group Writeback CloudConnect

Stattdessen ist die Funktion "Sync EntraID zum lokalen AD" nun Bestandteil des Entra ID Cloud-Connect, Dazu ist allerdings eine EntraID P1-Lizenz erforderlich.

Aktuell

3rd Party Sync

Es ist natürlich weiterhin möglich, sich die CloudOnly-Gruppen z.B. mit Microsoft Graph zyklisch auszulesen und im lokalen AD per Exchange PowerShell zu verwalten.

OK

Allerdings sollten Sie hier keine "bidirektionale Replikation" erwarten. ADSync könnte das sicherlich aber aktuell sind durch ADSync in der Cloud verwaltete Objekte in der Cloud an vielen Stellen "ReadOnly". Wenn Sie absichtlich "CloudOnly"-Objekte nutzen, damit diese in der Cloud auch verwaltet werden können, dann sollten Sie diese nie vom lokalen AD in die Cloud replizieren, weil sie über die Funktion ADSync - Gruppen matchen sonst wieder "ReadOnly" werden.

Sync Überblick

Wenn Sie nun alle Bausteine bei Gruppen zusammenfügen, gibt es folgende Konstellationen.

  1. Synchronisierte lokale AD-Gruppen
    Das ist der Regelfall: per EntraID Connect oder EntraID CloudSync sollten Sie alle Exchange Verteiler und gerne auch andere Sicherheitsgruppen ins Entra ID replizieren, die Sie in der Cloud als Mailempfänger oder zur Vergabe von Berechtigungen o.ä. benötigen. Diese Gruppen können aber nur im lokalen AD verwaltet werden. Der Verzeichnisabgleich übernimmt natürlich auch die "Member" und versucht die Objekte auch im Ziel wieder als Mitglied zu addieren. Das gelingt natürlich nur, wenn die Mitglieder auch im Ziel durch den Verzeichnisabgleich angelegt wurden.
  2. Nicht synchronisierte Gruppen
    Es wird sicher einige Gruppen im lokalen AD geben, die nicht in Entra ID auftauchen sollen, z.B.: administrative Gruppen. Denken Sie aber daran, dass der SamAccountName einer Gruppe pro AD-Domain eindeutig sein muss, was bei Gruppen vom Typ 3 interessant wird.
  3. Cloud-Managed Groups mit WriteBack
    Sie können nämlich auch Gruppen in EntraID anlegen und z.B. durch Benutzer als "Besitzer" sogar verwalten lassen, wenn diese nicht durch ADSync gegen Änderungen blockiert werden. Diese Gruppen können Sie dann mit "Groups WriteBack" im lokalen AD anlegen lassen. Denken Sie daran, dass dann aber die Cloud der "Master" ist und sie die lokale Gruppe nicht ändern sollten, weil dies sonst zu Unstimmigkeiten führen kann. Die aus der Cloud ins lokale AD replizierte Gruppe sollte auch nicht wieder in die Gegenrichtung repliziert werden.
  4. CloudOnly-Gruppen
    Zuletzt wird es auch weitere CloudOnly-Gruppen geben, die auch nur in der Cloud bleiben.

Es ist nicht vorgesehen, dass eine Synchronisierung "Bidirektional" ist. Technisch wäre es möglich, denn ADSync ist ja eine "Light"-Version des großen Microsoft Identity Server/Forefront Identity Server

Member

Gruppen werden angelegt, um weitere Objekte als Mitglieder aufzunehmen darüber zu berechtigen oder Mails zuzustellen. Natürlich erwarten wir, dass auch diese Mitglieder synchronisiert werden. Groups Writeback V2 und Cloud Sync machen dies für die Mitglieder, welcher auch repliziert werden, d.h. Sie erkennen die Mitglieder in der Quelle anhand einer Referenz und suchen das passende Objekt auch im Ziel. Werden andere Benutzer, Gruppen oder Computer durch den Verzeichnisabgleich synchronisiert, dann können diese auch als Mitglied synchronisiert werden. Wenn es die Objekte auf der jeweils anderen Seite natürlich nicht gibt, dann werden Sie auch nicht verwaltet. Solche "Unstimmigkeiten" sind nicht immer sofort offensichtlich. Häufiges Problem sind Mails an Verteiler, die dann nicht bei allen Empfängern abkommen, wenn die "Group Expansion" auf dem falschen Server erfolgt.

Weitere Links