All posts

7 min readMicrosoft Entra · App Registrations · Troubleshooting

AADSTS7000222 und andere Fehlercodes abgelaufener Entra-Credentials: Ursachen und Behebung

AADSTS7000222, AADSTS7000215 und weitere Fehlercodes, die Anwendungen bei abgelaufenen oder ungültigen Entra Client Secrets und Zertifikaten sehen: Meldung, Ursache, Fundort im Log, Behebung. Dazu: Token-Antwort lesen, Credentials per Portal und PowerShell prüfen, schnell wiederherstellen.

Read this post in English

Ein Backup-Job bricht ab, ein Connector liefert nichts mehr, im Log steht eine Zeile mit AADSTS und einer langen Zahl. Dieser Leitfaden ordnet die Fehlercodes ein, die Anwendungen bei abgelaufenen, falschen oder fehlenden Entra-Credentials bekommen: Meldung, Ursache, Fundort, Behebung. Die Meldungen stammen aus der Referenz der Entra-Fehlercodes und den Troubleshooting-Artikeln auf Microsoft Learn.

So liest du die Antwort des Token-Endpunkts

Der Token-Endpunkt antwortet bei Fehlern mit HTTP 400 oder 401 und einem JSON-Body. MSAL und andere Bibliotheken reichen den Text als Exception durch, deshalb steht er unverändert im Anwendungslog. Die Antwort bei einem abgelaufenen Secret:

{
  "error": "invalid_client",
  "error_description": "AADSTS7000222: The provided client secret keys for app '11111111-2222-3333-4444-555555555555' are expired. Visit the Azure portal to create new keys for your app: https://aka.ms/NewClientSecret, or consider using certificate credentials for added security: https://aka.ms/certCreds. Trace ID: 9215ac31-5c4d-468e-9dc8-1fa64ee60c00 Correlation ID: 367afda0-ca2d-48eb-8f49-a13c765618f7 Timestamp: 2026-09-27 06:12:41Z",
  "error_codes": [7000222],
  "timestamp": "2026-09-27 06:12:41Z",
  "trace_id": "9215ac31-5c4d-468e-9dc8-1fa64ee60c00",
  "correlation_id": "367afda0-ca2d-48eb-8f49-a13c765618f7",
  "error_uri": "https://login.microsoftonline.com/error?code=7000222"
}
  • error: die OAuth-Kategorie, bei Credential-Problemen invalid_client. Nur darauf sollte Code reagieren.
  • error_description: AADSTS-Code, meist App-ID, oft Tenant-ID, dazu Trace ID, Correlation ID und Zeitstempel. Der Text kann sich laut Microsoft ändern.
  • error_codes: die Zahl ohne Präfix, so steht sie auch im Anmeldeprotokoll als „Sign-in error code“. correlation_id und trace_id führen zum passenden Protokolleintrag, error_uri zur Fehlersuche unter login.microsoftonline.com/error.

Die Fehlercodes im Einzelnen

AADSTS7000222: Client Secret abgelaufen

Meldung: InvalidClientSecretExpiredKeysProvided - The provided client secret keys are expired. Create new keys for your app, or consider using certificate credentials for added security. Zur Laufzeit mit App-ID: The provided client secret keys for app '…' are expired.

Ursache: Das gesendete Secret gehört zu einem Eintrag, dessen Ablaufdatum überschritten ist.

Fundort: Anwendungslog, Token-Antwort, Anmeldeprotokoll im Reiter „Service principal sign-ins“, Fehlercode 7000222.

Behebung: Neues Secret unter „Zertifikate & Geheimnisse“ anlegen, in die Anwendung übernehmen, neu starten. Details unter „Schnell wiederherstellen“.

AADSTS7000215: Client Secret ungültig

Meldung: Invalid client secret is provided. Zur Laufzeit ergänzt um: Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '…'.

Ursache: Der Wert stimmt nicht: Secret-ID statt Secret-Wert kopiert, Secret einer anderen App, abgeschnittener Wert aus Konfiguration oder Key Vault, oder ein inzwischen gelöschtes Secret.

Fundort: Wie bei 7000222, Fehlercode 7000215.

Behebung: Neues Secret erstellen und den Wert sofort kopieren, das Portal zeigt ihn nur einmal. Prüfen, ob Client-ID und Secret zur selben App gehören.

