← Microsoft Entra ID & Microsoft 365 Administration

Identität, Tenant und Rollen

Eine Rolle ist zugewiesen, die Verwaltungseinheit ist angelegt — und trotzdem darf der Helpdesk plötzlich im ganzen Tenant Kennwörter zurücksetzen. Nicht wegen eines Fehlers, sondern weil beim Zuweisen ein Feld leer blieb und „leer“ hier „alles“ bedeutet. Dieses Modul ist der Einstieg in den Track: Es klärt, was ein Tenant ist, welche fünf Objekttypen du auseinanderhalten musst und woraus eine Rollenzuweisung besteht. Vorkenntnisse brauchst du keine — Begriffe wie Dienstprinzipal und Verwaltungseinheit werden unterwegs erklärt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Der Tenant ist die Grenze — und seinen ersten Namen wirst du nie los

Wer aus der Welt der Windows-Server kommt, sucht in Microsoft Entra ID zuerst nach einem Server. Es gibt keinen. Was es gibt, ist ein Tenant: eine Instanz des Verzeichnisdienstes, die Microsoft betreibt und die für deine Organisation die gemeinsame Grenze für Benutzer, Gruppen, Anwendungen und Geräte bildet. Alles, was in diesem Modul vorkommt, lebt in genau einem Tenant.

Tenant — Eine eigene, von anderen Organisationen abgeschottete Instanz von Microsoft Entra ID. Sie hat eine unveränderliche Tenant-ID im GUID-Format und trägt alle Identitätsobjekte der Organisation.

Bei der Erstellung bekommt jeder Tenant einen Anfangsdomänennamen der Form contoso.onmicrosoft.com. Die Dokumentation ist hier ungewöhnlich eindeutig: Diesen Anfangsnamen kannst du weder ändern noch löschen. Du kannst später contoso.com als eigene Domäne hinzufügen, ihren Besitz über einen DNS-Eintrag nachweisen und sie als primäre Domäne setzen — der onmicrosoft.com-Name bleibt trotzdem bestehen.

Das ist keine Kosmetik. Der Anfangsname taucht dauerhaft an Stellen auf, an denen man ihn nicht erwartet: im Anmeldenamen jedes eingeladenen Gastkontos zum Beispiel, wie du gleich sehen wirst. Wer einen Tenant nach einem Projekt, einem Produkt oder einer Firmierung benennt, die sich ändern kann, trägt diese Entscheidung dauerhaft mit.

Vor der ersten ZuweisungEin Tenant ist eine Grenze, kein Ordner. Zwei Tenants sind zwei Welten — es gibt keine übergeordnete Ebene, von der aus man beide gemeinsam verwaltet.

Fünf Objekte, die du auseinanderhalten musst

Der Rest des Tracks setzt voraus, dass diese fünf Begriffe sitzen. Sie sehen im Portal ähnlich aus und verhalten sich verschieden.

Benutzer: Ein Konto für einen Menschen. Trägt einen Anmeldenamen, Authentifizierungsmethoden und gegebenenfalls Lizenzen.
Gruppe: Bündelt Mitglieder. Steuert Zugriff, Lizenzzuweisung oder — in einer Sonderform — Rollenzuweisung.
Anwendungsobjekt: Die Registrierung einer Anwendung. Existiert genau einmal, im Heimat-Tenant der Anwendung.
Dienstprinzipal: Die lokale Erscheinung einer Anwendung in einem Tenant. Hier hängen Berechtigungen und Zustimmung.
Gerät: Ein registriertes oder eingebundenes Gerät. Wird später zum Signal für Zugriffsentscheidungen.

Sicherheitsprinzipal — Sammelbegriff für alles, dem sich Rechte zuweisen lassen: Benutzer, Gruppe oder Dienstprinzipal. Wo die Dokumentation von einem Sicherheitsprinzipal spricht, ist dieser Dreiklang gemeint.

Die häufigste Verwechslung ist die zwischen Anwendungsobjekt und Dienstprinzipal. Sie ist wichtig genug für einen eigenen Abschnitt.

Anwendungsobjekt und Dienstprinzipal: ein Ding mit zwei Seiten

