Effizientes Berechtigungs-Management mit SharePoint – Suche und Übertragung von Nuterrechten

SharePoint bietet die ideale Möglichkeit, um Nutzern Zugang zu Informationen zu gewähren und gleichzeitig vertrauliche Informationen vor unerwünschtem Zugang zu bewahren. Grundlage für diese Möglichkeit ist das Berechtigungskonzept im SharePoint, welches hierarchisch aufgebaut ist. AD Nutzer und Gruppen werden entweder in SharePoint Gruppen integriert (Best Practice) oder einem bestimmten Berechtigungslevel zugewiesen, z.B. dem Level „Besucher“. Zu diesem Level „Besucher“ gehören nun explizite Rechte, wie das Lesen von SharePoint-Seiten inkl. aller Funktionselemente wie Masterpage, Ansichten etc., sowie das Öffnen von Dokumenten. Dies ist gleichzeitig das letzte Element der Kette, das Objekt, auf das entsprechende Rechte angewendet werden.
[caption id="attachment_3451" align="alignnone" width="322"]
Abb. 1: Hierarchisch aufgebautes
Berechtigungskonzept im SharePoint[/caption] Basierend auf diesem Konzept muss ein SharePoint Administrator von unten nach oben planen. Er muss sich überlegen, auf welche Objekte er welchen SharePoint oder AD Nutzern und Gruppen mit welchen Berechtigungen Zugang ermöglichen möchte. Dabei ist ein weiterer Best Practice Ansatz sehr hilfreich: So viele Rechte wie nötig, aber so wenige wie möglich vergeben! Das ist in kleinen Umgebungen, die z.B. aus einem kleinen Intranet mit einem Farm Administrator und wenigen Nutzern, die Lesen und Beitragen dürfen, gar kein Problem. Was ist jedoch, wenn es mehrere Webapplikationen gibt? Als Beispiel kann man dazu ein standardisiertes Intranet Portal und eine Projekt-Webapplikation betrachten, in der es ad-hoc Projektseiten mit manuellen Rechtevergaben gibt. Weitere Beispiele sind Wiki-Seiten, die Verwendung von Content Deployments usw.… Dann kann es ganz schnell unübersichtlich werden. Im Idealfall gäbe es im SharePoint eine Auflistung darüber, wer welche Berechtigungen hat. Leider ist dies nicht der Fall. Hier ein Beispielszenario: Sie sind SharePoint Administrator in einem größeren Unternehmen, das demzufolge auch eine größere SharePoint Farm hat. Ein Mitarbeiter, dem schon innerhalb der Farm auf verschiedenen Ebenen Rechte zugewiesen wurden – zum Teil auch manuell und direkt vergeben – möchte sich weiterentwickeln. Ein neuer Mitarbeiter soll seinen Platz einnehmen. Somit braucht dieser idealerweise die gleichen Rechte, damit auch er die erforderlichen Aufgaben erfolgreich absolvieren kann. Daraus ergeben sich drei Konstellationen:

Berechtigungskonzept im SharePoint[/caption] Basierend auf diesem Konzept muss ein SharePoint Administrator von unten nach oben planen. Er muss sich überlegen, auf welche Objekte er welchen SharePoint oder AD Nutzern und Gruppen mit welchen Berechtigungen Zugang ermöglichen möchte. Dabei ist ein weiterer Best Practice Ansatz sehr hilfreich: So viele Rechte wie nötig, aber so wenige wie möglich vergeben! Das ist in kleinen Umgebungen, die z.B. aus einem kleinen Intranet mit einem Farm Administrator und wenigen Nutzern, die Lesen und Beitragen dürfen, gar kein Problem. Was ist jedoch, wenn es mehrere Webapplikationen gibt? Als Beispiel kann man dazu ein standardisiertes Intranet Portal und eine Projekt-Webapplikation betrachten, in der es ad-hoc Projektseiten mit manuellen Rechtevergaben gibt. Weitere Beispiele sind Wiki-Seiten, die Verwendung von Content Deployments usw.… Dann kann es ganz schnell unübersichtlich werden. Im Idealfall gäbe es im SharePoint eine Auflistung darüber, wer welche Berechtigungen hat. Leider ist dies nicht der Fall. Hier ein Beispielszenario: Sie sind SharePoint Administrator in einem größeren Unternehmen, das demzufolge auch eine größere SharePoint Farm hat. Ein Mitarbeiter, dem schon innerhalb der Farm auf verschiedenen Ebenen Rechte zugewiesen wurden – zum Teil auch manuell und direkt vergeben – möchte sich weiterentwickeln. Ein neuer Mitarbeiter soll seinen Platz einnehmen. Somit braucht dieser idealerweise die gleichen Rechte, damit auch er die erforderlichen Aufgaben erfolgreich absolvieren kann. Daraus ergeben sich drei Konstellationen:
- Wie finden Sie all die Rechte heraus, die der bestehende Mitarbeiter in der gesamten Farm hat?
- Wie können Sie all diese Rechte an den neuen Mitarbeiter übertragen?
- (Im schlechtesten Fall:) Der Mitarbeiter verlässt das Unternehmen und zusätzlich müssen Sie nun den Account aus allen SharePoint User-Tables löschen.
- Sie gehen in jede einzelne Seite, Liste und im worst case (Item-Level-Permission) sogar auf jedes einzelne Objekt, suchen die entsprechenden Berechtigungen zusammen und dokumentieren diese. Denken Sie dabei auch an den berühmten „Limited Access“! Diese Vorgehensweise würde Monate in Anspruch nehmen.
- Angenommen, Sie haben alle Berechtigungen sauber dokumentiert, dann müssen Sie dennoch, wie in Punkt 1 beschrieben, jedes einzelne Objekt im SharePoint auswählen, um dem neuen Nutzer die dortigen Rechte zuzuweisen. Ebenso kein praktikabler Ansatz. Sie möchten den Prozess abkürzen, indem Sie dem neuen Nutzer direkt „Full Control“ auf vielen, wenn nicht sogar allen Ebenen, vergeben. Zwar mag das Problem mit fehlenden Berechtigungen dann beseitigt sein, aber wie steht es bei diesem Vorgehen um Ihre Compliance-Richtlinien? Sehr wahrscheinlich ist auch dieser Ansatz wenig praktikabel.
- Sie können den betroffenen Nutzer aus Ihrem AD deaktivieren oder ganz löschen. Der User Profile Synchronization Service erkennt diese Änderung im ersten Sync (setzt eine Flag) und löscht den Nutzer beim zweiten Sync aus dem User Profile Service. Der Nutzer bleibt jedoch in allen User-Tables bestehen, sodass weder Deaktivieren noch Löschen eine saubere Lösung ist, um den Nutzer komplett aus Ihrer SharePoint Umgebung zu entfernen.
Robert Mulsow is VP of TSP EMEA at AvePoint, and a Microsoft P-TSP. Together with his previous experience at Microsoft, he specializes in SharePoint infrastructure and peripheral technologies SQL, Windows Server and Active Directory. As a Microsoft MVP and Certified Trainer for Office servers and services, he brings extensive experience in the field of consulting, implementation and troubleshooting.
View all posts by Robert Mulsow
Share this blog