Minimale Berechtigungen für Dienstkonten bei Sharepoint 2010, Teil 2

Bereits im ersten Teil dieser Beitragsreihe wurden einige Konten vorgestellt, die für die Installation von Sharepoint Server 2010 wichtig sind. Dazu gehört das Konto für den SQL-Server-Dienst – es bekam im bisherigen Verlauf als Benutzername SVC_SQL zugewiesen und bekommt bei der Installation des SQL Servers die Verantwortung für die Datenbankdienste MSSQLSERVER und SQLSERVERAGENT zugewiesen. Das Konto, über das der Sharepoint-Server selbst installiert wird, „Setup User Account“,  bekam im ersten Teil die  Bezeichnung SP_Admin verpasst.

Für alle Konten gilt die Aussage, dass sie mit den minimal notwendigen Berechtigungen ausgestattet sein sollen – den „Least Privileges“. Dabei darf man eines nicht außer Acht lassen: Dieses Prinzip sollte sich nicht nur auf die Konten von „echten“ Benutzern beziehen, sondern auch die Dienstkonten (Service Accounts) mit einschließen.

Dieses Thema spricht der Autor Dan Holme intensiv auf dem zweitägigen Workshop zu Sharepoint Server 2010, den Dan Holme MasterClasses an.

Für den Administrator gilt es beim Konto, von dem aus Sharepoint installiert wird, besonders aufzupassen: Er sollte Sharepoint nicht von seinem eigenen administrativen Konto aus installieren! Denn das Setup-Konto (es wurde bereits im ersten Teil des Beitrags als SP_Admin benannt) bekommt die Oberhoheit über die gesamte Sharepoint-Farm.

Ein weiterer wichtiger Tipp bezieht sich auf die Mail-Adresse für die Dienstkonten: Leider wird nur sehr selten in der Originaldokumentation darauf hingewiesen, dass der Administrator nie die eigene Mail-Adresse als allgemeine Mail-Adresse für seine Dienstkonten angeben soll. Wer dies von vorneherein berücksichtigt, spart sich später viel Aufwand.

Für SP_Admin – das trifft entsprechend auch auf alle anderen Dienstkonten zu – sollte die Mail-Adresse selbst schon darauf hinweisen, dass sich die Nachricht um die Sharepoint-Infrastruktur dreht und nicht um einen „selbst“. Daher könnte man zum Beispiel allen Sharepoint-Dienstkonten die Mail-Adresse „sharepoint@company.com“ im Active Directory zuordnen.

Bei dieser Vorgehensweise würden alle Benachrichtigungen, die zu Sharepoint gehören, an eine einzige Adresse geleitet – und das ist nicht die des Administrators selbst. Damit kann man diese Nachrichten für ein ganzes Team von Leuten, die für den Sharepoint-Betrieb zuständig sind, zur Verfügung stellen. Und wenn der Administrator andere Zuständigkeiten im Unternehmen übernimmt, lassen sich diese Nachrichten dann sehr einfach von jemand anderen übernehmen.

Aber auch aus rechtlicher Sicht bringt ein derartiger Ansatz Vorteile. Zum einen sind die Mails dann nicht einer Person zugeordnet, so dass die Datenschutzvorgaben sich leichter einhalten lassen. Zum anderen kann es auch sein, dass für eine bestimmte Service-Applikation eine andere Überwachung vorgesehen ist und dass man deswegen auch eine andere Mail-Adresse vorsehen muss.

Die Grundidee für diese Möglichkeiten aber bleibt gleich: Alle Dienstkonten-Mail-Adressen sollten identisch angelegt sein aber nie an eine echte Person gebunden werden. Damit zieht man eine Abstraktionsschicht ein und kann entsprechen der sich ändernden Vorgaben die Zuweisung der Verantwortung für diese Nachrichten sehr flexibel handhaben.

Das Konto für den Datenbankzugriff

Nach den ersten Installationsaufgaben zu Sharepoint, die von Assistenten geführt werden, muss der Administrator Informationen zum „Database Access Account“ eingeben. Hier sieht sich der Administrator allerdings eine Benutzerschnittstelle gegenüber, die zu vielen Missverständnissen und zu einigem Wirrwarr führen kann.

Der Assistent fragt einem nach dem Dienstkonto, das für den betrieb der gesamten Sharepoint-Farm Verwendung findet – und nicht nur für den Zugriff auf die Datenbank. Das Konto für die Sharepoint-Farm – es soll SP_Farm heißen – ist ein besonders mächtiges Konto mit sehr vielen Berechtigungen. Gibt man das Konto an den Konfigurationsassistenten (psconfig.exe), dann verwendet er die Anmeldeinformationen des Kontos, über das man aktuell angemeldet ist (also SP_Admin), um dem Konto SP_Farm die Oberhoheit (Ownership) der Config-Datenbank zuzuweisen.

Der Assistent konfiguriert noch eine Vielzahl von Sharepoint-Windows-Diensten, einschließlich des extrem wichtigen Sharepoint-Timer-Dienstes, um das Konto SP_Farm im Kontext zu verwenden. Zudem wird SP_Farm noch für die Identität der zentralen Verwaltungs-Website herangezogen. Anders ausgedrückt: Was die Benutzeroberfläche des Assistenten als „Database Access Account“ bezeichnet, ist in Wahrheit das Farm-Konto und somit die Oberhoheit über die gesamte Sharepoint-Farm.

