Microsoft-365-Tenant prüfen: Technische Bestandsaufnahme vor Betrieb oder Übernahme

Was muss vor der Übernahme oder Neuordnung eines Microsoft-365-Tenants geprüft werden? Eine belastbare Bestandsaufnahme umfasst mehr als Benutzer und Lizenzen. Sie erfasst verifizierte Domänen, Identitätsquellen, administrative Rollen, Authentifizierung, Conditional Access, Unternehmensanwendungen, externe Zugänge, Microsoft-365-Gruppen, Freigabeeinstellungen, Auditfunktionen und betriebliche Abhängigkeiten. Ziel ist kein möglichst langer Bericht, sondern ein reproduzierbarer Ist-Zustand mit priorisierten Risiken und klaren Maßnahmen.

Ein Tenant kann über Jahre stabil wirken und trotzdem versteckte Abhängigkeiten enthalten: ein nicht dokumentiertes App-Secret, ein ehemaliger Mitarbeiter als alleiniger Eigentümer einer Automatisierung, ein Partner mit delegierten Rechten oder eine Conditional-Access-Ausnahme, deren Zweck niemand mehr kennt. Vor einer Betriebsübernahme müssen solche Punkte sichtbar werden, damit Änderungen nicht unbeabsichtigt produktive Prozesse unterbrechen.

Prüfziel und Umfang zuerst festlegen

Ein Tenant-Check kann unterschiedliche Ziele haben:

• Übernahme des laufenden Betriebs,
• Sicherheitsbewertung,
• Vorbereitung einer Migration oder Konsolidierung,
• Lizenz- und Kostenprüfung,
• Einführung von Governance,
• Aufklärung wiederkehrender Störungen,
• Vorbereitung auf Audit oder Zertifizierung.

Das Ziel bestimmt die Tiefe. Eine vollständige technische Übernahme benötigt Eigentümer, Abhängigkeiten und Rückfallwege. Eine reine Lizenzprüfung kann enger ausfallen. Trotzdem sollte jeder Check dokumentieren, was geprüft, nicht geprüft und nur stichprobenartig bewertet wurde.

Read-only beginnen

Die Bestandsaufnahme sollte zunächst mit lesenden Rollen erfolgen. Global Reader deckt viele Verwaltungsansichten ab, ersetzt aber nicht jede Spezialrolle. Für Service Health, Message Center, Enterprise Applications sowie einzelne Sicherheits- und Compliance-Bereiche können zusätzliche Reader-Rollen nötig sein.

Diese Abweichungen gehören ins Prüfprotokoll. Schreibrechte werden erst vergeben, wenn aus der Analyse eine freigegebene Umsetzung wird; damit sinkt das Risiko, während der Erhebung produktive Einstellungen zu verändern.

1. Tenant-Grunddaten und Domänen

Zu Beginn werden die grundlegenden Identifikatoren dokumentiert:

• Tenant-ID,
• primäre und anfängliche onmicrosoft.com-Domäne,
• verifizierte benutzerdefinierte Domänen,
• Zweck jeder Domäne,
• DNS-Verantwortlicher und Registrar,
• Abhängigkeiten zu Exchange, Teams oder Drittanbietern,
• vorhandene Test- oder Alt-Tenants,
• Datenresidenz- und Organisationsinformationen, soweit relevant.

Fehlerbild: Die DNS-Verantwortung ist unbekannt

Microsoft-365-Dienste können von DNS-Einträgen abhängen. Wenn niemand Zugriff auf Registrar oder DNS-Zone besitzt, werden Änderungen an Mailfluss, Domänenverifizierung oder Sicherheitskonfiguration blockiert. Der Check sollte die Einträge und die administrative Zuständigkeit erfassen.

Test

• Kann eine autorisierte interne Person die DNS-Zone einsehen?
• Sind SPF-, DKIM- und DMARC-nahe Zuständigkeiten geklärt, ohne Werte ungeprüft zu verändern?
• Sind nicht mehr verwendete Domänen noch mit Konten, Gruppen oder Apps verbunden?

