locked
Accounts used by application pools or service identities are in the local machine Administrators group RRS feed

  • Question

  • Hi All,

    I installed sharepoint 2013 on windows server 2012 and sql server 2012.

    Used the accounts for Farm Installation - SPFArmAcc and for service SPServiceApps.

    When i see the health analyzer i am getting this message

    Using highly-privileged accounts as application pool or as service identities poses a security risk to the farm, and could allow malicious code to execute.  The following services are currently running as accounts in the machine Administrators group: SharePoint Central Administration v4 (Application Pool)
    SPUserCodeV4(Windows Service)
    SPTimerV4(Windows Service)
    AppFabricCachingService(Windows Service).

    I checked in the iis for central administration application pool identity is SPFarmAcc. and SPFarmAcc is in administrators group in the server.

    Can anybody help me how to solve this issue please.

    Am i need to change the Application pool identity to SPServiceApps Account. If so how to change it please.

    thank you

    Thursday, November 15, 2012 11:03 PM

Answers

  • The Central Administration site's application pool should be the server farm account. This is the required configuration, do not change it.

    However, the server farm account should not be a member of the local administrators group so it is best practice to remove it from the local administrators group (with one exception: when configuring the user profile synchronization service you temporarily need to make the farm account a local administrator so it can set the service up. You then remove it from the group once completed).


    Jason Warren
    Infrastructure Architect


    • Proposed as answer by Paul Turner _ Friday, November 16, 2012 10:29 AM
    • Marked as answer by ausla11 Tuesday, November 20, 2012 3:36 AM
    • Edited by Jason Warren Friday, February 8, 2013 7:00 PM clarified that the farm account is the "server farm account" from Microsoft's documentation
    Friday, November 16, 2012 1:30 AM

