One of my biggest beefs in the past (well, with SharePoint 2007) has been that you generally do a deployment with a specific account… which is often added to the Farm Administrator’s group and ends up becoming your “god” account… the secret back door you use to “get stuff done” (like service pack deployments, etc). Word gets around that the account exists, over time the password gets released (ostensibly to solve a crisis) and eventually things start “changing” in the production environment with little or no traceability (because changes appear as “System Administrator”, not an individual). This sort of security leakage happens over the space of years, not days… but it happens because there’s no impact to sharing a service account password.
I have started to take the approach (for SharePoint 2010 deployments only) where an individual is granted the necessary permissions on the target environments to do the deployment, and then removed once deployment is completed. In my mind, this achieves 2 goals:
- Generally, in a large organisation users do not share their password… because if they do, there’s nothing stopping someone logging in as you and sending email to the CEO on your behalf.
- Any actions are therefore traceable to an individual, instead of a device. Most large companies have IT policies that make the sharing of passwords a bad thing (with breaches requiring a trip to the IT or HR Manager’s office for a “chat”).
SharePoint 2010 also comes with a nifty feature – the ability for the application to automatically change the passwords before they expire… so now, your service accounts and app pool accounts can have the same (or better) password policies on them, and SharePoint will automatically take care of changing the passwords. Also Microsoft don’t specify the use of a single-purpose account – they just state “an account with enough rights” – http://technet.microsoft.com/en-us/library/ee662513.aspx.
So does anyone else feel the same way? Or am I on my own here? I admit, there are some benefits to using an account specifically designed to install SharePoint, but they are all related to “making it easier for the admin to do stuff after the farm is set up”, rather than “best practice”… and they tend to become an unintentional security hole (whereas IT will almost certainly ensure they “clean up” rights that have been assigned to a real user’s account).
So… how does this play out for the future? How are updates deployed? Let’s run up a scenario and see how that might work…
6 months after the deployment has finished, SP1 comes out and needs to be deployed. How do you do it (if you have no way to log in as a privileged account)? The answer’s easy – get your account added again to the SharePoint server’s Local Admin group and the Farm Administrator’s Group in SharePoint, and get SecAdmin and DB Creator rights on the SQL Server instance linked to ShatrePoint, then run the upgrade. Don’t forget to get these rights removed once you are finished, to avoid any accidents in the future.
Note that while I think the fact that you can use Managed accounts with expiring passwords to look after your services, there are still a few services that do not run under a Managed Account (like the User Profile Service, for example); luckily they all use the Farm Account to run. So even though you can, the Farm Account should never be set to expire (also, I have never tested to see whether it handles changing Windows services accounts very well… when the act of changing the password is done by the SharePoint Timer service).