Cloud Gruppen

Auf dieser Seite geht es um die verschiedenen Aspekte von Berechtigungen im Tenant, auf Daten und dem Abgleich mit einem lokalen AD und Exchange.

Geschmacksrichtungen

Wenn Sie das erste mal eine Gruppe im Microsoft 365 Admin-Center anlegen wollen, dann bietet ihnen der Assistent gleich eine ganze Menge unterschiedlicher Möglichkeiten an und empfiehlt direkt eine "Microsoft 365 Gruppe" ohne auf die Details einzugehen.

Mittlerweile hat Microsoft den Assistenten schon wieder geändert aber ich nutze die frühere Version weiter als Aufhänger für den Artikel.

Natürlich ist eine "Microsoft 365 Gruppe" eine sehr flexible Variante aber zugleich die einzige Option, die im Grund gar keine Gruppe ist. Zumindest nicht im klassischen Sinn. Im Juni 2024 hat Microsoft den Dialog umgestaltet und zeigt nun die drei Hauptkategorien und darunter dann die jeweiligen Unterkategorien an.

Daher müssen wir uns die verschiedenen Gruppen und deren Einsatzbereichen etwas genauer anschauen.

Die klassische Lehre

Vergessen wir erst einmal die Cloud und Microsoft 365 und denken wir an einen reine lokale Umgebung mit Windows Servern, Clients und einer Domain. Nach meinem Kenntnisstand war Windows NT3.1 (Sommer 1993) der erste Server von Microsoft, der eine Domain aufbauen konnte und damit Benutzer nicht mehr auf jedem Client lokal angelegt werden mussten. Damit mussten sich die Administratoren überlegen, wie Sie Berechtigungen für den Zugriff au Ressourcen vergeben wollten. Eine direkte Berechtigung von Benutzern ist zwar schon immer möglich aber bald nicht mehr zu verwalten. Damit waren die Windows Sicherheitsgruppe im Spiel, und wer es strukturiert machen wollte, hat schon damals eine dreistufige Berechtigung aufgebaut.

  • Benutzer sind Mitglied in Abteilungs- und Funktionsgruppen
    Das waren dann "NT4 Domaingruppen" oder "AD-Universal Security Groups" und konnten auch gut für Exchange Verteiler genutzt werden
  • Abteilungsgruppen sind mit Mitglied in Berechtigungsgruppen
    Ale Berechtigungsgruppe über mehrere Server konnte die "AD-Domain lokale Sicherheitsgruppe" oder gleich eine auf dem Server lokale Gruppe verwendet werden
  • Berechtigungsgruppen werden auf die Daten berechtigt
    Wenn pro Ressource dann auch nur eine oder zwei Gruppen (ReadOnly/ReadWrite) vorhanden sind, dann erkennt man sofort fremdvergebene Berechtigungen

Neue Anwender mussten einfach nur in die Abteilungs- und Funktionsgruppen addiert werden, um auf aus allen erforderlichen Zielen berechtigt zu sein. Umgekehrt konnte ein Administrator über die Berechtigungsgruppen quasi dokumentieren, wer auf welche Ressourcen berechtigt war. Zudem konnte nur jemand mit Admin-Rechten auf den Server so eine lokale Gruppe verändern.

Später kam dann Exchange dazu und natürlich haben sich die Abteilungsgruppen direkt als Mail-Verteiler aktivieren lassen. Exchange hat dazu gerne diese Gruppen dann immer zu "Universal Security Groups" konvertiert, damit auch in einer Umgebung mit mehreren Domains diese im globalen Katalog auffindbar waren.

Gruppen in AzureAD/EntraID

Wenn Sie ihren Tenant angelegt und hoffentlich die Checkliste Tenant Einrichtung durchgearbeitet haben, dann können Sie sich in EntraID ebenfalls die Gruppen anschauen. Im Portal unter https://portal.azure.com können Sie allerdings nur "Security Groups" oder "Microsoft 365 Groups anlegen.

Im klassischen Microsoft 365 Admin Center können Sie aber auch "Distributionlists" anlegen. Das ist eine kleine Inkonsistenz:

