Admin Consent in Microsoft Entra: Was MSPs wissen müssen

Ein Kunde soll einem Werkzeug des MSP Zugriff auf seinen Microsoft-365-Tenant geben. Der Weg dafür heißt Admin Consent. Wer ihn erteilt, sollte wissen, was dabei im eigenen Tenant entsteht, welche Berechtigungen wirklich nötig sind und wie sich der Zugriff wieder entfernen lässt.

Consent in Entra: zwei Zustimmungsarten, zwei Berechtigungstypen

Microsoft Entra ID kennt zwei Arten von Zustimmung:

User Consent: Ein Benutzer erlaubt einer App, in seinem Namen auf Daten zuzugreifen. Die Zustimmung gilt nur für ihn.
Admin Consent: Ein Administrator erlaubt einer App den Zugriff für die gesamte Organisation. Kein Benutzer wird danach noch gefragt.

Dazu kommen zwei Berechtigungstypen:

Delegierte Berechtigungen (delegated permissions) wirken im Kontext eines angemeldeten Benutzers. Die App kann höchstens das, was der Benutzer selbst darf. Viele davon kann der Benutzer selbst erteilen, hoch privilegierte nur ein Admin.
Anwendungsberechtigungen (application permissions, in Graph auch app roles) wirken ohne angemeldeten Benutzer. Anwendungsberechtigungen erfordern immer Admin Consent.

Ein Monitoring-Dienst für ablaufende Secrets läuft ohne Benutzer. Er braucht also Anwendungsberechtigungen und damit zwingend Admin Consent.

Was beim Tenant-weiten Admin Consent technisch passiert

Eine Multi-Tenant-App hat genau eine App-Registrierung, und die liegt im Tenant des Anbieters. Beim Admin Consent legt Entra im Kunden-Tenant einen Service Principal an. Im Portal erscheint er unter Enterprise applications. Er ist die lokale Instanz der App.

An diesem Service Principal hängen die erteilten Berechtigungen:

Anwendungsberechtigungen werden als appRoleAssignment gespeichert: Der Service Principal der App bekommt eine App-Rolle der Ressource Microsoft Graph zugewiesen.
Delegierte Berechtigungen werden als oAuth2PermissionGrant mit consentType gleich AllPrincipals gespeichert, dem Tenant-weiten Grant für alle Benutzer.

Ändert der Anbieter später die angeforderten Berechtigungen, greifen sie erst nach einem erneuten Consent, der frühere Tenant-weite Grants ersetzen kann.

Die Admin-Consent-URL

Der Anbieter schickt den Kunden-Admin auf den Admin-Consent-Endpunkt der Microsoft Identity Platform. Die Version 2 des Endpunkts sieht so aus:

https://login.microsoftonline.com/{tenant}/v2.0/adminconsent
    ?client_id={application-client-id}
    &scope=https://graph.microsoft.com/.default
    &redirect_uri={registered-redirect-uri}
    &state={opaque-value}

Die Bestandteile:

Tenant-Segment: die Tenant-ID des Kunden, eine verifizierte Domäne des Kunden oder der Platzhalter organizations. Mit organizations landet der Consent im Home-Tenant des Admins, der sich anmeldet. common ist für Admin Consent nicht vorgesehen.
adminconsent: der Pfad, der Entra anweist, nur einen berechtigten Administrator anmelden zu lassen und Tenant-weit zu fragen.
client_id: die Application (client) ID aus der Registrierung beim Anbieter. Sie bestimmt, wer Zugriff bekommt, und ist deshalb der Wert, den der Kunde prüfen sollte.
scope: https://graph.microsoft.com/.default fordert alle in der Registrierung hinterlegten Berechtigungen an. Für Anwendungsberechtigungen ist .default Pflicht.
redirect_uri: muss exakt einer in der App-Registrierung hinterlegten Redirect-URI entsprechen. Dorthin schickt Entra das Ergebnis.
state: ein beliebiger Wert, den Entra unverändert zurückgibt. Der Anbieter nutzt ihn, um die Antwort zuzuordnen.

