Entra ID Tenant Standardbenutzereinstellungen schränken App-Registrierung, Gruppenerstellung und Admin-Center-Zugriff ein

Entra ID Tenant Standardbenutzereinstellungen schränken App-Registrierung erst nach einer Admin-Änderung ein

Die Entra ID Tenant Standardbenutzereinstellungen schränken App-Registrierung, Gruppenerstellung und das Durchsuchen des Admin Centers ein — aber erst, sobald ein Administrator sie ändert. Bis das jemand tut, ist die dokumentierte Baseline für einen gewöhnlichen Member-Benutzer bewusst grosszügig, und die meisten Tenants überprüfen sie nie erneut.

Microsoft macht deutlich, was ein einfacher Member-Benutzer tun kann. Die Referenz zu Standardberechtigungen hält fest, dass Member-Benutzer Anwendungen registrieren, ihr eigenes Profilfoto und ihre Mobiltelefonnummer verwalten, ihr eigenes Passwort ändern und B2B-Gäste einladen können. Diese Benutzer können ausserdem alle Verzeichnisinformationen lesen (mit wenigen Ausnahmen). Dieselbe Seite listet unter Groups auf, dass Member-Benutzer Sicherheitsgruppen erstellen und Microsoft-365-Gruppen erstellen können; unter Applications, dass sie neue Anwendungen registrieren (erstellen) und die Liste aller Anwendungen aufzählen können; und unter Roles and scopes, dass sie alle administrativen Rollen und Mitgliedschaften lesen können (Default user permissions).

Das ist der unangenehme Teil. Die beiden Voraussetzungen, die OAuth-Consent-Phishing und Verzeichnis-Reconnaissance funktionieren lassen, sind keine exotischen Angreiferfähigkeiten — es sind Tenant-Einstellungen. Vier Schalter schliessen den grössten Teil der Lücke, und keiner davon erfordert ein Lizenz-Upgrade.

So funktioniert es: Vier Schalter, drei verschiedene Objekte

Das Microsoft Entra Admin Center präsentiert diese als übersichtliche Liste unter User settings und Group settings. Darunter liegen sie in drei voneinander unabhängigen Speicherorten — genau deshalb übersehen unvollständige Audits sie.

Die ersten beiden liegen auf dem tenantweiten Singleton-Objekt authorizationPolicy. Microsoft Graph dokumentiert allowedToCreateApps als Entsprechung zur Einstellung "Users can register applications" im Menü User settings, und allowedToCreateSecurityGroups als Entsprechung zur Einstellung "Users can create security groups" in den Microsoft Entra Admin Centern, der API oder PowerShell (defaultUserRolePermissions). Dasselbe Objekt trägt ausserdem allowedToCreateTenants, allowedToReadOtherUsers, allowedToReadBitlockerKeysForOwnedDevice und permissionGrantPoliciesAssigned.

Die Erstellung von Microsoft-365-Gruppen liegt an einer ganz anderen Stelle: der Einstellung EnableGroupCreation innerhalb der Vorlage Group.Unified, deren Standardeinstellung laut Microsoft true ist (Overview of group settings).

Der vierte Schalter ist der unbequeme, und er wird im eigenen Abschnitt weiter unten behandelt.

Die Angriffskette

Schritt 1 — Ein gewöhnliches Konto beschaffen

Keine Rolle, kein Admin-Consent, keine Rechteausweitung nötig. Password Spraying, Adversary-in-the-Middle-Token-Diebstahl oder Device Code Phishing enden alle am selben Punkt: einer Sitzung als Standard-Member-Benutzer. Alles Folgende ist das, wozu diese Sitzung standardmässig berechtigt ist.

Schritt 2 — Das Verzeichnis von innen kartieren

Member-Benutzer können alle Benutzer und Kontakte, alle Gruppen, alle Geräte und alle Anwendungen aufzählen sowie alle administrativen Rollen und Mitgliedschaften lesen. In der Praxis bedeutet das: Ein Angreifer mit einer gewöhnlichen Sitzung kann jeden Global Administrator im Tenant auflisten, cloud-only-Konten identifizieren und Ziele auswählen — ohne eine einzige Admin-Oberfläche zu berühren.

Schritt 3 — Eine Anwendung registrieren und ein Credential hinzufügen

Bleibt allowedToCreateApps auf dem Standardwert, erstellt das Konto eine App-Registrierung. Microsoft dokumentiert die Konsequenz: Wenn ein Benutzer eine Anwendung registriert, wird er automatisch als Owner der Anwendung hinzugefügt. Owner können anschliessend applications.credentials und weitere Eigenschaften aktualisieren.

