Group Writeback

Diese Seite beschreibt die Möglichkeiten, Gruppen aus dem AzureAD auch in das lokale AD zu übertragen. Dies ist eine andere Aufgabe als die Anlage von Exchange Empfängern im Exchange Hybrid Mode und Microsoft 365 Groups. Siehe dazu M365Groups Writeback. Hier gehe es um die Verwaltung von Gruppen in der Cloud über verschiedene Wege zu unterschiedliche Aufgabenstellungen und deren Verwendung im lokalen AD.

Beachte dazu auch die Seite ADSync Bidirektional und M365Groups Writeback

Umfeld

Auf der Seite ADSync und Gruppen habe ich beschrieben, wie lokale AD-Gruppen auch im EntraID mit ADSync verwaltet werden. Die Gruppen in der Cloud sind dann natürlich "ReadOnly". Eine echte bidirektional Replikation gibt es nicht und das haben insbesondere die Exchange Administratoren und Outlook Anwender immer wieder bemerkt. Sie können selbst als "Manager/Besitzer" einer Gruppe nicht die Mitgliedschaften verwalten. Für die "Microsoft 365 Groups" hat Microsoft mit der Funktion M365Groups Writeback eine eigene Lösung geschaffen, die eher eine Art "Kontakt" im lokalen AD anlegt, damit Exchange OnPremises die Empfänger in der Cloud kennt und erreichen kann.

Hier geht es aber nun um "richtige" Gruppen mit Mitgliedern, die direkt im EntraID verwaltet werden und nicht z.B. durch einen Verzeichnisabgleich mit ADSync geblockt sind. Es gab von Microsoft einige Zeit lang sogar eine "Group Writeback V2"-Preview mit ADSync, bei der zumindest die Mitglieder in Gruppen auch wieder ins lokale AD zurückgeschrieben wurden. Diese Funktion ist aber wieder abgeschaltet:


Quelle: Group writeback with Microsoft Entra Cloud Sync (Mai 2024)
https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync


ADSync Release History 2.32 https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/reference-connect-version-history#2320

Ein Wechsel zu AzureAD Cloud Sync ist der von Microsoft vorgeschlagene Weg. Sie können AzureAD Cloud Sync  auch parallel zu AzureAD Connect betreiben. EntraID Cloud Connect Sync ist die Variante von ADSync, die komplett in der Cloud administriert wird und mit einem lokalen Provisioning Agent arbeitet.

Gruppen synchronisieren

Da ADSync keine bidirektionale Replikation von Gruppen und insbesondere deren Mitglieder mehr erlaubt, müssen wir und für diese Funktion andere Alternativen betrachten. 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.

Und nur zur Sicherheit: Dies hat nichts mit M365Groups Writeback zu tun.

Entra ID Cloud Connect Writeback

Nachdem Microsoft das Zurückschreiben von Gruppen und Mitgliedern mit ADSync zum Sommer 2024 eingestellt hat, bleibt also nur noch der Weg durch eigene Skripte, 3rd Party Lösungen oder EntraID Cloud Connect. Da von Microsoft der Verzeichnisabgleiche mit AzureAD Cloud Sync sowieso präferiert wird, habe ich mir diese Funktion einmal angeschaut. Genaugenommen habe ich sie mir zweimal angeschaut, denn Cloud Sync können Sie "alleine" oder auch in Verbindung mit EntraID Connect (vormals ADSync) einsetzen. "EntraID Connect" brauchen Sie auch im Sommer 2024 noch immer dann, wenn Sie z.B. Computer mit als Hybrid Devices synchronisieren wollen (ADSync mit Devices) oder Exchange Hybrid (Exchange Online ADSync Provisioning) nutzen.