Im Microsoft 365 Admin Portal werden sie bei Verteilern allerdings gezwungen, einen Besitzer anzugeben. Die Pflege der Mitglieder hingegen ist in beiden Portalen möglich. Aber nur im AzureAD-Portal können Sie die Mitgliedschaften von "Assigned", d.h. statisch zugewiesen auf "dynamisch" umstellen. Dynamische Gruppen kennen Sie vielleicht von Exchange, die aber nur als Mailverteiler und nicht als Sicherheitsgruppe verwendet werden können. Im AzureAD können Sie aber auch die Mitglieder von Sicherheitsgruppen dynamisch an den verschiedenen Properties der Benutzer festmachen. Es gibt dann einen Hintergrundprozess, der die Mitglieder mit etwas Verzögerung aktualisiert. Wenn das nicht funktioniert, dann sehen Sie folgende Meldung im AzureAD Portal:

Dynamic distribution groups (DDGs) are mail-enabled Active Directory group objects that are created to expedite the mass sending of email messages and other information within a Microsoft Exchange organization.
The membership list is now stored for each DDG and is updated once every 24 hours. 
... Users have to wait up to 2 hours for the membership list to be recalculated and links updated.
Quelle: https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-dynamic-distribution-groups/manage-dynamic-distribution-groups?tabs=create-new-eac 

Microsoft 365 Gruppen

Eine Sonderfunktion nehmen Office 365 Groups, die mittlerweile Microsoft 365 Groups benannt sind, ein. Sie sehen auf der einen Seite wie eine Gruppe aus, das Sie Mitglieder haben und als Mailverteiler fungieren können. Mit jeder Gruppe ist aber auch ein Datenspeicher in Exchange Online verbunden und steht damit im Konkurrenz zur früheren "Shared Mailbox". Die Microsoft 365 Gruppe kann zudem auch ein "Teams Team" sind und bekommt damit noch eine SharePoint Bibliothek angebunden.

Interesssant sind diese Microsoft 365 Gruppen, da Sie nur Benutzer oder Gäste als Mitglieder haben dürfen aber keine andere Gruppen. Hier ist keine Rekursion möglich, d.h. eine Person muss immer direkt Mitglied in der Microsoft 365 Gruppe sein und kann diese Rechte nicht indirekt über eine andere Gruppe bekommen.

Übersicht

Damit haben wir folgende Gruppen:

  Sicherheit Verteiler Mitglieder Dynamisch Undelete ADSync Datenspeicher Einsatzzweck

Verteiler (Statisch)

Nein

Ja

User, Gast, Kontakt, MailSG (Über Exchange)

Nein (nicht änderbar)

Nein

Ja

Nein

Mailverteiler

Verteiler (Dynamisch)

Nein

Ja

Mailempfänger (über Exchange)

Ja (nicht änderbar)

Nein

Nein

Nein

Mailverteiler

Sicherheitsgruppe (Statisch)

Ja

Nein

 

Nein  (änderbar)

Nein

Ja

Nein

Berechtigungen

Sicherheitsgruppe (Dynamisch)

Ja

Nein

 

User oder Device  (änderbar)

Nein

Nein

Nein

Berechtigungen

Mail Enabled Sicherheitsgruppe

Ja

Ja

User, Gast, Kontakt, MailSG (Über Exchange)

Nein  (nicht änderbar)

Nein

Ja

Nein

Mailverteiler, Berechtigungen

Microsoft 365 (dynamisch)

Ja

Ja

User, Gast

User (änderbar)

Ja

Nein

Ja

Teams, Planner, OneNote, Mailverteiler, Berechtigungen,

Microsoft 365 (Statisch)

Ja

Ja

User, Gast

Nein (änderbar)

Ja

Nein

Ja

Teams, Planner, OneNote, Mailverteiler, Berechtigungen,

Beachten Sie dabei:

  • In EntraID wird nicht nach universellen, globalen, lokalen Gruppen o.ä. unterschieden.
  • Bei der dynamischen Mitgliedschaften gibt es zumindest bei der Sicherheitsgruppe noch die Unterscheidung nach Benutzern oder Devices
    Eine nachträgliche Änderung der
  • Optional können Sie eine Sicherheitsgruppe oder Verteilergruppe zusätzlich zur Nutzung bei EntraID Berechtigungsrollen zulassen.
  • Einige Einstellungen sind im AzureAD-Portal nicht erreichbar
    z.B. das Anlegen und Pflege von Mailverteilern, Mailcontacts. Das geht nur über das Exchange Admin Portal