Aus dieser Konstellation ergeben sich einige tiefgreifende Auswirkungen. Alles was man als Administrator im Rahmen der Zentraladministration ausführt, wird im Kontext des Kontos SP_Farm ausgeführt – und somit von der Identität des Applikations-Pools. Das bedeutet aber auch, dass SP_Farm über weitreichende administrative Berechtigungen verfügen muss.

Insbesondere muss das Konto SP_Farm in der lokalen Administratorgruppe eines jeden Servers in dieser Sharepoint-Farm liegen. Daher gilt es bereits im Vorfeld, das Konto SP_FARM in der Gruppe der lokalen Administratoren auf dem Server einzutragen, ehe es an das Installieren von Sharepoint auf diesem Server geht.

Originaldokumentation schweigt sich aus

Diesen Aspekt verschweigt die Originaldokumentation an nahezu allen Stellen. Doch es wird sehr viel Ärger bereiten, wenn die Synchronisation der Benutzerprofile nicht funktioniert. Es findet sich zwar eine Bemerkung in der „User Profile Synchronisation“-Readme-Datei – doch wer schaut sich das schon an. Daher der gute Rat: Dieser Schritt ist unbedingt auszuführen, ehe es an die Installation von Sharepoint geht. Zudem ist das Domänenbenutzerkonto SP_Farm mit der vereinheitlichten Mail-Adresse für die Sharepoint-Dienst auszustatten: sharepointservice@company.com – wie bereits zuvor erwähnt.

Die anderen Berechtigungen, die für SP_Farm nötig sind, werden automatisch im Zuge der Sharepoint-Konfiguration zugewiesen. Im speziellen bekommt SP_Farm die Rolle des dbcreator auf dem SQL Server eingeräumt. Das ist nötig, wenn man neue Web-Anwendungen und Inhaltsdatenbanken erzeugen will. Die Identität des Applikations-Pools der zentralen Administration – also SP_Farm – muss in der Lage sein, diese Datenbanken auf dem SQL Server anzulegen.

Ein weiterer Punkt betrifft die Server-Rolle „securityadmin“. Denn die zentrale Administration muss SQL-Server-Anmeldungen erzeugen können, etwa wenn man verwaltete Konten erzeugen muss oder die Applikations-Pool-Identitäten zu ändern hat. Das darf man nicht vergessen – eine jede Identität eines Web-Applikation-Pools muss über eine Anmeldung an der entsprechenden Inhaltsdatenbank für diese Web-Applikation verfügen.

Und zu guter Letzt benötigt SP_Farm noch die Datenbank-Rolle als db_owner für alle Sharepoint-Datenbanken in der Farm. Das Konto SP_Farm „besitzt“ zwar die Farm als ein Dienstkonto. Und das einzige, noch wichtigere Konto ist der SP_Admin – sprich das administrative Konto des Menschen, der effektiv auch alles mit der Sharepoint-Farm anstellen darf.

Einsatzbereiche für Konten nicht vermischen

Weil diese beiden Konten derartig hohe Berechtigungen in der Sharepoint-Infrastruktur aufweisen, sollte das Konzept der “least privilege” für die Verwaltung auf Unternehmensebene zum Einsatz kommen. Damit verfügen diese beiden Konten über keine Verwaltungsfähigkeiten außerhalb von Sharepoint. Das ist ein weiterer guter Grund, warum diese beiden Konten nicht mit anderen Rechten oder Einsatzbereichen vermischt werden sollten und eine eigenständige Identität benötigen.

Diese Erklärungen sollen die Hierarchie der Identitäten im Umfeld von Sharepoint verstehen helfen. Dabei ist das eigene Administratorkonto, das für die tagtäglichen Aufgaben herangezogen wird, außen vor zu lassen.
Das Konto SP_Admin verfügt über Berechtigungen auf dem SQL Server und auf jeden Server in der Farm. Damit wird es erlaubt mit diesem Konto Sharepoint zu installieren.

Der Systembetreuer meldet sich als SP_Admin auf den Sharepoint-Servern an, um zum Beispiel Sharepoint-Dienste zu bearbeiten oder Konfigurationsänderungen auszuführen. Während der Installation werden diese Berechtigungen verwendet, um die Rechte für das Konto SP_Farm zu konfigurieren. Das ist dann das Dienstkonto, das sozusagen die Sharepoint-Farm besitzt und die tagtäglichen Verwaltungsaufgaben an der Farm ausführt.

Wenn überhaupt sollte es nur wenige Szenarien geben, die das Anmelden als SP_Farm erfordern. Sharepoint sollte eigentlich auch so eingestellt sein, dass automatisch das Ändern des Kennworts für das Konto SP_Farm erfolgt.
In weiteren Beiträgen auf www.nt4admins.de sowie am Sharepoint-Tag von Dan Holmes MasterClasses 2010 werden weitere wichtige Konten für das Arbeiten mit den Dienst-und Web-Applikationen vorgestellt.

Dan Holme/rhh