Was bedeutet Entra ID Gruppenbesitz Governance?
Entra ID Gruppenbesitz Governance beginnt mit einer Zugriffsfrage: Wer kann ändern, welche Personen über eine Gruppe zugelassen werden, und wer bleibt verantwortlich, wenn sich ihr Zweck ändert? Microsoft unterscheidet Objektbesitz von Verzeichnisrollen. Ein Gruppenbesitzer kann die Eigenschaften, Besitzer und Mitgliedschaften seiner eigenen Gruppe verwalten; das manuelle Hinzufügen und Entfernen von Mitgliedern gilt für die Mitgliedschaft vom Typ Assigned. Der Besitz gibt dieser Person keine Verwaltungsrechte über sämtliche Gruppen. Microsoft Learn: Standardberechtigungen für Benutzer.
Diese Befugnis ist relevant, wenn eine Gruppe eine tatsächliche Ressource steuert. Microsoft dokumentiert Zuweisungen von Unternehmensanwendungen über Gruppen: Benutzer in der zugewiesenen Gruppe erhalten Zugriff, verschachtelte Gruppen werden dabei nicht berücksichtigt. Die gruppenbasierte Anwendungszuweisung erfordert Entra ID P1 oder P2. Die betriebliche Schlussfolgerung liegt nahe: Wer die Mitgliedschaft dieser Gruppe ändern kann, kann auch den Personenkreis ändern, der den zugewiesenen Anwendungszugriff erhält. Stellen Sie zuerst die tatsächliche Anwendungszuweisung fest; der Besitz einer anderen Gruppe belegt keinen solchen Zugriff. Microsoft Learn: Benutzer und Gruppen Anwendungen zuweisen.
Bei einer Microsoft 365-Gruppe, die mit einer SharePoint-Teamwebsite verbunden ist, werden Besitzer zu Websitebesitzern und Mitglieder zu Websitemitgliedern. SharePoint kann außerdem Berechtigungen unabhängig von der verbundenen Gruppe halten. Ihre Prüfung sollte deshalb sowohl die Gruppenbeziehung als auch die weiteren Berechtigungen der Website erfassen. Das Entfernen eines Gruppenmitglieds reicht nicht als Beleg dafür aus, dass sämtliche unabhängigen Zugriffswege auf eine Website verschwunden sind. Microsoft Learn: Freigaben und Berechtigungen in SharePoint.
Dieser Leitfaden unterscheidet sechs Prüfsignale: einen Gast als Besitzer, keinen Besitzer, keine Mitglieder und keine übergeordnete Beziehung, die Sichtbarkeit Public, fehlende mandantenweite Ablaufabdeckung und eine große erfasste Mitgliedschaft. Sie beantworten unterschiedliche Fragen. Keines belegt eine Kompromittierung, eine mandantenweite administrative Rolle oder eine geschäftliche Entscheidung zur Löschung einer Gruppe. Die genauen EtcSec-Prädikate folgen unten mit ihren Quellstellen.
Wie Besitz, Gasteinstellungen und Ablauf funktionieren
Gastbesitz ist an Bedingungen geknüpft
Für Microsoft 365-Gruppen steuert die Einstellung AllowGuestsToBeGroupOwner in Group.Unified, ob ein Gast Besitzer sein kann. AllowGuestsToAccessGroups betrifft den Zugriff auf Gruppen und deren Daten; AllowToAddGuests betrifft die Gastmitgliedschaft. Behandeln Sie diese als getrennte Entscheidungen, statt eine einzelne Einstellung als Erlaubnis für alle drei Vorgänge zu lesen. Die Einstellungsübersicht nennt den Microsoft 365-Geltungsbereich und die erforderliche P1-Lizenz für die Besitzereinstellung. Microsoft Learn: Gruppeneinstellungen.
Microsofts Konfigurationsreferenz nennt für AllowGuestsToBeGroupOwner den Standardwert False. Ein Mandant erlaubt nicht automatisch Gastbesitzer für Microsoft 365-Gruppen, nur weil er Zusammenarbeit unterstützt. Prüfen Sie die wirksame Konfiguration und die tatsächliche Besitzerzuweisung gemeinsam. Wenn kein angepasstes Einstellungsobjekt existiert, ziehen Sie die Vorlagenstandards heran, statt ein fehlendes Objekt als Erlaubnis zu interpretieren. Microsoft Learn: Gruppeneinstellungen konfigurieren.
Übertragen Sie diese Group.Unified-Steuerung nicht auf eine pauschale Regel für alle Sicherheitsgruppen. Graph dokumentiert separat das Hinzufügen von Benutzern oder Dienstprinzipalen als Besitzer von Microsoft 365- oder Sicherheitsgruppen. Bei einer mit Teams verbundenen Gruppe kann die Besitzersynchronisierung bis zu zwei Stunden dauern; manche Teamänderungen setzen außerdem voraus, dass der Besitzer Mitglied ist. Microsoft Learn: Gruppenbesitzer hinzufügen.
Gasteinschränkungen beeinflussen auch die verfügbare Verwaltungsoberfläche. Bei eingeschränkten Gastberechtigungen zeigt My Apps die Liste der Gruppen, die ein Gast besitzt oder denen er angehört, nicht an. SharePoint und Teams behalten ihre eigenen Gaststeuerungen. Eine beobachtete Besitzerbeziehung ist deshalb ein Prüfsignal, kein Beleg dafür, dass jede Verwaltungsaktion über jede Oberfläche gelingt. Validieren Sie den konkreten Vorgang und Dienst in einer autorisierten Testumgebung. Microsoft Learn: Gastberechtigungen einschränken.
Betrachten Sie ein beispielhaftes Zugriffsszenario: Eine Gruppe mit Assigned-Mitgliedschaft gewährt Zugriff auf eine Projektanwendung, und ein Gast ist autorisierter Besitzer. Eine Mitgliedschaftsänderung könnte den Zugriff auf diese Anwendung verändern, sofern der betreffende Vorgang erlaubt ist. Dies ist eine Schlussfolgerung aus dokumentierten Besitzerrechten und Anwendungszuweisungen, kein beobachteter Vorfall und keine nachgewiesene Eskalation zum Global Administrator. Dokumentieren Sie die Ressource und die geltenden Einschränkungen, bevor Sie das Szenario als handlungsrelevanten Zugriffspfad behandeln. Besitzerberechtigungen, Anwendungszuweisung.
Besitzerlos, leer und ungenutzt sind unterschiedliche Zustände
Eine Gruppe kann Mitglieder ohne Besitzer haben. Eine andere kann einen Besitzer ohne Mitglieder haben. Eine dritte kann leer sein und dennoch für einen geplanten Workflow benötigt werden. Erfassen Sie Besitz, Mitgliedschaft, übergeordnete Beziehungen und Geschäftszweck in getrennten Prüffeldern. group-no-owner.go:37 im Collector untersucht Besitzer; group-orphaned.go:39 untersucht Mitglieder und übergeordnete Beziehungen. Keine der Funktionen misst den geschäftlichen Bedarf.
Microsofts Richtlinie für besitzerlose Gruppen gilt für Microsoft 365-Gruppen und ist nur in öffentlichen Clouds verfügbar. Sie sendet berechtigten Mitgliedern Einladungen mit einer Aktion zur Übernahme des Besitzes; Benachrichtigungsdauer und Berechtigung über Sicherheitsgruppen sind konfigurierbar. Es handelt sich um einen Wiederherstellungsworkflow, der die Annahme durch Mitglieder erfordert, keine automatische Zuweisung von Verantwortung. Microsoft Learn: Ressource ownerlessGroupPolicy.
Wenn während des Benachrichtigungszeitraums niemand annimmt, enden die Benachrichtigungen, und Administratoren müssen einen Besitzer finden und zuweisen. Microsofts Administrationsleitfaden dokumentiert außerdem Lizenz- und Postfachvoraussetzungen für Benachrichtigungen. Nehmen Sie diese Warteschlange ungelöster Fälle in das Betriebsverfahren auf; allein das Aktivieren der Richtlinie belegt nicht, dass alle besitzerlosen Gruppen verantwortliche Besitzer erhalten haben. Microsoft Learn: besitzerlose Gruppen und Teams verwalten.
Ablauf gilt für Microsoft 365-Gruppen
Eine Ablaufrichtlinie gilt für Microsoft 365-Gruppen, nicht für jede Sicherheitsgruppe. Aktive Gruppen können sich kurz vor dem Ablauf durch dokumentierte Aktivitäten in Outlook, SharePoint, Teams oder Viva Engage automatisch verlängern. Nicht verlängerte Gruppen werden gelöscht; es gilt ein Wiederherstellungszeitraum von 30 Tagen. Eine langlebige Gruppe kann daher unter einer gültigen Richtlinie immer wieder verlängert werden. Ihr Alter allein beweist keine fehlende Ablaufabdeckung. Microsoft Learn: Ablauf von Microsoft 365-Gruppen.
Die Ressource groupLifecyclePolicy trennt Lebensdauer und Abdeckung: groupLifetimeInDays definiert das verlängerbare Intervall, während managedGroupTypes den Wert All, Selected oder None hat. Bei Selected muss die Einbeziehung der jeweiligen Gruppe geprüft werden. alternateNotificationEmails stellt Benachrichtigungsadressen für Gruppen ohne Besitzer bereit. Behandeln Sie ein verlängertes Ablaufdatum als Lebenszyklusbeleg, nicht als geschäftliche Bestätigung. Microsoft Learn: Ressource für Lebenszyklusrichtlinien.
Öffentliche Sichtbarkeit erfordert eine Ressourcenprüfung
Microsoft beschreibt Public als Möglichkeit für Benutzer, ohne Besitzererlaubnis beizutreten, während Private diese Erlaubnis verlangt. Private Mitgliedschaft ist nicht automatisch verborgen; HiddenMembership ist ein eigener Wert. Öffentliche Gruppensichtbarkeit sollte eine Prüfung des vorgesehenen Beitritts und der verbundenen Ressourcen auslösen. Für sich genommen belegt sie weder anonymen Internetzugriff noch einen erfolgreichen Datenabruf. Microsoft Learn: Optionen für Gruppensichtbarkeit.
Erkennung: das Verzeichnis erfassen, bevor Befunde interpretiert werden
Die folgenden Blöcke übernehmen Anfragesyntax oder Beispiele aus Microsoft Learn. Relative Pfade gehören zur Graph-v1.0-Dokumentation. Bezeichner in geschweiften Klammern müssen durch tatsächliche Objekte ersetzt werden; die feste Kennung im Zählbeispiel ist Microsofts Beispiel. Keine dieser Anfragen wurde gegen einen Mandanten ausgeführt. Bewahren Sie den Anfrageumfang, Erfassungsfehler und die Paginierung zusammen mit dem resultierenden Inventar auf.
1. Gruppentyp und Erfassungsumfang bestimmen
Microsofts Seite zum Auflisten von Gruppen enthält diesen Microsoft 365-Filter wortgetreu:
GET https://graph.microsoft.com/v1.0/groups?$filter=groupTypes/any(c:c+eq+'Unified')
Verwenden Sie ihn für das Microsoft 365-Inventar, nicht als vollständige Prüfung der Sicherheitsgruppen. Dieselbe Seite dokumentiert eine Standardseitengröße von 100 und eine maximale Seitengröße von 999 sowie Replikationsverzögerungen nach Änderungen. Folgen Sie jedem zurückgegebenen @odata.nextLink; eine einzelne Seite oder ein noch veraltetes Ergebnis sollte keinen Befund abschließen. Microsoft Learn: Gruppen auflisten.
Für jede ausgewählte Gruppe lautet die dokumentierte Syntax zum Abrufen einer Gruppe:
GET /groups/{id}
Die API unterstützt $select für bestimmte Eigenschaften. Halten Sie Gruppen-ID, Mitgliedschaftstyp und Synchronisierungsstatus im Prüfprotokoll fest und bewahren Sie die Rohantwort auf, damit fehlende Attribute von negativen Antworten unterscheidbar bleiben. Microsoft Learn: Gruppe abrufen.
Die aktuelle v1.0-Gruppenressource dokumentiert groupTypes mit dem Wert Unified für Microsoft 365-Gruppen und expirationDateTime als deren durch die Richtlinie festgelegten Ablaufzeitpunkt. Für Sicherheitsgruppen ist dieses Datum null. Melden Sie das null-Datum einer Sicherheitsgruppe nicht als fehlende Microsoft 365-Lebenszyklusabdeckung. Microsoft Learn: Gruppeneigenschaften.
2. Besitzer prüfen und ihren Identitätstyp auflösen
Lesen Sie die Besitzerbeziehung mit der Syntax aus Learn:
GET /groups/{id}/owners
Die Beziehung kann Benutzer oder Dienstprinzipale enthalten. Graph stellt Besitzer für in Exchange erstellte Gruppen, Verteilergruppen oder aus einer lokalen Umgebung synchronisierte Gruppen nicht bereit. Die v1.0-Seite dokumentiert außerdem fehlende Dienstprinzipale als Besitzer und Objekte mit eingeschränkten Informationen, wenn der Aufrufer einen Ressourcentyp nicht lesen darf. In solchen Objekten können Attribute null sein, während ID und Typ verfügbar bleiben. Folgen Sie der Paginierung und bewahren Sie nicht aufgelöste Identitäten auf; fehlende Attribute können weder Besitzerlosigkeit noch den Gaststatus eines Besitzers belegen. Microsoft Learn: Besitzer auflisten.
Lösen Sie Benutzer als Besitzer ausdrücklich auf und prüfen Sie den erfassten userType. Microsofts API zum Abrufen eines Benutzers unterstützt die Auswahl nicht standardmäßig zurückgegebener Eigenschaften; die Referenz für Standardberechtigungen unterscheidet Member- und Guest-Benutzer. Ersetzen Sie das Identitätsattribut nicht durch E-Mail-Domänen oder #EXT#-Zeichenfolgen und leiten Sie aus der Klassifizierung Guest keine Kompromittierung ab. Microsoft Learn: Benutzer abrufen, Benutzertypen.
Wenn Sie während der Untersuchung einen erweiterten Filter für die Besitzeranzahl verwenden, wenden Sie die dokumentierten Anforderungen an ConsistencyLevel: eventual und die Zählung an. Erweiterte Abfragen verwenden einen separaten Index und unterstützen die Kombination dieser Beziehungsfilter mit $expand nicht. Halten Sie eine Kandidatenliste besitzerloser Gruppen getrennt von bestätigten Besitzerabfragen je Gruppe. Microsoft Learn: erweiterte Abfragefunktionen.
3. Mitglieder, Größe und direkte übergeordnete Beziehungen separat prüfen
Learn liefert die Anfrage für direkte Mitglieder:
GET /groups/{id}/members
Das Zählbeispiel lautet:
GET https://graph.microsoft.com/v1.0/groups/02bd9fd6-8f93-4758-87c3-1fb73740a315/members/$count
ConsistencyLevel: eventual
Dies sind direkte Verzeichnisobjekte, keine transitive Zählung unterschiedlicher Personen. Die Mitglieder-API dokumentiert das Fehlen von Dienstprinzipalen in v1.0; verborgene Mitgliedschaft erfordert Member.Read.Hidden. Enumerieren Sie zur Validierung alle Seiten und deduplizieren Sie IDs; erfassen Sie Einschränkungen, statt eine unvollständige Liste als vollständige Mitgliederzahl auszugeben. Microsoft Learn: Mitglieder auflisten.
Lesen Sie die übergeordnete Beziehung in einer separaten Anfrage:
GET /groups/{id}/memberOf
Die API liefert direkte Mitgliedschaften, keinen transitiven Graphen. Ihre Antwort kann je nach Gruppentyp Gruppen, administrative Einheiten oder administrative Rollen enthalten. Identifizieren Sie die zurückgegebenen Objekttypen, wenn Sie übergeordnete Gruppen bestätigen. Eine fehlgeschlagene Beziehungsabfrage ist kein erfolgreich ermitteltes Nullergebnis. Microsoft Learn: memberOf auflisten.
4. Lebenszyklus- und Besitzrichtlinien lesen
Übernehmen Sie das Beispiel zum Auflisten der Lebenszyklusrichtlinien:
GET https://graph.microsoft.com/v1.0/groupLifecyclePolicies
Die API dokumentiert Directory.Read.All für delegierten Zugriff oder Anwendungszugriff. Bewahren Sie den zurückgegebenen Abdeckungsmodus auf und vergleichen Sie ihn mit der vorgesehenen Richtlinie. Eine Antwort mit Selected erfordert die Prüfung der ausgewählten Gruppenmenge; die bloße Existenz eines Richtlinienobjekts belegt keine Abdeckung sämtlicher Gruppen. Microsoft Learn: Lebenszyklusrichtlinien auflisten, Abdeckungseigenschaften.
Lesen Sie Einstellungen auf Mandantenebene mit dem dokumentierten Beispiel:
GET https://graph.microsoft.com/v1.0/groupSettings
Prüfen Sie Group.Unified und seine Werte, statt die gesamte Antwort als Boolean zu behandeln. Learn nennt GroupSettings.Read.All als Leseberechtigung mit den geringsten Rechten und erläutert die zusätzlichen Anforderungen an Benutzerrollen für delegierte Aufrufe, einschließlich des unterschiedlichen Verhaltens mit delegierten mandantenweiten Verzeichnisleseberechtigungen. Microsoft Learn: Gruppeneinstellungen auflisten.
Wenn angepasste Einstellungen fehlen, liefert die Einstellungsübersicht diese Vorlagenanfrage:
GET https://graph.microsoft.com/v1.0/groupSettingTemplates
Verwenden Sie die dokumentierten Vorlagenstandards zur Interpretation des fehlenden angepassten Objekts. Lesen Sie dessen Abwesenheit nicht als aktivierten Gastbesitz. Microsoft Learn: Vorlagen und Standardwerte für Gruppeneinstellungen.
Lesen Sie abschließend die Richtlinie für besitzerlose Gruppen mit ihrem Learn-Beispiel:
GET https://graph.microsoft.com/v1.0/policies/ownerlessGroupPolicy
Dieser Endpunkt unterstützt delegiertes Group.Read.All, wobei dem aufrufenden Benutzer die Rolle Groups Administrator oder Exchange Administrator zugewiesen sein muss. Anwendungsberechtigungen werden nicht unterstützt. Ein dokumentierter 404 bedeutet, dass die Richtlinie nicht existiert; ein Autorisierungsfehler muss anders interpretiert werden. Versprechen Sie nicht, dass ein ausschließlich mit Anwendungsberechtigungen arbeitender Collector diese Richtlinie über denselben Endpunkt prüfen kann. Microsoft Learn: ownerlessGroupPolicy abrufen.
Wie EtcSec dies erkennt
Die folgenden Beschreibungen stammen aus einer statischen Prüfung des etc-collector-Commits b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. Die Dateipfade sind relativ zu public/internal/audit/detectors/. Dies sind Implementierungskriterien, keine Messungen an einem Mandanten.
| Detektor | Tatsächliche Bedingung | Interpretationsgrenze |
|---|---|---|
AZ_GROUP_OWNER_IS_GUEST | Besitzer wurden abgefragt; mindestens ein Besitzer entspricht über einen UPN-Index in Kleinschreibung einem erfassten Benutzer, dessen userType exakt Guest ist. | Unbekannte Typen und nicht abgefragte Gruppen werden nicht gezählt. Jede betroffene Gruppe wird einmal gezählt. Quelle: azure/groups/security/group-owner-is-guest.go:51. |
AZ_GROUP_NO_OWNER | Besitzer wurden abgefragt, das Synchronisierungsflag ist nicht true, und es gibt keine erfassten Besitzereinträge. | Schließt synchronisierte Gruppen aus. Prüft nicht, ob ein vorhandener Besitzer intern, aktiviert oder verantwortlich ist. Quelle: azure/groups/security/group-no-owner.go:37. |
AZ_GROUP_ORPHANED | len(Members) + len(Member) == 0 und len(MemberOf) == 0. | Bedeutet keine Mitglieder und keine übergeordnete Beziehung in den erfassten Daten; bedeutet niemals keinen Besitzer. Es gibt keine Schutzbedingung für eine erfolgreiche Mitglieder-/Beziehungsabfrage. Quelle: azure/groups/security/group-orphaned.go:39. |
AZ_GROUP_PUBLIC_MEMBERSHIP | Die nicht-null Sichtbarkeit entspricht Public, ohne Beachtung der Groß-/Kleinschreibung. | Keine Beschränkung auf Unified, kein Test des tatsächlichen Beitritts oder Ressourcenzugriffs. Quelle: azure/groups/security/group-public-membership.go:25. |
AZ_GROUP_UNIFIED_NO_EXPIRY | Bei abgefragter Mandantenkonfiguration erfordert Abdeckung eine vorhandene Richtlinie mit managedGroupTypes == "All"; andernfalls sind Gruppen betroffen, die exakt Unified enthalten. | Eine fehlende Richtlinie, None und Selected erzeugen Befunde. Die Selected-Abdeckung wird nicht je Gruppe aufgelöst. Quelle: azure/groups/security/unified-group-no-expiry.go:42. |
AZ_GROUP_LARGE_MEMBERSHIP | len(Members) + len(Member) > 500. | Strikt größer als 500; weder dedupliziert noch transitiv. Quelle: azure/groups/membership/group-large-membership.go:24. |
Erfassungsgrenzen ändern den nächsten Validierungsschritt
Für NO_EXPIRY erzeugt eine nicht abgefragte Konfiguration einen als nicht bestimmbar bezeichneten Info-Befund mit Count=1. Dieser Wert steht nicht für eine einzelne unabgedeckte Gruppe. Die Funktion prüft weder Aktivität noch expirationDateTime noch einen Lebensdauerschwellenwert. Eine Selected-Richtlinie kann legitim sein, auch wenn diese Implementierung ihre Unified-Gruppen markiert; bestätigen Sie die tatsächliche Abdeckung, bevor Sie diese Gruppen als niemals ablaufend beschreiben. Quelle: unified-group-no-expiry.go:43 und :56.
Der aktuelle Azure-Provider weist dieselbe Mitglieder-ID-Liste sowohl Members als auch Member zu. LARGE addiert anschließend beide Längen. Auf diesem erfolgreichen Pfad wird bei vollständiger Erfassung ohne doppelte IDs aus 2 × n > 500 somit n > 250: 250 erfüllt die Bedingung nicht, 251 schon. Dies ist Arithmetik aus dem Code, kein Ergebnis eines Mandanten- oder Go-Tests. 500 ist der im Detektor geschriebene Schwellenwert, kein Microsoft-Limit für Gruppengrößen. Quellen: public/internal/providers/azure/client.go:1115, group-large-membership.go:29.
Der Provider befüllt MemberOf, obwohl ein veralteter Kommentar in ORPHANED das Gegenteil behauptet. Er speichert IDs aus der direkten memberOf-Antwort ohne Filterung nach Objekttyp; eine erfasste übergeordnete Beziehung führt daher nicht zwangsläufig zu einer anderen Gruppe. Microsoft Learn: memberOf-Objekttypen.
Bei Fehlern in Mitglieder- und übergeordneten Beziehungsabfragen fehlt die ausdrückliche Unterscheidung zwischen Erfolg und Fehler, die der Marker für die Besitzerabfrage bietet. Dieser Marker garantiert keine vollständigen Besitzerdaten: Die Besitzeranreicherung speichert UPN oder Anzeigename und verwirft ein Objekt, wenn beides fehlt, selbst nach einer erfolgreichen Antwort. Sie hat ein Zeitbudget von fünf Minuten und folgt in diesem Codepfad nicht der Besitzerpaginierung. Ein Gruppenlimit kann zudem eine Rückkehr vor der Anreicherung auslösen. Prüfen Sie Erfassungswarnungen und rohe Beziehungen, bevor Sie Nullzählungen vertrauen. Quellen: public/internal/providers/azure/client.go:1142, :1158, :1170, :1184, :1235, :1253, :1264, :1345.
Abhilfemaßnahmen: Verantwortung wiederherstellen und Zugriff prüfen (Remediation)
1. Besitz bestätigen, bevor Berechtigungen geändert werden
Als Ausgangspunkt empfehlen wir eine ressourcenbezogene Prüfung: Erfassen Sie Zweck, verantwortlichen internen Sponsor, zugewiesene Anwendungen oder verbundene Websites, aktuelle Besitzer, genehmigte Ausnahmen und die für die Mitgliedschaft verantwortliche Stelle. Lassen Sie den Ressourcenverantwortlichen bestätigen, ob die Gruppe weiterhin benötigt wird. Weisen Sie Gruppen, die fortbestehen, verantwortliche Besitzer zu, bevor Sie überholte Besitzerzuweisungen entfernen.
Microsoft dokumentiert im Admin Center den Pfad Entra ID → Gruppen → Alle Gruppen → Gruppe auswählen → Besitzer → Hinzufügen sowie das Entfernen über die Besitzerliste. Beachten Sie die dokumentierten Rollenanforderungen und bewahren Sie die Beziehungen vor und nach der Änderung auf. Nehmen Sie bei mit Teams verbundenen Gruppen die zuvor beschriebenen Mitgliedschafts- und Synchronisierungsanforderungen in die Abnahmeprüfungen auf. Microsoft Learn: Besitzer verwalten, Besitzer über Graph hinzufügen.
2. Gastbesitz bewusst einschränken
Für Microsoft 365-Gruppen, deren Richtlinie interne Besitzer verlangt, behalten Sie AllowGuestsToBeGroupOwner=False in Group.Unified bei oder stellen Sie diesen Wert wieder her. Prüfen Sie bestehenden Gastbesitz separat, statt anzunehmen, eine Konfigurationsänderung belege das Verschwinden aller vorhandenen Beziehungen. Bewahren Sie beim Aktualisieren des Objekts die anderen Einstellungen; Microsofts Konfigurationsleitfaden verlangt ausdrücklich das Lesen der aktuellen Werte, um unabhängige Konfiguration nicht zu überschreiben. Lesen Sie nach der Änderung sowohl Einstellungen als auch Besitzer erneut. Microsoft Learn: Gruppeneinstellungen konfigurieren.
Dokumentieren Sie Ausnahmen mit einem Sponsor und einem Prüfdatum. Prüfen Sie Einladung, Authentifizierung und Lebenszyklus der Gastidentität separat anhand des Leitfadens zur Angriffsfläche von Gastkonten, der Einladungsberechtigungen, MFA und veraltete Konten behandelt. Diese Identitätskontrollen ergänzen die Besitzprüfung; sie ersetzen keine Gruppenlebenszyklusrichtlinie.
3. Die Warteschlange zur Wiederherstellung besitzerloser Gruppen betreiben
Aktivieren Sie im Microsoft 365 Admin Center den Workflow für besitzerlose Gruppen unter Einstellungen → Einstellungen der Organisation → Microsoft 365-Gruppen. Konfigurieren Sie anschließend berechtigte Empfänger, Absender, Benachrichtigungszeitraum und Zielgruppen. Prüfen Sie unterstützte Lizenzen und Exchange Online-Postfächer: Der Absender benötigt ein Benutzer- oder Gruppenpostfach, freigegebene Absenderpostfächer werden nicht unterstützt, und Empfänger benötigen Benutzerpostfächer. Verfolgen Sie angenommene Besitzerzuweisungen und eskalieren Sie Gruppen, die am Ende der Benachrichtigungen ungelöst bleiben. Der dokumentierte Workflow überlässt die abschließende manuelle Zuweisung Administratoren, wenn niemand annimmt. Microsoft Learn: Richtlinie für besitzerlose Gruppen konfigurieren.
4. Ablauf anhand tatsächlicher Abhängigkeiten konfigurieren
Wählen Sie Lebensdauer und die Abdeckung All oder Selected nach einer Prüfung der Anwendungs- und Zusammenarbeitsabhängigkeiten. Entras Ablaufeinstellungen unterstützen außerdem eine alternative Benachrichtigungsadresse für besitzerlose Gruppen. Die Lizenzierung erfordert den Besitz von P1- oder P2-Lizenzen für Mitglieder der Gruppen, auf die der Ablauf angewendet wird. Bestätigen Sie die Handhabung der Verlängerung, bevor Sie Löschung als vorgesehenes Ergebnis behandeln. Microsoft Learn: Ablauf konfigurieren.
Lesen Sie die Lebenszyklusrichtlinie und die Ablaufbelege je Gruppe erneut. Halten Sie bei Selected-Abdeckung fest, welche Gruppen einbezogen sind. Behandeln Sie Gruppenablauf, Inhaltsaufbewahrung und Offboarding von Gastkonten als getrennte Entscheidungen; eine Lebenszyklusrichtlinie beschreibt eine verlängerbare Gruppenlebensdauer, nicht alle drei Ergebnisse. Microsoft Learn: Definition der Lebenszyklusrichtlinie.
5. Beitritt und große Mitgliedschaften prüfen
Fragen Sie bei Public-Gruppen, ob ein Beitritt ohne Besitzererlaubnis zur Zielgruppe der Ressource passt. Wenn eine Genehmigung erforderlich ist, prüfen Sie die Sichtbarkeit Private und verifizieren Sie separat die tatsächlichen Dienstberechtigungen. Beschaffen Sie bei LARGE-Befunden zunächst ein dedupliziertes Inventar direkter Mitglieder und prüfen Sie anschließend, warum jeder Personenkreis Zugriff benötigt. Teilen Sie Verantwortlichkeiten oder Zugriffsgruppen auf, wenn die geschäftliche Prüfung dies rechtfertigt; entfernen Sie Mitglieder nicht bloß, um das numerische Prädikat der Implementierung nicht mehr auszulösen.
Untersuchen Sie die Struktur privilegierter Gruppen separat. Der Artikel über verschachtelte privilegierte und rollenfähige Gruppen behandelt dieses Thema. Halten Sie dessen Themenabgrenzung ein, ohne eine Behauptung über Rollenerhöhung in diese Besitzprüfung zu übernehmen.
6. Mitgliedschaftsprüfungen zu einer Entscheidung führen
Erstellen Sie Prüfungen mit benannten Prüfern, Ersatzprüfern bei Auswahl von Gruppenbesitzern, einem ausdrücklichen Ergebnis für ausbleibende Antworten und einer Entscheidung über die automatische Anwendung der Ergebnisse. Learn dokumentiert die Ersatzbehandlung für besitzerlose Gruppen und warnt, dass das Entfernen bei Nichtantwort mit automatischer Anwendung den Ressourcenzugriff entziehen kann. Die Mitglieder einer besitzerlosen Gruppe behalten nach einer Prüfung nicht zwangsläufig Zugriff: Ihr Ergebnis hängt von diesen Einstellungen und der Anwendung der Entscheidungen ab. Prüfen Sie die aktuellen Governance- oder Suite-Lizenzanforderungen für die gewählte Prüfung. Microsoft Learn: Zugriffsüberprüfungen erstellen.
Entdecken Sie die Identity-Security-Seiten zu diesem Thema