All diese Gruppen sind erst einmal ohne ADSync beschrieben. Die Spalte ADSync zeigt aber, welche Gruppen durch ein lokales AD synchronisiert und verwaltet werden können.

ADSync und Gruppen

Die meisten Firmen haben lokal ein Active Directory mit ihren umfangreich gepflegten Lokalen, domainlokalen, domainglobalen und universellen Gruppen und all diese Gruppen kann ADSync problemlos auslesen und ins AzureAD synchronisieren. Dazu müssen Sie folgendes Wissen:

  • Mitglieder müssen synchronisiert sein
    Wenn Sie eine Gruppe ins AzureAD abgleichen und die lokalen Mitglieder nicht nicht auch mit ADSync in den Tenant synchronisiert, dann gibt es Warnungen im ADSync und die Mitglieder der Gruppe in der Cloud sind nur partiell. Bei Berechtigungen ist das weniger ein Problem, da sich der Benutzer sowieso nicht anmelden kann aber bei Mailverteilern bekommt er die Mails aus der Cloud nicht.
  • ReadOnly in der Cloud
    Sobald eine Gruppe durch ADSync verwaltet ist, ist das lokale AD "führend" und sie können in der Cloud quasi keine Einstellungen an der Gruppe mehr vornehmen. Das ist auch zwingend, da sie bei Cloud Only Gruppen, auch Gäste und andere CloudOnly-Objekte als Mitglied aufnehmen können, die es im lokalen AD nicht gibt. Das ist aber keine Garantie, dass die Gruppe in der Cloud keine zusätzlichen Mitglieder enthält.
  • Kein WriteBack
    Wenn Sie eine "CloudOnly"-Gruppe anlegen, dann wird diese nicht ins lokale AD zurückübertragen. Sie können "Microsoft 365 Groups" über die Funktion M365Groups Writeback als Exchange Empfänger im lokalen AD anlegen, damit sie dort auch im Adressbuch erscheint. Es ist aber mit einem MailContact zu vergleichen
  • Microsoft 365 Groups sind außen vor
    Die neuen Microsoft 365 Gruppen mit ihren Mitgliedern sind für ADSync unsichtbar und nicht verwaltbar, d.h. diese Gruppen sind nicht durch ADSync mit dem lokalen AD verknüpfbar.

Wer ein lokale Active Directory hat, sollte also genau trennen, welche Gruppen als "CloudOnly" anlegt und dort verwaltet werde und welche Gruppen im lokalen AD verwaltet werden und damit in der Cloud "ReadOnly" sind.

EntraID Dynamische Gruppen

Wenn Sie die Mitglieder nicht statische pflegen wollen, dann können Sie eine CloudOnly Gruppe in EntraID auch auf die Einstellung "Dynamic User" oder "Dynamic Device" stellen. Das geht bei der Neuanlage aber auch für bestehende Gruppen:

Die Einstellung kann nur bei "CloudOnly Security Groups" als auch bei "Microsoft 365 Groups" geändert werden. Verteilergruppen und alle per Dirsync replizierte Gruppen können nicht auf eine dynamische Mitgliederverwaltung umgestellt werden. Die dynamischen Gruppen in der Cloud werden werden auch nicht in "Echtzeit" umgesetzt, sondern ein Hintergrundprozess in EntraID aktualisiert die Mitglieder anhand der Abfrage alle 24 Stunden.

If everything looks correct, allow some time for the group to populate. Depending on the size of your tenant, the group may take up to 24 hours to populate the first time, or after a rule change.
Quelle: https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/dir-dmns-obj/troubleshoot-dynamic-groups#members-are-not-added-or-removed-as-expected

 

Mitgliedschaft alle 24h

 

Exchange Online Dynamische Gruppen

Exchange OnPremises hat seit der Version 2000 keinen eigenen Verzeichnisdienst mehr, sondern stützt sich zu 100% auf das Active Directory. Exchange OnPremises kennt auch dynamische Verteiler, deren Mitglieder anhand einer LDAP-Anfrage immer dann ermittelt werden, wenn eine Mail an den Verteiler gesendet und damit verteilt werden muss. Dies ist aber keine "Gruppe" sondern ein "besonderes AD-Objekt" mit dem Typ "msExchDynamicDistributionList" und wird auch nicht durch ADSync in die Cloud übertragen. Einige Firmen verwalten manuell Kontakte in der Cloud, damit Exchange Online die lokalen Verteiler im Adressbuch anzeigen kann.

