Microsoft 365-Migrationen | Teil 2: Administration der Umgebungen

Übersicht: Zusammenführung oder Trennung von Microsoft 365-Mandanten - ein Wegweiser
Vorheriger Artikel: Microsoft 365-Migrationen | Teil 1: Möglichkeiten zur Zusammenarbeit
Nächster Artikel: <FOLGT>

Die Optimierung und der Betrieb einer Microsoft Cloud-Umgebung sind nichts, das nebenbei erledigt werden kann. Unbestritten: die Cloud bietet viele Möglichkeiten zur Automatisierung und stellt entsprechende Dienste zur Absicherung nativ zur Verfügung. Diese konfigurieren sich jedoch nicht von selbst. Hier ist weiterhin die Unternehmens-IT gefragt, um die Anforderungen an Sicherheit und Compliance fachgerecht umzusetzen.

In der eigenen Umgebung, die man tagtäglich betreibt, mag das noch gut funktionieren. Kommen allerdings weitere Umgebungen hinzu - bspw. durch Zukäufe oder auch Trennungen durch Herauslösung eines Unternehmensbereichs, kann es sehr schnell komplex und aufwändig werden.

Dies liegt vor allem daran, dass es bislang keine native gebündelte Funktionalität innerhalb der Microsoft Cloud gibt, um alles zentral verwalten zu können. Stattdessen muss man aktuell auf eine Vielzahl von Einzellösungen zurückgreifen. Dieser Artikel bietet eine Übersicht der zur Verfügung stehenden zentralen Verwaltungslösungen sowohl für Azure als auch für Microsoft 365. Da sich diese Artikelserie um Microsoft 365 dreht, wird jedoch auf die für Azure relevanten Lösungen nicht im Detail eingegangen.

Auf einen Blick

Das folgende Schaubild gibt einen schnellen Überblick über die derzeit in der Microsoft Cloud nativ verfügbaren Lösungen sowie über etablierte Drittherstellerlösungen. Diese werden in den folgenden Kapiteln näher beschrieben.

Klassischer Ansatz: Zugriff mit Benutzern

Typischerweise werden privilegierte Zugriffe über zusätzliche Benutzerkonten innerhalb der zu verwaltenden Umgebungen bereitgestellt. Hierbei ist es grundsätzlich möglich, sowohl native Benutzer (Typ: intern) als auch Gastbenutzer (Typ: extern) zu verwenden. Diese unterscheiden sich in ihrer Handhabung und in den zur Verfügung stehenden Möglichkeiten.

Gegenüberstellung interne und Gastbenutzer

Die folgende Tabelle liefert eine Gegenüberstellung von internen und Gastbenutzern. Details hierzu werden in den folgenden Kapiteln erläutert.

Verwendung interner Benutzer

Interne Benutzerkonten entsprechen dem Standard-Benutzertyp in Entra ID. Dementsprechend stehen alle Möglichkeiten für die Zuweisung privilegierter Zugriffe zur Verfügung. Allerdings sind interne Benutzerkonten grundsätzlich lizenzierungspflichtig.

Wird ein solcher Benutzer beispielsweise über Regeln des bedingten Zugriffs geschützt, wird Entra ID P1 benötigt. Verwendet der Benutzer Entra Privileged Identity Management für eine zeit- und aufgabengebundene Rechteanhebung, wird Entra ID P2 benötigt.

Schon gewusst? Wenn ein Unternehmen mehrere Mandanten in seinem Besitz hat - beispielsweise innerhalb einer Unternehmensgruppe oder für Testzwecke - so wird pro Benutzer nur eine Lizenz im primären Mandanten benötigt! Es ist also nicht erforderlich, Benutzer pro Umgebung zu lizenzieren.

Wichtig: dies gilt nur für Funktionen, die in Entra ID P1, P2 und Governance enthalten sind. Um den jeweiligen Funktionsumfang in den anderen Umgebungen freizuschalten, muss außerdem dort eine einzelne Lizenz bereitgestellt werden.

Weitere Informationen und Details: Understanding Microsoft Entra Licensing With Multiple Tenants

Außerdem muss der Benutzer separat geschützt und verwaltet werden. Dies bedeutet zusätzlichen Aufwand für On- und Offboarding-Prozesse.

Verwendung von Gastbenutzern

Gastbenutzerkonten werden eigentlich für die externe Zusammenarbeit genutzt und nicht für administrative Zwecke. Dennoch ist es grundsätzlich möglich, Gastbenutzer mit privilegierten Zugriffen auszustatten.

Gastbenutzer sind im Rahmen von Funktionen in Entra ID P1 und P2 nicht lizenzierungspflichtig. Hier greift das sogenannte Monthly Active User-Modell, bei dem die ersten 50.000 Gastbenutzer kostenlos sind. Werden jedoch Governance-Funktionen eingesetzt, ist die Nutzung kostenpflichtig und erfordert die Abrechnung über ein Azure-Abonnement.

Außerdem können Gastbenutzer nicht auf alle Administrationsportale zugreifen oder sich mittels PowerShell zum Mandanten verbinden. Beispielsweise funktioniert der Zugriff auf Portale, in denen eine Wechsel-Funktion integriert ist (z.B. Azure oder das Entra Admin Center). Portale ohne diese Funktion (z.B. M365 Admin Center oder Exchange Online Admin Center) sind nicht verfügbar.

