A while ago I worked with a customer that kept having issues with SharePoint "not working". This could be anything from Search not returning results to office Web applications not opening items.
What we eventually found was that the network team was creating GPOs that were removing User Rights that SharePoint service accounts needed.
As part of the build documentation I suggest you record the following:
- Determine what services run on each server, who they run as, and what account do they use.
- Determine what User Rights do each account have, this would include local accounts as well as service accounts.
- Determine what local groups each account is a member of.
At the end of this blog I've also added links for different SharePoint permissions that are required, and remember that when running SharePoint wizard it will run the "psconfig -cmd secureresources" that will secure resources in file system and registry entries.
Determine what services run on each server
First I created a spreadsheet of each server and then listed the services that SharePoint created on that server, as well as the start up type, and log on as account.
The services running and start up type will vary between servers depending on the services running. I basically have 4 types of servers Central Admin, User Profile, Application, and Web Front End. If you have FAST installed you would also want to add those windows services. Log this information into a spreadsheet so that you have a baseline of where you started, you would log this for each server in the farm.
Determine what User Rights each account has
Now on each server in the farm open up Local Security Policy (SECPOL from a command prompt).
Look at the following rights and record the accounts with these rights.
- Adjust memory quotas for a process
- impersonate a client after authentication
- Logon as a batch job
- logon as a service
- replace token level access
- Allow Logon through Desktop Services
- Allow Log on locally
Here is an example from my lab. In the lab we created a separate account for everything. If considering this also consider the overhead of administering all these accounts. Log this information on each of your servers as the rights will vary based on what services are being provided by that server.
Determine what Local Groups each account has.
Open up computer manager and go through each of the local group and record any accounts that have membership in the following groups.
- Performance Log Users
- Performance Monitor Users
- Remote Desktop Users
Below is from my central admin.
If you go through this process you will see that your setting can vary greatly by the services each server provides but this should give you a good baseline for comparison later if required.
If you would like to see the WFE or APP servers, just let me know.
How to configure Claim to Windows Token Services in SharePoint 2010 with Kerberos Authentication (add C2WTS account to Administrators group and grants a couple of windows rights - not captured above)
SharePoint 2010: MsiInstaller errors while attempting to manage a User Profile Service Application (Grant network service rights to %programfiles%\Microsoft Office Servers\14.0)
SharePoint 2013 Group Policy Considerations (Focused on 2013 but good reading as most applies to 2010)
I recently ran into an issue with CLAIMS and "Bypass Traverse checking" following this article https://technet.microsoft.com/en-us/library/dd364071%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396.. We tried replacing Everyone with IIS_IUSRS and the appools seemed to be working, I could get into my service apps and the pools no longer stopped. The main portal however broke with Event ID 8305 "Access Denied" to the 'System.Xaml.Hosting.dll' and 'Microsoft.IdentityModel.Extensions.dll'.