Service-Account vs. Service Principal in Power Automate

Wenn ein Flow produktiv läuft, entscheidet die Wahl der zugrunde liegenden Identität darüber, ob er auch dann weiterläuft, wenn eine Kollegin krank ist, ein Passwort abläuft oder jemand das Unternehmen verlässt. Genau hier stellt sich in Power Automate immer wieder dieselbe Frage: Soll ein Flow unter einem klassischen Service-Account laufen, also einem geteilten Benutzerkonto, oder unter einem Service Principal, also einer eigenständigen, nicht-menschlichen Identität in Microsoft Entra ID?

Die kurze Antwort aus der offiziellen Dokumentation ist eindeutig: Microsoft empfiehlt für geschäftskritische, produktive Flows den Service Principal und stuft den klassischen Service-Account ausdrücklich nicht als Best Practice ein. Trotzdem lohnt sich ein genauer Blick auf beide Modelle, weil sie technisch unterschiedlich funktionieren und unterschiedliche Voraussetzungen mitbringen.

Was ist ein Service-Account in Power Automate?

Ein Service-Account ist laut der Microsoft-Dokumentation zur Power-Automate-Lizenzierung ein ganz normales Microsoft-Entra-Benutzerkonto, das zweckentfremdet wird, um eine nicht-menschliche Entität wie eine Anwendung oder einen Dienst darzustellen. In der Praxis heißt das: Ein Team legt ein Konto wie flow-produktion@firma.de an, gibt das Passwort an mehrere Kolleginnen und Kollegen weiter, und dieses Konto besitzt dann die produktiven Flows.

Das Problem dabei benennt Microsoft direkt: Haben mehrere Personen Zugriff auf dasselbe Konto, lässt sich kaum noch nachvollziehen, wer welche Änderung an einem Flow vorgenommen hat. Dazu kommt die Passwortverwaltung als Dauerthema, etwa bei erzwungenen Kennwortwechseln oder Multi-Faktor-Anmeldungen. Microsoft rät deshalb ausdrücklich, bestehende Service-Accounts regelmäßig auf ihre Berechtigungen zu prüfen, den Kreis der Zugriffsberechtigten möglichst klein zu halten und für unterschiedliche Szenarien getrennte Konten zu verwenden, um die Angriffsfläche zu reduzieren. In manchen Fällen wird ein Service-Account genutzt, um einen Flow unabhängig vom ursprünglichen Ersteller zu machen. Genau für diesen Zweck empfiehlt Microsoft aber ausdrücklich den Wechsel zum Service Principal.

Was ist ein Service Principal?

Ein Service Principal ist laut der Microsoft-Dokumentation zur Unterstützung von Flows im Besitz eines Dienstprinzipals eine nicht-menschliche Sicherheitsidentität, die eine Anwendung oder einen Dienst repräsentiert und eigenständig Ressourcen in Azure und der Power Platform besitzen und verwalten kann. Technisch steckt dahinter eine Microsoft-Entra-App-Registrierung. Damit ein Service Principal in der Power Platform überhaupt Flows besitzen kann, muss zunächst ein sogenannter Anwendungsbenutzer angelegt werden, entweder über das Power-Platform-Admin-Center oder über die API.

Ist dieser Anwendungsbenutzer eingerichtet, lässt sich ihm der Besitz eines Cloud-Flows übertragen: Im Flow öffnest Du den Bereich Details, wählst Bearbeiten und ersetzt den Besitzenden durch den Namen des Anwendungsbenutzers. Wichtig dabei: Ein Service Principal kann laut Dokumentation nicht Mitbesitzer eines Flows werden, sondern ausschließlich alleiniger Besitzer. Bei einem Flow außerhalb einer Lösung müssen zusätzlich alle verwendeten Verbindungen explizit für den Anwendungsbenutzer freigegeben werden, bei einem Lösungsflow entfällt dieser Schritt.

Service-Account oder Service Principal: die Entscheidungshilfe

Für die tägliche Praxis lässt sich die Entscheidung an klaren Kriterien festmachen, wie sie auch die Microsoft-Dokumentation zum Zugriff auf Power-Automate-Flows beschreibt:

• Geschäftskritische oder unternehmensweite Flows: Hier empfiehlt Microsoft ausdrücklich den Service Principal, weil der Flow-Besitz dadurch vollständig vom Lebenszyklus einer einzelnen Person entkoppelt wird. Verlässt jemand das Unternehmen oder ändert sich seine Rolle, bleibt der Flow unberührt.
• DevOps-Pipelines über mehrere Umgebungen: Wer Flows automatisiert von Dev über Test nach Produktion ausrollt, sollte laut Dokumentation ebenfalls auf den Service Principal setzen, weil er sich sauber über die API verwalten lässt.
• Auditierbarkeit: Ein Service Principal hinterlässt einen klaren, personenunabhängigen Prüfpfad. Bei einem geteilten Service-Account bleibt oft unklar, wer wann was geändert hat.
• Interaktive oder benutzerspezifische Flows: Braucht ein Flow den persönlichen Kontext eines Menschen, etwa für Freigaben oder personalisierte Berechtigungen, ist ein reguläres Benutzerkonto weiterhin die richtige Wahl, kein Service-Account und kein Service Principal.
• Bestehende Service-Accounts: Willst Du einen laufenden Flow von einem Service-Account auf einen Service Principal umstellen, solltest Du zusätzlich Lizenz- und Anfragelimits prüfen, dazu gleich mehr.

Lizenzierung und Anfragelimits nicht unterschätzen

