Ob Automatisierung, API-Integration oder SSO: Ohne App-basierte Verbindungen läuft in Microsoft 365 und Azure kaum noch etwas. Trotzdem legen abgelaufene App-Secrets und Zertifikate in erstaunlich vielen Tenants, die ich betreue, immer wieder Dienste lahm. Plötzlich funktioniert ein Service nicht mehr, weil ein Credential abgelaufen ist, ohne dass jemand Bescheid wusste oder ein Monitoring angeschlagen hätte. Ich erlebe das in ganz ähnlicher Form immer wieder: Das App-Secret läuft am Wochenende ab, die Benachrichtigung landet bei einem Projektleiter, der längst nicht mehr im Unternehmen ist, und am Montag steht ein Geschäftsprozess still.
Microsoft Graph PowerShell zeigt ablaufende App-Credentials zuverlässig an
Für das Reporting greife ich gern zu Microsoft Graph PowerShell. Stimmen die Berechtigungen (etwa Application.Read.All, delegiert oder als Managed Identity), läuft die Abfrage auch in großen Umgebungen zuverlässig. Das folgende Beispielskript (PowerShell 7, Modul Microsoft.Graph.Applications) liefert einen Überblick über alle App-Registrierungen und ihre Credentials:
# Voraussetzung: PowerShell 7, Microsoft.Graph.Applications Modul, Application.Read.All
Connect-MgGraph -Scopes Application.Read.All
$applications = Get-MgApplication -All -Property displayName,passwordCredentials,keyCredentials
$expiringCreds = foreach ($app in $applications) {
foreach ($cred in $app.PasswordCredentials + $app.KeyCredentials) {
if ($cred.EndDateTime -lt (Get-Date).AddDays(30)) {
[PSCustomObject]@{
AppName = $app.DisplayName
CredentialType = if ($cred.KeyId) { 'KeyCredential' } else { 'PasswordCredential' }
EndDateTime = $cred.EndDateTime
}
}
}
}
$expiringCreds | Format-Table
Damit erkenne ich sofort, welche Credentials bald ablaufen. Bei Service Principals mit mehreren Keys ist das besonders hilfreich. Soll das Reporting automatisch laufen, lässt sich das Skript in Azure Automation mit einer Managed Identity ausführen, die dafür Application.Read.All auf Tenant-Ebene benötigt. Einen CSV-Export, der per E-Mail an die App-Owner geht, richte ich grundsätzlich mit ein.
Aus Erfahrung: Bei wichtigen App-Registrierungen sollten immer mehrere Owner eingetragen sein, am besten echte Personen und zusätzlich ein zentraler Admin-Account. Steht ein Ablauf bevor, werden die Owner benachrichtigt – das hilft aber nur, wenn die Konten auch tatsächlich genutzt werden.
SAML-Zertifikate von Enterprise-Apps bleiben oft unbemerkt
Gern übersehen werden die SAML-Signaturzertifikate von Enterprise-Anwendungen. Sie hängen nicht an einer App-Registrierung, sondern an einer „Enterprise Application“ (Service Principal) in Entra ID und laufen in der Regel nach drei Jahren ab. Das Tückische daran: Ist ein solches Zertifikat abgelaufen, funktioniert SSO nicht mehr, und die Fehlersuche zieht sich meist hin, weil die übliche Überwachung von App-Secrets hier nicht greift. Die Laufzeiten stehen im Entra Admin Center unter „Enterprise-Anwendungen → → Single Sign-On → SAML-Zertifikate“. Eine fertige Abfrage, die alle SAML-Zertifikate im Tenant auflistet, gibt es derzeit leider nicht. Mit der Graph API (siehe Dokumentation zur Application-Ressource) und etwas PowerShell lassen sich aber auch diese Zertifikate regelmäßig prüfen. In meinen Projekten plane ich diese Prüfungen deshalb als Ergänzung zum eigentlichen Reporting ein.
Das Entra Admin Center warnt inzwischen selbst vor ablaufenden Credentials
Microsoft hat im Entra Admin Center nachgelegt. Unter „Identität → Überwachung & Gesundheit → Empfehlungen“ tauchen Hinweise auf ablaufende App-Credentials auf, mit Links zur betroffenen App und häufig auch zur zuständigen Person. Die Grundlage dafür bilden der Identity Secure Score und die Entra-ID-Empfehlungen (mehr dazu). Allein darauf verlassen würde ich mich allerdings nicht: Die Empfehlungen erfassen nicht immer alle Fälle und erscheinen teils recht kurzfristig. Für mich sind sie deshalb ein zusätzlicher Kontrollpunkt und kein Ersatz für das eigene Monitoring.
Das folgende einfache Ablaufdiagramm zeigt, wie Reporting, Alerting und Behebung ineinandergreifen:
flowchart TD
Erkennung["Credential Reporting"] --> Alert["Alert an Owner/Admin"]
Alert --> Maßnahme["Credential erneuern"]
Maßnahme --> Erfolg["App bleibt funktionsfähig"]
Abbildung: Vom Credential-Reporting über das Alerting bis zur Verlängerung.
Azure Automation verschickt den Bericht per Managed Identity
Regelmäßige Berichte erstelle ich mit Azure Automation und einer Managed Identity. Diese Lösung ist datenschutzkonform und servicebasiert, App-Secrets braucht es dafür keine. Für die Abfrage genügt es, der Managed Identity Application.Read.All auf Tenant-Ebene zuzuweisen. Der Runbook-Job schickt die CSV-Datei per E-Mail an eine festgelegte Adresse, am besten an ein zentrales IT-Postfach oder direkt an die App-Owner. Wer weitergehen möchte, wertet per PowerShell zusätzlich das Owners-Attribut jeder App aus und listet die tatsächlichen Ansprechpartner auf. So lässt sich das Alerting gezielt steuern.
In meinen Reviews stoße ich dabei regelmäßig auf verwaiste App-Registrierungen, bei denen kein gültiger Owner mehr hinterlegt ist oder das Owner-Konto längst deaktiviert wurde. Diese Fälle dokumentiere ich und sorge dafür, dass sie bereinigt werden. Ausführlicher habe ich das im Beitrag /blog/entra-id-ungenutzte-apps-service-principals-bereinigen beschrieben.
Die Überwachung von App-Credentials bleibt eine Daueraufgabe
Abgelaufene App-Credentials gehören nach wie vor zu den klassischen Ausfallursachen. Wer das Thema unterschätzt, muss mit technischen Störungen rechnen und obendrein mit Imageschäden, vor allem wenn Integrationen an geschäftskritischen Prozessen hängen. Die nötige Transparenz entsteht erst, wenn eigenes Reporting und zentrales Alerting zusammenspielen und die Entra-Empfehlungen ergänzend hinzukommen. Wichtig ist, das Ganze als fortlaufenden Prozess zu verstehen und nicht als einmalige Aufräumaktion. Je sorgfältiger die Owner gepflegt sind, desto verlässlicher greifen sämtliche Warnmechanismen. In jedem Entra-Tenant gehört diese Überwachung für mich heute fest dazu.


