Enterprise Applications und App Registrations in Microsoft Entra ID unterscheiden

Was ist der Unterschied zwischen App Registrations und Enterprise Applications in Microsoft Entra ID? Eine App Registration verwaltet das Application Object – also die Definition einer Anwendung in ihrem Home-Tenant. Unter Enterprise Applications wird der Service Principal verwaltet, die lokale Instanz dieser Anwendung in einem konkreten Tenant. Eine Anwendung kann ein Application Object besitzen, aber Service Principals in mehreren Tenants haben.

Diese Trennung ist entscheidend: API-Berechtigungen, Redirect URIs oder App-Credentials werden typischerweise an der Registrierung betrachtet; Benutzerzuweisungen, Single Sign-on, Conditional Access und tenantbezogene Nutzung am Service Principal. Wer beide Objekte verwechselt, löscht möglicherweise die falsche Instanz oder sucht eine Einstellung im falschen Portalbereich.

Die vier wichtigsten Begriffe

Application Object

Das Application Object beschreibt eine Anwendung in ihrem Home-Tenant. Es enthält unter anderem Identitätseigenschaften, unterstützte Kontotypen, Redirect URIs, angeforderte API-Berechtigungen und eigene Credentials.

App Registration

App registrations ist die Verwaltungsansicht für Application Objects. Dort registrieren Entwickler oder Administratoren eine eigene Anwendung und konfigurieren deren Identitätsintegration.

Service Principal

Der Service Principal ist die lokale Repräsentation einer Anwendung in einem Tenant. Er beschreibt, wie die App in diesem Tenant verwendet wird, welche Zuweisungen existieren und welche tenantbezogenen Berechtigungszustimmungen erteilt wurden.

Enterprise Application

In Microsoft Entra werden Application Objects, Service Principals und Managed Identities heute unter dem Oberbegriff Workload Identities zusammengefasst. Nicht jede Workload Identity erscheint deshalb als klassische App Registration; Managed Identities werden typischerweise als Azure-Ressource und als Service Principal sichtbar.

Enterprise applications ist die Verwaltungsansicht für Service Principals. Sie enthält selbst registrierte Apps ebenso wie SaaS-Anwendungen, Microsoft-Anwendungen, verwaltete Identitäten und weitere Service-Principal-Typen.

Objektbeziehung anhand eines Beispiels

Ein Softwareanbieter registriert eine Multi-Tenant-Anwendung in seinem Tenant. Dort liegt das Application Object. Ein Kunde erteilt Consent und verwendet die Anwendung. Dadurch entsteht im Kundentenant ein Service Principal.

• Hersteller-Tenant: Application Object und eigener Service Principal
• Kunden-Tenant A: Service Principal
• Kunden-Tenant B: Service Principal

Ändert der Hersteller die App-Definition, kann dies mehrere Tenants betreffen. Benutzerzuweisung, Conditional Access oder lokaler Consent werden jedoch im jeweiligen Kundentenant verwaltet.

Single-Tenant- und Multi-Tenant-Anwendungen

Single Tenant

Nur Konten des Home-Tenants sollen sich anmelden. Das ist häufig für interne Fachanwendungen geeignet.

Multi Tenant

Konten anderer Microsoft-Entra-Tenants können die Anwendung nutzen, wenn die App und der jeweilige Ressourcentenant dies zulassen. In jedem nutzenden Tenant entsteht ein Service Principal.

Persönliche Microsoft-Konten

App-Registrierungen können je nach Konfiguration auch persönliche Microsoft-Konten unterstützen. Diese Auswahl beeinflusst Endpunkte, Tests und Sicherheitsmodell.

Der unterstützte Kontotyp sollte nicht ohne Prüfung geändert werden. Eine Erweiterung von Single auf Multi Tenant verändert die potenzielle Nutzer- und Consent-Fläche.

Wo welche Einstellung verwaltet wird

Die Oberfläche kann sich ändern und manche Eigenschaften sind in beiden Ansichten verlinkt. Entscheidend ist das zugrunde liegende Objektmodell.

Object ID und Application ID nicht verwechseln

