Seit Anfang Oktober rollt Microsoft Phase 2 der Azure-MFA-Pflicht aktiv auf die Tenants aus, und in der Praxis merkt man das sofort. In mehreren Mandanten, die ich betreue, brechen plötzlich Deployments ab, die jahrelang ohne Murren liefen. Wer Ressourcen per Azure CLI, PowerShell oder ARM-basierten Tools anlegt, ändert oder löscht, bekommt auf einmal eine Fehlermeldung, weil eine MFA-Eingabe verlangt wird. Azure zieht damit die Zügel an, nachdem Phase 1 bereits den Portalzugriff für Admins abgesichert hat (siehe Phase 1 der Azure-MFA-Pflicht im Admin-Portal gestartet). Lesende Zugriffe (Read-Only) klappen weiterhin ohne MFA. Für alles, was Ressourcen verändert, gilt die Pflicht dagegen ab sofort.

Phase 2 erfasst alle schreibenden Zugriffe über den Azure Resource Manager

Betroffen sind sämtliche Schreib- und Änderungsaktionen, die über den Azure Resource Manager laufen. Das gilt für Azure CLI, Azure PowerShell (ab den aktuell unterstützten Versionen), die Azure Mobile App und direkte REST-API-Aufrufe. Auch gängige Infrastructure-as-Code-Werkzeuge wie Bicep, Terraform oder ARM-Templates fallen darunter, sobald sie die ARM-API mit Benutzerkonten ansprechen. Skripte und Pipelines, die unter einer Benutzeridentität laufen, scheitern jetzt am interaktiven MFA-Schritt, den ein automatisierter Ablauf schlicht nicht leisten kann. Bei komplexeren Umgebungen oder Sonderfällen lässt sich im Azure-Portal ein Aufschub beantragen. Mittelfristig trifft die MFA-Pflicht trotzdem jeden Tenant.

Benutzerkonten in Automationen werden jetzt zum Problem

In meinen Projekten sehe ich immer wieder Automationen, Legacy-Deployments und sogar Wartungsskripte, die noch mit persönlichen Konten oder generischen Servicekonten arbeiten. Meist liegt es daran, dass es schon immer so lief oder die Migration zu aufwendig erschien. Mit Phase 2 der Azure-MFA-Pflicht werden diese Altlasten zu einem echten Risiko. Die Skripte hören von heute auf morgen auf zu funktionieren, und häufig fällt das erst auf, wenn im Ernstfall Ressourcen nicht bereitgestellt oder aktualisiert werden. Auch CI/CD-Pipelines, die Azure CLI oder PowerShell mit Benutzeranmeldedaten aufrufen, brechen ab.

Praxis-Tipp: Prüft jetzt gezielt, welche eurer Azure-Automationen mit Benutzerkonten arbeiten. Unter Entra ID → Überwachungsprotokolle → Anmeldeprotokolle könnt ihr filtern, welche Konten sich mit User-Tokens per CLI oder PowerShell anmelden. Für die Suche nach automatisierten Anmeldungen kommt es vor allem auf die Felder „Anwendung“ (z. B. Azure PowerShell) und „Client App“ (z. B. Public client, User interactive) an.

Managed Identities und Workload Identity Federation lösen das Problem

Wer Ausfälle und lästige MFA-Abfragen vermeiden will, muss Automationen und Pipelines auf Serviceprinzipale, Managed Identities oder im Cloud-nativen Umfeld auf Workload Identity Federation umstellen. Mit Managed Identities authentifizieren sich Ressourcen in Azure ganz ohne Schlüssel und ohne zusätzlichen Aufwand. Mehr dazu steht im Beitrag Workload-Identitäten in Entra ID mit Managed Identities, App-Registrierungen und sicheren Alternativen. In hybriden Umgebungen oder bei GitHub Actions und Azure DevOps bietet sich Workload Identity Federation an, die einen sicheren, passwortlosen Zugriff per OIDC ermöglicht (Microsoft-Dokumentation).

