• administration
  • migration
  • powershell
  • kontakt
  • EN
info@firstattribute.com
by FirstAttribute
Active Directory FAQ Active Directory FAQ
  • administration
  • migration
  • powershell
  • kontakt
  • EN

SharePoint 2010 – Service Accounts

Sep 12, 2012 (Letztes Update) | Posted by Jens Künzler | Administration, KnowHow, Konfiguration, SharePoint |

 

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

AccountTypePermissionsComment
SQL Server serviceDomain UserMSSQLSERVERSQLSERVER AGENT 
SharePoint Setup AdminDomain UserSQL server loginSQL securityadmin

SQL dbcreator

Local admin of each server in farm

SharePoint_Shell_Access

For installlation / patchesLocal admin of each server in farm

Add/remove servers

SharePoint Farm ServiceDomain UserSharePoint assigns permissions automaticallyLocal admin on UPS (user profile) server

Dbcreator, securityadmin, db_owner

 
ApplicationPool AccountDomain UserTo be registered as “managed account”Assigned as application pool identity
Service Application AccountDomain UserTo be registered as “managed account” 
SharePoint Search AccountDomain UserRead permissions to all SP content (automatically)Configure SP_Crawl before creating webapps
User Profile SynchronizationDomain User“replicating directory changes” permissions on domain level 

 

Artikel weiterempfehlen:
  • xingen
  • sharen
  • tweeten
  • teilen
  • Google+
  • mailen
Artikel erstellt am: 12.09.2012
0

Leave a Reply

Danke für Ihre Anregungen, Fragen und Hinweise.
Infos zum Datenschutz

Cancel Reply

Neueste Artikel

  • Mailversand über O365 automatisieren
  • AD LDS Installation und Backup mit Powershell
  • E-Mail-Adresse mit PowerShell prüfen
  • Quest Resource Update Manager Agent richtig verbinden
  • AD Telefonnummern automatisch korrigieren
  • Windows Server 2019 Übersicht
  • Native Linux-Bash unter Windows
  • AD DS und AD LDS im Direktvergleich
  • Powershell 6 & .NET-Core – Die Zukunft?
  • Seltene AD Attribute mit PowerShell setzen

Links

  • FirstAttribute – AD Consulting
  • FirstAttribute – Migrationen
  • FirstAttribute – Software
  • FirstAttribute – Tech Blog
  • Jobs bei FirstAttribute

Kategorien

  • Administration
  • Citrix
  • Cloud
  • Exchange
  • KnowHow
  • Konfiguration
  • Migration
  • PowerShell
  • Programmierung
  • Quest Migration Manager
  • SharePoint
  • Tools

AD Gruppen dynamisch machen

Schlagwörter

.Net ACL Active Directory AD LDS AD Objekt Berechtigung Berechtigungen Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange 2016 Exchange Migration Federation FirstWare Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP lokale Gruppen Microsoft Azure Migration New-ADUser Novell NTFS O365 Office 365 PowerShell QMM QMM AD QMM Exchange Quest Migration Manager Schema Set-ADUser SID SID History Update Windows Windows 10 Windows Server 2012 R2

Kontakt aufnehmen

Sie haben eine Frage oder Anmerkung? Schicken Sie uns schnell eine Nachricht.

Nachricht senden
Ohne nachdenken. Active Directory ganz anders. FirstWare IDM-Portal

Folgen Sie uns

Kontakt

  • FirstAttribute AG
  • Am Büchele 18, 86928 Hofstetten, Germany
  • +49 89 215 442 400
  • www.firstattribute.com

Schlagwörter

.Net ACL Active Directory AD LDS AD Objekt Berechtigung Berechtigungen Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange 2016 Exchange Migration Federation FirstWare Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP lokale Gruppen Microsoft Azure Migration New-ADUser Novell NTFS O365 Office 365 PowerShell QMM QMM AD QMM Exchange Quest Migration Manager Schema Set-ADUser SID SID History Update Windows Windows 10 Windows Server 2012 R2

Neueste Kommentare

  • Paul bei Powershell – Home Directory anlegen und Berechtigungen vergeben
  • Steve König bei AD PowerShell Basics 1: New-ADUser
  • Dennis bei AD PowerShell Basics 1: New-ADUser
Login

© 2019 · Active-Directory-FAQ by firstattribute.com

Prev Next