Dies gilt nicht, wenn Sie klassische Verteiler oder Sicherheitsgruppe nutzen und die Mitglieder per Skript pflegen, wie ich das auf Tools: Querybased Security Group beschrieben habe.

In Exchange Online gibt es aber auch dynamische Verteiler, die Sie per Exchange Online PowerShell oder über das Admin Center anlegen können:


Quelle: https://admin.exchange.microsoft.com/#/groups

Wer dann aber nach dieser Gruppe im AzureAD/EntraID sucht, wird sie nicht im klassischen Portal finden. Exchange Online nutzt nicht direkt das AzureAD/EntraID, sondern hat einen eigenen Verzeichnisdienst, dessen Objekte aber über eine Synchronisierungsplattform mit EntraID und dem lokalen AD abgeglichen werden. Siehe dazu auch Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr. Eine dynamische Verteilerliste in Exchange Online ist ein Eintrag im Exchange Online Directory, zudem es kein Gegenstück im EntraID gibt.

Im Gegensatz zu Exchange OnPremises, wo bei jeder Mail an die Gruppe die Mitglieder in Echtzeit per LDAP aufgelöst werden, passiert dies in Exchange Online nicht. Hier generiert ein Hintergrundprozess die Mitgliederliste in der Regel mit bis zu 2 Stunden Verzögerung nach Anlage oder Änderung. Zudem kann es bis zu 24 Stunden dauern, bis bei Änderungen an den Mitgliedern selbst die Mitgliedschaft aktualisiert wird.

The membership list is now stored for each DDG and is updated once every 24 hours. You'll know exactly to whom the message is being sent, and it also addresses potential compliance issues. By storing the calculated list of members on the DDG object, messages can be delivered more quickly and our service will have greater reliability.
Quelle: https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-dynamic-distribution-groups/modern-dynamic-distribution-groups#ddg-behavior-changes 

Diese Vorgänge können auch nicht beschleunigt werden.

Wer noch ein OnPremises-AD hat, kann natürlich weiter lokale Verteiler einsetzen und deren Mitglieder mit Skripten wie Tools: Querybased Security Group pflegen und mit ADSync zu Exchange Online replizieren lassen. Ein Skript zur dynamischen Mitgliederpflege z.B. mittels Graph z.B. als Azure Functions wäre auch denkbar.

Rollengruppen

Sie können aber nicht nur Mitglied in einer "Gruppe" sein, sondern auch in einer "Role Group". Diese Objekte sind nur auf den ersten Blick Gruppen, denn Sie können nicht als Mailverteiler oder Sicherheitsgruppe zur Berechtigung auf Daten genutzt werden sondern sind ausschließlich für die Berechtigungen im EntraID zu verwenden. Dies ist ein Unterschied zum lokalen Active Directory. Dort konnten Sie eine Sicherheitsgruppe nur nur zur Berechtigung auf Dateien, Verzeichnissen und Freigaben verwenden, sondern problemlos auch Berechtigungen auf OUs und AD-Objekte gewähren.

Microsoft definiert jede Menge EntraID Role Groups vor aber sie können jederzeit auch eigene Role Groups anlegen und mit Berechtigungen versehen.


https://portal.azure.com/#view/Microsoft_AAD_IAM/RolesManagementMenuBlade

Kleine und mittlere Unternehmen sollten fast immer mit den "Build-In"-Rollen von Microsoft auskommen und diese verwenden. Wenn Sie eigene Rollen definieren wollen, dann planen sie vorher das "Warum", "Wo dokumentiert", "Wie umgesetzt" und "Wie überwacht" sehr sorgfältig.

Es gibt noch einen Sonderfall. Sie können auch normale EntraID-Gruppen so konfigurieren, dass diese als Mitglied in einer RoleGroup aufgenommen werden können. Dies ist aber nur während der Anlage und nicht nachträglich möglich. Zudem gelten weiteren Einschränkungen für diese Gruppen. Damit möchte Microsoft verhindern, dass jemand plötzlich zusätzliche Berechtigungen erlangen kann.


https://portal.azure.com/#view/Microsoft_AAD_IAM/AddGroupBlade

Auch hier würde ich ganz vorsichtig mit solchen Gruppen umgehen, da die Einschränkungen ihnen an anderer Stelle, z.B.: dem Provisioning, das Leben schwer machen können.

Weitere Links