← Microsoft 365 Collaboration Administration

Rolle, Zugriff, Ort: die Verwaltungsebene

Eine Kollegin mit der Rolle SharePoint Administrator soll eine offenliegende Gehaltsliste prüfen. Sie sieht die Site im Admin Center — und bekommt beim Öffnen Zugriff verweigert. Das ist kein Defekt, sondern eine dokumentierte Trennung: Wer eine Plattform verwalten darf, darf ihre Inhalte noch lange nicht lesen. In diesem Modul zerlegst du das Wort „Administrator“ in drei unabhängige Ebenen — die Entra-Rolle, die den Zugang zu einem Admin Center öffnet, die Site-Berechtigung, die den Inhalt freigibt, und die Ebene, auf der eine Einstellung überhaupt existiert. Du lernst, warum SharePoint Administrator Microsoft-365-Gruppen anlegen, aber deren Exchange-Eigenschaften nicht ändern darf, warum eine Site niemals weiter teilen kann als der Tenant, warum ein Rollenwechsel rund eine Stunde braucht und warum eine Administratoren-Liste aus den Rollenzuweisungen systematisch unvollständig ist.

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

Der Administrator, der die Datei nicht sehen darf

Eine Fachabteilung meldet, in einer Projekt-Site liege eine Gehaltsliste offen. Die Kollegin, die den Fall bearbeitet, trägt die Rolle SharePoint-Administrator — die höchste Rolle, die es für SharePoint und OneDrive gibt. Sie öffnet die Site-URL und bekommt: Zugriff verweigert.

Das ist kein Defekt und kein Rechtefehler. Es ist die dokumentierte Trennung zweier Dinge, die im Alltag beide „Admin-Rechte“ heißen: Wer eine Plattform verwalten darf, darf damit noch lange nicht ihre Inhalte lesen. In der SharePoint-Dokumentation steht der Satz wörtlich — globale Administratoren und SharePoint-Administratoren haben keinen automatischen Zugriff auf alle Sites und auf das OneDrive jedes Nutzers, aber sie können sich diesen Zugriff selbst verschaffen.

LernzielDu kannst für eine Aufgabe drei Fragen getrennt beantworten: welche Rolle sie braucht, welchen Inhaltszugriff sie zusätzlich braucht, und an welchem Ort die Einstellung wirkt, die du ändern willst. Und du kannst begründen, warum das drei Fragen sind und nicht eine.

Tenant — Die eine Verwaltungs- und Identitätsgrenze einer Organisation in Microsoft 365. Was hier Tenant-Ebene heißt, gilt organisationsweit für jede Site, jedes Team und jedes OneDrive darin — auch für die, die es noch nicht gibt.

Drei Ebenen, die ein einziges Wort zusammenwirft

Fast jede Verwirrung in diesem Track lässt sich auf eine von drei Ebenen zurückführen. Sie sind unabhängig voneinander: Man kann jede einzeln haben, und keine zieht die anderen automatisch nach sich.

Verwaltungsrolle: Eine Microsoft-Entra-Rolle wie SharePoint Administrator. Sie öffnet ein Admin Center und erlaubt Einstellungen — Sites anlegen, Sharing-Regeln setzen, Speichergrenzen ändern.
Inhaltszugriff: Eine Berechtigung auf einer konkreten Site, Bibliothek oder Datei. Sie erlaubt, den Inhalt zu sehen und zu ändern. Sie kommt aus der Site, nicht aus der Rolle.
Einstellungsort: Die Ebene, auf der eine Option überhaupt existiert: Tenant, Site, Gruppe oder einzelner Freigabelink. Dieselbe fachliche Frage hat auf verschiedenen Ebenen verschiedene Antworten.

Der Fall aus dem ersten Abschnitt ist Ebene eins ohne Ebene zwei: Verwaltungsrolle vorhanden, Inhaltszugriff nicht. Der umgekehrte Fall ist genauso häufig und fällt seltener auf — jemand verwaltet eine Site vollständig, ohne je eine Microsoft-365-Rolle bekommen zu haben.

Websitesammlungsadministrator — Wer eine einzelne Site vollständig verwaltet: Berechtigungen, Einstellungen, Papierkorb. Laut Dokumentation braucht ein Site-Admin keine Administratorrolle in Microsoft 365 — und hat umgekehrt keinen Zugang zum SharePoint Admin Center.

Die Rollen und was sie wirklich dürfen