All replies

  • The Central Administration site's application pool should be the server farm account. This is the required configuration, do not change it.

    However, the server farm account should not be a member of the local administrators group so it is best practice to remove it from the local administrators group (with one exception: when configuring the user profile synchronization service you temporarily need to make the farm account a local administrator so it can set the service up. You then remove it from the group once completed).


    Jason Warren
    Infrastructure Architect


    • Proposed as answer by Paul Turner _ Friday, November 16, 2012 10:29 AM
    • Marked as answer by ausla11 Tuesday, November 20, 2012 3:36 AM
    • Edited by Jason Warren Friday, February 8, 2013 7:00 PM clarified that the farm account is the "server farm account" from Microsoft's documentation
    Friday, November 16, 2012 1:30 AM
  • Thanks Jason,

    I followed your instructions and it works well for me. Thanks alot.

    Now i got the another issue. In my central administration i can't see site actions menu (like i can see site actions menu in sharepoint 2010 central administration mainpage left hand site top corner). Can anybody help me please.

    I installed and configured sp2013 using default settings only. I didn't used any custom settings.

    But i can't see the site actions menu(edit page,more,sharepoint designer,permissions,... and so on).

    I can see only system settings on the right hand side top corner.

    Any help please.

    Thank you.

    Tuesday, November 20, 2012 3:37 AM
  • Hello

    If you are running the central admin from the same server run the explorer as Administrator. The login to central admin with your admin farm account as usual.

    I hope this helps you

    Thursday, November 22, 2012 5:22 PM
  • Hi Jason,

    This might be silly questions but what would happened if I do not remove my farm account from this local admin group? If i remove it do I need to add it back on if say suppose i need to add new services or add new WFE or ay other configuration (NB. my UPS is up and running with no error)

    I'm very new to this and bit worried. Any advice greatly appreciated.

    Thanks,

    Balai

    Monday, January 28, 2013 3:50 PM
  • There is a requirement that the farm account is a local administrator when first provisioning the User Profile Synchronization (UPS) service. This is because it is configuring Windows services. This is the only service or situation where this is the case. Some (I) argue this is poor design and maybe a future version will correct this issue (by perhaps letting you specify an account to provision the service with), but for now we live with what we have.

    Leaving the farm account in the local administrator group after provisioning the UPS (or in a farm where you will not be using the UPS) is a security risk. As the farm account is responsible for running several components of the farm, should this account be compromised and it is a local administrator, an attacker could not potentially log onto your servers with full control. I'm not saying that this will happen in every farm, just that you increase your risk.

    This way of thinking is the basis of security by least permissions (i.e. "secure by default"). By giving your (user or service) accounts only the minimum amount of access they require to carry out their work, you effectively reduce the potential harm these accounts can cause either maliciously or accidentally. In other words, if the account doesn't have local administrative rights, it's can't perform tasks that a local administrator could.

    Summary: After provisioning the UPS, remove your farm service account from the local administrator group on all servers in the farm. This account is not an administrative account and you shouldn't be using to log into servers or the farm except for very specific troubleshooting (usually while following advice from Microsoft Support).


    Jason Warren
    Infrastructure Architect

    Monday, January 28, 2013 4:22 PM
  • Thanks for your swift response Jason.
    Monday, January 28, 2013 4:36 PM
  • Are we distinguishing here between Farm SERVICE account vs. Farm ADMIN account? Apologies, but I'm still rather confused. I get the same/similar warning; this, after following what I thought were Microsoft's own steps, which also are rather vague and open-ended on several points - one of which is that another blog recommends creating a separate account under which to install SharePoint - and yet, to my knowledge, Microsoft did NOT [specifically] mention or recommend that.

    Is it proper then to say, "Don't run ANY services via the Farm ADMIN account?

    I get this error:

    "Using highly-privileged accounts as application pool or as service identities poses a security risk to the farm, and could allow malicious code to execute.  The following services are currently running as accounts in the machine Administrators group: SharePoint Central Administration v4 (Application Pool)
    SPTimerV4(Windows Service)"

    And in yet another blog, the person points specifically to Microsoft's own documentation, saying that the 'Farm Account' (I'm guessing Farm ADMIN account) MUST be a local administrator for many Central Admin and SPTimer functions to work properly?


    tnjman

    Friday, February 8, 2013 1:44 PM
  • In my response, my use of the wording "farm account" means the server farm account (aka the database access account, or farm service account), that is detailed in the Plan for administrative and service accounts in SharePoint 2013 TechNet page. It is responsible for running the timer service and the Central Administration application pool.

    On that same page there are the details for the "setup user account" which indeed is a different account that is used to set up the farm. While this account is practically a god in the farm, it will still not have access to some databases and services until it has been granted access to do (and since it is a member of the farm administrators group, it has the rights to provision these itself). This account is intended for primarily for installing the SharePoint product and configuring the farm (i.e. running the configuration wizard etc).

    That error you see is indeed strange, but expected due to the way the farm needs to be configured. In addition to the server farm account running the timer service and CA app pool, it is also responsible for provisioning the User Profile Synchronization Service which contradicts Microsoft's documentation for service accounts. 

    I have updated my post to reflect this distinction in accounts.


    Jason Warren
    Infrastructure Architect

    Friday, February 8, 2013 7:00 PM
  • Thank you. I may decide to "live with the warning," partly because, as you state, MS even contradicts themselves - for example, the bottom Microsoft (technet) statement is just plain WRONG - case in point: If I am running a TEST/DEV server, where BOTH functions are on the same server, then the info below is definitely incorrect ("It must be a member of the local administrators group on each server in the SharePoint farm, excluding the server running SQL Server and the Simple Mail Transfer Protocol (SMTP) server.") - They cannot have it BOTH ways - since my TEST/DEV server is BOTH a SQL server and a SharePoint front-end server, then if I remove the "setup user administrator" account from local admin, things will break.

    Additionally, their documentation on setup/install needs to state EXPLICITLY: Do NOT log in via a domain admin account, such as "domain\administrator" when installing sharepoint; instead, create (beforehand) a standard domain user account to be used as the "setup user administrator" account; make that account a member of the "local administrators" group on the server on which you will be installing sharepoint. LOG IN *AS* THAT USER to the server on which you will be installing SharePoint; and install sharepoint via that user account.

    Do I have that correct? That is my understanding of the 'best practice,' and those detailed steps are NOT mentioned by Microsoft. It says create the account, but NEVER says, "Oh, by the way, LOG IN [using] that account, in order to install SharePoint."

    So, the conundrum is that I did install it in a TEST environment only - via a 'domain admin' account, just to have a look at some features. Subsequently, I followed some detailed steps to change from that domain admin account to a less privileged account as the 'setup user account.' (the account that connects to the DB). Fortunately, or unfortunately, I chose a prior account that was/is also used by Timer service and Central Admin - so, I have a combined Service account and Admin account, for the time being - at least for those functions mentioned (SPTimer svc, Central admin [app pool], and connecting to the TEST database) in my TEST environment. And again, if I were to remove that account from local admin, there would be problems, right?

    I always can re-do the installation, and start from scratch - I suppose the practice is useful? And there seems to be no simple way to change the app pools nor re-align the SPTimer service service account?

    Below is the MS contradictory info - about such a 'setup' account NOT being an admin on the SQL server:

    http://technet.microsoft.com/en-us/library/cc678863.aspx

    Setup user administrator account

    This account is used to set up each server in your farm by running the SharePoint Configuration Wizard, the initial Farm Creation Wizard, and Windows PowerShell. For the examples in this article, the setup user administrator account is used for farm administration, and you can use Central Administration to manage it. Some configuration options, for example, configuration of the SharePoint 2013 Search query server, require local administration permissions. The setup user administrator account requires the following permissions:

    • It must have domain user account permissions.

    • It must be a member of the local administrators group on each server in the SharePoint farm, excluding the server running SQL Server and the Simple Mail Transfer Protocol (SMTP) server.


    tnjman

    Friday, February 8, 2013 9:31 PM
  • The setup user account does not need to be an administrator on the SQL Server (and so we're clear, we're talking about a multi-server farm with one or more dedicated database servers). The only permissions it needs on the SQL Server is a SQL login with the Server admin SQL roles (note this has changed from 2007 and 2010 where it needed dbcreator and securityadmin. Server admin gives it more rights), which is listed in the page I linked to:

    Account Requirements

    Setup user account

    • Domain user account.

    • Member of the Administrators group on each server on which Setup is run.

    • SQL Server login on the computer running SQL Server.

    • Member of the Server admin SQL Server security role.

    If you run Stsadm commands that affect a database, this account must be a member of the db_owner fixed database role for the database.

    Those permissions are the minimum permissions this account requires to do its job. The documentation doesn't say you can't use a domain administrator. It's just in practice using a domain administrator to administrate anything other than the domain is something you shouldn't do. Most organizations that I help with installing SharePoint wouldn't give me a domain administrator account even if I paid them (not that I even have money to pay them). 

    In your case, a single server farm has different requirements. If SQL is installed locally, obviously the account that you install SharePoint in has to be a local administrator since only administrators can install software. This isn't necessarily a fault with the documentation, this is just a physical reality of your environment. And again, the document doesn't say the account can't have additional rights, only that those are the bare minimum needed.

    As for the documentation about using the setup user account to install SharePoint, the first table on the page I linked to clearly states:

    Account Purpose

    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 thedb_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

    It says right there that this account is used to install SharePoint on the servers ("The user account that is used to run Setup on each server computer").



    Jason Warren
    Infrastructure Architect

    Friday, February 8, 2013 9:56 PM
  • I wasn't speaking about "your" documentation - I was speaking of Microsoft's own summary "SharePoint Setup Steps" that do NOT clearly state, "Oh, by the way, BE SURE TO "LOG IN" USING the setup user account, in order to install SharePoint." Basically, the specific document that I saw says, "Install SharePoint." Again, it may be obvious, but it needs to be stated clearly. And we (you and I) may be referencing different MS and/or Technet documents. Your documentation seems to be clear enough.

    Also, more to the point are the "warnings" that MS sharepoint health tool lists as "critical' - which they are NOT, since they are "warnings;" and MS has admitted as much - and stated that they need to change it. Something like "Critical issues exist..." then you click to view, and you get one or more "warnings" - not errors; not 'critical items;' just 'warnings.'

    Case in point: "Using highly-privileged accounts as application pool or as service identities poses a security risk to the farm, and could allow malicious code to execute.  The following services are currently running as accounts in the machine Administrators group: SharePoint Central Administration v4 (Application Pool)
    SPTimerV4(Windows Service)"

    What is the best recourse for setting up new accounts and switching to those new, non-admin accounts? Seems like there's some combination of PowerShell and SharePoint admin steps needed, in order to change one or more of these two accounts - does that sound correct? This is what I found:

    http://blogs.msdn.com/b/malag/archive/2010/04/14/how-to-create-new-application-pool-and-change-app-pool-of-sharepoint-website.aspx

    I would like to keep the "farmadmin" account (under which the SPTimer service currently is running) as ONLY an 'admin' account; while chaging SPTimer service to run under a new, non-privileged account; and, as well, I would like to change the Central Admin app pool also to run under a different account from the 'farm admin' account - any hints, clues and/or tips would be greatly appreciated. The above link seems to have some of it covered, but I would like additional input, to make sure I have clear steps. Thank you for all the feedback.


    tnjman



    • Edited by TNJMAN Monday, February 11, 2013 1:48 PM spelling
    Monday, February 11, 2013 1:46 PM
  • I'm happy to discuss this further if you still have questions, though to be honest this post has taken a lot more time than I have to devote to the forums. I understand your frustration so I'm going to attempt to clarify what you've posted because I believe there still remains some confusion.

    I wasn't speaking about "your" documentation - I was speaking of Microsoft's own summary "SharePoint Setup Steps" that do NOT clearly state, "Oh, by the way, BE SURE TO "LOG IN" USING the setup user account, in order to install SharePoint." Basically, the specific document that I saw says, "Install SharePoint." Again, it may be obvious, but it needs to be stated clearly. And we (you and I) may be referencing different MS and/or Technet documents. Your documentation seems to be clear enough.

    My documentation is Microsoft's official documentation on TechNet and the documentation does clearly say to install SharePoint and run the config wizard with the setup user account. From Install SharePoint 2013 across multiple servers for a three-tier farm, the very first step is: 

    To run the Microsoft SharePoint Products Preparation Tool

    1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.

    OK. So you need to install it with the setup user account. Can't be any clearer than this. But to be fair there are also two other install guides for when you've got everything installed on one server. For a single server with a separate SQL Server install (i.e. a "single server farm") there's Install SharePoint 2013 on a single server with SQL Server. You're correct in that it isn't 100% clear if you are simply skimming the documentation. It doesn't explicitly state to use the setup user account. But it does say:

    Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed information, seeInitial deployment administrative and service accounts in SharePoint 2013.

    Which leads us again back to the documentation where Microsoft clearly says the setup user account installs SharePoint. It also says:

    securitySecurity

    As a security best practice, we recommend that you install SharePoint 2013 by using least-privilege administration.

    These two parts should implant the idea that you should think about service accounts before proceeding. We're not talking about installing a video game or a text editor. SharePoint is an enterprise application that comes can require significant planning and design.

    Also, to address your complaint about needing to log on (and I'm not trying to be a smart aleck) but should it really be spelled out in the year 2013 that you need to log in to a computer before you can run setup.exe? How else are you going to install the software? I suppose you can run executables remotely or create an automated installation using Group Policy. Sure, OK. If you go to the trouble of running setup.exe remotely you've probably done your homework and know to run it using the setup user account.

    Finally in the way of installation documentation there's the Install SharePoint 2013 on a single server with a built-in database guide which details installing the standalone installation. The standalone installation automatically installs SQL Server Express, does not require a domain and installs all available services and a default web application using the account you are logged in as (or maybe you can specify the server farm account, to be honest I have no idea). This guide states that this method is not for production use and is generally not recommended. The standalone install is not technically a farm and no one uses it for anything other than testing so warnings about service accounts are usually something you can overlook because your priorities are probably focused more around evaluating what SharePoint can do as opposed to deploying it to actual users.

    Speaking of warnings.

    <blocktquote></blocktquote>

    Also, more to the point are the "warnings" that MS sharepoint health tool lists as "critical' - which they are NOT, since they are "warnings;" and MS has admitted as much - and stated that they need to change it. Something like "Critical issues exist..." then you click to view, and you get one or more "warnings" - not errors; not 'critical items;' just 'warnings.'

    Case in point: "Using highly-privileged accounts as application pool or as service identities poses a security risk to the farm, and could allow malicious code to execute.  The following services are currently running as accounts in the machine Administrators group: SharePoint Central Administration v4 (Application Pool)
    SPTimerV4(Windows Service)"

    How is improperly configuring the farm not a critical issue that warrants a warning? Security is important and reducing the chance that of an account with high privileges being exploited is an important step in securing your farm.

    And let's clear up why the server farm account should not be a local administrator. Consider a scenario where the server farm account is a local admin. If the password of this account is sent to someone by accident or found out by other means, an attacker could then log onto the SharePoint server and access anything there (I'm assuming the RDP ports are open so your administrators can access the server). Once on the server it's trivial to determine the database hosts and here's the thing -- the farm account has read/write access to every database in the farm. An attacker installs SQL Server Management Studio, logs into the farm's database instance and can retrieve all data in the farm. Actually, they could also just log into every site in the farm, but raw databases can be more interesting. I'm not saying this to scare you, but to help clarify why this warning is critical.

    To put it another way, saying this alert is not critical is like saying the very annoying tone your car makes when you open the door and your keys are still in the ignition isn't a critical alert to the security of your car and possessions therein. If the car manufacturer didn't have that tone, would customers sue when a thief stole their car with the keys in the ignition? Can you imagine this conversation if you didn't have that alert and your farm was compromised? "How could Microsoft not bother telling me I configured the farm incorrectly and left the keys to the server lying out in the open? How irresponsible!"

    So let's talk about why you're seeing this warning. Is the server farm account, that is, the account used to run the Central Administration application pool and the SharePoint Timer service a local administrator? This warning suggests that it is and as per Microsoft's documentation it should not.

    What is the best recourse for setting up new accounts and switching to those new, non-admin accounts? Seems like there's some combination of PowerShell and SharePoint admin steps needed, in order to change one or more of these two accounts - does that sound correct? This is what I found:

    http://blogs.msdn.com/b/malag/archive/2010/04/14/how-to-create-new-application-pool-and-change-app-pool-of-sharepoint-website.aspx

    I would like to keep the "farmadmin" account (under which the SPTimer service currently is running) as ONLY an 'admin' account; while chaging SPTimer service to run under a new, non-privileged account; and, as well, I would like to change the Central Admin app pool also to run under a different account from the 'farm admin' account - any hints, clues and/or tips would be greatly appreciated. The above link seems to have some of it covered, but I would like additional input, to make sure I have clear steps. Thank you for all the feedback.

    The recourse is removing the server farm account from the local administrators group. Create another account for administration (that is a member of the local administrators group) and grant it the rights it needs.

    The server farm account is not an administrative account!

    I hope this post clears things up for you and if not, by all means please let me know.

    Thank you,

    Jason


    Jason Warren
    Infrastructure Architect

    Monday, February 11, 2013 3:24 PM
  • [Note, by the way, it is SP 2010 I am testing, not 2013 - there is no direct path to 2013 from 2007, so I have to bite the 2010 chunk first; and THEN move to 2013]

    Very clear. Thank you.

    I definitely was reading at least 2 technet articles that were more "general" and were not yours - much appreciated!


    tnjman

    And, to answer part of your question: yes, the server 'farm' account is a "local admin" in my case; and it was mentioned that it may need to be a local admin, at least during a specific part of the configuration; and then, after that part is done, then it no longer needs to be an admin. (?)

    Without excellent steps like yours, when a user is simply setting up sharepoint "out of the box" (and by the seat of his/her pants :-), then it is not always clear that the initial "server db-connect" account is equal to "an account that does not need to be a local administrator." And, as stated, the account (called 'farmadmin' in my case), really only needs db_owner and some other things along those lines.

    Your steps made all the details very clear - thanks again!

    [Further clarification] I never said "I did not realize i need to [log in]" to run setup

    I simply said that the 'vague summary' that I was referencing mentioned "Installing sharepoint," but it did not mention creating a separate account, and logging in with that separate (admin) account." And, it was a "test environment," so it wasn't a big deal that I logged in and failed to use a 'best-practice' account.

    I had no less than five summary sheets in front of me while installing SharePoint in the TEST environment, so that is partly my fault, for hopping back and forth between those five summaries.

    Again - many thanks!

    P.S. My statement about "NOT critical" was pointing out that Microsoft typically has, for example, in the case of 'Event Logs,' as an example, Serious/Critical as "Red/Error" vs. Informational/Warning as "Blue/Yellow." - conversely, the SP Health Analyzer says, "Critical issues exist with your farm," and yet, when viewing via the link, the items show ONLY as "warnings" - my point was that MS should be CONSISTENT between these types of errors/screens - if they are warnings, then the initial page should say, "Your Farm has some warnings, which may be serious..." and, in this case, you and I are definitely in agreement, you are simply misinterpreting my meaning: Admin vs. Non-admin rights and accesses are VERY CRITICAL, in my opinion! Thus, Microsoft should NOT list those items as "Warnings;" instead, they should have some Red or Orange color showing more seriousness and label them on BOTH screens as "Serious issues;" warnings, as in this case, tend to indicate "something that DOES NOT prevent your system from running." So again, MS is NOT being consistent, since they label one screen as "Critical" and the other screen as only "Warnings." To me, it should show more seriousness (even thought it does not stop the farm from running). Hope that's clear.

    • Edited by TNJMAN Monday, February 11, 2013 7:56 PM critical vs. warning
    Monday, February 11, 2013 7:30 PM
  • Yes, the one part where the server farm account requires local administrator rights is when setting up the user profile synchronization service. Once this is service is started you should remove the server farm account from the local administrators group and restart the servers.

    Jason Warren
    Infrastructure Architect

    Monday, February 11, 2013 7:57 PM
  • I removed the Farm account from the local Administrators group and clicked Reanalyze Now. Unfortunately, it's still showing this error.

    Any other suggestions?


    • Edited by hhancock Monday, March 24, 2014 8:56 PM
    Monday, March 24, 2014 8:56 PM
  • Dear, I resolved it as follows:

    1. remove farm account from local admins.
    2. stop the SharePoint timer service.
    3. start it again.
    4. reanalyze the error from the central admin.
    5. add the farm account again locally on every machine.

    BR

    Ahmed Samir

    Support Engineer Linkdev

    Monday, October 20, 2014 12:28 PM