Following Least Privilege Principle, i always wanted to nail down on permissions required to setup, manage and administer SharePoint, recently working quite a lot on ensuring how important it is working with a close environment which mimics Production environment which makes you sleep as you code won’t fail in such environment as you already tested and built code to very similar environment.
There has been good documentation on setting up SharePoint environment with detail account permission on Servers and SQL Server
Account permissions and security settings in SharePoint 2013
I found it really hard to nail down for Search Service Application, People have done quite a lot work to get the PowerShell scripts to deploy different search topology but i couldn’t find one where they are talking about very specific permissions required.
So i just wanted to document what I've experienced and got the search service application working without issues.
I already have my SharePoint Farm Build with best Practice and followed Least Privilege Principle.
Note: As per Microsoft documentation the Farm Account doesn’t need to be a local administrator, but it is required when you need to perform User Profile Synchronization. With such exception I’ve tried to get very similar workaround working for search. I’m going to setup default search topology as this is my development environment but still wanted to keep it inline with Least Privilege Principle.
Current environment
DC Server : Windows 2012, Hosting Active Directory Domain Service, DNS
APP Server : Windows 2012, SharePoint 2013, SQL Server 2012, all the service Applications.
For search Service Application, i created following Accounts and added them as Managed account.
ACCOUNT | Comments |
WS_SEARCH_CRAWL | Windows Service OSearch15 / SharePoint Server Search 15 |
WS_SEARCH_HC | Windows Service SPSearchHostController / SharePoint Search Host Controller |
AP_SEARCH_QSS | App pool for Query Site and Settings Web Service |
AP_SEARCH_AWS | App pool for Search Admin Web Service |
SP_SEARCH_DC | Service Account for Default Content Access |
I like prefixing the accounts for what they are used for
Following is the step i performed for setting up Search Service Application.
1. Logged in as Farm account, note: my farm account is added to local admin group as it is needed for profile synchronization.
2. Assigned
WS_SEARCH_HC to Windows Service - Search Host Controller Service
WS_SEARCH_CRAWL to Windows Service - SharePoint Server Search
CA—> Security –> Configure Managed Accounts.
3. Started following services from
CA –> System Settings –> Mange Services on Server
Search Host Controller Service
Search Query and Site Settings Service
SharePoint Server Search
4. Created Search Service Application and assigned respective service accounts (domain accounts) as below.
Search Service Account : WS_SEARCH_CRAWL
Application Pool for Search Admin Web Service : AP_SEARCH_AWS
Application Pool for Search Query and Site Settings Web Service : AP_SEARCH_QSS
5. Restarted my App Server.
6. Started getting error in log as access denied for Search Host controller not able to access Search_Service_Application_DB_{guid} so explicitly added the login rights for WS_SEARCH_HC –> Search_Service_Application_DB_{guid} and also gave SPSearchDBAdmin role
7. Restarted the server again to ensure things are smooth, again got errors, and it happened to be WS_SEARCH_CRAWL account doesn’t have SPSearchDBAdmin role on all the four search database, so gave/added the role.
8. Again started getting error in ULS log which was not quire really sure why but was related to gatherer and this was only solved by giving WS_SEARCH_CRAWL Account giving Local Admin access. Note once you give local admin rights to any account you need to restart/log-in/log-off once to take it into affect, so i again i restarted.
9. Well till now i was not getting any error in my ULS log, so i thought of changing my default content access account to SP_SEARCH_DC from WS_SEARCH_CRAWL which has higher rights now.
10. slowly after sometime i started getting error in ULS where the WS_SEARCH_HC service was not able to login on Search_Service_Application_DB_{GUID} which i gave along with SPSearchDBAdmin role.
11. I also need to give WS_SEARCH_HC permission on Search_Service_Application_LinksStore_{guid} with SPSearchDBAdmin role.
12. Again i restarted, and did a full crawl i don’t see a single error in my event log and search is working absolutely fine.
Hope to get more granular permission details from MS Documentations with proper justification soon so that should fix this workaround.
Thanks
Akhilesh
I like what you guys are up too. Such intelligent work and reporting!Keep up the excellent works guys I have incorporatedsharepoint training
ReplyDeleteI am glad to find amazing information from the blog.
ReplyDeleteThanks for sharing the information.
GSTR 1filling, Account Services
"Hope to get more granular permission details from MS Documentations with proper justification soon so that should fix this workaround" Any follow up on this?
ReplyDeleteI was encountering MSSQLSERVER EventID 18456 in my Application Log stating "Login failed for user 'domain\sharepointsearchhost'. Reason: Failed to open the explicitly specified database. [CLIENT: ]". In my environment, my DB server is separate from my web servers. Points 10 and 11 in your article here resolved my event logs, that were occurring every 1-10 seconds, and flooding my Application Log.
ReplyDelete