4 min readMicrosoft Entra · App Registrations · Best Practices
Entra App Registration Secrets laufen ab: So verhinderst du den Ausfall
Warum Client Secrets und Zertifikate in Microsoft Entra ablaufen, warum Microsoft nicht warnt und wie IT-Admins und MSPs Ausfälle sicher vermeiden.
Ein abgelaufenes Client Secret ist eine der häufigsten Ursachen für plötzlich stehende Integrationen in Microsoft 365: Das Backup meldet sich nicht mehr, der Ticket-Connector schweigt, ein PowerShell-Job bricht mit einem Authentifizierungsfehler ab. Nichts wurde geändert, nichts wurde gehackt. Ein Datum ist einfach abgelaufen.
Warum Secrets und Zertifikate überhaupt ablaufen
Jede App-Registrierung in Microsoft Entra ID authentifiziert sich mit einem Client Secret oder einem Zertifikat. Beide haben ein festes Ablaufdatum:
- Client Secrets bekommen ihre Laufzeit beim Erstellen. Das Entra-Portal schlägt 180 Tage vor und erlaubt maximal 24 Monate.
- Zertifikate laufen ab, wenn das Zertifikat selbst abläuft, meist nach ein bis drei Jahren.
Das ist so gewollt. Ein Credential, das nie abläuft, ist ein Credential, das nach einem Leak für immer gültig bleibt. Das Problem ist nicht das Ablaufdatum, sondern dass niemand rechtzeitig davon erfährt.
Microsoft warnt nicht
Microsoft Entra hat keine eingebaute Benachrichtigung für ablaufende App-Credentials. Keine E-Mail, keine Meldung im Admin Center, kein Eintrag im Service Health. Die Liste der App-Registrierungen zeigt in der Spalte „Zertifikate & Geheimnisse“ zwar „Läuft bald ab“ an, aber die muss jemand aktiv öffnen. Für jeden Tenant. Regelmäßig.
Bei einem Tenant mit fünf Apps geht das noch. Ein MSP mit 40 Kunden-Tenants und mehreren hundert App-Registrierungen hat diese Übersicht ohne Werkzeug nicht.
Was beim Ablauf passiert
Sobald das Secret abgelaufen ist, lehnt Entra die Token-Anforderung ab. Im Log steht dann zum Beispiel:
AADSTS7000222: The provided client secret keys for app '…' are expired.
Alles, was diese App nutzt, steht: Graph-API-Skripte, Backup- und Archivierungslösungen, Monitoring-Tools, Power-Automate-Verbindungen, Single Sign-on in Drittanbieter-Apps. Oft erfährt es die IT erst vom Fachbereich, der sich wundert, warum seit gestern keine Daten mehr ankommen.
Vier Wege, den Überblick zu behalten
1. Die Portal-Spalte
Im Entra Admin Center unter App-Registrierungen zeigt die Spalte „Zertifikate & Geheimnisse“ je App, ob ein Credential aktuell, bald ablaufend oder abgelaufen ist. Kostet nichts, funktioniert, skaliert nicht. Jemand muss daran denken, und bei mehreren Tenants heißt das mehrfach anmelden.
2. PowerShell mit Microsoft Graph
Ein Skript, das alle App-Registrierungen samt Credentials liest und die in den nächsten 30 Tagen ablaufenden nach Datum sortiert:
Connect-MgGraph -Scopes "Application.Read.All"
$limit = (Get-Date).AddDays(30)
Get-MgApplication -All -Property DisplayName, AppId, PasswordCredentials, KeyCredentials |
ForEach-Object {
$app = $_
@($app.PasswordCredentials) + @($app.KeyCredentials) |
Where-Object { $_.EndDateTime -lt $limit } |
ForEach-Object {
[pscustomobject]@{
App = $app.DisplayName
Credential = $_.DisplayName
Expires = $_.EndDateTime
}
}
} | Sort-Object Expires
Das funktioniert gut, solange jemand es regelmäßig ausführt, die Ausgabe liest und für jeden Tenant eine Verbindung pflegt. In der Praxis liegt das Skript nach drei Monaten in einem Ordner, den niemand mehr öffnet.
3. Azure Automation oder Logic App
Das Skript aus Punkt 2 als Runbook oder Logic App mit Zeitplan, dazu ein E-Mail-Versand. Zuverlässiger als manuell, aber jetzt betreibst du selbst eine kleine Anwendung: Berechtigungen, ein eigenes Credential für die Automation (das ebenfalls abläuft), Fehlerbehandlung, ein Deployment pro Tenant.
4. Ein Dienst, der genau das macht
SecretExpiry liest per Admin Consent mit der Berechtigung Application.Read.All nur Metadaten aus: App-Namen, IDs und Ablaufdaten. Die Secret-Werte selbst sieht der Dienst nie. Danach:
- täglicher Sync über alle verbundenen Tenants in einem Dashboard,
- Warnungen per E-Mail an Schwellenwerten deiner Wahl (Standard 90, 30, 14, 7 und 1 Tag), sofort oder als Wochen-Zusammenfassung,
- dieselben Warnungen in einem Teams- oder Slack-Kanal,
- alle Ablaufdaten als Kalender-Abo in Outlook,
- eine eigene Empfängeradresse je Kunden-Tenant.
Der Aufwand pro Tenant: einmal Admin Consent erteilen.
Rotation ohne Ausfall: fünf Regeln
Zu wissen, wann etwas abläuft, ist die halbe Miete. Die andere Hälfte ist, das Credential so zu tauschen, dass nichts stehen bleibt:
- Überlappend rotieren. Neues Secret anlegen, Anwendung umstellen, prüfen, erst dann das alte löschen. Eine App-Registrierung darf mehrere gültige Secrets gleichzeitig haben.
- Zertifikate statt Secrets, wo die Anwendung es unterstützt. Sie sind schwerer zu leaken und laufen typischerweise länger.
- Managed Identities und Workload Identity Federation für alles, was in Azure, GitHub Actions oder Kubernetes läuft. Dort gibt es kein Secret mehr, das ablaufen kann.
- Beschreibung und Besitzer pflegen. Ein Secret namens „Test“ ohne Owner ist im Ernstfall nicht zuzuordnen. Schreib den Zweck in die Beschreibung und trage einen Besitzer an der App ein.
- Laufzeiten vereinheitlichen. Zwölf Monate für Secrets, Warnstufen bei 30, 14 und 7 Tagen. Dann fällt Rotation in einen Rhythmus statt in Notfälle.
Fazit
Abgelaufene Secrets sind kein Sicherheitsvorfall, sondern ein Kalenderproblem. Wer die Ablaufdaten aller App-Registrierungen an einer Stelle sieht und rechtzeitig erinnert wird, rotiert entspannt, statt nachts Integrationen wiederzubeleben. Ob mit einem Skript, einer Automation oder einem Dienst: Hauptsache, es passiert automatisch.