Registrierst du eine Anwendung in deinem Tenant, entstehen zwei Objekte: ein Anwendungsobjekt und ein Dienstprinzipal. Das Anwendungsobjekt ist die Vorlage — es existiert nur im Heimat-Tenant und beschreibt, was die Anwendung grundsätzlich ist. Der Dienstprinzipal ist die Ausprägung dieser Vorlage in einem konkreten Tenant und entscheidet, was die Anwendung dort tatsächlich darf.

Anwendungsobjekt — Die globale Definition einer Anwendung. Eins pro Anwendung, im Heimat-Tenant. Im Portal unter App registrations zu finden.

Dienstprinzipal — Die lokale Instanz einer Anwendung je Tenant. Trägt Berechtigungen, Zustimmung und Zuweisungen. Im Portal unter Enterprise applications zu finden.

Eine Anwendung hat also ein Anwendungsobjekt und kann viele Dienstprinzipale haben — einen in jedem Tenant, in dem sie genutzt wird. Eine Anwendung, die nur im eigenen Tenant läuft, hat genau einen. Wer eine mehrmandantenfähige Anwendung aus dem Katalog hinzufügt, legt im eigenen Tenant nur den Dienstprinzipal an; das Anwendungsobjekt steht beim Hersteller.

Der Fallstrick bei der AutomatisierungÜber das Portal entstehen beide Objekte zusammen. Über die Microsoft-Graph-API ist das Anlegen des Dienstprinzipals laut Dokumentation ein eigener Schritt. Ein Skript, das nur die Registrierung anlegt, hinterlässt eine Anwendung, die sich nirgends anmelden kann — und der Fehler zeigt sich erst beim ersten Tokenabruf.

Eine dritte Variante fällt aus dem Muster: der Dienstprinzipal einer verwalteten Identität. Er hat kein zugehöriges Anwendungsobjekt und lässt sich laut Dokumentation nicht direkt bearbeiten. Man kann ihm Berechtigungen geben, aber nicht an ihm schrauben — genau das ist sein Zweck, denn dadurch gibt es kein Kennwort und kein Zertifikat, das jemand verwalten oder verlieren könnte.

Kurzcheck

Ein Kollege sucht die erteilten Berechtigungen einer Anwendung und findet sie unter App registrations nicht. Woran liegt das am wahrscheinlichsten?

Erteilte Berechtigungen hängen am Dienstprinzipal, also unter Enterprise applications.
Die Anwendung wurde gelöscht und liegt noch im Papierkorb.
Berechtigungen sind ausschließlich über die Graph-API sichtbar.
Dem Kollegen fehlt die Rolle Global Reader.

Treffer. Richtig. Die Registrierung beschreibt, was die Anwendung anfordern möchte; was sie in diesem Tenant tatsächlich bekommen hat, steht am Dienstprinzipal.

Wer jemand ist: `userPrincipalName`, `userType` und `#EXT#`

Ein Benutzerkonto trägt mehrere Namen, und sie bedeuten Verschiedenes. Der userPrincipalName ist der Anmeldename. Das Attribut mail ist die Mailadresse. Beide sind oft gleich, müssen es aber nicht sein — und Anmeldeprobleme entstehen regelmäßig genau dort, wo jemand das eine für das andere hält.

Bei eingeladenen Gästen wird der Unterschied sichtbar. Lädt der Tenant fabrikam die Person john@contoso.com ein, lautet ihr userPrincipalName im Verzeichnis von fabrikam john_contoso.com#EXT#@fabrikam.onmicrosoft.com. Die ursprüngliche Adresse steckt darin, aber der Anmeldename ist ein anderer — und er trägt den Anfangsdomänennamen aus dem ersten Abschnitt, dauerhaft.

Daneben steht das Attribut userType mit den beiden Werten Member und Guest. Es beschreibt das Verhältnis zur Organisation, nicht den Ort der Authentifizierung. Beides lässt sich unabhängig kombinieren:

Externer Gast: Konto in einer fremden Organisation, userType ist Guest. Der Normalfall der Zusammenarbeit.
Externes Mitglied: Konto in einer fremden Organisation, userType ist Member. Üblich in Konzernen mit mehreren Tenants.
Interner Gast: Konto im eigenen Verzeichnis mit eigenen Anmeldedaten, aber userType ist Guest. Meist Altbestand aus der Zeit vor der B2B-Zusammenarbeit.
Internes Mitglied: Konto im eigenen Verzeichnis, userType ist Member. Die Beschäftigten der Organisation.

