OAuth-App-Einwilligungen in Microsoft Entra ID prüfen

In einem Microsoft-Entra-ID-Tenant mit Standardeinstellungen kann jeder Benutzer eine Drittanbieter-App genehmigen, die sein Postfach liest, ohne dass jemand in der IT gefragt wird. Wenn Sie diese Einstellung noch nie überprüft haben, gehen Sie davon aus, dass bereits einige Grants existieren, und prüfen Sie diese, bevor Sie die Richtlinie ändern.

Was die Standardeinstellung erlaubt

Ein Benutzer kann einer App erlauben, sein eigenes Postfach zu lesen. Er kann einer App aber keinen uneingeschränkten Lese- und Schreibzugriff auf alle Dateien der Organisation geben, denn dafür ist ein Administrator nötig. Microsoft empfiehlt, User Consent nur für Apps von einem verifizierten Herausgeber zuzulassen, um das Risiko zu verringern, dass schädliche Apps Benutzer zur Zustimmung verleiten.

Ein Grant ist außerdem kein Passwort. Gemäß OAuth 2.0 (RFC 6749) erhält die App ein Access Token mit definiertem Scope und begrenzter Lebensdauer, das anstelle der Zugangsdaten des Benutzers ausgestellt wird. Der Grant ist ein eigenes Objekt, das Sie finden und entfernen müssen.

Erteilte Grants auflisten

Sie benötigen mindestens die Rolle Cloud Application Administrator oder Application Administrator. Gehen Sie im Microsoft Entra Admin Center zu Entra ID > Enterprise apps > All applications, wählen Sie die App aus und öffnen Sie Permissions. Der Tab Admin consent zeigt die Berechtigungen, die für die gesamte Organisation erteilt wurden. Der Tab User consent zeigt, was einzelne Benutzer oder Gruppen erteilt haben.

Das Portal arbeitet App für App, für eine tenantweite Sicht brauchen Sie daher eine Schleife. Die Graph-Endpunkte in der Microsoft-Anleitung zum Widerruf beziehen sich jeweils auf einen einzelnen Service Principal: oauth2PermissionGrants liefert delegierte Berechtigungen, appRoleAssignments liefert Anwendungsberechtigungen. Das folgende Skript verwendet die entsprechenden Cmdlets und löst IDs in Namen auf, auch bei Anwendungsrollen wie Mail.Read:

Connect-MgGraph -Scopes "Application.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All","AppRoleAssignment.ReadWrite.All"

$sps  = Get-MgServicePrincipal -All
$name = @{}
$role = @{}
foreach ($s in $sps) {
  $name[$s.Id] = $s.DisplayName
  foreach ($r in $s.AppRoles) { $role["$($s.Id)|$($r.Id)"] = $r.Value }
}

$rows = @()
foreach ($g in Get-MgOauth2PermissionGrant -All) {
  $rows += [pscustomobject]@{ App=$name[$g.ClientId]; Type="Delegated"
    Resource=$name[$g.ResourceId]; Detail=$g.Scope }
}
foreach ($sp in $sps) {
  $assigned = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All |
    Where-Object { $_.PrincipalType -eq "ServicePrincipal" }
  foreach ($a in $assigned) {
    $rows += [pscustomobject]@{ App=$sp.DisplayName; Type="Application"
      Resource=$name[$a.ResourceId]; Detail=$role["$($a.ResourceId)|$($a.AppRoleId)"] }
  }
}
$rows | Export-Csv consent-audit.csv -NoTypeInformation

Diese Scopes stammen aus den Widerrufsbeispielen von Microsoft und enthalten Schreibzugriff, den ein reiner Lese-Audit nicht benötigt. Fordern Sie engere Scopes an, sofern Ihr Tenant das zulässt, und testen Sie das Skript zunächst an einer kleinen Auswahl.

Reihenfolge der Triage

Diese Reihenfolge stammt von uns und ist keine Vorgabe von Microsoft. Beginnen Sie mit delegierten Grants, deren Scopes E-Mails lesen oder senden oder Dateien lesen. Filtern Sie dazu die Spalte Detail nach Mail und Files. Nehmen Sie sich danach alle Anwendungsberechtigungen vor.

Ein bösartiger Grant sieht im Portal unauffällig aus, mit plausiblem Namen und wenigen Scopes. Achten Sie auf das Muster, dass mehrere Benutzer derselben unbekannten App zugestimmt haben, deren Herausgeber Sie nicht verifizieren können. Wenn Sie einen solchen Fall finden, behandeln Sie ihn als Incident und ziehen Sie unser Incident-Response-Team oder Ihr eigenes hinzu.

Riskante Grants entfernen

Für Berechtigungen, die Administratoren erteilt haben, öffnen Sie den Tab Admin consent, wählen das Steuerelement ... neben der Berechtigung und klicken auf Revoke permission. Im Tab User consent können Sie im Portal nichts widerrufen. Dafür benötigen Sie Graph oder PowerShell.

In Graph löschen Sie einen delegierten Grant über seine ID oder entfernen eine Anwendungsberechtigung über ihre Assignment-ID:

DELETE https://graph.microsoft.com/v1.0/oAuth2PermissionGrants/{id}
DELETE https://graph.microsoft.com/v1.0/servicePrincipals/{resource-servicePrincipal-id}/appRoleAssignedTo/{appRoleAssignment-id}