Die Rollen, die das Microsoft 365 Admin Center zur Auswahl stellt, sind Microsoft-Entra-Rollen — und zwar nur eine Teilmenge davon; die vollständige Liste führt das Entra Admin Center. Für Collaboration sind sechs davon der Alltag:

Global Administrator: Alle administrativen Funktionen, einschließlich SharePoint Online und Exchange Online. Kann die eigene Zuweisung nicht selbst entziehen — damit nie null globale Administratoren entstehen.
SharePoint Administrator: SharePoint Admin Center: Sites anlegen und löschen, Site-Admins benennen, Sharing-Einstellungen und Speichergrenzen verwalten, Microsoft-365-Gruppen verwalten.
Teams Administrator: Teams Admin Center: Besprechungen, Konferenzbrücken und alle organisationsweiten Einstellungen einschließlich Föderation und Client-Einstellungen.
Groups Administrator: Gruppen über die Admin Center hinweg — anlegen, ändern, löschen, wiederherstellen — plus Erstellungs-, Ablauf- und Namensrichtlinien.
Global Reader: Sieht, was ein globaler Administrator sieht, und kann nichts ändern. Bei über einen Partner erworbenen Abonnements steht die Rolle laut Dokumentation nicht zur Verfügung.
Exchange Administrator: Postfächer, Microsoft-365-Gruppen und Exchange Online. Hier relevant, weil an jeder Microsoft-365-Gruppe ein Postfach hängt.

Die interessante Grenze liegt nicht bei den Sites, sondern bei den Gruppen. SharePoint Administrator und Teams Administrator dürfen Microsoft-365-Gruppen anlegen, lesen, ändern und löschen — aber ihre Exchange-Online-Eigenschaften nicht ändern. Sicherheitsgruppen dürfen sie nur verwalten, wenn sie selbst deren Besitzer sind. Verteilergruppen und E-Mail-aktivierte Sicherheitsgruppen dürfen sie ausschließlich lesen.

Warum das im Betrieb wehtutEine Anfrage wie „bitte den Anzeigenamen dieser Gruppe korrigieren“ landet je nach betroffenem Attribut bei verschiedenen Rollen. Wer die Rollennamen kennt, aber nicht diese Kanten, sagt Termine zu, die er nicht halten kann.

Was keine Rolle mitliefert: Zugriff auf den Inhalt

Der Satz aus der SharePoint-Dokumentation ist die wichtigste Einzelaussage dieses Moduls, und er hat zwei Hälften. Die erste: kein automatischer Zugriff auf Sites und OneDrives. Die zweite: die Administratoren können sich den Zugriff selbst geben.

Die Trennung ist keine Sicherheitsgarantie — ein SharePoint-Administrator kommt an jeden Inhalt, wenn er will.
Sie ist eine Spur: Der Selbstzugriff ist ein eigener, protokollierter Vorgang statt eines stillen Dauerrechts.
Die richtige Reaktion auf „ich komme nicht rein“ ist deshalb nicht, die Rolle zu erhöhen, sondern den Zugriff fallbezogen und nachvollziehbar zu setzen.
Und eine Kontrolle, die sich darauf stützt, dass Administratoren die Daten ohnehin nicht sehen, ist falsch begründet.

In der Gegenrichtung gilt dasselbe mit umgekehrtem Vorzeichen: Ein Site-Admin führt die Berechtigungen einer Site vollständig, taucht aber in keiner Rollenliste des Microsoft 365 Admin Center auf. Wer Administratoren über die Rollenzuweisungen inventarisiert, übersieht diese Gruppe komplett — und in gewachsenen Tenants ist sie die größere.

Getrennt davon: der Term StoreInnerhalb von SharePoint gibt es mit dem Term Store Administrator eine weitere Rolle, die außerhalb des Rollenmodells des Admin Center liegt. Wer Begriffe im Termspeicher pflegt, braucht sie — und sonst nichts.

Die Administratoren-Inventur ist unvollständig

Die Frage „wer hat bei uns eigentlich administrative Rechte?“ wird meistens über die Rollenzuweisungen im Microsoft 365 Admin Center beantwortet. Diese Liste ist nützlich und sie ist unvollständig, und zwar systematisch: Mindestens drei Gruppen mit erheblicher Wirkung stehen nicht darin.

