Bedingter Zugriff und Automatisierung: warum Flows nach der MFA-Pflicht stehen bleiben

Wenn eine Conditional-Access-Richtlinie greift, blockiert sie nicht nur Anmeldungen von Nutzern, sie kann auch Automatisierungen treffen, die im Namen eines Dienstkontos oder über eine Service Principal laufen. Entscheidend ist, ob die Anmeldung interaktiv oder nicht-interaktiv erfolgt: Richtlinien, die gezielt auf Benutzer und Gruppen wirken, greifen laut Microsoft Learn nicht automatisch bei reinen Service-Principal-Aufrufen, während eigene Richtlinien für Workload-Identitäten genau solche Aufrufe erfassen können. Wer also einen n8n-Workflow, einen Power-Automate-Flow oder einen Connector plötzlich mit Anmeldefehlern sieht, sollte zuerst prüfen, welche Identität dahintersteckt und welche Richtlinie sie erfasst. Stand: August 2026.

Was unterscheidet eine Richtlinie für Nutzer von einer für Workload-Identitäten?

Eine klassische Conditional-Access-Richtlinie zielt auf Benutzer und Gruppen und wird bei jeder interaktiven Anmeldung ausgewertet. Für nicht-interaktive Konten wie den Microsoft-Entra-Connect-Sync-Account oder Service Principals gilt das nicht automatisch: Laut Microsoft Learn sind solche Konten typischerweise für den programmatischen Zugriff von Backend-Diensten gedacht und werden von nutzerbezogenen Richtlinien nicht erfasst. Wer automatisierte Zugriffe absichern will, braucht eine separate Richtlinie für Workload-Identitäten, die einzelne, im eigenen Tenant registrierte Service Principals gezielt einschließt oder ausschließt. Multitenant-Apps und von Microsoft verwaltete Identitäten fallen dabei ausdrücklich nicht unter diese Richtlinien.

Welche Rolle spielen die Microsoft-verwalteten Basisrichtlinien?

Microsoft rollt eigene, vorkonfigurierte Richtlinien aus, etwa eine MFA-Pflicht für Admin-Konten, die in der Richtlinienliste des Entra Admin Centers mit "Microsoft" als Ersteller erscheinen. Diese Basisrichtlinien lassen sich anpassen oder mit eigenen Ausschlüssen versehen, aber nicht beliebig umbauen, ohne sie zu duplizieren. Laut Microsoft Learn wird die Durchsetzung dieser Basis-Ausnahmen seit dem 15. Juni 2026 schrittweise automatisch aktiviert, wenn an den Einstellungen nichts geändert wurde. Für Unternehmen mit bestehenden Automatisierungen heißt das: Ein Flow, der bisher unter dem Radar lief, kann durch eine solche automatische Umstellung erstmals betroffen sein, ohne dass jemand aktiv eine neue Richtlinie angelegt hat.

Wie schließt man Dienstkonten sauber aus, ohne ein Sicherheitsloch zu reißen?

Ein pauschaler Ausschluss aller Automatisierungskonten aus jeder Richtlinie ist keine saubere Lösung, weil er die eigentliche Schutzwirkung von Conditional Access aushebelt. Sinnvoller ist es, gezielt die einzelne Workload-Identität des betroffenen Connectors oder Service Principals einzuschließen oder auszuschließen, statt ganze Gruppen pauschal freizustellen. Break-Glass- beziehungsweise Notfallkonten sollten dabei laut Microsoft grundsätzlich aus jeder Richtlinie ausgeschlossen bleiben, damit im Ernstfall ein administrativer Zugriff möglich bleibt, unabhängig davon, was gerade blockiert. Bei Include- und Exclude-Regeln für dieselbe Identität gilt zudem: Der Ausschluss gewinnt immer gegenüber dem Einschluss.

Was tun, wenn ein Automatisierungs-Connector nach einem Update plötzlich blockiert wird?

Der erste Schritt ist die Anmeldeprotokollierung in Entra ID, um zu sehen, welche konkrete Richtlinie den Zugriff verweigert hat und mit welcher Identität sich der Connector angemeldet hat. Häufig zeigt sich dabei, dass eine neu durchgesetzte Basisrichtlinie oder eine kürzlich geänderte Ausschlussliste die Ursache ist, nicht ein Fehler im Workflow selbst. Für produktive Automatisierungen lohnt es sich, Dienstkonten und Service Principals von Anfang an dokumentiert und mit einer eigenen, engen Richtlinie zu versehen, statt sie implizit von allgemeinen Regeln mit erfassen zu lassen. Wer n8n oder Power-Automate-Flows an Microsoft-365-Dienste anbindet, sollte diese Prüfung fest in die Inbetriebnahme neuer Automatisierungen aufnehmen, das gehört bei uns standardmäßig zu jeder Automatisierungs-Einrichtung dazu.

Häufige Fragen zu Conditional Access und Automatisierung

Blockiert Conditional Access automatisch alle Service-Principal-Aufrufe?

Nein, nutzerbezogene Richtlinien greifen bei reinen Service-Principal-Aufrufen laut Microsoft grundsätzlich nicht. Erst eine eigens für Workload-Identitäten angelegte Richtlinie kann solche nicht-interaktiven Zugriffe erfassen. Ob ein Connector betroffen ist, hängt also davon ab, ob im Tenant überhaupt eine Workload-Identity-Richtlinie existiert.

Was ist eine Workload-Identity in diesem Zusammenhang?

Eine Workload-Identity ist die Identität einer Anwendung oder eines Dienstes, meist in Form eines im eigenen Tenant registrierten Service Principal. Sie unterscheidet sich von einer Benutzeridentität dadurch, dass keine Person interaktiv angemeldet ist, sondern ein Dienst im Hintergrund Zugriffstoken anfordert. Conditional-Access-Richtlinien für Workload-Identitäten lassen sich gezielt auf einzelne dieser Identitäten anwenden.

Muss ich Notfallkonten von jeder Richtlinie ausschließen?

Ja, Break-Glass-Konten sollten laut Microsoft konsequent aus allen Conditional-Access-Richtlinien ausgeschlossen werden. Das gilt auch für neue oder von Microsoft verwaltete Basisrichtlinien. Ohne diesen Ausschluss riskiert man, sich im Ernstfall selbst aus der Verwaltung auszusperren.

Wann beginnt die automatische Durchsetzung der Basisrichtlinien 2026?

Laut Microsoft Learn wird die Durchsetzung für die betroffenen Basis-Ausnahmen seit dem 15. Juni 2026 schrittweise über mehrere Wochen automatisch aktiviert. Unternehmen, die an den Standardeinstellungen nichts geändert haben, sollten in diesem Zeitraum ihre Automatisierungen und Connectoren gezielt beobachten. Wer bereits vorher eigene Anpassungen vorgenommen hat, ist von der automatischen Umstellung nicht betroffen.