Was Microsoft nicht meldet: Ablaufende App-Credentials in Entra

Nach dem ersten Ausfall durch ein abgelaufenes Client Secret stellt jede IT dieselbe Frage: Hätte Microsoft nicht warnen können? Die kurze Antwort: Für App-Registrierungen gibt es keine Benachrichtigung. Die lange Antwort ist eine Karte. Microsoft bietet durchaus einiges, aber jedes Angebot hat einen klar begrenzten Zuständigkeitsbereich, und keines davon ist ein Alarm für deine Client Secrets und Zertifikate.

Dieser Beitrag geht die Quellen einzeln durch, jeweils mit dem Stand auf Microsoft Learn. Die Grundlagen, warum Credentials ablaufen und wie du ohne Ausfall rotierst, stehen im Beitrag Entra App Registration Secrets laufen ab.

Keine E-Mail für Client Secrets und Zertifikate

Microsoft Learn dokumentiert keine E-Mail-Benachrichtigung für ablaufende Client Secrets oder Zertifikate einer App-Registrierung. Die einzige dokumentierte Ablauf-Mail betrifft etwas anderes: Für Enterprise Applications mit SAML-SSO verschickt Entra ID 60, 30 und 7 Tage vor Ablauf des SAML-Signaturzertifikats eine Mail an bis zu fünf hinterlegte Adressen. Das ist das Zertifikat, mit dem Entra Token signiert, nicht das Credential, mit dem sich deine Anwendung anmeldet.

Microsofts eigene Empfehlung in der Dokumentation zu Microsoft.Identity.Web lautet entsprechend: die Spalte „Expires“ unter „Certificates & secrets“ prüfen und die Entra Recommendations nutzen. Beides sind in erster Linie Ansichten, keine Alarme.

Was das Portal zeigt

Zwei Stellen im Entra Admin Center zeigen Ablaufdaten:

• Die Seite Certificates & secrets einer App-Registrierung listet jedes Client Secret und jedes Zertifikat mit Ablaufdatum.
• Die Liste App registrations hat eine Statusspalte „Certificates & secrets“. Nach meiner Beobachtung zeigt sie pro App „Current“, „Expiring soon“ oder „Expired“; die genauen Schwellen dahinter dokumentiert Microsoft nicht.

Beides funktioniert, sobald jemand hinschaut. Für einen Tenant mit zehn Apps reicht ein wöchentlicher Blick. Für 40 Kunden-Tenants heißt es 40 Anmeldungen.

Microsoft Entra Recommendations

Die Recommendations sind das Nächste, was Microsoft zu einem eingebauten Ablauf-Monitor hat. Vier Einträge betreffen App-Credentials, alle derzeit in Preview:

• Renew expiring application credentials (applicationCredentialExpiry): Credentials einer App-Registrierung, die innerhalb der nächsten 30 Tage ablaufen.
• Renew expiring service principal credentials (servicePrincipalKeyExpiry): dasselbe für Credentials direkt am Service Principal.
• Remove unused credentials from applications (staleAppCreds).
• Remove unused applications (staleApps).

Du findest die Liste unter Entra ID, Overview, Reiter Recommendations, oder per Microsoft Graph unter /beta/directory/recommendations. Im Admin Center sind die betroffenen Ressourcen auf 50 Einträge begrenzt, die vollständige Liste liefert nur Graph. Zum Lesen reicht die Rolle Reports Reader. Eine eigene Lizenz nennt Microsoft für diese vier Einträge nicht; die Übersicht sagt nur, dass manche Recommendations P2 oder eine andere Lizenz brauchen und dass sich die Anforderungen in der Preview ändern können.

Drei Eigenschaften machen daraus ein Dashboard-Element und keinen Alarm:

1. Aktualisierung: Die Daten werden alle 24 Stunden mit einem Tag Verzögerung aufbereitet, in Einzelfällen dauert es bis zu 72 Stunden. Ein Secret, das morgen abläuft, kann heute noch fehlen.
2. Feste Schwelle: 30 Tage, nicht änderbar. Bereits abgelaufene Credentials erscheinen als „completed“, nicht als Problem.
3. E-Mail nur bei neuer Recommendation: In Preview verschickt Entra eine Mail, wenn eine Recommendation neu erzeugt wird. Empfänger sind alle Nutzer mit aktiv zugewiesener Rolle Application Administrator. Wer die Rolle nur per PIM aktivieren kann, bekommt nichts. Ist niemand aktiv zugewiesen, geht keine Mail raus. Eine Empfängeradresse lässt sich nicht hinterlegen, und Microsoft selbst rät, die Recommendations trotzdem regelmäßig zu prüfen.

Wer Microsoft Defender mit App Governance und einer Workload ID Premium Lizenz nutzt, bekommt dort zusätzlich Filter nach Ablaufdatum. Auch das ist eine Ansicht pro Tenant.

Message Center und Service Health

Beide Kanäle im Microsoft 365 Admin Center haben mit deinen Credentials nichts zu tun. Das Message Center kündigt geplante Änderungen an Microsoft-Diensten an. Service Health meldet Incidents und Advisories in der von Microsoft betriebenen Umgebung; Störungen durch Änderungen in der Kundenumgebung gelten ausdrücklich nicht als Service Incident. Ein abgelaufenes Secret ist genau so eine Änderung.

Azure Key Vault meldet, aber nur für sich selbst

Key Vault ist die eine Stelle, an der Microsoft tatsächlich vor dem Ablauf warnt. Über Event Grid liefert ein Vault unter anderem die Ereignisse Microsoft.KeyVault.SecretNearExpiry und Microsoft.KeyVault.CertificateNearExpiry, jeweils 30 Tage vor dem Ablaufdatum, sowie SecretExpired und CertificateExpired. Daran hängst du eine Logic App oder eine Function und hast eine echte Benachrichtigung.