2. Identitätsquelle und Benutzerbestand

Zu prüfen ist, wie Benutzer entstehen und aktualisiert werden:

• ausschließlich cloudbasiert,
• synchronisiert aus Active Directory oder einer anderen Quelle,
• automatisiert aus einem HR-System,
• manuell durch Administratoren,
• gemischtes Modell.

Für jede Benutzerkategorie werden Status, Eigentümer und Lebenszyklus betrachtet:

• aktive Mitarbeiter,
• externe Gäste,
• Shared- oder Funktionskonten,
• administrative Konten,
• Servicekonten,
• deaktivierte Benutzer,
• ehemalige Mitarbeiter,
• Testkonten.

Datenfelder, die häufig fehlen

Abteilung, Manager, Mitarbeiter-ID, Eintritts- und Austrittsdatum oder Kontotyp werden für gruppenbasierte Zuweisungen und Lifecycle-Prozesse benötigt. Freitext und uneinheitliche Werte erschweren Automatisierung. Der Check sollte deshalb vorhandene Objekte und Datenqualität bewerten.

Test

Wählen Sie Stichproben aus jeder Benutzerklasse und prüfen Sie:

1. Wer ist fachlicher Eigentümer?
2. Woher stammen die Attribute?
3. Welche Gruppen und Lizenzen werden zugewiesen?
4. Welche Authentifizierungsmethoden sind registriert?
5. Was geschieht bei Austritt oder Wegfall des Zwecks?

3. Administrative Rollen und privilegierte Zugänge

Alle aktiven und – bei Einsatz von PIM – berechtigten Rollenzuweisungen werden erfasst. Besonders relevant sind:

• Global Administrator,
• Privileged Role Administrator,
• Conditional Access Administrator,
• Authentication Administrator und Privileged Authentication Administrator,
• Exchange, SharePoint und Teams Administrator,
• Application Administrator und Cloud Application Administrator,
• Security- und Compliance-Rollen,
• Gruppen- und Benutzeradministration.

Die Bewertung klärt vor allem:

• Warum wird sie benötigt?
• Ist sie dauerhaft aktiv oder nur bei Bedarf?
• Ist das Konto ein separates Administratorkonto?
• Ist starke Authentifizierung eingerichtet?
• Gibt es eine Vertretung?
• Wann wurde der Bedarf zuletzt bestätigt?

Fehlerbild: Unbekannter globaler Administrator

Das Konto kann einem früheren Dienstleister, ehemaligen Mitarbeiter oder Testprojekt gehören. Vor dem Entzug muss geprüft werden, ob Automatisierungen, App-Objekte oder Wiederherstellungsprozesse davon abhängen. Danach wird der Zugriff kontrolliert entfernt und das Ergebnis in Anmelde- und Auditprotokollen verifiziert.

4. Authentifizierungsmethoden, MFA und SSPR

Der Check erfasst nicht nur, ob MFA „aktiv“ ist. Relevant sind:

• welche Methoden zugelassen sind,
• für welche Gruppen sie gelten,
• ob Conditional Access oder andere Mechanismen MFA erzwingen,
• ob Self-Service Password Reset konfiguriert ist,
• wie neue Benutzer ihre erste starke Methode registrieren,
• wie der Helpdesk bei Geräteverlust vorgeht,
• ob Temporary Access Pass kontrolliert eingesetzt wird,
• ob privilegierte Konten phishingresistente Methoden nutzen.

Fehlerbild: Benutzer kann nach Smartphone-Wechsel nicht mehr anmelden

Ein sicherer Wiederherstellungsprozess benötigt Identitätsprüfung, berechtigte Helpdesk-Rollen und eine dokumentierte Methode, etwa das Zurücksetzen vorhandener Registrierungen oder einen zeitlich begrenzten Temporary Access Pass. Ein improvisiertes Entfernen sämtlicher Sicherheitsanforderungen ist kein geeigneter Rückfallweg.

