In this chapter, youre introduced to least-privileged SharePoint builds. It is important to understand the components of a least-privileged build because it aids in troubleshooting the odd behaviors that can arise when builds that were once least privileged have been modified. Least-privileged SharePoint builds follow the best practice recommendations of Microsoft, and as a result, offer better performance.
As you read through Chapter (and the entire book), you dont need to have a SharePoint environment to follow along; but it would definitely be a plus and youll get more out each chapter and the chapter exercises, if you have a farm. If you dont have a farm and do not know how to build one, you should purchase a copy of my book Building a SharePoint 2016 Home Lab: A How-To Reference on Simulating a Realistic SharePoint Testing Environment (Apress, 2016). This book moves along at a little slower pace than the book in your hands. With that said, lets get going.
An Ounce of Prevention Is Worth a Pound of Cure
Knowing if a farm is least privileged is often half the battle in troubleshooting various issues with SharePoint. When SharePoint is installed using an administrative account, a common mistake is to use the same account for all services. This happens when the same account that is used to install or set up SharePoint is also used to access or connect to the databases that are stored on SQL Server. The account used to access the SQL databases is known as the farm account , which should not be a local administrator.
Note
The only time the farm account is a local administrator is during a User Profile service setup and configuration.
Its really easy to make the mistake of using the install account for the farm account. The post setup Configuration Wizard (psconfiggui.exe) prompts for the farm account . This is where that ounce of planning is worth a pound of cure, because even though there are blogs and TechNet forums posts that advise on methods of how this account can be modified after the fact, it is always cleaner, and in your best interest, to plan a farm account separate from the install accountbefore installing SharePoint .
Once the setup account has been erroneously given as the farm account, and the databases are created, the cat is out of the bag. The best way to correct this is too start with a fresh build. There are a couple of methods that you can use to determine if the farm youre working with is over-privileged. Method number one is the Windows operating systems Services console.
For example, if you open the services console (services.msc) and notice that all the SharePoint services are running under an account that looks like the farm account (say, something like 2013Farm), its probably a safe bet that youre not working with a least-privileged farm. Figure shows a farm that was installed in an over-privileged fashion.
Figure 1-1.
Farm account used as the identity for all services
The only Windows operating system service related to SharePoint that the farm account should run is the SharePoint timer service (SPTimerV4). The farm account should not be used to run the SharePoint administration service (SPAdminV4) since this service performs automated changes that require local administrator permission on the server.
The farm account would never be used to run the search services, as this would be worse than using the search service administration account as the crawler account . In both cases, SharePoint search results would include unpublished versions and would show these versions in search queries to users who shouldnt be able to read them until they were published. This is why we always use a search service account for the SharePoint Search Host Controller service (SPSearchHostController) and for the SharePoint Server Search 15 Service (OSearch15). A separate SharePoint service account is then used as the default content account, otherwise known as the crawler , or crawl account .
If youve never least privileged a SharePoint environment, youre probably starting to see that it is not as easy as just inserting the binaries and running the Configuration Wizard to completion, and possibly the farm Configuration Wizard, all with the same login account. As I mentioned earlier, this is a common occurrence, and one that is easily rectified by a farm rebuild using PowerShell scripts to build the farm and provide the least-privileged access.
So what do to if youre seeing an account listed for most of the services, you can make sure that this is the case by running the following PowerShell:
(Get-SPFarm).DefaultServiceAccount.Name
This one-liner returns the farm account. If the two match up, then its up to you to determine how to go about least privileging the farm.
Figure shows the results of running the PowerShell one-liner.
Figure 1-2.
defaultServiceAccount is the farm account
You might be dealing with a farm that has many solutions deployed. These solutions might not like having to live in an environment where they cannot run in some form of over privilege. Before completely throwing out the seemingly over-privileged build, you should dig a little deeper and open IIS Manager (inetmgr.exe) . Once you have Internet Information Services (IIS) Manager open, the identities that the application pool accounts are using will give another indication of whether the environment is somewhat least privileged, or if it is possibly over-privileged to some extent. In other words, the Windows operating system Services console and the PowerShell one-liner are not the end-all/be-all decision makers deciding whether the farm is too bad off from a least-privileged standpoint.
If you open the IIS Manager and see something similar to Figure , there was an attempt to least privilege the farm, and it may be salvageable. You might be able to adjust the various service identities using Central Administration and/or PowerShell, and be completely fine.
Figure 1-3.
IIS Manager shows signs of least privilege
I say maybe because if the same account used to install SharePoint was used for the farm account, my experience has shown me that it is best to rebuild this type of farm. If you know for certain that that was not the case, then you should proceed with looking at the rest of the least-privileged settingsbefore making your determination. If youre not sure, theres another troubleshooting step to possibly yield the desired results; these are to determine what has happened to the farm that is exhibiting some form of over-privilege. Hopefully, it is not due to the setup account erroneously used as the install and the farm account.
The account that was used to run the Configuration Wizard is the owner of both the Central Administration and the configuration databases in SQL. This account should not be the farm account. The farm account is the account that should be running the SharePoint Timer Service and the identity that the Central Administration web site is running with when looking at the application pools within IIS Manager. I know that Ive said that a couple of times, but it is very important to drive this point into the root of your SharePoint least privileging knowledge.
