In the last few years, enterprises have come to care about least privilege—the security concept that relates to an account being given only the permissions it requires to perform its tasks, nothing more. Least privilege is important for security, auditing, and compliance, and it applies not only to the accounts used by human beings, but also by service accounts.
And, like least privilege, enterprises have come to care about service accounts as well. I remember the days when it was perfectly acceptable to create a service account and set “password never expires.” Now, most enterprises have security policies that explicitly forbid such configuration because of the open door it leaves into a system.
During the next few weeks, I’ll be posting steps to help you deploy SharePoint with least privilege and to manage SharePoint service accounts. Let’s start by clearing up some confusion and all-too-prevalent mistakes that I see made with SQL Server, SharePoint administration, and farm accounts—and don’t be surprised that at least some of the confusion is due to the weirdness of the SharePoint setup wizard itself.
3 Accounts
Microsoft describes the administrative and service accounts required for initial deployment but skims over some important details and emphases, so let’s take a look at the three accounts this week, then we’ll return to some refiners next week.
SQL Server Service Account
The first service account you’ll need to install in SharePoint is a SQL Server service account. For discussion purposes, let’s give it a user name of SVC_SQL. When you install SQL Server, you assign this account to be the identity of the MSSQLSERVER and SQLSERVERAGENT services.
Although it’s possible in some limited scenarios to use a local or system account, the practical reality, and certainly the best practice, is that this account needs to be a user account in your Active Directory (AD) domain. It should be secured in accordance with your IT security policies.
Let me digress just a bit to point out that AD now includes both fine-grained password policies and managed service accounts (MSAs). The former allows you to require stronger, more complex, more frequently changed passwords for important accounts including service accounts. The latter allows you to change a password on a service account without having to go reconfigure the service itself with the new password—a painful process that led to the “password never expires” bail-out practice in days of yore.
SVC_SQL doesn’t require, and shouldn’t have, any special permissions or resource access or administrative privileges in the domain. It will be given the rights it needs on the SQL Server during SQL Server setup.
Setup User Account
The second account you’ll need is the account you’ll use to log on to a server in order to install SharePoint. This is referred to as the “setup user account,” and we’ll call it SP_Admin for the purposes of discussion. When you’re ready to install SharePoint, you’ll log on as SP_Admin to run setup and the SharePoint Products Configuration Wizard. You should also use SP_Admin to perform post-installation updates, patches, and installation of products such as language packs. This is the “human being” account that is all-powerful on your SharePoint farm.
Create a domain user account, and add it to the local Administrators group of each SharePoint server in the farm. It should not (for least privilege) have any special rights or privileges on the SQL Server system as long as the SQL server is separate from the SharePoint server(s). In other words, if SQL Server is on a dedicated virtual or physical system, SP_Admin shouldn’t have any administrative clout on that system.
However, SP_Admin does require permissions to the SQL Server. When you run SharePoint setup and configuration as SP_Admin, the setup and psconfig.exe processes use your credentials to create databases and to create SQL logins for SharePoint accounts.
Therefore, before you set up SharePoint, you must assign SP_Admin the securityadmin and dbcreator server roles on the SQL Server. Those are the privileges that are leveraged during SharePoint setup and configuration.
SP_Admin also requires the SharePoint_Shell_Access database role for any database that you want to create or modify using Windows PowerShell. This role is currently equivalent to dbowner, but is a separate role. See my March 29, 2009 article, “T’is a Privilege to PowerShell.”
Now here’s the kicker: Don’t install SharePoint with your own administrative account! SP_Admin becomes the “owner” of the SharePoint farm, from a practical perspective. For example, it becomes the dbowner of the SharePoint Config database. There are numerous other places where the account and its email address get integrated into the farm.
Use a dedicated SP_Admin account so that the farm isn’t owned by an account (yours) that has privileges elsewhere, and so that when you get promoted to CIO because you’ve done such a great job with SharePoint, your account isn’t left owning the SharePoint farm.
Also, one other tip that is far too under-documented: Use a unified email address for all of your service accounts—and not yours! Again, save yourself headache later by doing it correctly up front.
SP_Admin (and all other service accounts) should have email addresses that reflect the fact that they are part of the SharePoint infrastructure, not “you.” For example, assign all accounts the address “[email protected]” as the email address in Active Directory.
That way, all notifications related to SharePoint go to a single address—not yours—that can be monitored by the SharePoint team which may be you today, but may not be you after you’ve been promoted. There may be governance reasons for separate addresses for certain accounts. For example, there may be a service application like a Managed Metadata Service or search crawler that should be monitored separately and therefore should have email addresses different from the farm’s generic address.
The bottom line here is start with the assumption that all service account email addresses should be the same, and not tied to an actual human being user, and then go from there based on your business requirements.
Database Access Account
After you install SharePoint and run the SharePoint Products and Technologies Configuration Wizard, you are prompted to provide the “Database access account.” This is, in my humble opinion, the single worst UI blunder in all of SharePoint, because it leads to enormous confusion and mistakes in configuration.
The Configuration Wizard is asking you for the service account that will be used to run the SharePoint farm as a whole—it’s not just for database access. The SharePoint Farm account, we’ll call it SP_Farm, is the service account that is all-powerful. When you give the account to the Configuration Wizard, the wizard (psconfig.exe) uses the credentials you’re logged on as (SP_Admin) to give SP_Farm ownership of the Config database.
The wizard also configures numerous SharePoint Windows services including the all-important SharePoint timer service to use SP_Farm as their identity. And SP_Farm is used as the identity for the Central Administration website. So what the UI describes as the “database access account” is really the Farm Account—the über-god of your entire farm.
The latter fact is particularly important to think about. Anything you do as an administrator in Central Administration is actually implemented using SP_Farm, the app pool identity. That means SP_Farm will have to have broad administrative permissions.
Specifically, SP_Farm must be in the local Administrators group of every server in the farm. You must manually add SP_Farm to the local Administrators group on a server before installing SharePoint on that server!
This is a terribly under-documented fact, and it becomes painful when you discover that user profile synchronization isn’t working. It’s documented in the user profile synchronization readme file--the read what? file—so I’m telling you now to save yourself the pain and do this step before installing SharePoint. Configure SP_Farm’s Active Directory account with the unified SharePoint service email address—[email protected].
All the other privileges required by SP_Farm are assigned automatically during SharePoint configuration. Specifically, SP_Farm is given the dbcreator fixed server role on the SQL server, because when you create new web applications and content databases, Central Administration’s application pool identity (SP_Farm) has to be able to create those databases on the SQL server.
It is also given the securityadmin fixed server role, so that Central Admin can create SQL Server logins when you create managed accounts or modify app pool identities. Think about it—each web application pool’s identity must have a login for that web application’s content databases.
Finally, SP_Farm is given the db_owner fixed database role for all SharePoint databases in the farm. SP_Farm “owns” the farm as a service account, and perhaps the only more important account is SP_Admin, the “human being” administrative account, which can effectively do anything to the farm as well.
Go the Least Privilege Route
Because these two accounts are so highly privileged in your SharePoint infrastructure, the least privilege approach to managing the accounts at the enterprise level is to give them no administrative capabilities outside of SharePoint—another reason why these should be unique accounts and not your own administrative identity.
Hopefully this explanation helps you make sense of the hierarchy of identities used to set up SharePoint. Your own, day-to-day administrative account is set aside and not used.
The SP_Admin account has privileges on SQL Server and on each server in the farm that allow it to install SharePoint. You log on to SharePoint servers as SP_Admin to perform any farm service level installation or configuration. During installation, those privileges are used to configure the rights for SP_Farm, which then is the service account that owns and manages the farm on a day-to-day basis.
There should be few if any scenarios that require you to log on using SP_Farm. In fact, SharePoint is now set up to automatically change the password of SP_Farm!
We’ll return to the other important accounts—identities for service applications and web applications—in an upcoming SharePointPro Connections newsletter and at the SharePointPro Connections website.
