SharePoint 2010 – Service Accounts

Zu Beginn von SharePoint Projekten stellt sich immer wieder die gleiche Frage nach den Service Accounts.

Welche Accounts werden benötigt?
Wann ist es sinnvoll dedizierte Accounts für spezielle Aufgaben zu benutzen?
Welche Berechtigungen sind nötig?
Wer benötigt wirklich das Recht „logon as a service“?

Im Zuge eines SharePoint 2010 Projekts haben wir eine genaue Auflistung der benötigten Service Accounts, sowie der nötigen Berechtigungen erarbeitet.

SharePoint Administrator / Installer Account

Dieser Account wird zur Installation der SharePoint Farm benutzt. Er kann Server zur hinzufügen und entfernen. Er sollte auch genutzt werden um Patches und Updates zu installieren. Zu diesem Thema gibt es viele Diskussionen, welche nicht eindeutig geklärt wurden. Es kursieren Empfehlungen, nach denen das SharePoint Setup sowie weitere Installationen von Patches und Updates immer mit dem gleichen Account ausgeführt werden sollten. Dies bedingt jedoch einen anonymen nicht personalisierten Setup-Account, welcher sich interaktiv an den Servern anmelden darf uns dessen Passwort mehreren Personen bekannt ist. Viele Unternehmen sind bestrebt genau diese Accounts loszuwerden. Wir haben es nicht geschafft von Microsoft hier eine eindeutige Aussage zu bekommen. Da es keine Aussage in dem Sinne „es muss ein Setup Account genutzt werden„ gibt, haben wir uns entschieden das Setup mit personalisierten Admin-Accounts auszuführen.

Es genügt ein normaler Account (domain user) mit den folgenden Berechtigungen:

Mitglied der Farm Administrators Gruppe
SQL Security Admin
SQL dbcreator
Local Admin auf jedem Server der Farm
SharePoint_Shell_Access (zur Nutzung von PowerShell)

SharePoint Farm Service

Mit diesem Account findet die automatische Kommunikation innerhalb der Farm statt. Die Berechtigungen für diesen Account werden während der Installation der Farm vom Setup Programm automatisch gesetzt. (SQL dbcreator, securityadmin und db_owner). Ein normaler „domain user“ ist hier ebenfalls ausreichend. Wichtig: während der Installation der Service Application „User Profile Service“ muss dieser Account kurzfristig lokale Admin Berechtigungen auf dem User Profile Service Application-Server haben, da mit diesen Credentials die MIIS Komponenten installiert werden.

Application Pool Account

Der Application Pool Account wird, wie der Name vermuten lässt, bei den IIS Application Pools hinterlegt. Die SharePoint WebApplications erben die Identität dieses Accounts. In der Regel kann dieser Account für alle Application Pools verwendet werden. Ausnahmen könnten für besonders Sicherheitsrelevante Bereiche gemacht werden.

Der Account wird als „managed account“ in der SharePoint Farm konfiguriert. Es werden keine weiteren Berechtigungen benötigt.

Service Application Account

Dieser Account wird für alle Service Applications genutzt. Eine Unterscheidung für einzelne Service Applications wird nicht gemacht. Der Account wird als „managed account“ in der SharePoint Farm konfiguriert. Es werden keine weiteren Berechtigungen benötigt.

SharePoint Search Account

Mit diesem Account wird der SharePoint Content durchsucht. Er benötigt zumindest LESE Berechtigungen auf alle Daten der SharePoint Farm. Diese Berechtigungen werden automatisch gesetzt, wenn die Search Service Application vor der der ersten WebApplication erstellt wird. Wichtig ist hier noch mal die Unterscheidung: die Search Service Application läuft mit dem Service Application Account. Die Suche selbst wird mit dem Search Account durchgeführt. Es genügt ein normaler Account (domain user).

User Profile Synchronization Account

Der User Profile Synchronization Account synchronisiert Informationen der Windows Domain mit der SharePoint Farm. Hierzu zählen z.B. Benutzer und Gruppen. Damit diese Informationen übertragen werden können, benötigt der Account spezielle „replicating directory changes“ Berechtigungen in der Windows Domäne. Vorsicht: es gibt zwei ähnlich bezeichnete Berechtigungen „replicating directory changes“ und „replicating directory changes all“. Nur die erste Berechtigung (ohne ALL) funktioniert.

SQL Server Service

Die meisten SQL Server laufen als „local system“ ohne speziellen Service Account. Dies ist auch für SharePoint Installationen möglich. Soll jedoch SharePoint Backup mit PowerShell verwendet werden, so ist es notwendig, dass der SQL Server mit einem Service Account läuft. Die PowerShell cmdlets exportieren die Daten aus der SQL Datenbank mit der Identität des SQL Servers. Läuft der SQL Server als „local system“, so können die Daten nicht auf ein Netzwerk Share übertragen werden.

Zusammenfassung