← Microsoft 365 Collaboration Administration

Berechtigungen: fünf Ebenen, vier Quellen

In einer Bibliothek mit 400 Dateien fällt genau eine aus der Reihe: Jemand aus einer anderen Abteilung kommt heran. Kein Administrator hat etwas vergeben — ein Kollege hat die Datei geteilt, und SharePoint hat dabei die Vererbung an diesem Dokument automatisch beendet. Die wirksamste Berechtigungsänderung im System braucht keine Rolle, sondern einen Freigabeknopf. In diesem Modul lernst du die fünf Geltungsbereiche von der Websitesammlung bis zum einzelnen Element kennen und die vier Quellen, aus denen Zugriff entsteht. Du lernst, warum die Gruppe Mitglieder mit Edit auch Bibliotheken löschen darf, warum Limited Access wie ein Zugriff aussieht und keiner ist, warum View Only ausgerechnet Videos und .png-Dateien nicht vor dem Herunterladen schützt und warum auf einer öffentlichen Team-Site die ganze Organisation schreiben darf, ohne dass ein einziger Name in der Mitgliederliste steht.

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

Die Datei, die aus der Reihe tanzt

In einer Bibliothek liegen 400 Dateien. Für 399 gilt: Wer im Team ist, darf lesen und schreiben; sonst niemand. Eine Datei fällt aus der Reihe — eine Person aus einer anderen Abteilung kommt heran. Niemand hat die Bibliothek angefasst, kein Administrator etwas vergeben, und im Änderungsprotokoll der Site steht nichts Auffälliges.

Der Vorgang ist dokumentiert und völlig alltäglich: Ein Benutzer kann die Vererbung für ein einzelnes Element unterbrechen, indem er ein Dokument mit jemandem teilt, der keinen Zugriff hat — SharePoint beendet die Vererbung an diesem Dokument dann automatisch. Die wirksamste Berechtigungsänderung im System braucht keine Administratorrolle. Sie braucht einen Freigabeknopf.

LernzielDu kannst zu einer Datei sagen, auf welchem Geltungsbereich ihre Berechtigung entsteht, aus welcher der vier möglichen Quellen sie stammt und was eine gebrochene Vererbung für alles Weitere bedeutet. Und du kennst die Stufen, die anders wirken, als ihr Name verspricht.

Geltungsbereich — Die Ebene, auf der eine Berechtigung gesetzt ist. SharePoint kennt sie vom Weitesten zum Engsten: Websitesammlung, Site, Untersite, Liste oder Bibliothek, und schließlich das einzelne Element. Jede Ebene erbt standardmäßig von der darüber.

Vererbung ist der Normalzustand

Laut Dokumentation erben alle Sites und Inhalte einer Sammlung die Einstellungen der obersten Site. Das ist kein Vorschlag, sondern der Auslieferungszustand — und solange er gilt, ist eine Berechtigungsfrage an genau einer Stelle zu beantworten.

Websitesammlung: Ein Websitesammlungsadministrator legt die Berechtigungen der obersten Site für die gesamte Sammlung fest.
Site: Ein Site-Besitzer kann die Einstellungen der Site ändern — und beendet damit deren Vererbung.
Liste oder Bibliothek: Erbt von ihrer Site. Ein Site-Besitzer kann die Vererbung beenden und eigene Berechtigungen setzen.
Element oder Datei: Erbt von seiner Liste. Wer die Liste kontrolliert, kann die Vererbung beenden und direkt am Element berechtigen.

Ein Bruch ist nie rückwirkend und nie automatisch reparierend. Ab dem Moment des Bruchs führt das Objekt eine eigene Berechtigungsliste. Änderungen weiter oben erreichen es nicht mehr — auch die nicht, die jemand in drei Jahren für selbstverständlich hält, weil sie überall sonst greifen.

Der leiseste der vier WegeDrei der vier Wege in den Bruch gehen über eine bewusste Entscheidung an Site, Liste oder Element. Der vierte ist eine Freigabe durch einen Endnutzer. Nur dieser vierte hinterlässt keinen Vorgang, der wie eine Berechtigungsänderung aussieht — und er ist der mit Abstand häufigste.