Entra ID Cloud Connect erlaubt das Synchronisieren von Gruppen aus ihrem Tenant in ein lokales AD unter einigen Voraussetzungen:

  • Entra ID P1-Lizenzen
    Die Funktion ist nicht im AzureAD Basic-Plan enthalten, der zu Office 365 gehört. Es darf also schon ein Microsoft 365-Paket pro Benutzer sein oder Sie lizenzieren EntraID P1 nach. Damit bekommen Sie dann auch Conditional Access, Azure AD Application Proxy und andere Funktionen dazu, die heute eigentlich sowieso dazugehören.
  • Lokales AD auf Windows 2016 Server
    Es muss nicht zwingend auch den Forest Functional Mode haben, aber der erste Windows 2016 DC addiert im Schema das erforderliche Feld "msDS-ExternalDirectoryObjectId"
  • Provision Agent Version 1.1.1370.0 oder neuer
    Dieser Agent wurde am 16. Oktober 2023 bereitgestellt. Prüfen Sie, ob bei ihnen der Agent automatisch aktualisiert wurde, z.B. durch einen Blick ins Azure Portal:
  • Rechte für dem Provisioning Agent
    Bei einer Neuinstallation erhält das Konto gleich die Rechte, Gruppen und User zu verwalten. Aus meiner Sicht ist das sogar ein sehr umfangreiches Recht, was aber per Default nicht auf Admin-Objekte wirkt (Siehe
    AdminSDHolder) Bei Bestandsinstallation müssen Sie einmal folgendes ausführen:
