What is the advantage of using local server admin account on the SharePoint 2010 server over sp_farm account?

Question

What is the best practice and advantage of having the local server admin accounts(user accounts) on the SharePoint 2010 server(to login and check the logs) over the sp_farm & sp_admin account. i.e., traceability(who does what), accountability, limited access(PS console, Databases)...

Right now, we are using the SP_Farm/SP_Admin account to log into the server however those are provided with the higher privileges like

-Setup
-SharePoint Products Configuration Wizard
-Configure and manage the server farm.
-Act as the application pool identity for the SharePoint Central Administration Web site.
-Run the Microsoft SharePoint Foundation Workflow Timer Service.

we could see a potential risk of using those accounts, like what will happen if the account is locked due to some mistake...

and our intention is to log into the server with limited access to check the logs or something of that sort...Can we just give the remote login permission to the users account/groups?

Answer 1

It's all about the Principle of Least Access. For one thing, you pretty much never want to force your farm account to change passwords every X amount of time because that farm account is used for a ton of internal processes ranging from deciding to run timer jobs on your various servers to (at least prior to 2013) getting permission to crawl over your user profile services (yes, there's a separate service account you set for that but at least prior to 2013 the regular old farm account handles a lot of those processes).

The ideal thing you want to do with your farm account is to put down the password somewhere just in case and otherwise never, ever use it. In reality, I've used the farm account as an admin.

Otherwise, if you want to just look at log files and you don't actually need to access Central Administration at all, sure, you should be able to grant a user remote login permission. Make sure they also have access to the folder where the log files are kept, of course. That being said, if said user also wants to be able to change the nature of the log files from time to time (for instance, ramping up one of the log options to Verbose in order to track down a recurring issue), you'd also need to give them some level of permission to your Central Administration web application. In 2010 at least you can do that within CA the same way you grant permissions to any other web app.

Answer 2

Sounds like you need to read up on SharePoint security :-)

You should never ever log in as any service account, that is why they are called service accounts: they are exclusively used for services! There are many good reasons for this, one of them being the one you mention regarding lockout, another being security.

This account also have no special permissions (except given through local SharePoint related groups like WSS_Admin) and should not be local admin on any server in the farm either (only when starting certain services like User Profile Sync Service).

For all managed accounts it is not even necessary to know the password. You can let SharePoint manage the passwords for the managed account for you (check under managed accounts in Central Administration).

If you have followed best practices while installing the SharePoint farm, you should have an install account (often named SPInstall or similar) which can be used for local logins when you need to patch or configure your farm, for example with PowerShell. However it is recommended to create an admin account (often named SPAdmin or similar) that could be local admin (not necessary except for some security related settings in CA and if you want to add solutions to the farm) and should be Farm Administrator and Shell Admin (you can find info on how to give Shell Admin access on this post on my blog)

More info: Plan for administrative and service accounts (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/cc263445(v=office.14).aspx

Account permissions and security settings (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/cc263445(v=office.14).aspx