How Literal Interpertation of SharePoint Planning leads to Poor Security

I love the technical documentation from Microsoft.  It's the best technical documentation form any vendor I've ever worked with. I love it, or at least I used to.

<RANT>Microsoft's documentation for SharePoint's development API is pretty sparse, but since we can de-compile code (did I just say that?),  we get the best documentation there is, the code itself.  <ENDRANT>

OK, that was my rant, sorry everyone.  What I really wanted to cover in this post was a tendency by a lot of my colleagues and clients to read Plan for administrative and service accounts in SharePoint 2013 literally.  I'm going to breakdown the Administrative and Service accounts.  Jump straight to The Ugly.

The Good

• Server Farm Account -- a.k.a. Farm Account: You must separate this account from the App Pool, otherwise: DANGER WILL ROBINSON, DANGER!  Also, this account really needs to be a member of the local Administrators group on each of the farm's servers, otherwise you won't be able to deploy Web Applications or any Solutions that add code to the GAC.
• Application Pool Identity -- a.k.a. App Pool: Did you know that if you use the Farm Account as the App Pool account, it's possible to access all of the stored passwords from the Managed Accounts and Secure Store Service?
• Default Content Access -- a.k.a. Search Crawl Account, also bad idea to be the Farm Account, while this will work, the Search Crawl Account may need access to file shared and other web applications outside of SharePoint.
• Synchronization Connection -- a.k.a. User Profile Service Account. Since this account needs to have special access in Active Directory, it's best to separate it out.  Some people re-use the Farm Account because the FIM components have to be run by that account anyway, but heck, do you really want all your eggs in one basket?  Although the App Pool account is the most vulnerable to attacks, the Farm Account is second most, because it hosts Central Admin.  Any code injected in 15/TEMPLATES/ADMIN runs as the Farm Account, so should the Farm Account really have access to all of your AD information?

The Bad

There are so many possible service accounts to deploy in SP2013 (and SP2010 for that matter) that it gets a bit dizzying.  It's all fine and good to create accounts for each of these, but it's a pain in the but to actually get them all in there, even if you're using AutoSPInstaller.

The downside to using lots of service accounts, is that each different account must run in a separate memory context (Application Pool for those that only speak IIS).  That means you're using 0.5 - 2 GB per service account or application pool whichever count is higher.  The fewer accounts you configure, the fewer application pools you're required to run.  The fewer application pools you run the less memory you need to run, and the less likely that the W3P instance gets swapped out or restarted.  All this leads to higher overall performance.

OK, so you say that you want a W3P service for each Web Application your farm hosts.  Fine, but what do you get?  You might be able to service web pages faster (more threads right), but probably not as SQL Server is the bottleneck in a SharePoint system.  And if you think that separating App Pools by Web Application means that you can hot-install GAC code, think again.  SharePoint only knows how to restart IIS not a single pool.  Plus, you may have to restart the SharePoint Timer Service too if you have Feature Receivers.

Accounts that probably should be combined

So IMHO,  all of these accounts should just be the Application Pool account:

• Access Services
• Access Services 2013
• Business Data Connectivity service
• Secure Store Service
• Usage and Health Data Collection Service
• Visio Graphics Service
•  Word Automation services
•  Excel Services
•  Managed Metadata Service
•  PerformancePoint Service
• App Management Service
•  PowerPoint Conversion Service
• Machine Translation service
• Work Management
• Distributed Cache (OK, so this actually needs access by the Farm and App Pool, so, it's weird).

All of these accounts must be the Farm Account by definition, so why are they mentioned by Microsoft (I don't know...).

•  Security Token Service
•  Application Discovery and Load Balancer Service

The Ugly

Here's my gripe.  Almost everyone I speak to, who hasn't had any formal Information Assurance (read Computer Security) training reads the notes about the Setup User Account, and thinks this should be a single, shared account.  Yep you read that right, shared account!  The first rule of Information Assurance is NO SHARED ACCOUNTS!  The minute you have an administrator who changes job positions or otherwise leaves the organization, you're screwed.

I quote from Microsoft's "Plan for Administrative and..."

Setup user account

The user account that is used to run: If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database. Setup on each server computer  SharePoint Products Configuration Wizard The  Psconfig command-line tool  The Stsadm command-line tool

Microsoft doesn't mention it, but this account is the initial Farm Administrator as well.

What's the solution?  Here's the best way to go about this:

1. Create an AD Group called SP Farm Admins (or what ever makes sense to you)
2. Grant DBO to SP Farm Admins back on the SQL server before you even think of installing the SharePoint binaries.
3. Add SP Farm Admins to the Administrators group of each of the farm servers.
4. For each of the intended administrators from your organization, add them to the SP Farm Admins group.
5. Now, I'm assuming that you're one of the admins, log-in using your account and install SharePoint normally.
6. Use the PowerShell commandlet Add-SPShellAdmin to add the SP Farm Admins as a shell-level administrator.
7. Add SP Farm Admin to the Farm Administrator's group in Central Admin.
8. You could think about adding SP Farm Admin to one of those weirdo groups that SharePoint supposedly needs, but I've never seen it actually required.

Now you're set.  When you're ready to pull a Milton (Office Space, keep up people) and burn some bridges, all they have to do is disable your account, and anyone else who's a member of SP Farm Admin can take over and make sure each of those $0.01 transactions goes to that account in the Cayman Islands.