Skip to content
ViganoLabs Dokumentation

Azure 401/403: Häufige Ursachen

401 vs. 403 – was der Unterschied meist bedeutet

Section titled “401 vs. 403 – was der Unterschied meist bedeutet”
  • 401 Unauthorized: Authentifizierung fehlt/ist ungültig (Token/Client/Session). Oft “nicht angemeldet” oder Token passt nicht zum Tenant.
  • 403 Forbidden: Authentifiziert, aber nicht autorisiert (RBAC/Policy/Deny Assignment/Conditional Access).

In Azure tauchen beide Codes in Portal, CLI oder SDKs auf – die Ursache ist oft identisch, nur der Client “formuliert” anders.

Schnellcheck (5 Minuten)

Section titled “Schnellcheck (5 Minuten)”

  1. Tenant/Subscription-Kontext

    • Portal: bist du im richtigen Directory?
    • CLI: az account show (Subscription, Tenant) prüfen.

    Praktischer Zusatz: Wenn du mehrere Subscriptions hast, setze den Kontext explizit: az account set --subscription <id>.

  2. Scope

    • Betrifft es eine Ressource, RG oder Subscription?
    • Rollen müssen auf einem Scope liegen, der die Ressource umfasst.

  3. Rollenaktivierung (PIM)

    • Ist die Rolle nur “eligible” und nicht aktiv?
    • Nach Aktivierung ggf. Token neu holen (Ab-/Anmelden).

  4. Propagation/Cache

    • Neue Role Assignments wirken nicht sofort.
    • CLI/SDK caches können veraltet sein; erneute Anmeldung hilft oft.

    Typisch: Direkt nach einer Rollenänderung kann es Minuten dauern, bis der Zugriff überall konsistent ist. Plane das ein, bevor du “wild” weitere Rechte verteilst.

  5. Deny Assignments / Policy Effekte

    • Manche Managed Apps/Blueprints erzeugen Deny Assignments.
    • Policies können Deployments blocken (Deny) oder Parameter erzwingen.

Häufige Ursachen (mit typischen Symptomen)

Section titled “Häufige Ursachen (mit typischen Symptomen)”

Falscher Kontext (Tenant/Subscription)

Section titled “Falscher Kontext (Tenant/Subscription)”

Symptom: Du siehst Ressourcen nicht oder bekommst 403 in der “richtigen” Subscription.

Fix:

  • Kontext aktiv setzen (CLI) und sicherstellen, dass du im richtigen Tenant bist.
  • Bei mehreren Accounts/Guests: bewusst zwischen Directories wechseln.

Rolle fehlt oder ist am falschen Scope

Section titled “Rolle fehlt oder ist am falschen Scope”

Symptom: Zugriff auf eine RG funktioniert, aber nicht auf eine andere.

Fix:

  • Scope der Zuweisung prüfen.
  • Role Assignment über Gruppen modellieren (weniger Fehler).

Wenn du es hart verifizieren willst (CLI):

  • az role assignment list --assignee <objectId> --all

Damit siehst du auch, ob die Rolle zwar existiert, aber auf einem Scope liegt, der die Ressource nicht umfasst.

Data Plane vs. Management Plane verwechselt

Section titled “Data Plane vs. Management Plane verwechselt”

Symptom: Du darfst eine Ressource sehen/ändern, aber Datenzugriff (z. B. Storage) scheitert.

Fix:

  • Data-Plane-Rollen prüfen (z. B. “Storage Blob Data Reader”).

Hinweis: Besonders häufig bei Storage/Key Vault. “Contributor” ist hier oft nicht das, was du glaubst.

Conditional Access / Gerätestatus

Section titled “Conditional Access / Gerätestatus”

Symptom: Portal geht, aber bestimmte Aktionen/Apps nicht; oder Zugriff nur von bestimmten Geräten.

Fix:

  • Sign-in Logs prüfen: welche Policy greift?
  • Gerätestatus (compliant) und Authentifizierungsstärke prüfen.

Wenn Portal und CLI unterschiedlich reagieren, ist CA ein sehr häufiger Grund: unterschiedliche Clients, unterschiedliche CA-Auswertung.

Wenn du den Root Cause dokumentieren willst

Section titled “Wenn du den Root Cause dokumentieren willst”

Für Incidents/Audits hilft ein kurzer Befund:

  • Welche Identität, welcher Scope, welche fehlende Rolle (oder welche CA-Policy)?
  • Welche Änderung hat es behoben?
  • Was ist die preventive Maßnahme (z. B. Gruppenmodell, PIM, Policy Guardrail)?

Wenn du systematisch tiefer gehen willst

Section titled “Wenn du systematisch tiefer gehen willst”