Das ist der Dreh- und Angelpunkt. Das Hinzufügen eines von Angreifern kontrollierten Secrets oder Zertifikats zu einer Anwendung oder einem Service Principal ist bei MITRE ATT&CK als T1098.001 — Account Manipulation: Additional Cloud Credentials katalogisiert. Dort heisst es, dass Angreifer zusätzlich zu bestehenden legitimen Credentials Credentials für Service Principals und Anwendungen in Azure/Entra ID hinzufügen können — dazu zählen sowohl x509-Schlüssel als auch Passwörter. Ein Credential auf einem Anwendungsobjekt ist nicht an das Passwort des kompromittierten Benutzers gebunden, weshalb ein Zurücksetzen dieses Passworts den Angreifer nicht aussperrt.

Die App braucht ausserdem Berechtigungen, um nützlich zu sein, und genau hier kommt die Consent-Seite des Tenants ins Spiel: Standardmässig dürfen alle Benutzer Anwendungen Berechtigungen zustimmen, die keine Administrator-Zustimmung erfordern (Configure how users consent to applications). Diese Hälfte des Problems behandeln wir ausführlich in OAuth Consent Phishing: Wie bösartige Apps Passwortdiebstahl umgehen und in Entra App-Registrierung: Gefährliche Graph-API-Berechtigungen.

Schritt 4 — Eine Gruppe erstellen, die niemand verwaltet

Self-Service-Gruppenerstellung ist für sich genommen keine Rechteausweitung — eine neue Gruppe gewährt Zugriff auf nichts. Der Schaden liegt in der Governance. Ein Member-Benutzer, der eine Gruppe erstellt, wird normalerweise automatisch als deren Owner hinzugefügt, mit Rechten über groups.members und groups.owners — mit einer dokumentierten Ausnahme: Bei Sicherheitsgruppen, die im Azure-Portal erstellt werden, weist Microsoft darauf hin, dass der Owner bei der Gruppenerstellung nicht automatisch zugewiesen wird. Microsoft weist weiter darauf hin, dass Sicherheitsgruppen, die per Self-Service über das My-Groups-Portal erstellt werden, für alle Benutzer beitretbar sind, unabhängig davon, ob die Mitgliedschaft owner-genehmigt oder automatisch genehmigt ist (Set up self-service group management).

Das Ergebnis ist ein Verzeichnis mit Tausenden Gruppen, deren Ownership bedeutungslos ist, in dem eine von einem Angreifer kontrollierte Gruppe nicht von den übrigen zu unterscheiden ist — bis ein Administrator dieser Gruppe Zugriff auf eine Anwendung, eine Site oder eine Conditional-Access-Ausnahme gewährt.

Warum der Admin-Center-Schalter Reibung ist, keine Kontrolle

Das ist der Schalter, der am häufigsten als "gehärtet" gemeldet und am häufigsten missverstanden wird. Microsofts eigene Dokumentation trägt über der Tabelle einen Warnhinweis: Die Einstellung Restrict access to Microsoft Entra administration portal beschränkt den Zugriff auf eine Reihe häufig besuchter Admin-Center-Seiten. Sie ist keine Sicherheitsmassnahme.

Das Detail lohnt eine genaue Lektüre. Wird sie auf Yes gesetzt, fügt sie dem beiläufigen Browsen eine zusätzliche Reibungsebene hinzu, indem sie Nicht-Administratoren daran hindert, häufig besuchte Seiten wie die Startseite, die Tenant-Übersicht und die Benutzerliste zu laden. Microsoft stellt aber klar, dass sie den programmatischen Zugriff auf Microsoft-Entra-Daten über PowerShell, die Microsoft Graph API oder andere Tools wie Visual Studio nicht blockiert, dass sie nicht für Benutzer mit einer administrativen Rolle gilt, und dass die meisten Seiten im Admin Center weiterhin erreichbar bleiben, wenn der Benutzer über einen direkten (Deep) Link verfügt.

Jeder Schritt der oben beschriebenen Angriffskette läuft über Microsoft Graph. Keiner davon wird von diesem Schalter beeinflusst.

Es gibt eine zweite Konsequenz für Auditoren: Anders als die drei übrigen Einstellungen hat diese keine Eigenschaft auf der Ressource authorizationPolicy. Deren dokumentierte Eigenschaftenliste — in v1.0 wie in beta — enthält defaultUserRolePermissions, guestUserRoleId, allowInvitesFrom, blockMsolPowerShell und ähnliche, aber nichts für den Admin-Portal-Zugriff. Wenn Ihre Tenant-Baseline behauptet, diese Einstellung aus Graph auszulesen, prüfen Sie, was dort tatsächlich gelesen wird.