# Quelle: https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync
Set-AADCloudSyncPermissions `
   -PermissionType UserGroupCreateDelete `
   -TargetDomain "FQDN of domain" `
   -EACredential (Get-Credential)
  • Verbindungen zu den DCs auf LDAP (389/TCP) und GC (3268/TCP)
  • Entra Connect 2.2.8.0 oder höher
    Sollten Sie parallel noch mit Entra Connect auch Objekte in die Cloud replizieren, dann muss diese Mindest-Version genutzt werden, da nur Sie auch die lokale "objectGUID" der Benutzer in die Cloud in das Feld "onPremisesObjectIdentifier" überträgt und damit eine eindeutige Verarbeitung der Mitgliedschaften zuverlässig möglich ist.
  • Nur "Cloud Only Security Groups"
    Die Gruppen in der Cloud zur Rückreplikation dürfen also selbst keine "Dirsync-Gruppen" sein und auch keine RoleGroups, Microsoft 365 Groups oder reine Distributiongroups o.ä.
  • Legitime Mitglieder sind nur ADSyncUser des gleichen OnPremises-Forest und andere CloudVerteiler
    Es ist also nicht möglich, Gastkonten, CloudOnly-Benutzer oder DirSync User aus anderen Forests in einer Cloud-Gruppe zu addieren und dann zurückschreiben zu lassen. Die Objekte gibt es schlicht im lokalen Forest nicht.
  • Dynamische Mitgliedschaften sind aber erlaubt
    AzureAD erlaubt, vergleichbar zu Exchange "Querybased Distributiongroups", auch für Sicherheitsgruppen z.B. Mitgliedschaften anhand von Feldern wie Company, Country etc.
  • Universelle Gruppen im lokalen Forest
    Cloud Connect legt die Gruppen immer als "Universal Security Groups" an.
  • Max 50.000 Mitglieder
  • Abgleich alle 20 Minuten
    Änderungen im AzureAD/EntraID werden nach max. 20 Minuten im lokalen AD sichtbar. Denken Sie aber daran, dass ein Benutzer sich immer erst neu anmelden muss, um seine aktuelle Gruppenmitgliedschaft und damit verbundene Berechtigungen (NTLM-Token, Kerberos-Ticket) zu erhalten. Mailverteiler gehen aber schneller.
  • Kein bidirektionaler Abgleich
    Cloud Connect führt keine "Reconsiliation" durch, wenn Sie die lokale Gruppe an dem Dirsync vorbei ändern.

Das Grundprinzip ist dann:

Damit der "Sync3" die Gruppe samt ihren Mitgliedern auch ins lokale AD zurückschreiben kann, dürfte nur Objekte als Mitglied addiert werden, die auch im lokalen AD bekannt sind. Daher ist "Sync1" hier wichtig. Sie können auch Gruppen (Sync2) aus dem lokalen AD in die Cloud synchronisieren und sogar zum Mitglied machen. Achten Sie aber darauf, dass die in der Cloud verwaltete und ins lokale AD synchronisierte Gruppe wieder in die Cloud synchronisiert wird. Meine Empfehlung ist daher:

  • Nutzen Sie eine eigene OU für diese zurückgeschriebenen Gruppen
  • Kennzeichnen Sie dieser aus der Cloud verwalteten Gruppen über einen deutlichen Namen
  • Erlauben Sie keine Bearbeitung der AD-Gruppen in dieser OU

Einsatzweck

Sie wissen nun, wie Sie auch "Cloud Only"-Gruppen mit EntraID Cloud Sync in das lokale AD zurückreplizieren können. Da stellt sich die Frage, was denn der Sinn davon ist. Ich kann auf Anhieb zwei Beispiele aufführen.

  • Exchange Verteiler Management
    ACHTUNG: Diese Funktion ist aktuell nicht möglich, das Group Writeback keine "Mailenabled" Gruppen supportet
    Beim Exchange Hybrid Betrieb werden klassische alle Empfänger im lokalen AD verwaltet und zu Exchange Online synchronisiert. Eine Ausnahme ist die Funktion M365Groups Writeback. Da aber alle anderen Verteiler in der Cloud "ReadOnly" sind können Exchange Online Anwender selbst als "Manager" oder "Besitzer" z.B. diese Verteiler nicht mehr verwalten. Wenn nun aber sowieso schon die überwiegende Anzahl an Postfächern in Exchange Online sind, dann könnten die Sie Verteiler als "CloudOnly"-Verteiler anlegen und damit komplett in Exchange Online verwalten. Allerdings müssten sie dann sicherstellen, dass lokale Exchange Server diese Verteiler als Kontakte oder als zurückreplizierte Verteiler kennen um Unzustellbarkeiten zu verhindern.
  • OnPremises PIM
    Mit der passenden Lizenz (Entra ID P2) können Sie die Mitgliedschaften von Gruppen und RoleGroups in EntraID (PIM/PAM - Least Privileges) sehr fein und dynamisch steuern. Damit lassen sich privilegierte Rechte z.B. zeitlich beschränken. Mit Group Writeback können Sie solche Gruppen auch ins lokale AD replizieren und damit auch OnPremises die Berechtigungen auf Zeit vergeben. Siehe dazu auch PIM OnPremises und PIM OnPremises Skript

Das sind nur zwei Beispiele, wenn Sie Mitgliedschaften aus CloudOnly-Gruppen auch im lokalen AD bereitstellen.

Konfiguration

Im Bereich EntraID Cloud Sync habe ich schon mehrere Einstellungen zu Cloud Sync dokumentiert. Die Rückreplikation ist eine eigene Konfiguration, die Sie über https://portal.azure.com. Zuerst müssen sie natürlich die CloudSync Einrichtung durchlaufen und den Agenten installieren.

Der Provisioning Agent kann problemlos auch parallel zu seiner ADSync-Installation laufen. Zukünftig wird Cloud Sync auch ADSync ablösen. Noch sind aber nicht alle "Features" vorhanden, z.B. Support Hybrid-Device-Join und Exchange Hybrid.

Wählen Sie die passende Extension aus:

Nach der Authentifizierung am Tenant wird der Provisioning Agent eingerichtet. Erst dann können Sie im Azure Portal eine "Cloud Sync"-Konfiguration anlegen.  Hier geht es nun um die Rückreplikation aus EntraID in das lokale AD:

Es kann manchmal etwas dauern, ehe ein gerade installierter Agent zur Auswahl steht. In den folgenden Dialogen, die Microsoft gut dokumentiert hat, wählen Sie die zu replizierenden Gruppen (Filter) aus und geben die Ziel-OU zum Schreiben an.

Einschätzung

Gewöhnen Sie sich langsam daran, dass der "alte ADSync" immer weniger Funktionen erhält und Microsoft den Verzeichnisabgleich mit EntraID Cloud Sync immer weiter forciert. Der Wegfall von "Group Writeback V2" in ADSync zugunsten von Cloud Sync ist ein deutliches Zeichen. Das ist aber nicht schlimm, da beide Synchronisationstools sogar parallel betrieben werden können und damit der langsame Übergang schon eingeleitet werden kann. Ich hoffe ja darauf, dass Cloud Connect zukünftig noch viel mehr Objekte und deren Properties auch wieder ins lokale AD zurückschreiben kann, denn viele Einstellungen werden heute schon direkt in EntraID vorgenommen. Die für Group Writeback erforderliche EntraID P1-Lizenz sollte heute kein Problem mehr sein, denn die Security Defaults sind nachweislich nicht sicher genug.

Als Backend für ein OnPremises-PIM kann die Funktion Group Writeback nur genutzt werden, wenn Sie bis zu 20 Minuten Zeit haben und Security Groups statt der sichereren RoleGroups verwenden. Aber auch dafür gibt es Lösungen (z.B. PIM OnPremises Skript)

Weitere Links