Die Application/Client ID identifiziert die Anwendung logisch und ist tenantübergreifend mit der App verknüpft. Die Object ID identifiziert ein konkretes Verzeichnisobjekt. Application Object und Service Principal besitzen unterschiedliche Object IDs.

Bei Microsoft Graph oder PowerShell muss deshalb klar sein, welches Objekt erwartet wird. Ein häufiger Fehler ist, die Object ID der App-Registrierung an eine Operation zu übergeben, die den Service Principal erwartet.

Test

1. App Registration öffnen und Client ID notieren.
2. Unter Enterprise Applications nach dieser Client ID suchen.
3. Object IDs beider Objekte vergleichen.
4. über Microsoft Graph application und servicePrincipal getrennt abfragen.

Benutzer- und Gruppenzuweisung

Bei vielen Enterprise Applications kann die Einstellung Assignment required aktiviert werden. Dann genügt Consent allein nicht; Benutzer oder Gruppen benötigen zusätzlich eine Zuweisung.

Prüfen Sie:

• unterstützt die Anwendung Zuweisungen wie erwartet,
• werden Gruppenmitgliedschaften ausgewertet,
• existieren verschachtelte Gruppen,
• welche App Roles werden zugewiesen,
• erhalten Administratoren unbeabsichtigt Zugriff,
• wie wird der Entzug getestet.

Eine Zuweisung ist nicht dasselbe wie API-Consent. Der Benutzer kann zugewiesen sein, während der Anwendung eine benötigte API-Berechtigung fehlt – oder umgekehrt.

App Roles und Scopes

Eine eigene App kann Rollen oder OAuth-Scopes bereitstellen.

• App Roles werden Benutzern, Gruppen oder Anwendungen zugewiesen und erscheinen als Claims.
• Delegated Scopes erlauben einer App, im Kontext eines angemeldeten Benutzers zu handeln.
• Application Permissions erlauben app-only Zugriff ohne Benutzerkontext, wenn Consent und Authentifizierung vorhanden sind.

Die Definition liegt am Application Object; die konkrete Zuweisung oder Zustimmung wird im Tenant wirksam.

Single Sign-on und Provisioning

Enterprise Applications können SSO-Konfiguration und automatisches Provisioning enthalten. Für SAML-Anwendungen sind beispielsweise Identifier, Reply URL, Signaturzertifikat und Claims relevant. Für Provisioning können SCIM-Endpunkt, Secret oder Token und Attributzuordnungen hinzukommen.

Diese technischen Credentials sind unabhängig von OAuth-Client-Secrets einer App Registration. Ablaufüberwachung muss deshalb alle Credential-Arten erfassen.

Eigentümer und Verantwortlichkeiten

App Registrations können Eigentümer besitzen. Zusätzlich braucht jede produktive Anwendung:

• fachlichen Owner,
• technischen Owner,
• Security-/Consent-Verantwortung,
• Betriebs- und Supportkontakt,
• Credential-Verantwortung,
• dokumentierten Zweck und Datenzugriff,
• Ablauf- und Löschprozess.

Ein einzelner Entwickler als Owner ist riskant. Verlässt er das Unternehmen, kann die App technisch weiterlaufen, aber niemand darf oder versteht ihre Konfiguration.

Typische Fehlerbilder

App wurde registriert, aber nicht unter Enterprise Applications gefunden

Prüfen Sie Filter, Tenant und Client ID. Bei einer App-Registrierung im Entra-Portal wird im Home-Tenant in der Regel zugleich ein Service Principal erzeugt. Wird das Application Object jedoch automatisiert, etwa über Microsoft Graph, angelegt, muss der Service Principal je nach Ablauf separat erstellt oder geprüft werden. Zusätzlich können Ansichten oder Filter ihn ausblenden.

App existiert unter Enterprise Applications, aber nicht unter App Registrations

Das ist bei fremden SaaS- und Multi-Tenant-Anwendungen normal. Das Application Object liegt im Home-Tenant des Herstellers; im eigenen Tenant existiert nur der Service Principal.

