Microsoft 365 | Was passiert bei einem neuen Tenant?

Ein Microsoft 365 Tenant ist keine einzelne Cloud-Anwendung und auch kein virtueller Server, den Microsoft als geschlossene Instanz für dein Unternehmen bereitstellt. Mit der Registrierung entsteht zuerst eine dedizierte Instanz von Microsoft Entra ID. Dieses Verzeichnis bildet die Identitäts-, Zugriffs- und Verwaltungsgrenze deiner Organisation innerhalb der Microsoft Cloud.

Innerhalb dieser Grenze verwaltest du Benutzer, Gruppen, Geräte, Anwendungen, Administratorrollen, Authentifizierungsmethoden und Zugriffsrichtlinien. Microsoft 365 Dienste wie Exchange Online, SharePoint Online, Teams, Intune, Defender und Purview verwenden diese gemeinsame Identitätsebene. Die Dienste besitzen trotzdem eigene Datenbestände, Richtlinien und Verwaltungsobjekte.

Diese Trennung ist wichtig, weil der Begriff „Microsoft 365 Tenant“ häufig den Eindruck erweckt, alle Komponenten würden als ein einheitliches System bereitgestellt. Technisch besteht der Tenant aus einem zentralen Entra-Verzeichnis und mehreren angebundenen Workloads, die abhängig von Abonnement, Lizenzierung und Aktivierung provisioniert werden.

Microsoft beschreibt einen Tenant als dedizierte Instanz von Microsoft Entra ID. Jeder Tenant ist von anderen Tenants getrennt und besitzt eigene Identitäten, App-Registrierungen, Richtlinien und Konfigurationen. Aus Sicht von Microsoft Entra bildet er eine Identity-and-Access-Management-Grenze. Aus Sicht von Microsoft 365 ist er zugleich die übliche Kollaborations- und Lizenzgrenze.

Innerhalb des Verzeichnisses verwaltest du unter anderem:

Ein interner Benutzer kann andere Benutzer derselben Organisation über Outlook, Teams oder weitere Microsoft 365 Dienste finden. Ein Konto aus einem fremden Tenant gehört dagegen nicht automatisch zu dieser Vertrauensgrenze. Der Zugriff muss über Funktionen wie B2B Collaboration, Cross-Tenant Access oder andere externe Identitätsmodelle hergestellt werden.

Der Tenant enthält damit nicht nur Benutzerkonten. Er bildet die technische Grundlage für Authentifizierung, Autorisierung und die Zuordnung von Anwendungen zu deiner Organisation.

Bei der Erstellung eines Microsoft 365 Tenants entstehen beziehungsweise beginnen folgende Strukturen:

Nicht jede Komponente steht in derselben Sekunde vollständig zur Verfügung. Microsoft Entra ID ist unmittelbar nach der Tenant-Erstellung vorhanden. Andere Dienste werden abhängig vom erworbenen Produkt und der technischen Aktivierung eingerichtet.

Nach einer neuen Registrierung kann es deshalb vorkommen, dass ein Adminportal bereits erreichbar ist, bestimmte Funktionen aber noch fehlen. Auch eine zugewiesene Lizenz führt nicht immer dazu, dass alle zugehörigen Dienste sofort nutzbar sind.

Exchange Online muss beispielsweise eine Exchange-Organisation und anschließend Postfächer provisionieren. SharePoint Online benötigt einen eigenen Tenant-Namensraum. OneDrive wird für einzelne Benutzer häufig erst bei der ersten Nutzung vollständig angelegt.

Der ursprüngliche Abschnitt nennt diese Strukturen bereits korrekt und unterscheidet zwischen unmittelbar vorhandenen Entra-Objekten und später bereitgestellten Workloads.

Die Begriffe Microsoft Entra Tenant und Microsoft 365 Tenant werden oft verwendet, als handele es sich um zwei eigenständige Verzeichnisse. Das ist technisch missverständlich.

Microsoft 365 verwendet dieselbe Microsoft Entra ID Instanz für Benutzer, Gruppen, Geräte, Anwendungen und Zugriffstoken. Erstellst du im Microsoft 365 Admin Center einen Benutzer, wird das zugehörige Benutzerobjekt im Microsoft Entra Verzeichnis angelegt.

Eine Lizenzzuweisung ergänzt dieses Identitätsobjekt um Nutzungsrechte für bestimmte Dienste. Enthält die Lizenz Exchange Online, kann auf Grundlage des Benutzerobjekts ein Postfach provisioniert werden. Enthält sie SharePoint Online, erhält der Benutzer Zugriff auf SharePoint und OneDrive. Enthält sie Intune, kann er abhängig von den übrigen Einstellungen Geräte registrieren und verwalten.

Das Verhältnis lässt sich vereinfacht darstellen:

Entra ID bildet die gemeinsame Identitäts- und Zugriffsebene. Die Workloads verwenden diese Identitäten, speichern ihre Fachdaten aber in eigenen Systemen.