Site-Admins: führen eine Site vollständig, brauchen dafür laut Dokumentation keine Microsoft-365-Rolle und erscheinen folglich in keiner Rollenliste. Sie sind nur im SharePoint Admin Center je Site sichtbar.
Gruppen- und Teambesitzer: entscheiden über Mitgliedschaft und damit über den Zugriff auf alles, was an der Gruppe hängt — Site, Postfach, Team.
Delegierte Partner-Administratoren: Ein autorisierter Microsoft-Partner kann die Rolle Admin Agent vergeben, die laut Dokumentation den Rechten eines globalen Administrators entspricht — mit Ausnahme der MFA-Verwaltung über das Partner Center.

Wer den administrativen Zugriff eines Tenants beurteilen soll, muss diese drei Quellen also einzeln erheben. Eine Zahl wie „wir haben vier Administratoren“ ist aus der Rollenliste allein nie belegbar.

Der Ausweg aus der eigenen AussperrungDie Empfehlung, möglichst wenige globale Administratoren zu haben, hat eine dokumentierte Kehrseite: Sperrt sich ein globaler Administrator selbst aus, kann sein Kennwort nur ein anderer globaler Administrator oder ein Privileged Authentication Administrator zurücksetzen. Wer die Zahl der globalen Administratoren senkt, ohne diese zweite Rolle zu besetzen, spart genau so lange, bis es einmal klemmt.

Eine verwandte Kante trifft den Helpdesk: Die Rolle Helpdesk Administrator darf laut Dokumentation nur Nutzern helfen, die selbst keine Administratoren sind — abgesehen von einer kurzen Liste harmloser Leserollen. Ein Kennwortzurücksetzen für den Kollegen mit Teams Administrator scheitert also nicht an einem Fehler, sondern an der Rollendefinition.

Vier Admin Center, und welches was führt

Es gibt keinen Ort, an dem alle Collaboration-Einstellungen stehen. Welche Oberfläche eine Einstellung führt, folgt dem Dienst, der sie durchsetzt — nicht dem Thema, unter dem man sie sucht.

Microsoft 365 Admin Center: Nutzer, Lizenzen, Rollenzuweisungen, Gruppen, Message Center und Dienstzustand. Führt Entra- und Intune-Rollen, aber nur eine Teilmenge der jeweils verfügbaren.
SharePoint Admin Center: Sites und deren Einstellungen, Site-Admins, organisationsweite Sharing-Regeln, Speichergrenzen, OneDrive-Einstellungen.
Teams Admin Center: Teams-Richtlinien, Besprechungen, Konferenzbrücken, Föderation und Client-Einstellungen.
Microsoft Purview: Aufbewahrung, Vertraulichkeitsbezeichnungen, DLP, eDiscovery und das einheitliche Überwachungsprotokoll.

Eine Frage wie „dürfen unsere Leute Dateien nach außen teilen?“ berührt drei dieser vier Oberflächen: die Sharing-Stufe im SharePoint Admin Center, die Gastzugriffs-Einstellung für Teams im Teams Admin Center und die Einladungsregeln für Gäste in Entra. Dass die Antwort an einer Stelle Ja lauten kann und der Effekt trotzdem ausbleibt, ist bei diesem Thema die Normalform, nicht die Ausnahme.

Sonderfall API-ZugriffFür die Verwaltung des API-Zugriffs im SharePoint Admin Center reicht die SharePoint-Rolle nicht; dafür ist laut Dokumentation mindestens die Rolle Application Administrator nötig. Eine Oberfläche, zwei Rollenanforderungen.

PowerShell: zweite Oberfläche, nicht zweite Wahrheit

Jede Einstellung, die eine Oberfläche zeigt, liegt im Dienst — nicht in der Oberfläche. PowerShell greift auf denselben Dienst zu und zeigt häufig mehr Felder, weil dort nichts weggelassen wurde, um eine Seite ruhig zu halten. Drei Module decken den Collaboration-Alltag ab:

Microsoft.Online.SharePoint.PowerShell — Einstieg mit Connect-SPOService -Url https://contoso-admin.sharepoint.com. Die Admin-URL trägt den Tenantnamen plus -admin; die normale Site-URL funktioniert hier nicht.
MicrosoftTeams — Einstieg mit Connect-MicrosoftTeams. Ohne Parameter meldet sich die Sitzung am Heimat-Tenant an; -TenantId wird nötig, sobald man als Dienstprinzipal oder mit einem Microsoft-Konto arbeitet.
Microsoft.Graph — für alles, was quer über Gruppen, Nutzer und Mitgliedschaften geht, und für Auswertungen, die keine der Oberflächen anbietet.

