In vielen Tenants, die ich mir anschaue, liegen noch Altlasten herum. Gemeint sind Serviceprinzipale, die einmal für Legacy-Anwendungen oder alte Drittanbieter-Tools angelegt wurden und bei denen oft niemand mehr genau weiß, wozu sie eigentlich da sind. Die Abschaltung von Azure AD Graph wirkte lange wie ein fernes Thema. Seit dem aktualisierten Zeitplan vom August 2024 ist klar, dass es jetzt ernst wird.

Microsoft hat die Fristen für Azure AD Graph deutlich verschärft

Mit den Ankündigungen vom August 2024 hat Microsoft die Zügel spürbar angezogen. Ab dem 1. Februar 2025 dürfen Anwendungen den Azure-AD-Graph-API-Endpunkt nur noch verwenden, wenn sie ausdrücklich für einen verlängerten Zugriff konfiguriert sind (authenticationBehaviors → blockAzureADGraphAccess = false). Alle anderen werden dann abgewiesen. Im Laufe des Jahres 2025 ist schließlich endgültig Feierabend, denn dann nimmt Azure AD Graph überhaupt keine Anfragen mehr an. Betroffen sind viele Altanwendungen, aber ebenso Drittanbieterprodukte, um die sich seit Jahren niemand mehr kümmert. Wer den Umstieg weiter vor sich herschiebt, muss ab Februar 2025 damit rechnen, dass Integrationen plötzlich ausfallen – und das meist genau dann, wenn es am wenigsten passt.

Betroffene Anwendungen lassen sich an mehreren Stellen aufspüren

Zuerst braucht man einen Überblick. Microsoft unterstützt dabei inzwischen selbst: Im Entra Admin Center taucht unter Übersicht → Empfehlungen ein Eintrag auf, der alle Serviceprinzipale auflistet, die noch Azure-AD-Graph-APIs aufrufen. Als erster Filter taugt das gut, eine gründliche Recherche ersetzt es aber nicht. Heikel sind vor allem Anwendungen, die in den vergangenen Monaten kaum genutzt wurden und dann zu bestimmten Terminen im Jahr auf einmal unverzichtbar sind, etwa bei Gehaltsläufen oder speziellen Reports.

Aufschlussreich ist auch ein Blick auf die API-Berechtigungen der App-Registrierungen. Steht dort noch Azure Active Directory Graph, zum Beispiel mit Berechtigungen wie „Directory.Read.All“, besteht Handlungsbedarf. Das gilt ebenso für eigene Automatisierungsskripte, PowerShell-Module oder interne Tools, besonders dann, wenn sie nie auf Microsoft Graph umgestellt wurden.

Praxistipp: In meinen Projekten hat es sich bewährt, über das letzte Anmeldedatum der Serviceprinzipale hinauszuschauen und gezielt nach Berechtigungen auf „Azure Active Directory Graph“ zu filtern. Auf diese Weise fallen auch alte Integrationen auf, an denen noch kritische Prozesse hängen.

Im PowerShell-Terminal (z. B. PowerShell 7 mit dem Microsoft.Graph-Modul, Rolle: Application Administrator) ist der Überblick schnell erstellt:

Get-MgApplication -All | Where-Object {
    $_.RequiredResourceAccess.ResourceAppId -contains '00000002-0000-0000-c000-000000000000'
} | Select-Object DisplayName, AppId

Das Skript gibt alle App-Registrierungen aus, die noch auf die alte Azure AD Graph API (AppId: 00000002-0000-0000-c000-000000000000) verweisen.

Der Umstieg auf Microsoft Graph erfordert mehr als Suchen und Ersetzen