Die Stufen und was sie wirklich erlauben

Eine Berechtigungsstufe bündelt Einzelrechte. Die Standardstufen decken laut Dokumentation die üblichen Fälle ab; feinere Abstufungen sind möglich, aber selten eine gute Idee.

Full Control: Enthält alle verfügbaren SharePoint-Berechtigungen. Standard der Gruppe Besitzer. Nicht anpassbar und nicht löschbar.
Edit: Elemente und Dokumente anzeigen, hinzufügen, aktualisieren und löschen — und Listen hinzufügen, bearbeiten und löschen. Standard der Gruppe Mitglieder.
Contribute: Elemente und Dokumente anzeigen, hinzufügen, aktualisieren und löschen. Ohne das Recht an den Listen selbst.
Read: Seiten und Elemente ansehen und Dokumente herunterladen. Standard der Gruppe Besucher.
Restricted Read: Seiten und Dokumente ansehen, aber keine früheren Versionen und keine Berechtigungen.
View Only: Ansehen ohne Herunterladen — mit einer wichtigen Einschränkung, siehe unten.

Der Unterschied zwischen Edit und Contribute ist die folgenreichste Zeile dieser Tabelle. Die Gruppe Mitglieder bekommt standardmäßig Edit — und damit das Recht, Listen und Bibliotheken zu löschen, nicht nur deren Inhalt. Wer das nicht will, muss die Stufe der Mitgliedergruppe bewusst auf Contribute senken; von selbst passiert das nicht.

Was sich ändern lässt und was nichtLaut Dokumentation lässt sich jede Standardstufe anpassen — außer `Full Control` und `Limited Access`. Wer eine abgewandelte Vollzugriffsstufe braucht, legt eine neue an, statt die vorhandene zu verbiegen.

Limited Access: die Stufe, die nichts gewährt

In der Berechtigungsansicht einer Site taucht regelmäßig eine Stufe auf, die niemand vergeben hat: Limited Access. Sie sieht aus wie ein Zugriff und ist keiner.

Laut Dokumentation vergibt SharePoint sie automatisch, sobald jemand Zugriff auf ein einzelnes Element bekommt. Damit die Oberfläche überhaupt darstellbar ist, braucht die Person ein Minimum an den übergeordneten Containern — Site und Bibliothek. Genau das ist Limited Access. Direkt zuweisen lässt sie sich nicht, und sie gewährt keine zusätzlichen Rechte: Kein anderer Inhalt wird dadurch sichtbar.

Ein Eintrag mit Limited Access auf einer Site ist ein Hinweis, kein Befund: Irgendwo darunter ist etwas einzeln freigegeben worden.
Er beantwortet nicht, was freigegeben wurde — dafür muss man die Ebene darunter aufsuchen.
Ihn zu entfernen, um aufzuräumen, nimmt der Person den Weg zu dem Element, das sie legitim sehen darf.
Web-Only Limited Access ist eine Variante davon, die den Zugriff auf das Web-Objekt beschränkt.

SperrmodusDer Limited-Access-Sperrmodus ist ein Feature der Websitesammlung, das die Feinrechte dieser Stufe weiter reduziert — etwa View Application Pages und Use Remote Interfaces. Für Veröffentlichungssites ist er laut Dokumentation standardmäßig an und gilt als empfohlene Konfiguration, wo höhere Sicherheit gefordert ist.

Zwischenstand

Kurzcheck

In der Berechtigungsansicht einer Projekt-Site steht eine Person aus der Buchhaltung mit der Stufe Limited Access. Was weißt du damit?

Dass ihr unterhalb der Site etwas einzeln freigegeben wurde — aber nicht, was.
Dass sie eingeschränkten Lesezugriff auf die Inhalte der gesamten Site hat.
Dass jemand ihr diese Stufe bewusst zugewiesen hat und sie zurückgenommen werden sollte.

Treffer. Richtig. Die Stufe wird automatisch gesetzt, damit ein einzeln freigegebenes Element erreichbar ist. Was es ist, steht eine Ebene tiefer.

Vier Quellen, aus denen Zugriff kommt