Darüber hinaus steht nur eine begrenzte Auswahl an Authentifizierungsmethoden für Gastbenutzer zur Verfügung (Authenticator App, SMS) und es ist kein Einsatz von Entra Privileged Identity Management möglich. Über Entra B2B kann dies zwar indirekt erreicht werden (siehe How to enable passkeys for guest users in Entra ID - JanBakker.tech). Allerdings kann ein Gastbenutzer nicht direkt zu einer Authentifizierung mit einer nicht unterstützten Methode gezwungen werden (bspw. FIDO-Schlüssel).

Daher wird vom Einsatz von Gastbenutzern für administrative Zwecke abgeraten.

Nativ integrierte Dienste für eine zentrale Verwaltung

Neben klassischen Benutzerzugriffen ist es auch bis zu einem gewissen Grad möglich, zentrale Dienste für die Verwaltung mehrerer Mandanten bzw. Umgebungen zu verwenden. Die folgende Tabelle nennt alle derzeit nativ verfügbaren Verwaltungslösungen in der Microsoft Cloud und ihren jeweiligen Einsatzzweck:

* GDAP ist für die Administration von Kundenumgebungen durch Microsoft-Partner gedacht. Ist das Unternehmen Microsoft-Partner, kann diese Option theoretisch verwendet werden. Besser ist jedoch die Verwendung von Entra-Mandantengovernance für diesen Zweck. GDAP kann in Kombination mit Microsoft 365 Lighthouse verwendet werden.

** Microsoft 365 Lighthouse ist für Managed Service Provider gedacht, um die Umgebungen ihrer Kunden zentral verwalten zu können. Hierzu muss der MSP ein Microsoft-Partner sein, um Anspruch auf die Nutzung des Dienstes zu haben. Es kann in Kombination mit GDAP eingesetzt werden.

Zentrale Verwaltung mit Entra-Mandantengovernance

Die Entra-Mandantengovernance ist die neueste Ergänzung im Funktions-Portfolio von Entra ID. Wie der Name schon andeutet, geht die Funktion über reine Administration hinaus.

Hiermit wird es möglich, mehrere Mandanten mithilfe eines zentral gepflegten Benutzers zu administrieren und auch Konfigurationsvorgaben für die Mandanten zu erzwingen. Für die Nutzung wird im Haupt-Mandanten eine Lizenz für Entra ID Governance benötigt (zwar sind viele Funktionen auch in Entra ID P1/P2 enthalten, gerade die wichtigen Funktionen sind jedoch der Governance-Variante vorbehalten).

Da dieses Thema etwas umfangreicher ist, habe ich hierfür einen eigenen Artikel erstellt, der die Funktionen und die aktuell noch existierenden Einschränkungen näher beleuchtet:

Die Zukunft: #IntuneForMSPs-Initiative

Microsoft ist sich durchaus bewusst, dass die eigenen Lösungen momentan viele Anforderungen nicht erfüllen können. Es gibt derzeit zumindest für Endkunden keine zentrale Lösung, um alle Funktionen abzubilden und von einer Stelle aus bedienbar zu machen. Stattdessen muss man sich in mehreren Portalen bewegen und die individuelle Bedienung beherrschen.

Daher hat Microsoft die Initiative #IntuneForMSPs ausgerufen. Der Name ist hierbei etwas unglücklich gewählt, da die Initiative nicht nur auf Intune, sondern auf eine vollumfängliche Verwaltung von Microsoft 365 abzielt. Die Initiative basiert auf einer Zusammenarbeit mit Partnern, die eigene Lösungen entwickelt haben, um die existierenden Lücken in den Microsoft-Lösungen zu schließen.

Aktuell sind die folgenden Dritthersteller Teil der Initiative:

Es bleibt abzuwarten, wie sich diese Initiative weiterentwickelt. Zwei Richtungen sind denkbar:

• Microsoft kauft den beliebtesten Anbieter bzw. dessen Lösung und integriert sie in das eigene Portfolio.
• Microsoft überlässt es weiterhin anderen Anbietern, gebündelte Lösungen für die Verwaltung anzubieten und zu vermarkten.

Wenn man sich die neueste Veröffentlichung "Entra-Mandantengovernance" anschaut, so scheint Microsoft eine ähnliche Ausrichtung wie die der Initiative zu planen. Dies wird daran deutlich, dass die Funktion (derzeit noch) keine Verwaltung von Azure zulässt und sich sehr auf Microsoft 365-Produktivitätsdienste wie Exchange, SharePoint und Intune fokussiert. Aber vielleicht kommt da in Zukunft noch mehr hinzu.

Und was ist mit lokaler Infrastruktur?

In solchen Migrationsprojekten findet man selten eine reine Cloud-Umgebung vor. Üblicherweise werden Identitäten aus einem Active Directory synchronisiert. Auch können Produktivitätsserver wie Exchange und SharePoint noch lokal betrieben werden. Hierfür entsteht ebenfalls Pflegeaufwand.

Typischerweise werden auch hier separate Konten für einen administrativen Zugriff angelegt, die jedoch wieder zusätzlichen Pflegeaufwand bedeuten. Es gibt jedoch einen interessanten Ansatz, um auch hier eine zentralisierte Verwaltung solcher Konten zu ermöglichen. Konten werden hierbei im eigenen Entra ID angelegt, über eine Azure Functions App in den anderen Mandanten und von dort in das zugehörige Active Directory synchronisiert.

Einen Artikel, der diesen Ansatz im Detail beschreibt, findest Du hier: Automated Admin User Provisioning in hybrid Multi‑Tenant Environments | LinkedIn

Gefällt Dir der Beitrag? Lass es andere wissen!

• Share on LinkedIn
• Share on Bluesky
• Share on Facebook
• Email this Page
• Share on Reddit