Warum das zähltViele Richtlinien und Standardeinstellungen greifen auf userType zu. Wer annimmt, extern sei gleichbedeutend mit Gast, übersieht das externe Mitglied — und wundert sich, warum eine Gastregel bei einem Partnerkonto nicht greift.

Eine Rollenzuweisung besteht aus drei Teilen

Rechte bekommt niemand, weil er eine bestimmte Person ist. Rechte entstehen aus einer Rollenzuweisung, und die besteht laut Dokumentation immer aus denselben drei Bestandteilen.

Sicherheitsprinzipal — wer bekommt das Recht→Rollendefinition — welche Berechtigungen→Geltungsbereich — auf welchen Ressourcen

Drei Teile, kein Teil optional

Microsoft Entra ID bringt über 65 eingebaute Rollen mit. Eingebaute Rollen lassen sich nicht verändern; reicht keine davon, gibt es benutzerdefinierte Rollen, die aus derselben Berechtigungsliste zusammengestellt werden. Zugriff entsteht, indem eine Zuweisung angelegt wird, und endet, indem sie entfernt wird.

Rollendefinition — Eine benannte Sammlung von Berechtigungen. Sie sagt, was getan werden darf, aber nichts darüber, woran — das ist die Aufgabe des Geltungsbereichs.

Entra-Rollen sind nicht Azure-Rollen

Zwei Rechtesysteme tragen ähnliche Namen und dieselbe Denkweise, sind aber getrennt. Die Verwechslung kostet regelmäßig eine Stunde Fehlersuche.

Entra-Rollen: Steuern Verzeichnisobjekte — Benutzer, Gruppen, Anwendungen. Wirken über die Microsoft-Graph-API.
Azure-Rollen: Steuern Azure-Ressourcen — virtuelle Maschinen, Speicherkonten. Wirken über Azure Resource Manager.

Die Dokumentation ist an dieser Stelle ausdrücklich: Berechtigungen aus Entra-Rollen lassen sich nicht in benutzerdefinierten Azure-Rollen verwenden und umgekehrt. Wer als Global Administrator eine Azure-Ressourcengruppe verwalten will, stellt fest, dass die Rolle dort zunächst nichts bewirkt.

Die dritte EbeneZusätzlich haben einzelne Microsoft-365-Dienste eigene Rollenmodelle, etwa Exchange Online. Eine Aufgabe, die im Exchange-Admin-Center scheitert, braucht deshalb nicht zwingend eine Entra-Rolle — sondern manchmal eine Rolle im Dienst selbst.

Geltungsbereich: Tenant, Verwaltungseinheit, einzelne Ressource

Der dritte Teil der Zuweisung ist der, den Einsteiger am häufigsten weglassen — und weglassen heißt hier: der ganze Tenant. Wer eine Rolle ohne Geltungsbereich zuweist, hat sie organisationsweit vergeben.

Tenant — die Rolle wirkt auf alle Objekte der Organisation.
Verwaltungseinheit — die Rolle wirkt nur auf die Mitglieder dieser Einheit.
Einzelne Ressource — die Rolle wirkt nur auf ein Objekt, etwa eine einzelne Anwendungsregistrierung.

Verwaltungseinheit — Ein Container innerhalb des Tenants, der Benutzer, Gruppen oder Geräte aufnehmen kann. Er begrenzt den Wirkungsbereich einer Rollenzuweisung auf seine Mitglieder.

Das klassische Beispiel ist der regionale Helpdesk: Die Rolle Helpdesk Administrator wird nicht tenantweit vergeben, sondern auf eine Verwaltungseinheit für einen Standort, die genau die dortigen Benutzer enthält.

Die Falle mit den GruppenFügst du eine Gruppe zu einer Verwaltungseinheit hinzu, kommt nur das Gruppenobjekt in den Wirkungsbereich — nicht ihre Mitglieder. Ein darauf begrenzter User Administrator kann die Gruppe umbenennen und ihre Mitgliedschaft ändern, die Kennwörter der enthaltenen Benutzer aber nicht zurücksetzen. Dafür müssten diese Benutzer selbst Mitglieder der Verwaltungseinheit sein.

Zwei weitere Grenzen stehen in der Dokumentation: Verwaltungseinheiten lassen sich nicht schachteln, und ihr Einsatz kostet Lizenz. Jeder Administrator, der über den Bereich einer Verwaltungseinheit Rollen zugewiesen bekommt, braucht eine Microsoft-Entra-ID-P1-Lizenz. Das Anlegen selbst ist in der kostenlosen Edition möglich — die Delegation ist es nicht.