Die Frage „wer darf das sehen?“ ist erst beantwortet, wenn alle vier Quellen geprüft sind. Sie sind unabhängig voneinander und werden an verschiedenen Orten gepflegt.

Microsoft-365-Gruppe: Bei gruppenverbundenen Team-Sites: Gruppenbesitzer werden Site-Besitzer, Gruppenmitglieder werden Site-Mitglieder. Gepflegt in der Gruppe oder in Teams.
SharePoint-Gruppe: Besitzer, Mitglieder, Besucher der Site. Bei Kommunikations-Sites die einzige Quelle; bei Team-Sites zusätzlich möglich.
Direktvergabe: Eine Person oder Sicherheitsgruppe direkt am Objekt berechtigt — Site, Bibliothek oder Element.
Freigabelink: Ein Link auf Datei oder Ordner. Erzeugt bei Bedarf einen Vererbungsbruch am Element.

Zwischen den ersten beiden Quellen liegt eine dokumentierte Asymmetrie, die im Alltag regelmäßig überrascht: Wer direkt zur Site hinzugefügt wird, bekommt keinen Zugriff auf die übrigen Dienste der Gruppe — kein Postfach, keinen Planner, kein Team. Die Gruppenmitgliedschaft öffnet alles, die Site-Mitgliedschaft nur die Site.

Warum Besucher trotzdem direkt eingetragen werdenMicrosoft-365-Gruppen kennen laut Dokumentation keinen reinen Lesezugriff. Wer jemandem nur Leserechte auf die Site geben will, muss ihn direkt in die Gruppe Besucher der Site eintragen. Der einzige saubere Weg für Lesezugriff ist also genau der Weg, der an der Gruppe vorbeiführt.

Wer überhaupt berechtigen darf

Bevor man fragt, woher ein Zugriff kam, lohnt die Frage, wer ihn überhaupt hätte vergeben können. Die Antwort ist in SharePoint breiter, als die meisten Organisationen annehmen.

Das Einzelrecht Manage Permissions — Berechtigungsstufen anlegen und ändern, Rechte an Benutzer und Gruppen vergeben — steckt laut Dokumentation nur in Full Control und Manage Hierarchy. Das klingt nach einer engen Gruppe. Direkt daneben steht aber der Satz, dass standardmäßig Site-Besitzer und Site-Mitglieder neue Benutzer zur Site hinzufügen können. Mitglieder brauchen also gar kein Manage Permissions, um den Kreis zu erweitern.

Jedes Teammitglied kann damit im Normalfall neue Personen auf die Site holen — das ist gewollt und der Grund, warum Zusammenarbeit ohne Ticket funktioniert.
Jede Person mit Schreibrecht kann eine einzelne Datei teilen und dabei einen Vererbungsbruch erzeugen.
Websitesammlungsadministratoren stehen über all dem; die Gruppe Unternehmensadministratoren wird ihnen automatisch hinzugefügt.
Bei Kanal-Sites entfällt diese Freiheit: Dort ist die Kanalmitgliedschaft die einzige Quelle, und SharePoint zeigt die Rechte nur lesend an.

Eine Ausnahme lohnt die Erwähnung, weil sie das Muster durchbricht: Wer Sites an eine Hub-Site anbinden darf, legt laut Dokumentation der SharePoint-Administrator im Admin Center fest — und Site-Besitzer können das nicht ändern. Das ist eine der wenigen Stellen, an der eine Entscheidung bewusst oberhalb der Site verankert ist.

Die Konsequenz für ZugriffsprüfungenWenn Mitglieder berechtigen dürfen, ist die Berechtigungslage einer Site kein Zustand, den jemand einmal gesetzt hat, sondern ein Ergebnis vieler kleiner Alltagsentscheidungen. Eine Prüfung, die nach dem „Verantwortlichen für diese Freigabe“ sucht, sucht meistens vergeblich — und die richtige Frage ist, ob das Ergebnis heute noch passt.

Wo die Quellen nicht wählbar sind

Welche der vier Quellen überhaupt infrage kommen, hängt vom Typ der Site ab. Das ist keine Empfehlung, sondern teilweise erzwungen.