🚨 Gefahr: Zählen Sie den Portal-Schalter nicht als kompensierende Kontrolle für offene App-Registrierung. Microsofts Empfehlung lautet, eine Conditional-Access-Richtlinie einzusetzen, die auf die Windows Azure Service Management API zielt, um Nicht-Admin-Zugriff auf Azure-Management-Endpunkte zu blockieren.

Detection

Lesen Sie den tatsächlichen Zustand statt der Darstellung im Admin Center. Drei der vier Schalter sind mit Read-only-Scopes abrufbar; der vierte — der Admin-Center-Schalter — hat aus dem oben genannten Grund keine auslesbare Eigenschaft.

Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"

$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
$policy.defaultUserRolePermissions

$settings = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/groupSettings"
$settings.value

Ein Tenant, der nie gehärtet wurde, liefert etwas sehr Ähnliches wie das Folgende zurück, mit einer leeren groupSettings-Collection:

{
  "allowedToCreateApps": true,
  "allowedToCreateSecurityGroups": true,
  "allowedToCreateTenants": true,
  "allowedToReadOtherUsers": true,
  "permissionGrantPoliciesAssigned": ["managePermissionGrantsForSelf.microsoft-user-default-legacy"]
}

Kombinieren Sie das Auslesen der Konfiguration mit dem Audit-Log. Diese Aktivitätsnamen sind exakt so benannt und alle im Microsoft-Entra-Audit-Log abrufbar:

Quelle für jeden Aktivitätsnamen: die Microsoft Entra Audit Log Activity Reference.

Daraus ergeben sich zwei praktische Detections. Erstens: Alarmieren Sie bei Add application oder Add service principal, wenn der auslösende Principal keine Verzeichnisrolle innehat — in einem Tenant mit kontrollierter Entwicklerpopulation sollte das eine kurze Liste sein. Zweitens: Alarmieren Sie bedingungslos bei Update authorization policy; es gibt sehr wenige legitime Gründe für eine Änderung dieser Richtlinie, und ein Angreifer, der Privileged Role Administrator erreicht, wird sie nutzen, um erneut zu öffnen, was Sie geschlossen haben. Wenn Ihr Tenant diese Logs nicht lange genug aufbewahrt, um zu ermitteln, beheben Sie das zuerst — siehe Entra ID Logging: Aufbewahrung und Diagnoseeinstellungen.

Remediation

1. Die Standard-Benutzerrollenberechtigungen schliessen. Microsofts eigenes PowerShell-Beispiel zum Deaktivieren der App-Erstellung bildet die Basis; die beiden zusätzlichen Eigenschaften sind auf demselben Objekt dokumentiert.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$params = @{
    defaultUserRolePermissions = @{
        allowedToCreateApps           = $false
        allowedToCreateSecurityGroups = $false
        allowedToCreateTenants        = $false
    }
}

Update-MgPolicyAuthorizationPolicy -BodyParameter $params

Wird allowedToCreateTenants auf $false gesetzt, beschränkt das die Tenant-Erstellung auf die Rolle Tenant Creator. Das ist bedeutender, als es aussieht: Microsoft weist darauf hin, dass der Benutzer, der einen Microsoft-Entra-Tenant erstellt, standardmässig automatisch die Rolle Global Administrator zugewiesen bekommt, und dass das Ereignis als Create Company protokolliert wird.

2. Die Erstellung von Microsoft-365-Gruppen schliessen und delegieren. Dafür wird ein groupSettings-Objekt benötigt, das aus der Vorlage Group.Unified erstellt wird, denn ein Standard-Tenant besitzt keines. Lesen Sie die Template-ID zuerst aus Ihrem eigenen Tenant mit GET https://graph.microsoft.com/v1.0/groupSettingTemplates aus, statt sie hart zu codieren.

{
  "templateId": "62375ab9-6b52-47ed-826b-58e47e0e304b",
  "values": [
    { "name": "EnableGroupCreation", "value": "false" },
    { "name": "GroupCreationAllowedGroupId", "value": "<object-id-of-your-approved-creators-group>" }
  ]
}

GroupCreationAllowedGroupId ist dokumentiert als die Kennung der Sicherheitsgruppe, deren Mitglieder Microsoft-365-Gruppen erstellen dürfen, selbst wenn EnableGroupCreation auf false steht — das ist Ihr Notausgang, und er benötigt keine P1-Lizenz.