Kurzcheck

Ein Administrator ist als User Administrator auf eine Verwaltungseinheit begrenzt, die eine Gruppe mit 40 Benutzern enthält. Was kann er?

Die Gruppe verwalten, aber die Kennwörter der 40 Benutzer nicht zurücksetzen.
Die Gruppe und ihre 40 Mitglieder vollständig verwalten.
Nichts, weil Gruppen in Verwaltungseinheiten nicht zulässig sind.
Die Kennwörter zurücksetzen, aber die Gruppe nicht umbenennen.

Treffer. Richtig. Die Aufnahme der Gruppe holt nur das Gruppenobjekt in den Bereich, nicht ihre Mitglieder.

Die beiden Zahlen, die Microsoft nennt

An zwei Stellen verlässt die Dokumentation die Allgemeinplätze und nennt konkrete Obergrenzen. Beide sind gut zu merken, weil das Portal sie überwacht.

Unter fünf Global Administrators. Microsoft empfiehlt, die Rolle Global Administrator an weniger als fünf Personen zu vergeben. Ab fünf privilegierten Zuweisungen blendet die Übersichtsseite eine Warnkarte ein. Der Grund ist nüchtern: Diese Rolle kann fast jede Verwaltungseinstellung lesen und ändern, in Entra wie in Microsoft 365, und sie kann ihren eigenen Zugriff erweitern, um an Daten zu kommen.

Unter zehn privilegierte Rollenzuweisungen. Manche Rollen gelten als privilegiert, weil sie Anmeldeinformationen ändern oder Berechtigungen verteilen können und damit eine Rechteausweitung ermöglichen. Über zehn solchen Zuweisungen zeigt die Rollenseite eine Warnung. Im Portal tragen sie die Kennzeichnung PRIVILEGED; per Skript findest du sie so:

Get-MgBetaRoleManagementDirectoryRoleDefinition -Filter "isPrivileged eq true" listet die privilegierten Rollendefinitionen.
Bei ihnen ist die Eigenschaft IsPrivileged auf True gesetzt.
Jede eingebaute Rolle hat eine feste TemplateId als GUID — sie ist in jedem Tenant dieselbe und damit der stabile Bezug für Skripte.

Woher die erste Zuweisung kommtWer einen Microsoft-Cloud-Dienst zeichnet, erzeugt damit einen Tenant und bekommt selbst die Rolle Global Administrator. Der erste Administrator eines Tenants ist also nie das Ergebnis einer Planung, sondern ein Nebenprodukt der Anmeldung.

Zwei Konten, die niemandem gehören

Aus derselben Empfehlungsliste stammt eine Regel, die dem Prinzip der kleinsten Rechte auf den ersten Blick widerspricht: Microsoft empfiehlt zwei reine Cloud-Konten mit dauerhafter Zuweisung der Rolle Global Administrator. Sie gehören keiner Person und dienen ausschließlich dem Notfall — wenn die üblichen Konten nicht nutzbar sind oder sich alle Administratoren versehentlich ausgesperrt haben.

Rein cloudbasiert ist dabei die entscheidende Eigenschaft: Diese Konten stammen nicht aus einem lokalen Verzeichnis und überleben deshalb dessen Ausfall. Zwei statt eines, weil auch ein Notfallkonto durch einen abgelaufenen Berechtigungsnachweis oder einen Tippfehler unbrauchbar werden kann.

Der Preis dieser EmpfehlungZwei dauerhaft hoch privilegierte Konten sind zwei dauerhaft lohnende Ziele — und sie werden üblicherweise von Zugriffsregeln ausgenommen, damit genau diese Regeln sie im Notfall nicht blockieren. Diese Ausnahme muss man bezahlen: mit überwachter Anmeldung, mit getrennt aufbewahrten Anmeldedaten und mit einem regelmäßigen Test, ob der Weg überhaupt noch funktioniert. Ungetestet ist ein Notfallkonto nur eine Annahme.

Was Entra ID nicht ist

Der verbreitetste Denkfehler bei der Umstellung ist, Microsoft Entra ID für ein Active Directory in der Cloud zu halten. Beide verwalten Identitäten, aber das Ordnungsmodell ist ein anderes.