Der ältere Endpunkt ohne v2.0 funktioniert weiterhin und fragt ohne scope alle registrierten Berechtigungen an. Nach erfolgreichem Consent leitet Entra auf die Redirect-URI weiter, mit admin_consent=True und der Tenant-ID des Kunden als Parametern.

Wer zustimmen darf und was der Dialog zeigt

Tenant-weiten Consent für Anwendungsberechtigungen von Microsoft Graph darf ein Global Administrator oder ein Privileged Role Administrator erteilen. Application Administrator und Cloud Application Administrator dürfen Tenant-weit zustimmen, aber nicht für Graph-Anwendungsberechtigungen. Für einen Monitoring-Dienst mit Application.Read.All braucht es also eine der beiden ersten Rollen.

Der Consent-Dialog zeigt:

den Namen der App,
den Herausgeber, entweder mit blauem Häkchen als verifizierter Publisher oder mit dem Hinweis „Unverified“,
die Liste der angeforderten Berechtigungen. Der Pfeil neben jeder Berechtigung öffnet ihre Beschreibung.

Die Beschreibung verrät den Typ: Anwendungsberechtigungen enden auf „without a signed-in user“, delegierte auf „on behalf of the signed-in user“. Wer über den Admin-Consent-Endpunkt kommt, sieht einen Dialog, dessen Titel und Texte deutlich machen, dass die Zustimmung für die ganze Organisation gilt. Wer die App stattdessen normal öffnet, sieht als berechtigter Admin die Checkbox „Consent on behalf of your organization“. Ohne Haken gilt die Zustimmung nur für das eigene Konto.

Die Anbieterseite: Multi-Tenant und verifizierter Publisher

Damit Kunden aus fremden Tenants überhaupt zustimmen können, muss die App-Registrierung des Anbieters als Multi-Tenant angelegt sein. Im Manifest steht dann signInAudience gleich AzureADMultipleOrgs, im Portal heißt die Option „Accounts in any organizational directory (Any Microsoft Entra directory - Multitenant)“.

Der zweite Punkt ist die Publisher-Verifizierung. Der Anbieter verknüpft seine App-Registrierung mit einem verifizierten Konto im Microsoft AI Cloud Partner Program (früher Microsoft Partner Network) und einer verifizierten Publisher-Domäne. Danach erscheint im Consent-Dialog das blaue Häkchen mit dem Firmennamen. Ohne Verifizierung steht dort „Unverified“.

Kunden dürfen das erwarten. Microsofts empfohlene Einstellung für User Consent lautet „Allow user consent for apps from verified publishers, for selected permissions“. Wer Anwendungsberechtigungen in fremden Tenants anfordert, sollte diesen Nachweis erbracht haben.

Least Privilege: warum nur Application.Read.All

Ein Werkzeug, das Ablaufdaten von Secrets und Zertifikaten überwacht, muss App-Registrierungen lesen. Mehr nicht. Microsoft Graph nennt für das Auflisten von Anwendungen Application.Read.All als am wenigsten privilegierte Berechtigung. Die Alternativen sind deutlich breiter:

Berechtigung	Anzeigename	Erlaubt laut Microsoft Graph
`Application.Read.All`	Read all applications	Alle Anwendungen und Service Principals lesen, ohne angemeldeten Benutzer
`Application.ReadWrite.All`	Read and write all applications	Anwendungen und Service Principals anlegen, lesen, ändern und löschen, einschließlich ihrer Credentials
`Directory.Read.All`	Read directory data	Verzeichnisdaten lesen, darunter Benutzer, Gruppen und Apps

Application.ReadWrite.All ist für ein Monitoring falsch: Wer Credentials an fremden Apps anlegen darf, kann in deren Namen handeln. Microsoft warnt in der Berechtigungsreferenz ausdrücklich davor. Directory.Read.All liest zusätzlich alle Benutzer und Gruppen, die ein Secret-Monitoring nie braucht. Microsoft rät, Directory-Berechtigungen zu meiden, wenn eine ressourcenspezifische Berechtigung reicht.

Die Faustregel für Kunden: Steht im Dialog etwas mit „ReadWrite“ oder „Directory“, sollte der Anbieter erklären, warum.

