Azure

Service Principal (Dienstprinzipal)

Overview

Ein Service Principal (deutsch Dienstprinzipal) repräsentiert eine Anwendung in einem bestimmten Microsoft-Entra-Tenant. Über ihn bekommt die Anwendung Rollen in Azure RBAC, Berechtigungen für Microsoft Graph oder andere APIs und unterliegt Richtlinien wie Conditional Access. Im Entra Admin Center findest Du Service Principals unter Unternehmensanwendungen (Enterprise Applications).

Wichtig ist die Trennung zur App-Registrierung: Das Anwendungsobjekt ist die globale Definition einer App und existiert nur im Heimtenant. Der Service Principal ist ihre lokale Instanz in jedem Tenant, in dem die App genutzt wird. Eine mandantenfähige App hat also ein Anwendungsobjekt, aber in jedem zustimmenden Kundentenant einen eigenen Service Principal. Die Client-ID (auch App-ID oder Application ID) ist die global eindeutige Kennung der App und verbindet beide, jedes Objekt hat zusätzlich eine eigene Objekt-ID.

Es gibt drei Typen: Anwendung (lokale Instanz einer App-Registrierung, entsteht bei der Registrierung oder bei Zustimmung), Managed Identity (von Azure verwaltet, ohne App-Objekt) und Legacy (vor App-Registrierungen entstanden, nur im eigenen Tenant nutzbar). Service Principals zählen zu den Workload Identities, für sie gelten die MFA-Pflichten für Benutzer nicht, dafür braucht es eigene Schutzmaßnahmen.

How it works

So entsteht und arbeitet ein Service Principal:

  1. Bei der App-Registrierung legt Entra ID das Anwendungsobjekt an und im Heimtenant automatisch den Service Principal.
  2. Weitere Service Principals entstehen, wenn ein Admin oder Benutzer in einem anderen Tenant der App zustimmt, oder per Azure CLI, PowerShell bzw. Microsoft Graph.
  3. Die Anwendung authentifiziert sich mit einem Client Secret, einem Zertifikat oder föderierten Anmeldeinformationen (Workload Identity Federation, z. B. aus GitHub Actions, Azure DevOps oder Kubernetes).
  4. Entra ID stellt einen Zugriffstoken aus, der die Rollen und App-Berechtigungen des Service Principals enthält.
  5. Rechte vergibst Du über Azure-RBAC-Rollenzuweisungen, Entra-Rollen oder App-Berechtigungen mit Admin-Zustimmung.

Änderungen am Anwendungsobjekt wirken nur auf den Service Principal im Heimtenant. Löschst Du das Anwendungsobjekt, verschwindet auch dieser Service Principal, eine Wiederherstellung der App stellt ihn nicht wieder her. Zum vorübergehenden Sperren lässt sich die App deaktivieren. Anmeldungen erscheinen in den Entra-Anmeldeprotokollen unter Dienstprinzipal-Anmeldungen.

Benefits

  • Anwendungszugriff ohne Benutzerkonto: Skripte und Dienste laufen nicht mehr unter persönlichen Admin-Konten, die beim Austritt oder bei MFA-Pflicht brechen.
  • Feingranulare Rechte: Jede Anwendung erhält nur die Rollen und Graph-Berechtigungen, die sie braucht.
  • Auditierbar: Anmelde- und Auditprotokolle zeigen, welche App wann worauf zugegriffen hat.
  • Mandantenfähig: Eine App kann in vielen Tenants mit jeweils eigener, vom Kunden-Admin kontrollierter Zustimmung laufen.
  • Ohne Secrets möglich: Zertifikate und Workload Identity Federation ersetzen langlebige Client Secrets.

Practical example

Ein IT-Dienstleister mit 15 Mitarbeitenden betreut die Microsoft-365-Tenants von 40 Kunden und liest wöchentlich Lizenz- und Anmeldeberichte per Microsoft Graph aus. Früher lief das Skript mit einem Admin-Konto pro Kunde. Heute registriert das Team eine eigene App mit Zertifikat, nur mit lesenden Graph-App-Berechtigungen, und lässt sie in jedem Kundentenant per Admin-Zustimmung anlegen. Die Deployments in Azure laufen über eine Azure-DevOps-Service-Connection mit Workload Identity Federation, ein Client Secret existiert nirgends mehr.

Things to keep in mind

  • Bevorzuge für Code in Azure Managed Identities, für Pipelines Workload Identity Federation und sonst Zertifikate statt Client Secrets.
  • Überwache Ablaufdaten von Secrets und Zertifikaten, abgelaufene Anmeldedaten sind eine häufige Ursache für nächtliche Ausfälle.
  • Vergib Berechtigungen minimal und prüfe App-Berechtigungen mit hohem Risiko (z. B. Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory) regelmäßig.
  • Lege pro Anwendung Besitzer fest und entferne ungenutzte Service Principals, verwaiste Apps mit Rechten sind ein bekannter Angriffsweg.
  • Schränke ein, wer Apps registrieren und wer Zustimmungen erteilen darf (Benutzerzustimmung einschränken, Admin-Zustimmungsworkflow).

Licensing & availability

Service Principals, App-Registrierungen und die Grundfunktionen sind in jedem Microsoft-Entra-Tenant ohne Zusatzkosten enthalten. Conditional Access für Workload Identities, risikobasierte Erkennung für Workload Identities und App-Governance-Funktionen erfordern die Zusatzlizenz Microsoft Entra Workload ID Premium. Stand: Oktober 2026.

Conclusion

Service Principals sind das richtige Werkzeug für Anwendungs- und Automatisierungszugriffe. Halte Rechte klein und ersetze Secrets durch Zertifikate, Federation oder Managed Identities.

Further reading

Related articles