Auf der Seite zum Widerruf finden Sie außerdem PowerShell-Skripte, die alle delegierten Berechtigungen und Anwendungsberechtigungen einer App entfernen. Lesen Sie diese vor der Ausführung sorgfältig, denn sie entziehen diesem Service Principal sämtliche Berechtigungen.

Ein Widerruf hindert Benutzer nicht daran, derselben App erneut zuzustimmen. Microsoft nennt zwei Abhilfen: Sie verhindern, dass die App die Berechtigungen per Dynamic Consent anfordert, oder Sie blockieren User Consent vollständig. Bei Drittanbieter-Apps können Sie nicht ändern, was diese anfordern. Aus unserer Sicht ist daher das Blockieren die Kontrolle, die Sie selbst in der Hand haben.

User Consent einschränken

Sie benötigen die Rolle Privileged Role Administrator. Die Rolle Global Administrator ist nur erforderlich, wenn Sie das Admin Center verwenden, wo sich die Einstellung unter Identity > Applications > Enterprise apps > Consent and permissions > User consent settings befindet.

Entra bringt dafür zwei integrierte Richtlinien mit:

Die Low-Richtlinie setzt voraus, dass Sie Berechtigungen klassifizieren. Damit legen Sie fest, was Benutzer genehmigen dürfen. Erledigen Sie das zuerst und testen Sie anschließend mit einem normalen Benutzerkonto.

Bevor Sie in PowerShell oder Graph etwas ändern, rufen Sie die aktuelle authorizationPolicy ab. In Ihrem Tenant können ManagePermissionGrantsForOwnedResource.*-Richtlinien zugewiesen sein, etwa jene, mit der Entwickler Consent für Apps verwalten, die ihnen gehören. Behalten Sie diese in der Collection, sonst entfernen Sie sie. User Consent deaktivieren Sie mit Graph PowerShell so:

Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$body = @{
  "permissionGrantPolicyIdsAssignedToDefaultUserRole" = @(
    "managePermissionGrantsForOwnedResource.{other-current-policies}"
  )
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $body

Um stattdessen Consent unter der Low-Impact-Richtlinie zuzulassen, fügen Sie managePermissionGrantsForSelf.microsoft-user-default-low im Graph-PATCH zu defaultUserRolePermissions.permissionGrantPoliciesAssigned hinzu. Eine Richtlinienänderung wirkt sich nur auf künftige Zustimmungen aus, bestehende Grants bleiben also bestehen, bis Sie sie entfernen.

Nutzern eine Möglichkeit zum Nachfragen geben

Wenn Sie Consent ohne Alternative blockieren, suchen Benutzer nach Umgehungen. Mit dem Admin-Consent-Workflow können sie stattdessen eine Genehmigung anfragen. Ein Global Administrator aktiviert ihn unter Entra ID > Enterprise apps > Consent and permissions > Admin consent settings. Setzen Sie "Users can request admin consent to apps they are unable to consent to" auf Yes und wählen Sie dann:

• Reviewers: Benutzer, Gruppen oder Rollen. Die Rolle als Reviewer erhöht ihre Rechte nicht, jeder Reviewer muss also bereits die Berechtigung besitzen, für die angefragte App Consent zu erteilen. Nur Global Administrators können Apps genehmigen, die Microsoft-Graph-App-Rollen (Anwendungsberechtigungen) anfordern.
• Email notifications: Wenn Sie diese für Reviewer deaktivieren, werden auch die Benachrichtigungen an die Antragsteller deaktiviert.
• Request lifetime und Expiration reminders: Die Lifetime ist die Anzahl der Tage, die eine Anfrage gültig bleibt. Die erste Erinnerung kommt etwa zur Hälfte der Zeit, bei einer dreitägigen Anfrage also an Tag zwei.

Speichern Sie und warten Sie bis zu eine Stunde, bis der Workflow wirksam wird. Ein entfernter Reviewer behält den Zugriff auf Anfragen, die gestellt wurden, solange er die Rolle innehatte. Neue Reviewer können Anfragen, die vor ihrer Hinzufügung erstellt wurden, nicht bearbeiten.

Auch integrierte Entra-Rollen, Exchange RBAC und Teams Resource-specific Consent können Zugriff gewähren. Beziehen Sie sie deshalb in eine umfassendere Prüfung ein.

Wo Sie anfangen

1. Führen Sie das Inventarskript aus und prüfen Sie delegierte Grants und Anwendungsberechtigungen als getrennte Listen. Markieren Sie die Apps, die niemand begründen kann.
2. Widerrufen Sie die riskanten Grants: die per Admin-Zustimmung erteilten im Portal, die per User Consent erteilten über Graph oder PowerShell.
3. Lesen Sie die aktuelle authorizationPolicy aus und setzen Sie dann User Consent auf microsoft-user-default-low mit klassifizierten Berechtigungen oder deaktivieren Sie ihn, und behalten Sie dabei die ManagePermissionGrantsForOwnedResource.*-Einträge bei.
4. Aktivieren Sie den Admin-Consent-Workflow. Benennen Sie Reviewer, deren Rollen Consent für das erteilen dürfen, was Benutzer anfragen werden, und behalten Sie einen Global Administrator darunter, denn nur diese Rolle genehmigt Microsoft-Graph-Anwendungsberechtigungen.
5. Wiederholen Sie die Prüfung regelmäßig. Falls Ihnen die Zeit fehlt, kann unser Consulting-Team sie als Assessment durchführen, und unser Managed-Security-Service kann das Monitoring übernehmen.