3. Das Self-Service-Gruppenmanagement verschärfen. Setzen Sie im Admin Center unter Groups → General settings die Optionen "Users can create security groups in Azure portals, API or PowerShell" und "Users can create Microsoft 365 groups in Azure portals, API or PowerShell" auf No. Microsoft nennt den Notausgang ausdrücklich: Wenn Sie einigen, aber nicht allen Benutzern die Gruppenerstellung erlauben möchten, können Sie diesen Benutzern eine Rolle zuweisen, die Gruppen erstellen kann, etwa Groups Administrator. Kennen Sie die Grenze des benachbarten Schalters, bevor Sie sich darauf verlassen — Restrict user ability to access groups features in the Access Panel beschränkt nur den Zugriff auf Gruppeninformationen in My Groups. Er beschränkt nicht den Zugriff auf Gruppeninformationen über andere Methoden wie Microsoft Graph API-Aufrufe oder das Microsoft Entra Admin Center.

4. Den Admin-Center-Schalter durch eine echte Kontrolle ersetzen. Setzen Sie ihn auf Yes, wenn Sie die Reibung wünschen, implementieren Sie aber zusätzlich die Kontrolle, die Microsoft tatsächlich empfiehlt: eine Conditional-Access-Richtlinie, die auf die Windows Azure Service Management API zielt und Nicht-Admin-Zugriff auf Azure-Management-Endpunkte blockiert. Verifizieren Sie sie zuerst im Report-only-Modus — siehe Conditional Access Report-only-Modus und veraltete Ausnahmen.

5. Verifizieren, und die zwei Fallstricke beachten. Führen Sie den oben stehenden Detection-Block erneut aus und bestätigen Sie, dass sich jeder Wert geändert hat. Zwei dokumentierte Verhaltensweisen lassen Sie sonst denken, die Änderung sei fehlgeschlagen oder erfolgreich gewesen, obwohl das nicht stimmt:

• Gruppeneinstellungen können bis zu 15 Minuten benötigen, um wirksam zu werden.
• Diese Einstellungen gelten für Benutzer und betreffen keine Service Principals. Hatte beispielsweise ein Service Principal Berechtigungen zur Gruppenerstellung, kann er weiterhin Gruppen erstellen, selbst wenn Sie diese Einstellungen auf No setzen.

Dieser zweite Punkt ist der Grund, warum dieser Härtungsdurchgang zusammen mit einer Anwendungsinventur erfolgen sollte. Die benutzerseitige Erstellung zu schliessen, während überberechtigte Service Principals bestehen bleiben, verschiebt das Problem, statt es zu lösen — siehe Azure App-Registrierungen: Sicherheitsrisiken und die umfassendere Azure Tenant-Härtung: Unsichere Defaults.

Wie EtcSec dies erkennt

EtcSec teilt diese Angriffsfläche bei jedem Azure-Audit in vier getrennte Findings auf, statt sie in einen vagen "Tenant-Härtung"-Score zu falten. Alle vier werden mit mittlerem Schweregrad gemeldet.

• AZ_APP_REGISTRATION_OPEN — App Registration Open to All Users: wird ausgelöst, wenn authorizationPolicy → defaultUserRolePermissions.allowedToCreateApps als true zurückkommt. Dieser Wert wird direkt aus Microsoft Graph gelesen.
• AZ_SELF_SERVICE_GROUPS_OPEN — Self-Service Group Creation Open: wird ausgelöst, wenn der Tenant keine Einschränkung der Gruppenerstellung trägt — was dem Zustand eines Standard-Tenants entspricht, da EnableGroupCreation auf true bleibt, bis ein Group.Unified-Objekt existiert.
• AZ_GROUP_SELF_SERVICE — Self-Service Group Management Unrestricted: derselbe uneingeschränkte Zustand, von der Gruppenseite aus bewertet — nicht verwaltete Gruppen und eine Ownership, die bedeutungslos ist.
• AZ_ADMIN_PORTAL_ACCESS_OPEN — Admin Portal Access Not Restricted: wird ausgelöst, sofern der Tenant nicht als Einschränkung des Admin-Center-Zugriffs auf Administratoren erfasst ist. Dies wird, in Übereinstimmung mit Microsofts eigenem Vorbehalt, als Konfigurationshygiene gemeldet, nicht als Sicherheitsgrenze.

Die getrennte Behandlung ist wichtig, weil sich der Fix je Finding unterscheidet: eines ist ein Update von authorizationPolicy, zwei erfordern ein groupSettings-Objekt, das erst erstellt werden muss, und das vierte ist eine Conditional-Access-Richtlinie. Für die vollständige Abfolge siehe Microsoft Entra ID Sicherheit auditieren: Leitfaden.