AADSTS7000218: Kein Credential im Request

Meldung: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.

Ursache: Ein vertraulicher Client sendet gar kein Credential, meist weil die Konfiguration leer ist: Umgebungsvariable nicht gesetzt, falscher Pfad, Key-Vault-Referenz löst nicht auf.

Fundort: Token-Antwort, Anwendungslog, Fehlercode 7000218.

Behebung: Prüfen, ob das Secret beim Start geladen wird. „Öffentliche Clientflows zulassen“ ist nur für echte Public Clients (Device Code, ROPC) die Antwort, nicht für Dienste.

AADSTS700027: Signatur der Client Assertion ungültig

Meldung: Client assertion failed signature validation. Zur Laufzeit etwa Client assertion contains an invalid signature. The key was expired. oder The certificate with identifier used to sign the client assertion is not registered on application. [Reason - The key was not found]. Thumbprint of key used by client: '…'.

Ursache: Die Anwendung signiert mit einem Zertifikat, das an der App-Registrierung fehlt oder dort abgelaufen ist. Seltener: falsch kodierter Thumbprint im JWT-Header.

Fundort: Wie oben, Fehlercode 700027. Die Meldung nennt den verwendeten Thumbprint.

Behebung: Thumbprint mit dem Reiter „Zertifikate“ vergleichen. Fehlt er oder ist das Zertifikat abgelaufen, neues Zertifikat hochladen und die Anwendung umstellen.

AADSTS700024: Client Assertion zeitlich ungültig

Meldung: Client assertion is not within its valid time range.

Ursache: Das signierende Zertifikat ist abgelaufen oder die Systemuhr des Clients weicht deutlich ab.

Fundort: Wie oben, Fehlercode 700024.

Behebung: NotAfter des Zertifikats prüfen, NTP kontrollieren. Bei Zertifikaten aus Key Vault sicherstellen, dass die Anwendung die aktuelle Version lädt.

AADSTS700016: Anwendung im Tenant nicht gefunden

Meldung: UnauthorizedClient_DoesNotMatchRequest - The application wasn't found in the directory/tenant. Zur Laufzeit: Application with identifier '…' was not found in the directory '…'.

Ursache: Die Client-ID passt nicht zum Tenant in der Authority-URL: Tippfehler, mandantenfähige App ohne Zustimmung im Ziel-Tenant, oder eine gelöschte App-Registrierung.

Fundort: Token-Antwort und Anwendungslog. Die Meldung enthält beide IDs.

Behebung: Beide IDs mit der App-Registrierung vergleichen. Gelöschte App-Registrierungen lassen sich im Reiter „Gelöschte Anwendungen“ 30 Tage lang wiederherstellen.

AADSTS650057: Ressource nicht in den Berechtigungen

Meldung: Invalid resource. The client has requested access to a resource which isn't listed in the requested permissions in the client's application registration. Client app ID: {appId}({appName}). Resource value from request: {resource}. Resource app ID: {resourceAppId}. List of valid resources from app registration: {regList}.

Ursache: Der Scope zeigt auf eine API, für die an der App keine Berechtigung konfiguriert ist. Kein Credential-Problem, aber ein typischer Folgefehler, wenn eine App-Registrierung in Eile neu angelegt wurde.

Fundort: Token-Antwort. Die Meldung listet die gültigen Ressourcen auf.

Behebung: Unter „API-Berechtigungen“ die Berechtigung ergänzen und Administratorzustimmung erteilen. Scope prüfen, für Graph https://graph.microsoft.com/.default.

AADSTS500011: Resource Principal nicht im Tenant

Meldung: InvalidResourceServicePrincipalNotFound - The resource principal named {name} wasn't found in the tenant named {tenant}.

Ursache: Die Ziel-API hat in diesem Tenant keinen Service Principal, der Request ging an den falschen Tenant oder die Ressourcen-URL ist falsch. Bei MSPs häufig: die eigene Tenant-ID statt der des Kunden.

Fundort: Token-Antwort, error ist hier invalid_resource.

Behebung: Tenant-ID und Ressourcen-URL aus der Meldung prüfen. Fehlt der Service Principal, die Ressourcen-App bereitstellen oder Zustimmung erteilen.

AADSTS53003: Durch Conditional Access blockiert