Ein Benutzerobjekt liegt in Microsoft Entra ID. Das Postfach liegt in Exchange Online. Die Dateien des Benutzers liegen in OneDrive auf Basis von SharePoint Online. Teams verwendet für Chats, Besprechungen, Dateien und Gruppen mehrere Microsoft 365 Backends.

Jeder Microsoft Entra Tenant besitzt eine weltweit eindeutige Tenant-ID. Je nach Portal oder Dokumentation wird sie auch als Directory ID, Microsoft Entra Tenant ID, Mandanten-ID oder Verzeichnis-ID bezeichnet.

Es handelt sich immer um eine GUID:

Die Tenant-ID ist nicht mit dem Anzeigenamen des Unternehmens, der initialen Domain oder einer später hinzugefügten Unternehmensdomain identisch.

Beispiel:

Der Anzeigename kann geändert werden. Unternehmensdomains lassen sich hinzufügen und unter bestimmten Bedingungen wieder entfernen. Microsoft erlaubt unter definierten Voraussetzungen sogar eine Umbenennung der SharePoint- und OneDrive-Domain.

Die Tenant-ID bleibt dagegen die stabile technische Kennung des Verzeichnisses.

Sie wird unter anderem verwendet bei:

Ein mandantenspezifischer OAuth-Endpunkt kann die Tenant-ID direkt enthalten:

Domänen können ebenfalls zur Auswahl eines Tenants verwendet werden. Für Skripte, API-Konfigurationen und technische Dokumentationen ist die Tenant-ID meist eindeutiger, weil sie sich nicht verändert.

Die Tenant-ID bezeichnet das Microsoft Entra Verzeichnis. Eine Subscription-ID bezeichnet ein bestimmtes Azure-Abonnement.

Ein Tenant kann mit mehreren Azure-Abonnements verbunden sein:

Die Azure-Abonnements verwenden den zugeordneten Microsoft Entra Tenant für die Authentifizierung von Benutzern, Service Principals und Managed Identities.

Microsoft 365 Abonnements besitzen ebenfalls eigene Produkt-, Vertrags- und Abrechnungsbeziehungen. Sie erzeugen aber kein separates Identitätsverzeichnis für jeden Lizenzvertrag. Die Produkte und verfügbaren Lizenzmengen werden dem vorhandenen Tenant zugeordnet.

Diese Unterscheidung ist bei PowerShell und Azure CLI relevant. Eine Anmeldung kann im richtigen Tenant erfolgen, während gleichzeitig das falsche Azure-Abonnement ausgewählt ist.

Microsoft Graph stellt zentrale Tenant-Informationen über eine Ressource vom Typ organization bereit. In einem normalen Microsoft Entra Tenant existiert ein Organisationsobjekt.

Dieses Objekt enthält abhängig von Berechtigungen und Konfiguration unter anderem:

Die Eigenschaft Id entspricht der Tenant-ID.

Du kannst das Organisationsobjekt über Microsoft Graph PowerShell auslesen:

Die verifizierten Domains sind verschachtelte Objekte. Für eine besser lesbare Ausgabe bereitest du sie separat auf:

Eine zusammengefasste Übersicht kannst du als eigenes Objekt erzeugen:

Organization.Read.All erteilt den vorgesehenen Lesezugriff auf die Organisationsinformationen. Ohne ausreichende Berechtigung können einzelne Eigenschaften fehlen oder mit null zurückgegeben werden.

Während der Tenant-Erstellung legst du eine initiale Domain fest:

Microsoft dokumentiert, dass diese initiale Domain später weder bearbeitet noch gelöscht werden kann. Du kannst eine eigene Unternehmensdomain hinzufügen und als primäre Domain setzen. Die ursprüngliche onmicrosoft.com-Domain bleibt trotzdem Bestandteil des Tenants.

Sie wird anfangs verwendet für:

Beispiel:

Für administrative Cloud-only-Konten ist diese Domain häufig sinnvoll. Das Konto bleibt dadurch unabhängig von einer späteren Änderung der Unternehmensdomain oder von der Synchronisation mit einem lokalen Active Directory.

Bei einer klassischen Tenant-Erstellung erhält der Benutzer, der das Verzeichnis erstellt, standardmäßig die Rolle Global Administrator. Microsoft nennt ihn zugleich als technischen Kontakt des neuen Tenants.

Dieses Konto ermöglicht die weitere Konfiguration von Domains, Benutzern, Lizenzen und Sicherheitseinstellungen.

Nach der Basiseinrichtung solltest du prüfen:

Das Registrierungskonto sollte nicht ungeprüft zum dauerhaften Standardkonto für alle administrativen Aufgaben werden.

Die ursprüngliche onmicrosoft.com-Domain wird bei der Bereitstellung von SharePoint Online für die SharePoint- und OneDrive-URLs verwendet.