Eine Verbindung je SitzungConnect-SPOService erlaubt laut Dokumentation eine SharePoint-Verbindung pro PowerShell-Sitzung und Geo. Ein zweiter Aufruf trennt die bestehende Verbindung und ersetzt sie. Ein Skript, das zwischen zwei Tenants hin- und herschaltet, arbeitet danach im falschen — ohne Fehlermeldung.

Das ist der Grund, aus dem Massenänderungen über PowerShell zuerst lesend laufen sollten. Ein Get- mit genau dem Filter, mit dem hinterher das Set- läuft, beantwortet die einzige Frage, die vor einer Änderung zählt: Welche Objekte trifft sie wirklich?

Durchgerechnet: eine Anforderung, drei Entscheidungen

Das Projektbüro soll eigene Sites anlegen dürfen

Szenario

Das Projektbüro soll künftig selbst Projekt-Sites anlegen und die Berechtigungen darin führen. Eine Kollegin übernimmt das. Die naheliegende Umsetzung — Global Administrator — wäre die teuerste, und schneller ist sie auch nicht.

Anforderungen

Sites anlegen und wieder löschen können
In den angelegten Sites Berechtigungen und Besitz führen können
Keinen Zugriff auf Sites anderer Abteilungen erhalten
Die Einrichtung muss nachvollziehbar dokumentiert sein

Schritte

Ebene eins, Verwaltungsrolle: SharePoint Administrator deckt Anlegen und Löschen ab. Diese Rolle wird zugewiesen, nicht Global Administrator.
Prüfen, was die Rolle mitbringt: Zugang zum SharePoint Admin Center und damit Sicht auf alle Sites der Organisation — auch die der anderen Abteilungen. Die dritte Anforderung ist auf Rollenebene damit nicht erfüllbar.
Die Konsequenz benennen statt sie zu umgehen: Wer Sites organisationsweit anlegen darf, sieht sie organisationsweit. Ist das nicht gewollt, ist die Rolle falsch und die Anforderung braucht ein Bestellverfahren, das Sites zentral erzeugt.
Ebene zwei, Inhaltszugriff: Für die Projekt-Sites wird die Kollegin als Site-Admin eingetragen. Das ist der Zugriff, der ihre eigentliche Arbeit trägt, und er ist site-genau.
Ebene drei, Einstellungsort: Die Sharing-Stufe der neuen Sites folgt der Tenant-Einstellung und lässt sich je Site nur enger setzen. Was das Projektbüro an Freigaben braucht, muss also zur Tenant-Stufe passen — sonst ist es keine Site-Frage.
Warten: Eine Rollenänderung, die Zugang zum SharePoint Admin Center gibt oder nimmt, wird laut Dokumentation erst nach etwa einer Stunde wirksam. Der Termin für die Einweisung liegt danach.

Merksatz: Die Rolle beantwortet nur die erste der drei Fragen. Die zweite löst ein Site-Eintrag, die dritte eine Tenant-Entscheidung — und eine der vier Anforderungen ließ sich mit keiner davon erfüllen. Das ist ein Ergebnis, kein Scheitern.

Zwischenstand

Kurzcheck

Ein Kollege hat die Rolle Global Reader. Er soll nachsehen, ob die organisationsweite Sharing-Stufe auf „Only people in your organization“ steht, und das Ergebnis melden. Reicht seine Rolle?

Ja — die Rolle sieht dieselben Einstellungen wie ein globaler Administrator und darf sie nur nicht ändern.
Nein — Sharing-Einstellungen liegen im SharePoint Admin Center, das nur die SharePoint-Rolle öffnet.
Nein — zum Lesen der Einstellung braucht er zusätzlich Zugriff auf mindestens eine Site.

Treffer. Richtig. Global Reader ist genau für diesen Fall gedacht: nachsehen und berichten, ohne Schreibrecht. Nur bei über einen Partner erworbenen Abonnements steht die Rolle nicht zur Verfügung.

Wo eine Einstellung wirkt: die Kette nach unten

Die externe Freigabe ist das Musterbeispiel für die dritte Ebene, weil sie auf mehreren Stufen gleichzeitig existiert. Organisationsweit stehen vier Stufen zur Wahl:

Anyone: Freigabe über Links, die jeder ohne Anmeldung öffnen kann. Diese Links lassen sich auf ein Ablaufdatum und auf reines Lesen begrenzen.
New and existing guests: Empfänger müssen sich mit Arbeits-, Schul- oder Microsoft-Konto anmelden oder ihre Identität über einen zugesandten Code bestätigen.
Existing guests: Freigabe nur an Gäste, die bereits im Verzeichnis stehen — etwa aus früheren Einladungen.
Only people in your organization: Externe Freigabe ist aus.

Entscheidend ist die Richtung: Jede Site hat ihre eigene Sharing-Einstellung, sie muss aber laut Dokumentation gleich oder restriktiver sein als die der Organisation. Dieselbe Regel gilt für OneDrive gegenüber SharePoint — enger ja, weiter nein. Eine Site kann sich also nie mehr erlauben als der Tenant.

Daraus folgt die Diagnose-Reihenfolge, und sie läuft der Intuition entgegen. Wenn eine Freigabe nicht funktioniert, ist die Site selten die Ursache: Die Kette wird von oben geprüft, Tenant, dann Site, dann der einzelne Link. Wenn eine Freigabe zu weit geht, wird von unten geprüft — dort ist sie entstanden.

Der stille RückfallSteht die organisationsweite Voreinstellung für Links auf Anyone with the link, die betroffene Site aber auf eine Stufe, die Anmeldung verlangt, fällt der vorgeschlagene Link laut Dokumentation auf Only people in your organization zurück. Der Nutzer sieht keinen Fehler — nur einen anderen Link als erwartet, und sein externer Partner bekommt nichts.

Was nicht sofort wirkt

Drei Verzögerungen in diesem Bereich sind dokumentiert und erzeugen regelmäßig Fehlmeldungen, weil man ihnen nicht ansieht, ob etwas falsch konfiguriert oder nur noch nicht durch ist:

Rollenwechsel: Gewinnt oder verliert jemand den Zugang zum SharePoint Admin Center, dauert es laut Dokumentation etwa eine Stunde, bis die Änderung greift.
Entzug externer Freigabe: Wird externe Freigabe eingeschränkt oder abgeschaltet, verlieren Gäste ihren Zugriff typischerweise innerhalb einer Stunde — nicht sofort.
Ablauffristen für Anyone-Links: Wird die maximale Gültigkeit geändert, behalten bestehende Links ihre alte Frist, wenn die neue länger ist, und übernehmen die neue, wenn sie kürzer ist.

Und eine Falle, die keine Verzögerung istWer externe Freigabe organisationsweit abschaltet und später wieder einschaltet, gibt den Gästen damit laut Dokumentation ihren Zugriff zurück. Das Abschalten löscht nichts; es blendet aus. Wer bestimmten Gästen den Zugriff dauerhaft nehmen will, muss das an den betroffenen Sites tun, bevor er organisationsweit schaltet.

Der Preis und die Route

Die enge Rolle ist die richtige Wahl, und sie ist nicht kostenlos. Vier Rollen statt einer heißt: vier Zuweisungen zu pflegen, vier Wege bei Urlaub und Ausscheiden, und regelmäßig die Rückfrage, warum jemand etwas plötzlich nicht mehr darf. Eine Organisation, die das nicht leisten will, bekommt keine bequeme Alternative, sondern nur eine unehrliche — mehr globale Administratoren, als sie verantworten kann.

Der Gegenwert ist der Radius im Schadensfall. Ein übernommenes Konto mit SharePoint Administrator kostet Sites; eines mit Global Administrator kostet den Tenant. Und weil ein globaler Administrator die eigene Zuweisung nicht entziehen kann, hängt die Bereinigung im Ernstfall an einem zweiten Konto, das es dann geben muss.

Aufgabe benennen — nicht die Person, nicht das Portal→Ebene eins: kleinste Rolle, die die Aufgabe trägt→Ebene zwei: Inhaltszugriff fallbezogen und site-genau setzen→Ebene drei: Einstellungsort bestimmen — Tenant, Site oder Link→Wirkung am Zielobjekt prüfen, nicht in der Oberfläche, die sie gesetzt hat

Rolle, Zugriff, Ort

Diese Reihenfolge trägt durch den ganzen Track. Die nächsten Module füllen sie: Gruppen liefern das Objekt, an dem Mitgliedschaft und Besitz hängen, Teams und SharePoint die Oberflächen darauf, und die Berechtigungs- und Sharing-Module arbeiten dieselbe Kette weiter nach unten ab.

Jetzt anwenden

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

Zum Modul →

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