Die Einschränkung: Das gilt nur für Objekte im Vault. Legst du den Wert eines Client Secrets als Key-Vault-Secret ab und trägst das Ablaufdatum von Hand ein, warnt Key Vault für diese Kopie. Die App-Registrierung selbst kennt den Vault nicht, und ein Secret, das jemand im Portal angelegt hat, taucht dort nie auf.

Was du selbst bauen kannst

Sign-in-Logs: die Meldung nach dem Ausfall

Sobald ein Secret abgelaufen ist, lehnt Entra die Token-Anforderung mit AADSTS7000222 ab (InvalidClientSecretExpiredKeysProvided). Der Fehlschlag landet in den Sign-in-Logs unter Service Principal Sign-ins. Streamst du die Logs per Diagnostic Setting nach Log Analytics (Entra ID P1 oder P2 erforderlich), kannst du darauf eine Alert Rule setzen:

AADServicePrincipalSignInLogs
| where ResultType == "7000222"
| summarize Failures = count(), LastSeen = max(TimeGenerated)
    by ServicePrincipalName, AppId, ServicePrincipalCredentialKeyId

Das ist nützlich, um schnell zu erfahren, welche App gerade steht. Proaktiv ist es nicht: Die Abfrage feuert erst, wenn die Anmeldung bereits fehlgeschlagen ist.

PowerShell mit Microsoft Graph

Vor dem Ablauf helfen nur die Ablaufdaten selbst. Microsoft Graph liefert sie über PasswordCredentials und KeyCredentials jeder Anwendung, jeweils mit EndDateTime. Ein Runbook in Azure Automation mit Managed Identity, deren Application-Berechtigung Application.Read.All einmal per Admin Consent erteilt wurde, kommt ohne eigenes Secret aus:

Connect-MgGraph -Identity   # Managed Identity des Automation-Kontos
$limit = (Get-Date).AddDays(30)

Get-MgApplication -All | ForEach-Object {
  $app = $_
  foreach ($cred in @($app.PasswordCredentials) + @($app.KeyCredentials)) {
    if ($cred.EndDateTime -lt $limit) {
      "$($app.DisplayName): $($cred.DisplayName) läuft ab am $($cred.EndDateTime)"
    }
  }
}

Microsoft veröffentlicht auf Learn ähnliche Beispielskripte mit CSV-Export. Die Ausgabe verschickst du dann per Logic App mit der Office 365 Outlook Aktion „Send an email (V2)“.

Azure Automation oder Logic Apps

Der Zeitplan ist der einfache Teil. Azure Automation führt das Runbook täglich aus, eine Logic App mit Recurrence-Trigger ruft es auf und verschickt die Mail. Nach einem Nachmittag steht die erste Version.

Was Selbstbau im Betrieb kostet

Die erste Version ist nicht das Problem. Das Problem ist das dritte Jahr.

• Das Skript braucht selbst ein Credential. Eine Managed Identity funktioniert nur im eigenen Tenant. Für Kunden-Tenants brauchst du eine Multi-Tenant-App-Registrierung mit Zertifikat oder Secret, und dieses Credential läuft ebenfalls ab. Das Monitoring für ablaufende Secrets fällt dann am selben Tag aus wie das, was es überwachen soll.
• Multi-Tenant-Schleifen. Consent pro Tenant, eine Liste von Tenant-IDs, die jemand pflegt, Fehlerbehandlung, damit ein Tenant mit entzogenem Consent nicht den ganzen Lauf abbricht, und die Zuordnung der Ausgabe zum richtigen Kunden.
• Modulpflege. Die Graph-PowerShell-Module in Automation müssen versioniert und gelegentlich zurückgerollt werden; Anmeldefehler mit Managed Identity nach einem Modul-Update sind ein bekanntes Muster.
• Alert-Müdigkeit. Eine tägliche Mail mit denselben 30 Zeilen wird nach zwei Wochen weggefiltert. Schwellen, Deduplizierung, Snooze und die Weiterleitung an den zuständigen Kunden-Kontakt sind Funktionen, die niemand am ersten Nachmittag baut.
• Besitz. Das Skript gehört der Person, die es geschrieben hat. Wenn sie geht, läuft es weiter, bis es das nicht mehr tut.

Vergleich der Quellen

Wie SecretExpiry hilft

SecretExpiry liest App-Registrierungen mit der Graph-Berechtigung Application.Read.All nur lesend und synchronisiert Client Secrets und Zertifikate über viele Tenants fortlaufend. Warnungen gehen per E-Mail pro Ereignis oder als Wochen-Digest, als Webhook an Microsoft Teams oder Slack und als Kalender-Abo (ICS). Jeder Tenant kann eine eigene Benachrichtigungsadresse haben, einzelne Credentials lassen sich snoozen, und das Dashboard zeigt eine Liste der dringenden Fälle. Die Einrichtung ist in der Dokumentation beschrieben; der Dienst kostet ab 10 € pro Tenant und Monat, mit 14 Tagen kostenlosem Test.

Was du diese Woche tun kannst

Unabhängig vom Werkzeug: Öffne in jedem Tenant einmal die Recommendations und die Statusspalte in der App-Registrierungsliste und notiere, was innerhalb von 30 Tagen abläuft. Prüfe, ob überhaupt jemand die Rolle Application Administrator aktiv zugewiesen hat, sonst kommt auch die Recommendation-Mail nie an. Und lege fest, wer in drei Jahren noch weiß, wo das Skript läuft.