So sieht die Umstellung eines Pipeline-Skripts von der Benutzeranmeldung auf eine Managed Identity aus (ausgeführt in Azure PowerShell 9+ auf einer VM mit zugewiesener Identität):

# Alte Variante: Mit Benutzerkonto (ab sofort MFA-pflichtig)
Connect-AzAccount -UserName "[email protected]"

# Neue Variante: Mit system-assigned Managed Identity
Connect-AzAccount -Identity

Auch wer Terraform oder Bicep einsetzt, kommt um den Wechsel auf Serviceprinzipale oder Managed Identities nicht herum. Dabei sollte man gleich prüfen, ob die verwendeten Tools die aktuellen Authentifizierungsmethoden unterstützen.

Das Anmeldeprotokoll verrät die betroffenen Automationen

In gewachsenen Umgebungen ist es alles andere als trivial, sämtliche betroffenen Automationen aufzuspüren. Am ergiebigsten ist das Entra-ID-Anmeldeprotokoll, weil es jede Authentifizierung gegenüber Azure festhält. Mit diesen Filtern im Portal lassen sich benutzerbasierte Anmeldungen über CLI und PowerShell finden:

  1. Anmeldeprotokolle öffnen (Entra ID → Überwachung → Anmeldeprotokolle)
  2. „Anwendung“ nach „Azure PowerShell“ oder „Azure CLI“ filtern
  3. „Client App“ auf „Public client“ oder „User interactive“ setzen
  4. Zeitraum auf die letzten 30 Tage festlegen

Skripte, die hier mit User-Tokens auftauchen, gehören ganz oben auf die Liste für die Umstellung auf Serviceprinzipale oder Managed Identities. Ein Blick in die Deployment-Pipelines, etwa in Azure DevOps oder GitHub Actions, lohnt sich ebenfalls. Dort sind die Authentifizierungsmechanismen schnell geprüft und umgestellt.

Der Umstieg tut kurz weh und macht Azure-Umgebungen deutlich sicherer

Ich persönlich finde es richtig, dass Microsoft Phase 2 so konsequent durchsetzt, auch wenn es kurzfristig schmerzt. Viel zu viele Umgebungen haben jahrelang aus Bequemlichkeit Benutzerkonten für Automationen verwendet. Wer jetzt gezwungenermaßen auf Managed Identities oder Workload Identity Federation umsteigt, hebt das Sicherheitsniveau im gesamten Azure-Umfeld spürbar an. Der Migrationsdruck ist sicher nicht zu unterschätzen. Kompromittierte Konten oder fehlende MFA sind aber das größere Risiko. Die dringendsten Baustellen zeigt das Entra-Log ohnehin schnell, und nach der Migration laufen die Deployments wieder reibungslos und sind endlich MFA-sicher.

Das folgende Flussdiagramm zeigt, wie Benutzerkonten, Managed Identities und Workload Identity Federation zusammenhängen und welche Migrationspfade nötig sind:

flowchart TD
    UserScript["Automation mit Userkonto"] --> MFAFail["MFA-Pflicht: schlägt fehl"]
    UserScript -->|"Migration nötig"| Mitigation["Serviceprinzipal/Managed Identity"]
    Mitigation --> ARM["Authentifizierung ohne MFA"]
    WorkloadFed["Workload Identity Federation (OIDC)"] --> ARM

Abbildung: Migration von benutzerbasierten zu Managed bzw. Workload-Identitäten für ARM-Operationen.

Warum Workload Identity Federation gerade jetzt unverzichtbar wird und wie sie im Detail funktioniert, habe ich im Beitrag Client Secrets ablösen und auf sichere Alternativen in Entra ID setzen beschrieben. Zu den Hintergründen der MFA-Pflicht findet ihr mehr im Artikel über die erste Phase. Und wie gewohnt halte ich euch hier im Blog auf dem Laufenden, was die nächsten Schritte für Azure-Admins bedeuten.