Beispiel:

OneDrive for Business verwendet die SharePoint-Online-Plattform. Deshalb teilen sich beide Dienste denselben Tenant-Namensraum.

Eine später hinzugefügte Domain ändert diese URLs nicht:

Microsoft unterstützt eine nachträgliche Domainumbenennung für SharePoint und OneDrive. Dabei werden alle betroffenen Sites einzeln umbenannt und können während der Verarbeitung vorübergehend nicht erreichbar sein. Die Standardfunktion ist aktuell für Tenants mit höchstens 10.000 Sites, OneDrive-Konten und SharePoint-Embedded-Containern vorgesehen. Größere Umgebungen benötigen Advanced Tenant Rename und passende SharePoint-Advanced-Management-Lizenzen.

Die Namenswahl bei der Registrierung bleibt deshalb eine Architekturentscheidung und keine reine kosmetische Eingabe.

Die einzelnen Microsoft 365 Dienste sind keine bloßen Ansichten auf dasselbe Verzeichnis.

Microsoft Entra ID speichert die Identitätsobjekte und stellt Zugriffstoken bereit. Die fachlichen Daten liegen in den jeweiligen Workloads.

Diese Architektur erklärt, warum eine Rolle oder Lizenz nicht automatisch alle Dienste unmittelbar nutzbar macht. Jeder Workload besitzt eigene Provisionierungsprozesse, Rollenmodelle und teilweise zusätzliche Lizenzprüfungen.

Ein Microsoft Entra Tenant kann ohne vollständige Microsoft 365 Benutzerlizenz existieren. Der Tenant bildet zuerst die Identitäts- und Organisationsgrenze.

Abonnements stellen Produkte und Lizenzmengen bereit. Die Zuweisung einer Lizenz an einen Benutzer aktiviert die enthaltenen Servicepläne und startet bei Bedarf die Provisionierung benutzerbezogener Dienste.

Nicht jeder Dienst erzeugt sofort ein sichtbares Objekt. OneDrive wird beispielsweise häufig erst bei der ersten Nutzung oder durch einen administrativen Provisionierungsprozess eingerichtet.

Eine kurze Verzögerung nach der Lizenzzuweisung ist deshalb kein Beweis für eine Fehlkonfiguration.

Du findest die Tenant-ID im Microsoft Entra Admin Center unter:

Microsoft nennt den Bereich Entra ID > Übersicht > Eigenschaften als offiziellen Navigationspfad.

Nur die Tenant-ID liest du per Microsoft Graph PowerShell so aus:

Der aktuelle Graph-Kontext zeigt ebenfalls eine Tenant-ID:

Beide Cmdlets beantworten unterschiedliche Fragen:

Gerade bei mehreren Kunden- oder Testtenants solltest du den Kontext vor jeder Änderung prüfen:

Diese Kontrolle reduziert das Risiko, administrative Befehle im falschen Tenant auszuführen.

Bei der Erstellung eines Microsoft 365 Tenants entsteht zuerst eine eigenständige Microsoft Entra ID Instanz. Sie bildet die Identitäts-, Zugriffs- und Verwaltungsgrenze deiner Organisation. Benutzer, Gruppen, Geräte, Apps, Rollen und Sicherheitsrichtlinien werden innerhalb dieses Verzeichnisses verwaltet.

Die weltweit eindeutige Tenant-ID ist die dauerhaft wichtigste technische Kennung. Anzeigename, Unternehmensdomains und unter bestimmten Bedingungen sogar SharePoint-URLs können geändert werden. Die Tenant-ID bleibt bestehen und verbindet Identitäten, Anwendungen, Partnerbeziehungen, APIs, Protokolle und Automatisierungen mit der richtigen Organisation.

Microsoft 365 Dienste verwenden dasselbe Entra-Verzeichnis, bleiben aber eigenständige Workloads. Exchange Online, SharePoint, Teams, Intune und Purview besitzen eigene Datenbestände, Richtlinien und Provisionierungsprozesse. Lizenzen schalten diese Dienste frei und erzeugen benutzerbezogene Objekte. Sie erzeugen nicht das zugrunde liegende Verzeichnis.

Die initiale onmicrosoft.com-Domain verdient besondere Aufmerksamkeit. Sie bleibt dauerhaft im Tenant und beeinflusst später den SharePoint- und OneDrive-Namensraum. Eine Umbenennung ist möglich, aber mit technischen Auswirkungen verbunden.

Dokumentiere deshalb unmittelbar nach der Erstellung mindestens Tenant-ID, initiale Domain, SharePoint-Namensraum, Organisationseigenschaften und administrative Konten. Prüfe bei PowerShell-Arbeiten zusätzlich den aktuellen Graph-Kontext. Der Tenant ist nach wenigen Minuten vorhanden. Seine technische Struktur bestimmt aber über Jahre, wie Identitäten, Dienste und Automatisierungen zusammenarbeiten.