Ein Azure-Tenant und ein Microsoft-365-Tenant sind im Grunde dasselbe technische Konstrukt: Beide sind Instanzen von Microsoft Entra ID (früher Azure Active Directory) und werden durch dieselbe Tenant-ID identifiziert. Der entscheidende Unterschied liegt nicht in der Tenant-Struktur selbst, sondern in den Diensten und Lizenzen, die innerhalb dieses gemeinsamen Tenants aktiviert sind. Ob du Azure-Infrastruktur betreibst, Microsoft 365 nutzt oder beides kombinierst, die folgenden Fragen klären, was das konkret für dein Unternehmen bedeutet.
Wie hängen Azure-Tenant und Microsoft-365-Tenant zusammen?
Ein Azure-Tenant und ein Microsoft-365-Tenant teilen dieselbe Grundlage: Microsoft Entra ID. Wenn dein Unternehmen sowohl Azure als auch Microsoft 365 nutzt und beide unter derselben Organisation registriert sind, laufen sie in der Regel im selben Tenant. Die Tenant-ID ist identisch, die Identitätsverwaltung ist zentral und Nutzerkonten gelten für beide Dienste gleichermaßen.
In der Praxis bedeutet das: Wer sich mit seinem Unternehmenskonto bei Microsoft Teams anmeldet, nutzt dieselbe Identität, mit der er auch auf Azure-Ressourcen zugreifen kann, sofern die entsprechenden Berechtigungen vergeben wurden. Der Tenant ist also kein Produkt, sondern ein organisatorischer Container, der alle Microsoft-Cloud-Dienste eines Unternehmens unter einem Dach vereint. Dieser Zusammenhang ist besonders relevant, wenn du eine strukturierte Azure-Infrastruktur aufbaust, denn Governance und Identitätsmanagement greifen von Anfang an ineinander.
Was ist der Unterschied zwischen Azure-Diensten und M365-Diensten im Tenant?
Obwohl Azure und Microsoft 365 im selben Tenant laufen können, unterscheiden sie sich grundlegend in ihrer Ausrichtung. Microsoft-365-Dienste umfassen Produktivitäts- und Kollaborationstools wie Teams, Exchange Online, SharePoint und OneDrive. Azure-Dienste dagegen sind Infrastruktur- und Plattformdienste: virtuelle Maschinen, Datenbanken, KI-Services, Netzwerkkomponenten und vieles mehr.
Ein weiterer zentraler Unterschied liegt im Abrechnungsmodell. Microsoft 365 wird in der Regel über Nutzerlizenzen abgerechnet, also pro Person und Monat. Azure hingegen folgt einem nutzungsbasierten Modell, bei dem du für tatsächlich verbrauchte Ressourcen zahlst. Das hat auch organisatorische Konsequenzen: Azure-Ressourcen werden in Subscriptions und Resource Groups strukturiert, während M365-Dienste direkt an Benutzerkonten und Lizenzen geknüpft sind.
Für Unternehmen, die eine zentrale Datenplattform auf Azure betreiben und gleichzeitig Microsoft 365 für die tägliche Zusammenarbeit nutzen, ist das Verständnis dieser Trennung essenziell, um Kosten, Berechtigungen und Governance sauber zu strukturieren.
Welche Rolle spielt Microsoft Entra ID für beide Tenant-Typen?
Microsoft Entra ID ist das Herzstück jedes Tenants, egal ob du primär Azure oder Microsoft 365 nutzt. Es ist der zentrale Identitäts- und Zugriffsmanagement-Dienst, der Benutzerkonten, Gruppen, Authentifizierung und Autorisierung für alle Microsoft-Cloud-Dienste bereitstellt. Ohne Entra ID gibt es keinen Tenant.
Konkret übernimmt Entra ID folgende Aufgaben für beide Dienst-Welten:
- Single Sign-On (SSO): Nutzer*innen melden sich einmal an und haben Zugriff auf alle verbundenen Dienste, von Teams bis zu Azure-Portalen.
- Multi-Faktor-Authentifizierung (MFA): Sicherheitsrichtlinien gelten zentral für alle Dienste im Tenant.
- Conditional Access: Zugriffsregeln lassen sich granular nach Gerät, Standort oder Risikostufe definieren.
- Gruppenbasierte Lizenz- und Rechteverwaltung: Entra-Gruppen steuern sowohl M365-Lizenzen als auch Azure-Rollenzuweisungen.
Der frühere Name Azure Active Directory (Azure AD) führte oft zu Verwirrung, weil er den Dienst als rein Azure-spezifisch erscheinen ließ. Die Umbenennung zu Microsoft Entra ID spiegelt besser wider, was der Dienst tatsächlich ist: die plattformübergreifende Identitätsbasis für das gesamte Microsoft-Cloud-Ökosystem.
Wann braucht ein Unternehmen separate Tenants für Azure und M365?
In den meisten Fällen braucht ein Unternehmen keine separaten Tenants für Azure und Microsoft 365. Ein gemeinsamer Tenant ist die empfohlene Standardarchitektur, weil er die Verwaltung vereinfacht, Single Sign-On ermöglicht und die Identitätsverwaltung zentralisiert. Separate Tenants sind nur in spezifischen Ausnahmesituationen sinnvoll.
Gründe, die für separate Tenants sprechen können:
- Strikte regulatorische Trennung: Wenn bestimmte Datenschutz- oder Compliance-Anforderungen eine vollständige organisatorische Isolation verlangen, etwa bei Tochtergesellschaften in regulierten Branchen.
- Fusionen und Übernahmen: Wenn zwei Unternehmen zusammenwachsen, aber die Systeme noch nicht migriert sind, existieren vorübergehend mehrere Tenants parallel.
- Entwicklungs- und Testumgebungen: Manche Unternehmen nutzen separate Tenants als vollständig isolierte Sandbox, obwohl Azure-Subscriptions innerhalb eines Tenants in der Regel ausreichend Trennung bieten.
- Mandantenfähige Dienstleister: IT-Dienstleister und Managed Service Provider betreiben oft eigene Tenants und verwalten Kunden-Tenants separat.
Wichtig: Mehrere Tenants erhöhen die Verwaltungskomplexität erheblich. Identitäten müssen dupliziert oder über B2B-Gastkonten verwaltet werden, Lizenzen sind nicht übertragbar, und Governance-Richtlinien müssen in jedem Tenant separat gepflegt werden. Die Entscheidung für mehrere Tenants sollte daher bewusst und mit klarer Begründung getroffen werden.
Wie werden Berechtigungen und Zugriffsrechte im Tenant verwaltet?
Berechtigungen im Tenant werden über Microsoft Entra ID und ein rollenbasiertes Zugriffsmodell (Role-Based Access Control, RBAC) gesteuert. Für Microsoft-365-Dienste gelten Entra-Rollen wie globaler Administrator oder Exchange-Administrator. Für Azure-Ressourcen greift Azure RBAC mit Rollen wie Owner, Contributor oder Reader, die auf Subscription-, Resource-Group- oder Ressourcenebene vergeben werden.
Berechtigungen für Microsoft 365
In M365 werden Berechtigungen primär über Entra-Rollen und Lizenzzuweisungen gesteuert. Administratorrollen legen fest, wer Einstellungen im Admin Center ändern darf. Nutzerrechte für einzelne Dienste wie SharePoint oder Teams werden zusätzlich über Gruppen und Richtlinien konfiguriert. Das Prinzip der minimalen Rechte gilt hier genauso wie in Azure: Nutzer*innen erhalten nur die Berechtigungen, die sie für ihre Aufgaben tatsächlich benötigen.
Berechtigungen für Azure-Ressourcen
In Azure erfolgt die Berechtigungsvergabe über Azure RBAC auf verschiedenen Ebenen der Ressourcenhierarchie. Management Groups ermöglichen es, Richtlinien und Rollen für mehrere Subscriptions gleichzeitig zu definieren. Subscriptions trennen Workloads und Kostenstellen voneinander. Resource Groups fassen zusammengehörige Ressourcen zusammen und erleichtern die granulare Rechtevergabe. Diese Struktur ist ein zentraler Baustein einer sauber aufgebauten Azure-Architektur.
Was sollten IT-Verantwortliche beim Tenant-Setup beachten?
Das Tenant-Setup ist eine der folgenreichsten Architekturentscheidungen im Microsoft-Cloud-Umfeld, weil viele Konfigurationen nachträglich nur schwer oder gar nicht rückgängig gemacht werden können. IT-Verantwortliche sollten von Anfang an strategisch vorgehen und es nicht organisch wachsen lassen.
Die wichtigsten Punkte beim Tenant-Setup:
- Domänenstrategie festlegen: Welche primäre Domäne wird für den Tenant verwendet? Wie werden Subdomänen und Abteilungen abgebildet? Das beeinflusst E-Mail-Adressen, Anmeldenamen und die externe Wahrnehmung.
- Administratorrollen einschränken: Globale Administratorrechte sollten auf wenige, dedizierte Konten beschränkt sein. Für den Alltag reichen spezifische Rollen mit eingeschränkten Rechten.
- Sicherheitsgrundlagen von Beginn an aktivieren: MFA, Conditional Access und Entra ID Protection sollten nicht nachträglich ergänzt, sondern von Anfang an konfiguriert werden.
- Subscription-Struktur in Azure planen: Wie werden Umgebungen (Produktion, Test, Entwicklung), Kostenstellen und Workloads in Subscriptions und Resource Groups abgebildet? Diese Struktur beeinflusst Governance, Abrechnung und Skalierbarkeit langfristig.
- Naming Conventions und Tagging-Strategie definieren: Einheitliche Benennungsregeln für Ressourcen erleichtern Verwaltung, Kostenzuordnung und Automatisierung erheblich.
- Datenschutz und Compliance berücksichtigen: Wo werden Daten gespeichert? Welche Compliance-Anforderungen gelten? Die Wahl der Azure-Region und entsprechende Richtlinien müssen von Anfang an feststehen.
Gerade Unternehmen, die Azure OpenAI und KI-Dienste einsetzen möchten, profitieren von einem sauber strukturierten Tenant, weil diese Technologien klare Datenstrukturen, Berechtigungen und Governance voraussetzen.
Wie Communardo Smart Work beim Tenant-Setup und der Azure-Architektur unterstützt
Ein solider Tenant ist keine einmalige Einrichtung, sondern eine strategische Grundlage, die mit deinem Unternehmen wachsen muss. Communardo Smart Work begleitet Unternehmen ab 500 Mitarbeitenden dabei, diese Grundlage von Anfang an richtig zu legen oder bestehende, organisch gewachsene Umgebungen strukturiert weiterzuentwickeln.
Das Leistungsangebot umfasst konkret:
- Tenant-Analyse und Architekturberatung: Bewertung der bestehenden Tenant-Struktur, Identifikation von Risiken und Optimierungspotenzialen.
- Azure Landing Zone-Aufbau: Strukturierte Umsetzung nach dem Microsoft Cloud Adoption Framework mit klarer Governance, Sicherheitsarchitektur und skalierbarer Organisationsstruktur.
- Entra ID und Berechtigungskonzepte: Entwicklung eines tragfähigen Rollen- und Berechtigungsmodells für Azure und Microsoft 365.
- Sicherheit und Compliance by Design: Azure Policies, Conditional Access und Sicherheitsrichtlinien werden von Beginn an integriert, nicht nachträglich ergänzt.
- Begleitung bis in den Betrieb: Von der Strategie über die Implementierung bis zum laufenden Support.
Wenn du wissen möchtest, wie eine strukturierte Cloud-Basis für dein Unternehmen aussehen kann, nimm jetzt Kontakt auf und besprich deine Ausgangssituation in einem ersten unverbindlichen Gespräch.