Sind die Altlasten gefunden, fängt die eigentliche Arbeit erst an. Welcher Weg der richtige ist, hängt von der Anwendung ab. Selbst entwickelte Tools müssen im Code auf Microsoft Graph umgestellt werden, und mit Suchen und Ersetzen kommt man dabei selten weit. Die Microsoft Graph API ist strukturell wie inhaltlich anders aufgebaut: Viele Endpunkte heißen inzwischen anders, und Rückgabeobjekte oder Authentifizierung weichen oft ab. Eine Übersicht samt Migrationshilfe findet sich im offiziellen Leitfaden von Microsoft, zusätzlich lohnen sich die Empfehlungen im Entra Admin Center.

Bei Drittanbieter-Apps wird es häufig schwierig. Liefert der Hersteller keine Updates mehr oder gibt es ihn gar nicht mehr, bleibt nur, die Anwendung abzuschalten oder nach Ersatz zu suchen. In manchen Fällen lässt sich etwas Zeit gewinnen, indem man die verlängerte Nutzung über die Einstellung authenticationBehaviors vorübergehend aktiviert. Mehr als ein Aufschub bis zur vollständigen Abschaltung später im Jahr ist das allerdings nicht.

Gern unterschätzt wird das Berechtigungsmodell, das in Microsoft Graph wesentlich feiner aufgeteilt ist. Viele Rollen und Scopes müssen neu justiert werden, vor allem wenn bisher „allmächtige“ Directory-Berechtigungen im Spiel waren. Welche Authentifizierungs- und Berechtigungsverhalten unterstützt werden, steht in der offiziellen Übersicht.

Die verlängerte Nutzung verschafft nur einen kurzen Aufschub

Für die Zeit ab Februar 2025 gibt es eine Ausnahmeregel. Anwendungen, die ausdrücklich mit der Einstellung blockAzureADGraphAccess = false konfiguriert sind, dürfen Azure AD Graph vorübergehend weiterverwenden. Admins bekommen damit eine letzte Verschnaufpause, die aber ebenfalls bald endet. Eingerichtet wird die Ausnahme direkt in der App-Registrierung im Entra Admin Center oder per PowerShell. Wer davon Gebrauch macht, sollte einen klaren Migrationsplan in der Schublade haben, denn mit der endgültigen Abschaltung der API funktioniert ohnehin nichts mehr. Die Ausnahme ungeprüft zu setzen, nur damit die Warnungen verschwinden, löst das Problem also nicht.

Den Ablauf habe ich zur Veranschaulichung in einer kleinen Mermaid-Grafik skizziert:

flowchart TD
    Start["Ab Februar 2025?"] --> CheckBehavior["blockAzureADGraphAccess = false?"]
    CheckBehavior -- "Ja" --> AllowAccess["Zugriff auf Azure AD Graph erlaubt"]
    CheckBehavior -- "Nein" --> BlockAccess["Zugriff auf Azure AD Graph blockiert"]
    AllowAccess --> Shutdown["Komplettabschaltung später 2025"]
    BlockAccess --> Shutdown
    Shutdown --> End["Zugriff endgültig gesperrt"]

Abbildung: Zugriff auf Azure AD Graph nach Februar 2025 – Ablauf je nach Einstellung

Die Abschaltung trifft viele Tenants härter als erwartet

Ich kann nur dazu raten, das Thema ernst zu nehmen. Für viele Tenants wird die Abschaltung von Azure AD Graph schmerzhafter, als es zunächst aussieht. In der Praxis stoße ich immer wieder auf Integrationen, die seit Jahren niemand dokumentiert hat, und oft kann keiner mehr sagen, was bei einem Ausfall alles mit wegbricht. Wer jetzt sorgfältig prüft, die App-Registrierungen durchgeht und die Migrationen plant, erspart sich im Frühjahr 2025 schlaflose Nächte. Diesmal lässt Microsoft Nachzüglern kaum Spielraum.

Noch ein Hinweis zum Schluss: Wer gerade ohnehin andere Modernisierungsprojekte vorantreibt, etwa die Umstellung auf den neuen Teams-Client (siehe /blog/neues-microsoft-teams-umstieg-planen), sollte die Migration gleich mit einplanen. Abhängigkeiten lassen sich so besser abstimmen, und unnötiger Ärger bleibt aus.