Ein Service Principal, der einen Flow besitzt, gilt in Power Automate als nicht-interaktiver Anwendungsbenutzer und kann deshalb keine reguläre Benutzerlizenz erhalten. Stattdessen gelten eigene, nicht-lizenzierte Anfragelimits, und sobald der Flow Premium-Konnektoren nutzt, braucht er eine Power-Automate-Process-Lizenz oder eine Lizenz pro Flow, alternativ die Mitgliedschaft in einer entsprechend lizenzierten Flow-Gruppe.

Beim klassischen Service-Account greift dagegen die reguläre Lizenzlogik für Benutzerkonten, ergänzt um eine Sonderregel gegen sogenanntes Multiplexing: Teilen sich mehrere Personen die Zugangsdaten eines Service-Accounts und nutzt der Flow Premium-Funktionen, empfiehlt die Dokumentation eine Prozesslizenz für den Flow, sobald viele unterschiedliche Personen den Account verwenden, damit neu hinzukommende Nutzer automatisch lizenzkonform bleiben. Nicht zu verwechseln ist der Service-Account dabei mit den nicht-interaktiven Benutzerkonten, die Dataverse für Hintergrundprozesse wie Datenmigrationen vorsieht: Davon sind pro Mandant maximal sieben erlaubt, und Power Automate selbst unterstützt diesen speziellen Kontotyp laut Dokumentation bisher nicht als Flow-Besitzer.

Und was ist mit Managed Identity?

Wer aus der Azure-Welt kommt, denkt bei nicht-menschlichen Identitäten schnell an Managed Identities, also system- oder benutzerseitig zugewiesene Identitäten, die Anmeldedaten komplett überflüssig machen. Für Power-Automate-Cloud-Flows ist dieses Konzept bislang aber keine direkte Option: Managed Identities sind vor allem in Azure Logic Apps verankert, wo bestimmte integrierte und verwaltete Konnektoren wie Azure Key Vault, Azure Blob Storage oder Azure SQL darüber authentifiziert werden können. In Power Automate selbst übernimmt der Service Principal die vergleichbare Aufgabe, einem Flow eine stabile, von einzelnen Personen unabhängige Identität zu geben. Wer Flows und Logic Apps parallel betreibt, sollte diesen Unterschied im Kopf behalten, statt beide Konzepte gedanklich gleichzusetzen.

Umstellung in der Praxis: vom Service-Account zum Service Principal

Der Wechsel läuft in drei Schritten ab: Zuerst legst Du in Microsoft Entra ID eine App-Registrierung an und erstellst daraus in der Power Platform einen Anwendungsbenutzer. Anschließend teilst Du alle Verbindungen, die der Flow verwendet, explizit mit diesem Anwendungsbenutzer, sofern es sich nicht um einen Lösungsflow handelt. Zum Schluss änderst Du im Flow den Besitzenden auf den neuen Anwendungsbenutzer und schaltest den Flow wieder ein. Plane für diesen letzten Schritt einen kurzen Testlauf ein, bevor der bisherige Service-Account deaktiviert wird, damit produktive Prozesse nicht ins Leere laufen.

Wer den Umstieg mehrerer produktiver Flows von Service-Accounts auf Service Principals nicht allein durchziehen möchte, findet dabei Unterstützung im Power-Automate-Angebot von NordFlux, von der Einrichtung der App-Registrierung bis zur Absicherung der Lizenz- und Berechtigungsstruktur. So behältst Du auch bei wachsender Flow-Landschaft die Kontrolle darüber, wer welche Automatisierung besitzt und betreibt.

Häufige Fragen

Ist ein Service-Account für produktive Flows verboten?

Verboten nicht, aber Microsoft stuft ihn ausdrücklich nicht als Best Practice ein. Für unternehmenskritische oder langlaufende Flows empfiehlt die Dokumentation stattdessen klar den Service Principal, weil dieser nicht von einzelnen Personen oder geteilten Passwörtern abhängt.

Kann ein Service Principal Mitbesitzer eines Flows sein?

Nein. Laut Dokumentation kann ein Service-Principal-Anwendungsbenutzer ausschließlich alleiniger Besitzer eines Flows sein, nicht Mitbesitzer. Im Bearbeitungsdialog für Mitbesitzende taucht er deshalb gar nicht erst auf.

Braucht ein Service Principal eine eigene Power-Automate-Lizenz?

Ein Service Principal ist ein nicht-interaktiver Anwendungsbenutzer und kann deshalb keine reguläre Benutzerlizenz erhalten. Sobald der Flow Premium-Konnektoren nutzt, braucht er stattdessen eine Power-Automate-Process-Lizenz oder eine Lizenz pro Flow beziehungsweise die Mitgliedschaft in einer passend lizenzierten Flow-Gruppe.

Lässt sich Managed Identity auch in Power Automate nutzen?

Nicht direkt für den Besitz eines Cloud-Flows. Managed Identities sind in erster Linie ein Konzept von Azure Logic Apps für die Authentifizierung gegenüber bestimmten Azure-Ressourcen. In Power Automate übernimmt der Service Principal die vergleichbare Rolle einer stabilen, nicht-menschlichen Flow-Identität.

Was passiert mit bestehenden Verbindungen, wenn ich den Besitzer wechsle?

Verbindungen gehören nicht automatisch zum neuen Besitzenden. Handelt es sich um einen Flow außerhalb einer Lösung, musst Du alle verwendeten Verbindungen zusätzlich explizit für den neuen Service-Principal-Anwendungsbenutzer freigeben, sonst schlägt die Ausführung fehl. Bei einem Lösungsflow ist dieser Schritt laut Dokumentation nicht erforderlich.