5. Conditional Access

Alle Richtlinien werden mit folgenden Merkmalen exportiert oder dokumentiert:

• Name und fachlicher Zweck,
• Status: aus, Report-only oder aktiv,
• Zielbenutzer und Gruppen,
• ausgeschlossene Identitäten,
• Zielressourcen,
• Bedingungen wie Standort, Plattform oder Client-App,
• Grant- und Session Controls,
• Abhängigkeit zu Geräteverwaltung oder Authentifizierungsstärke,
• Eigentümer und letztes Review-Datum.

Mehrere zutreffende Richtlinien werden gemeinsam ausgewertet. Daher ist eine Einzelbetrachtung unzureichend. Der What-If-Test und reale Anmeldeprotokolle helfen, die kombinierte Wirkung zu verstehen.

Kritischer Test

• Funktionieren Emergency-Access-Konten?
• Werden alte Authentifizierungsprotokolle angemessen behandelt?
• Sind Servicekonten oder Geräte mit Sonderanforderungen sauber dokumentiert?
• Gibt es breite Ausschlussgruppen, die die Richtlinienwirkung unterlaufen?

6. Enterprise Applications und App Registrations

Der Tenant-Check erfasst:

• alle relevanten Service Principals unter Enterprise Applications,
• eigene App Registrations,
• delegierte und Application Permissions,
• Admin Consent,
• Benutzer- und Gruppenzuweisungen,
• Single-Sign-on-Konfiguration,
• App-Eigentümer,
• Zertifikate, Secrets und Ablaufdaten,
• letzte Anmelde- oder Nutzungsindikatoren,
• Publisher- und Herstellerinformationen.

Fehlerbild: App ohne Eigentümer

Eine technisch funktionierende Anwendung kann geschäftskritisch sein, obwohl niemand die Verantwortung trägt. Vor Änderungen muss über Anmeldeprotokolle, Zielsysteme, Quellcode-Repositories, Automatisierungen und Fachbereiche ermittelt werden, wofür sie verwendet wird.

Der Unterschied zwischen App-Registrierung und Service Principal wird im Beitrag Enterprise Applications und App Registrations unterscheiden vertieft.

7. Gruppen, Teams und SharePoint-Strukturen

Microsoft-365-Gruppen verbinden häufig Teams, SharePoint, Exchange und weitere Dienste. Daher werden nicht nur sichtbare Teams gezählt. Zu prüfen sind:

• Gruppen- und Team-Eigentümer,
• Gruppen ohne Eigentümer,
• private und freigegebene Kanäle,
• externe Mitglieder,
• archivierte oder inaktive Teams,
• SharePoint-Sites ohne klaren Zweck,
• Freigabeeinstellungen auf Tenant- und Site-Ebene,
• anonyme beziehungsweise „Anyone“-Links, falls zulässig,
• Sensitivitäts- und Lebenszykluskonzepte,
• Speicher- und Löschabhängigkeiten.

Test

Wählen Sie eine typische Projektgruppe und verfolgen Sie den gesamten Zugriffspfad: Identität → Gruppenmitgliedschaft → Team → SharePoint-Site → Bibliothek oder Datei. So wird sichtbar, ob Berechtigung über Gruppen, direkte Freigaben oder Links entsteht.

8. Lizenzen und Zuweisungslogik

Die Lizenzprüfung unterscheidet:

• erworbene Produkte,
• zugewiesene Lizenzen,
• gruppenbasierte und direkte Zuweisungen,
• deaktivierte Servicepläne,
• Zuweisungsfehler,
• ungenutzte oder doppelte Zuweisungen,
• Funktionen, die von Premium- oder Governance-Lizenzen abhängen.

