Why make managed accounts local admin?

May 27, 2010 at 6:36 AM
Edited May 27, 2010 at 6:36 AM


A couple of things I have noticed, which the Health Analyzer complains about. First is that you must be logged on as the farm account. A process within the script checks that the current account (i.e. farm admin) has local admin rights. When the managed service application account is created it also is added as a local administrator. Is there a specific reason for this? After the installation can the accounts be removed from the local administrator's group?

May 27, 2010 at 3:47 PM

I definitely need to review some of this.

First, the installation account obviously must be a local admin, but the question is whether a) the installation account should also be the farm account and/or b) the farm account should be a local admin. I know the Health Analyzer complains about this, but in Beta and RC, you couldn't really get your farm to work properly (e.g. Profile Sync) unless everything was done with farm account as local admin (and some people went as far as to make the farm account a Domain Admin...)

Second is the question about service app accounts being local admin. I also found during Beta and RC testing that this certainly got rid of some potential issues, but like I said I need to test/review this in the RTM release to see if it's still the case, or if the service app accounts can now be regular low-privilege accounts.

Thanks for bringing this up - future updates of the script will reflect my findings.


May 27, 2010 at 5:44 PM

OK so I just confirmed that the farm account needs to be a local admin, otherwise the User Profile Synchronization Service won't start...

Jun 3, 2010 at 2:59 PM

FYI I've just updated the script according to your comments/suggestions - thanks!

Jul 12, 2010 at 7:25 AM
Edited Jul 12, 2010 at 7:26 AM
Have you read this article? http://technet.microsoft.com/en-us/library/ee662513.aspx It describes all user accounts needed for an installation, and what permissions to give these accounts. It's all based on four simple rules: * All accounts must be Active Directory accounts * The installation account must be local admin on each SharePoint server in the farm * The installation account must have the securityadmin and dbcreator fixed roles on the SQL instance. Local admin on the SQL server will do as well but is not required. * ALL other accounts (i.e. farm account, service accounts, etc) should NOT have any permissions granted at all. They will be given permissions automatically in the database, file system, services, IIS, etc accordingly by the SharePoint configuration wizards. I can't tell by your comments how the script ended up, does the farm account need local admin permissions or what? Because in the version of the script that one of my clients used, that was the case and it resulted in an entire farm with faulty permissions. The farm account should not be given any local permissions at all - it is a service account and should be used as such. For install, Microsoft recommends a "SharePoint Setup" account which can be shared among administrators (rather than using someone's personal account for installation). Don't hesitate to ask if you have any questions. I have worked a great deal with installations and issues related to service accounts and permissions.
Jul 12, 2010 at 1:57 PM

My script (now) follows most of the MS best practices, with one notable exception: the installation account and the Farm account are one & the same (and hence the Farm Account must, initially at least, have Local Admin).

The reason I do this is because whichever account is used to perform the installation is made dbo in the SharePoint SQL databases. This has been linked to issues later on, when internal stored procs etc. (which run as Farm Account) try to work with objects owned by that other installation account. Therefore I install everything as Farm Account, the objects get created with Farm Account as dbo, and I can then remove the Farm Account from the Local Admins group once the installation (and Profile Sync config) is done. Again, after the install is done, everything follows best practices because neither the Farm Account nor any of the other managed accounts are local admin.

Having said that, I'm definitely not opposed to using a shared, non-personal, installation account instead of Farm Account to perform the installation. If you want, just comment out those lines in the script (currently 163-170) and you should be good to go. But just be aware of the potential issue I mentioned above, and also that the Farm Account MUST be made a local admin for your User Profile Synchronization setup (see http://www.harbar.net/articles/sp2010ups.aspx for more info) but can be removed afterwards. Again, I just choose to take care of all potential issues at once by actually performing the install with Farm Account, then removing it from the local admins when we're done.

Hope this makes sense,


Jul 30, 2010 at 1:21 PM

Hey Brian,

Yeah, I commented out those lines a few months ago when I first used the scripts and it worked fine with the Setup account, although I had also commented all of the Service Application creation at that time because I think there were still some issues with it back then. Later I tested Spencer Harbar's UP configuration against that installation and it worked fine as you suggest, adding the Farm account as Local Admin temporarily.