Gruppenverbundene Team-Site: Über die Microsoft-365-Gruppe führen. Getrennte Verwaltung über SharePoint-Gruppen ist möglich, wird aber ausdrücklich nicht empfohlen.
Kanal-Site (privat oder geteilt): Die Verwaltung muss in Teams erfolgen. Kanalbesitzer werden Site-Besitzer, Kanalmitglieder Site-Mitglieder; SharePoint zeigt die Rechte nur lesend an.
Kommunikations-Site: Nicht mit einer Microsoft-365-Gruppe verbunden. Es gelten die SharePoint-Gruppen Besitzer, Mitglieder und Besucher.
Hub-Site: Richtet sich nach dem darunterliegenden Typ. Wer Sites an den Hub anbinden darf, legt der SharePoint-Administrator fest — Site-Besitzer können das nicht ändern.

Für Kommunikations-Sites gilt die klassische Aufteilung: wenige Besitzer, eine überschaubare Zahl von Mitgliedern, die Inhalte erstellen, und viele Besucher. Für die Besuchergruppe empfiehlt die Dokumentation Sicherheitsgruppen — mit der Einschränkung, dass geschachtelte Sicherheitsgruppen Leistungsprobleme verursachen können und nicht empfohlen sind.

Zwei Gruppen, die niemand angelegt hat

In jedem Tenant existieren zwei Sicherheitsgruppen, die Microsoft 365 selbst erzeugt und die in Berechtigungslisten auftauchen, ohne dass jemand sie dort eingetragen hätte.

Jeder außer externen Benutzern enthält jede Person im Verzeichnis mit Ausnahme derer, die ausdrücklich als externe Benutzer angelegt wurden.
Unternehmensadministratoren enthält die Microsoft-365-Administratoren und wird der Gruppe der Websitesammlungsadministratoren hinzugefügt.

Die erste ist die wichtigere, und ihre Wirkung hängt am Datenschutzgrad der Site. Bei modernen Team-Sites mit dem Datenschutzgrad Öffentlich wird sie laut Dokumentation automatisch der Mitgliedergruppe hinzugefügt, damit alle Nutzer die Site erreichen und bearbeiten können. Bei Team-Sites mit dem Grad Privat kann ihr dagegen überhaupt keine Berechtigung erteilt werden — dort muss jede Person einzeln berechtigt werden.

Was daraus für eine Prüfung folgtEine öffentliche Team-Site ist nicht „noch nicht berechtigt“, sondern für die gesamte Organisation bearbeitbar — und zwar ohne dass ein einziger Name in der Mitgliederliste steht. Wer Berechtigungen anhand sichtbarer Personen prüft, übersieht bei diesen Sites genau den Fall, der zählt.

Die Grenzen des Leseschutzes

Zwei Stufen versprechen mehr Schutz, als sie halten — und in beiden Fällen ist die Einschränkung dokumentiert, nur wenig bekannt.

View Only soll das Herunterladen verhindern. Laut Dokumentation gilt das für Dokumente mit einem serverseitigen Dateihandler: Sie lassen sich im Browser ansehen, aber nicht herunterladen. Dateitypen ohne solchen Handler — als Beispiele nennt die Dokumentation Videodateien und .png — können weiterhin heruntergeladen werden. Die Stufe schützt also genau die Formate, die sich ohnehin am leichtesten ersetzen lassen, und nicht die Mediendateien, an die man dabei zuerst denkt.

Restricted Read erlaubt Seiten und Dokumente, verwehrt aber frühere Versionen und die Berechtigungsansicht. Das ist nützlich gegen die stille Recherche, wer sonst noch Zugriff hat — es ist kein Schutz gegen das Lesen des aktuellen Inhalts.

Die Abhängigkeitsregel dahinterEinzelrechte hängen voneinander ab: View Items setzt Open voraus, Manage Lists setzt View Items voraus. Laut Dokumentation ist Open das einzige Recht ohne Abhängigkeit — alle anderen setzen es voraus. Wer eine eigene Stufe prüfen will, entfernt Open: Dann fallen automatisch alle übrigen Rechte mit.

Durchgerechnet: warum sieht diese Person die Datei?

Eine Frage, fünf Ebenen, vier Quellen

Szenario