Benutzer kann sich anmelden, erhält aber keinen fachlichen Zugriff

Mögliche Ursachen:

• fehlende Benutzer-/Gruppenzuweisung,
• falsche App Role,
• Anwendung wertet Claims anders aus,
• Conditional Access blockiert späteren Zugriff,
• Provisioning hat Zielkonto nicht angelegt,
• API-Consent fehlt.

AADSTS700016 oder App nicht gefunden

Prüfen Sie Client ID, Tenant/Authority, unterstützten Kontotyp, gelöschtes Objekt und verwendeten Endpoint. Die Anwendung kann im falschen Tenant registriert oder als Single Tenant konfiguriert sein.

Service Principal versehentlich gelöscht

Das kann Zuweisungen, Consent und SSO im Tenant unterbrechen. Eine Wiederherstellung des Application Objects stellt den Service Principal nicht in jedem Szenario automatisch vollständig wieder her. Vor Löschung müssen Konfiguration und Berechtigungszustand exportiert werden.

Sicheres Entfernen einer Anwendung

1. Nutzung feststellen

• Anmeldeprotokolle,
• Service-Principal-Sign-ins,
• API-Nutzung und Zielsystem,
• Gruppen- und Benutzerzuweisungen,
• Abhängigkeiten in Flows, Skripten und Diensten,
• Eigentümer und Fachbereich.

2. Zugriff zunächst blockieren

Je nach Anwendung kann die Anmeldung oder Zuweisung kontrolliert deaktiviert werden. Das schafft eine Beobachtungsphase, bevor das Objekt gelöscht wird.

3. Credentials und Consent behandeln

• neue Token verhindern,
• Secrets/Zertifikate entfernen, wenn sicher,
• Consent widerrufen,
• Provisioning stoppen,
• Sitzungen und bestehende Tokens nach Risiko berücksichtigen.

4. Konfiguration exportieren

Object IDs, Client ID, Redirect URIs, Permissions, Zuweisungen, SSO und Provisioning dokumentieren.

5. Löschen und überwachen

Nach Löschung Anmeldefehler, Geschäftsprozesse und Auditprotokolle überwachen. Wiederherstellbarkeit hängt vom Objekt und Zeitraum ab und sollte nicht als alleiniger Rollback dienen.

Testkatalog

1. interner Benutzer mit direkter Zuweisung,
2. Benutzer über Gruppe,
3. Benutzer ohne Zuweisung,
4. Gastbenutzer, falls unterstützt,
5. Admin Consent vorhanden und entzogen,
6. delegated und app-only Zugriff unterscheiden,
7. Conditional Access auf Zielapp,
8. abgelaufenes Credential,
9. deaktivierter Service Principal,
10. Multi-Tenant-Anmeldung aus Testtenant.

Betriebsregister für Anwendungen

Empfohlene Felder:

• Anzeigename,
• Client ID,
• Application Object ID,
• Service Principal Object ID,
• Home-Tenant,
• Single-/Multi-Tenant,
• Eigentümer,
• fachlicher Zweck,
• Benutzer-/Gruppenzuweisung,
• Permissions und Consent,
• Credentials mit Ablaufdatum,
• SSO/Provisioning,
• letzte Nutzung,
• Review- und Abschaltdatum.

Für die eigentliche Berechtigungsbewertung schließt der Beitrag App-Berechtigungen und Admin Consent prüfen an. Den laufenden Betrieb von Secrets, Zertifikaten und föderierten Credentials behandelt anschließend Secrets und Zertifikate von Entra-Anwendungen überwachen.

So lassen sich Anwendungen im Entra-Tenant eindeutig zuordnen und verwalten

App Registration und Enterprise Application sind zwei Ansichten auf unterschiedliche Objekte. Das Application Object definiert die Anwendung; der Service Principal repräsentiert ihre Nutzung im Tenant. Wer IDs, Eigentümer, Consent, Zuweisungen und Credentials getrennt dokumentiert, kann Anmeldefehler gezielt analysieren und Anwendungen kontrolliert ändern oder entfernen, ohne tenantübergreifende Beziehungen zu verwechseln.