Delegation im Active Directory: Über Domänen, Organisationseinheiten und Gruppen — die Struktur des Verzeichnisses trägt die Rechte.
Delegation in Entra ID: Über eingebaute und benutzerdefinierte Rollen, begrenzt durch Verwaltungseinheiten — die Rolle trägt die Rechte, nicht die Position in einem Baum.

Praktisch heißt das: Es gibt keine Organisationseinheiten, an die sich eine Richtlinie hängen lässt, und keine Gruppenrichtlinien. Anwendungen, die auf LDAP oder die Windows-integrierte Anmeldung angewiesen sind, sprechen mit Entra ID nicht unmittelbar; für sie gibt es den Anwendungsproxy, der lokale Anwendungen veröffentlicht und die Anmeldung im Hintergrund weiterhin über Kerberos abwickelt.

Wer aus dem Active Directory kommt, sucht also einen Baum und findet eine Liste von Rollen. Das ist keine fehlende Funktion, sondern ein anderes Modell — und es erklärt, warum die Frage nach dem Geltungsbereich hier so viel Gewicht hat.

Durchgerechnet: die kleinste Rolle für eine konkrete Aufgabe

Ein Helpdesk soll Kennwörter zurücksetzen

Szenario

Ein Service-Desk-Team von drei Personen soll Kennwörter zurücksetzen können. Der bisherige Weg war eine Zuweisung der Rolle Global Administrator an eine Sammelgruppe — mit dem Argument, dass dann nie etwas fehlt.

Anforderungen

Nur Kennwortrücksetzung für normale Beschäftigte, keine Administratorkonten.
Die Rechte sollen nachweisbar begrenzt sein.
Der Weg soll auch dann tragen, wenn das Team wächst.

Schritte

Aufgabe benennen statt Person: Das Kennwort eines Nicht-Administrators zurücksetzen.
Passende Rolle suchen. Die Beschreibung von Helpdesk Administrator lautet wörtlich, dass sie Kennwörter für Nicht-Administratoren und für Helpdesk-Administratoren zurücksetzen kann — die Grenze ist also bereits eingebaut.
Geltungsbereich festlegen. Ohne Angabe wirkt die Rolle tenantweit; mit einer Verwaltungseinheit nur auf deren Mitglieder.
Nicht der einzelnen Person zuweisen, sondern einer Gruppe, die Rollenzuweisungen tragen darf — dann ändert Wachstum im Team nichts an der Rechtevergabe.
Gegenprobe: Kann ein Mitglied jetzt das Kennwort eines anderen Administrators ändern? Nein — und genau das war der Zweck.

Merksatz: Die Reihenfolge ist immer dieselbe: erst die Aufgabe, dann die Rolle, dann der Bereich. Wer mit der Rolle anfängt, landet bei Global Administrator, weil die immer passt.

Der Preis dieser Sorgfalt ist echt: Die Suche nach der kleinsten passenden Rolle unter über 65 Kandidaten dauert länger als eine Zuweisung der Rolle, die alles kann. Und sie geht gelegentlich daneben — dann fehlt einem Kollegen mitten in der Arbeit ein Recht, und es braucht einen zweiten Durchgang. Dieser Aufwand ist der Beitrag, den man für einen begrenzten Schaden im Ernstfall zahlt.

Die Reihenfolge, die alles zusammenhält

Aufgabe beschreiben, nicht Person→Kleinste Rolle suchen, die die Aufgabe abdeckt→Geltungsbereich setzen — sonst gilt der ganze Tenant→Einer rollenfähigen Gruppe zuweisen statt einer Person→Zuweisungen nachweisen und entfernen, was niemand mehr braucht

Ohne Schritt 3 ist alles tenantweit

Mit diesen fünf Schritten und den Objekten aus den ersten Abschnitten steht das Gerüst, auf dem die übrigen Module dieses Tracks aufbauen: Gruppen und Lizenzen, Anmeldeverfahren, Conditional Access und schließlich die bedarfsgesteuerte Aktivierung privilegierter Rollen.

Gleich im CheckDie Übungen prüfen genau diese Kette — Objekttypen auseinanderhalten, den Geltungsbereich einer Zuweisung bestimmen und die kleinste Rolle für eine benannte Aufgabe finden.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität12 Primärquellen · zuletzt geprüft: 2026-09-12