Eine ungenutzte Lizenz ist nicht automatisch entbehrlich. Ein Konto kann für Aufbewahrung, Postfachzugriff oder Übergangsprozesse benötigt werden. Vor Entzug sind technische und rechtliche Folgen zu prüfen.

9. Protokollierung, Audit und Überwachung

Zu prüfen sind:

• Zugriff auf Entra-Anmelde- und Auditprotokolle,
• Aufbewahrungsdauer und Exportanforderungen,
• Diagnostic Settings oder SIEM-Anbindung, sofern vorhanden,
• Service Health und Message Center,
• Alarmierungen für privilegierte Ereignisse,
• Überwachung von App-Credentials,
• dokumentierte Incident- und Eskalationswege.

Microsoft-Entra-Auditprotokolle erfassen Änderungen an Benutzern, Gruppen, Anwendungen und Lizenzen. Anmeldeprotokolle zeigen interaktive und weitere Anmeldearten. Welche Daten wie lange verfügbar sind, hängt von Dienst und Lizenz ab und muss zum Prüfzeitpunkt verifiziert werden.

10. Ergebnis priorisieren

Ein Prüfbericht sollte Befunde nach Risiko und Umsetzbarkeit ordnen. Ein mögliches Schema:

Jeder Befund enthält Beleg, Auswirkung, empfohlene Maßnahme, Abhängigkeiten, verantwortliche Rolle und Rückfallweg.

Rückfallweg bei fehlerhaften Bereinigungen

Eine Bestandsaufnahme erzeugt oft den Wunsch, sofort aufzuräumen. Genau dabei entstehen Ausfälle. Vor dem Löschen oder Entziehen sollte unterschieden werden:

• deaktivieren oder blockieren als reversible Vorstufe,
• Zuweisung entfernen statt Objekt sofort löschen,
• Credential parallel rotieren statt altes sofort entfernen,
• Report-only oder Pilotgruppe statt tenantweiter Aktivierung,
• Eigentümer ergänzen bevor ehemaliges Konto entfernt wird.

Der Rückfallplan dokumentiert den alten Zustand und die maximale Zeit, in der eine Wiederherstellung sinnvoll möglich ist.

Abnahmetests nach der Bestandsaufnahme

Der Check ist abgeschlossen, wenn Daten gesammelt und kritische Annahmen getestet wurden:

1. Interne Administratoren können den Tenant unabhängig erreichen.
2. Notfallzugang funktioniert und löst Monitoring aus.
3. Für kritische Apps existieren Eigentümer und Ablaufdaten.
4. Eine typische Benutzeranlage und ein Austritt sind nachvollziehbar.
5. Externer Zugriff kann von Identität bis Ressource verfolgt werden.
6. Änderungen werden in Auditprotokollen gefunden.
7. Lizenzzuweisungsfehler sind identifiziert.
8. Dienstmeldungen erreichen zuständige Personen.
9. Kritische Maßnahmen sind priorisiert und nicht nur aufgelistet.
10. Der Ist-Zustand ist so dokumentiert, dass eine zweite Person ihn reproduzieren kann.

Für Folgeschritte aus der Bestandsaufnahme sind drei Vertiefungen besonders hilfreich: Das Betriebsmodell für Microsoft-365-Administration ordnet Verantwortlichkeiten und laufende Verwaltung ein, Conditional Access sicher einführen vertieft Zugriffsregeln und das Microsoft-365-Notfallkonto sichert den Rückfallweg.

So wird aus dem Tenant-Check ein belastbarer Verwaltungsplan

Eine gute Tenant-Prüfung verbindet technische Inventarisierung mit Eigentum, Risiko und Betriebsfähigkeit. Sie zeigt, welche Objekte existieren, warum sie benötigt werden, wer sie verantwortet, wie sie überwacht werden und wie Änderungen sicher zurückgenommen werden können. Erst diese Verknüpfung macht die Bestandsaufnahme zu einer Grundlage für sicheren Eigenbetrieb oder eine kontrollierte Betriebsübernahme.