Consent prüfen und widerrufen

Im Microsoft Entra Admin Center unter Entra ID > Enterprise apps > All applications öffnet der Kunde die App, dann Permissions, und sieht im Tab Admin consent alle Tenant-weit erteilten Berechtigungen. Über die drei Punkte neben einer Berechtigung lässt sich Revoke permission auswählen. Dafür reicht die Rolle Cloud Application Administrator.

Soll die App komplett aus dem Tenant verschwinden, löscht der Admin den Service Principal über Properties > Delete. Die App liegt danach 30 Tage im Papierkorb und lässt sich in dieser Zeit wiederherstellen.

Consent im Audit-Log

Jeder Consent hinterlässt Spuren in den Entra-Audit-Logs, Dienst Core Directory, Kategorie ApplicationManagement. Relevante Aktivitäten:

Add service principal: die App wurde im Tenant angelegt,
Add app role assignment to service principal: eine Anwendungsberechtigung wurde erteilt,
Add delegated permission grant: eine delegierte Berechtigung wurde Tenant-weit erteilt,
Consent to application: der Consent-Vorgang selbst, mit dem zustimmenden Benutzer als Akteur.

Beim Widerruf erscheinen die Gegenstücke Remove app role assignment from service principal, Remove delegated permission grant und Remove service principal. Speziell Graph-Berechtigungen zeigt die Anwendung Microsoft Graph unter Enterprise apps im Bereich Audit logs; die Rolle Reports Reader reicht dafür.

GDAP und Admin Consent sind zwei verschiedene Dinge

MSPs im CSP-Programm arbeiten mit Granular Delegated Admin Privileges (GDAP). Dabei beantragt der Partner im Partner Center eine Admin-Beziehung mit bestimmten Entra-Rollen und einer Laufzeit von 1 bis 730 Tagen. Ein Global Administrator des Kunden genehmigt sie im Microsoft 365 Admin Center. Die Rollen werden Sicherheitsgruppen im Partner-Tenant zugewiesen. Techniker des MSP handeln dann als Personen mit diesen Rollen im Kunden-Tenant.

Admin Consent für eine App ist davon unabhängig. Er gibt keinem Menschen eine Rolle, sondern einem Service Principal eine Berechtigung. Er hat kein Ablaufdatum und endet nicht mit der GDAP-Beziehung. Der Kunde sollte ihn deshalb bewusst selbst erteilen und dokumentieren.

Checkliste für Kunden vor dem Consent

Prüfe, ob die client_id in der URL mit der Application ID übereinstimmt, die der Anbieter schriftlich genannt hat.
Prüfe, ob der Dialog einen verifizierten Publisher mit dem erwarteten Firmennamen zeigt.
Prüfe, ob die Liste nur Berechtigungen enthält, die zum Zweck passen. Für Secret-Monitoring: Application.Read.All und sonst nichts.
Prüfe, ob alle Beschreibungen auf „without a signed-in user“ enden und ob der Anbieter erklärt, warum die App ohne Benutzer läuft.
Halte fest, wer den Consent wann erteilt hat und wo der Anbieter den Widerruf beschreibt.
Kontrolliere nach dem Consent den Eintrag im Audit-Log und den dort genannten Akteur.

Wie SecretExpiry hilft

SecretExpiry fordert genau eine Anwendungsberechtigung an: Application.Read.All, nur lesend. Der Kunde erteilt den Admin Consent einmal pro Tenant, danach überwacht der Dienst Client Secrets und Zertifikate aller verbundenen Tenants in einem Dashboard mit Dringlichkeitsliste. Benachrichtigungen gehen per E-Mail je Ereignis oder als Wochenübersicht, in einen Teams- oder Slack-Kanal per Webhook und als Kalender-Abo (ICS), mit eigener Empfängeradresse je Tenant und Snooze-Funktion. Was beim Ablauf eines Secrets passiert, beschreibt der Beitrag Entra App Registration Secrets laufen ab. Details zum Consent-Ablauf stehen in der Dokumentation. Der Test ist 14 Tage kostenlos, danach ab 10 € pro Tenant und Monat.