Meldung: BlockedByConditionalAccess - Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.

Ursache: Eine Conditional-Access-Richtlinie für Workload Identities blockiert den Service Principal, etwa wegen Standort oder Risiko. Das Credential selbst ist in Ordnung.

Fundort: Anmeldeprotokoll, Reiter „Service principal sign-ins“. Der Reiter „Bedingter Zugriff“ im Eintrag zeigt die Richtlinie.

Behebung: Richtlinie anpassen oder den Service Principal ausnehmen. Das Secret zu rotieren ändert nichts.

Die betroffene App finden

Die error_description liefert fast immer die App-ID, oft auch die Tenant-ID. Danach suchst du unter „App-Registrierungen“ im Reiter „Alle Anwendungen“.

Ohne Anwendungslog hilft das Anmeldeprotokoll im Reiter „Service principal sign-ins“. Filtere auf Status „Fehler“ und den Zeitraum. Jeder Eintrag zeigt Service Principal, Anwendungs-ID, Fehlercode als Zahl und den Fehlergrund. Über die Correlation ID findest du den exakten Request.

Verbleibende Credentials prüfen

Im Portal zeigt „Zertifikate & Geheimnisse“ beide Reiter mit Beschreibung, Ablaufdatum und Secret-ID beziehungsweise Thumbprint. Per PowerShell mit dem Microsoft Graph SDK, Leserechte reichen:

Connect-MgGraph -Scopes "Application.Read.All"

$app = Get-MgApplication -Filter "appId eq '11111111-2222-3333-4444-555555555555'" `
  -Property DisplayName, AppId, PasswordCredentials, KeyCredentials

$app.PasswordCredentials | Select-Object DisplayName, KeyId, EndDateTime
$app.KeyCredentials      | Select-Object DisplayName, KeyId, EndDateTime

PasswordCredentials sind die Client Secrets, KeyCredentials die Zertifikate. Alles mit EndDateTime in der Vergangenheit ist tot. Ein Skript für alle Apps eines Tenants steht im Beitrag Entra App Registration Secrets laufen ab.

Schnell wiederherstellen

  1. Neues Secret anlegen oder neues Zertifikat hochladen, mit Beschreibung wie „Backup-Connector, rotiert 2026-09“.
  2. Den Wert überall eintragen, wo die Anwendung ihn liest: Konfiguration, Umgebungsvariablen, Key Vault, Pipeline-Variablen, Service Connections. Ein vergessener Ort ist der häufigste Grund, warum der Fehler bleibt.
  3. Anwendung neu starten oder deployen und im Anmeldeprotokoll prüfen, dass der Status auf „Erfolg“ wechselt.
  4. Das alte Credential erst löschen, wenn alle Verbraucher umgestellt sind. Eine App-Registrierung darf mehrere gültige Secrets und Zertifikate gleichzeitig haben.

Den nächsten Vorfall vermeiden

  • Inventar: Welche Anwendung nutzt welches Credential, wer ist Besitzer. Beides an der App-Registrierung eintragen.
  • Überlappend rotieren: neues Credential 30 Tage vor Ablauf anlegen, umstellen, altes danach löschen.
  • Laufzeiten vereinheitlichen, etwa zwölf Monate für Secrets, mit Erinnerungen bei 30, 14 und 7 Tagen.
  • Wo möglich Zertifikate, Managed Identities oder Workload Identity Federation nutzen. Dort läuft kein Secret mehr ab.
  • Ablaufdaten überwachen, per Skript, Automation oder Dienst. Microsoft Entra selbst verschickt keine Warnung.

Wie SecretExpiry hilft

SecretExpiry liest mit der Berechtigung Application.Read.All nur Metadaten der App-Registrierungen und überwacht Client Secrets und Zertifikate über viele Tenants hinweg. Ablaufende Credentials melden wir per E-Mail, je Ereignis oder als Wochenzusammenfassung, per Microsoft-Teams- oder Slack-Webhook und als Kalender-Abo (ICS). Je Tenant lässt sich eine eigene Benachrichtigungsadresse hinterlegen, einzelne Meldungen kannst du stummschalten. Das Dashboard zeigt die dringenden Fälle in einer Liste. Der Dienst kostet ab 10 € pro Tenant und Monat, 14 Tage lang kostenlos zum Testen. Details in der Dokumentation.