Eine Meldung sagt, eine Kollegin aus dem Einkauf sehe ein Dokument in der Bibliothek Vergabe einer Projekt-Site. Sie ist nicht im Team und steht in keiner Mitgliederliste. Die Frage lautet nicht, wie man ihr den Zugriff nimmt, sondern woher er kommt — sonst nimmt man den falschen weg.

Anforderungen

Die Quelle des Zugriffs benennen, nicht nur seine Existenz
Feststellen, ob weitere Personen auf demselben Weg Zugriff haben
Die Rücknahme so wählen, dass legitime Zugriffe erhalten bleiben

Schritte

Am Element beginnen, nicht an der Site: Erbt die Datei noch von ihrer Bibliothek, oder führt sie eine eigene Berechtigungsliste? Ein Bruch hier erklärt einen Einzelfall, ohne dass oben etwas falsch wäre.
Ist die Vererbung gebrochen, die Ursache benennen: Eine Freigabe durch einen Endnutzer bricht sie laut Dokumentation automatisch. Der Bruch ist dann kein Konfigurationsfehler, sondern das Ergebnis eines Klicks.
Erbt die Datei noch, eine Ebene höher gehen — Bibliothek, dann Site. Eine gebrochene Bibliothek erklärt alle 400 Dateien darin, nicht nur die gemeldete.
Auf Site-Ebene alle vier Quellen prüfen: Microsoft-365-Gruppe, SharePoint-Gruppen, Direktvergaben und bestehende Freigabelinks.
Den Datenschutzgrad der Site prüfen. Ist sie öffentlich, steht Jeder außer externen Benutzern in der Mitgliedergruppe — dann ist der Zugriff organisationsweit und die gemeldete Person nur die erste, die auffiel.
Einträge mit Limited Access als Hinweis lesen: Jeder davon zeigt auf eine Einzelfreigabe weiter unten, die eigens geprüft werden muss.
Erst jetzt zurücknehmen — an der Ebene, auf der der Zugriff entstanden ist. Eine Rücknahme eine Ebene zu hoch trifft Personen, die legitim Zugriff haben.

Merksatz: Die Ebene, auf der man etwas entfernt, muss die Ebene sein, auf der es entstanden ist. Wer die Datei repariert, obwohl die Bibliothek offen ist, hat 399 Dateien übersehen — und wer die Site verschärft, obwohl nur eine Freigabe schuld war, nimmt dem Team die Arbeitsgrundlage.

Der Preis und die Route

Feingranulare Berechtigungen lösen echte Probleme — und sie sind der Hauptgrund, warum Berechtigungsfragen in gewachsenen Umgebungen unbeantwortbar werden. Jeder Bruch erzeugt ein Objekt mit eigener Geschichte, das nie wieder von oben mitgepflegt wird. Nach drei Jahren ist die Frage „wer darf hier was?“ keine Abfrage mehr, sondern eine Untersuchung.

Die Gegenrichtung hat ebenfalls ihren Preis. Wer Brüche vermeidet, muss Inhalte trennen, statt Rechte zu verfeinern — also mehr Bibliotheken und mehr Sites anlegen, und den Beteiligten erklären, warum ihre Unterlagen an zwei Orten liegen. Das ist unbequem, aber es ist prüfbar. Die Dokumentation empfiehlt aus demselben Grund, vertrauliche Inhalte in einer eigenen Site ohne externe Freigabe abzulegen, statt sie in einer offenen Site eng zu berechtigen.

Objekt bestimmen und fragen: erbt es noch?→Beim engsten Bruch beginnen, nicht bei der Site→Alle vier Quellen prüfen — Gruppe, SharePoint-Gruppe, Direktvergabe, Link→Datenschutzgrad und Spezialgruppen mitprüfen→Auf der Ebene zurücknehmen, auf der der Zugriff entstanden ist

Erst die Ebene, dann die Quelle

Das nächste Modul nimmt sich die vierte Quelle vor — den Freigabelink. Dort geht es darum, wer überhaupt teilen darf, welche Linktypen es gibt und warum ein Link nicht dasselbe ist wie eine Berechtigung.

Jetzt anwenden

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

Zum Modul →

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