EXPLAINED: What the SHAREPOINT\System account actually IS…

2012-11-24 MV: There’s a lot of confusion out there concerning the entity called “SHAREPOINT\System”. Many people have tried explaining what it is by explaining what to do (or not do) with it. It’s surprising just how LITTLE documentation is readily available from Microsoft on this – something I consider a very important topic toward understanding SharePoint.

Here is my own attempt at an explanation, but even I will readily acknowledge I’m still NOT convinced I understand all aspects of what I’m trying to explain.

First some background terminology – to make sure we’re on the same page:
Virtual Machine: a program running on a host OS, using a subset of the underlying physical resources. The program can be either an application interacting with the host OS, or an application interating with its very own guest OS, which in turn interacts with the underlying host OS as if it were actually all on a separate physical server. It’s important with SharePoint to understand that the concept of a “Virtual Machine” is not actually REQUIRED to have its own OS;  only that the code running as the Virtual Machine is somehow “self-contained” – e.g. has its own internal domain, resources (defined/set aside by an “application pool” in the outerlying IIS)  and process threads, and perceived as its own entity.

Runtime: A very UNintuitive term describing an actually-running “instance” of a Virtual Machine.

SharePoint Runtime (SPR): An actual running instance of the SharePoint Virtual Machine – a VM which sits on-top-of-but-apart-from the underlying host OS – and hence also has its own internal domain – JUST like the server OS does!


WHAT actually IS the account “SHAREPOINT\System”?

The account created/defined within the SPR’s own VM environment, used as the core security context in which the SPR actually executes all its internal code. But that’s not all…

The SPR is capable of (in fact it’s essential) interacting with other servers in the domain – like its associated Database server. When The SPR makes calls to the Database Server, or file servers, or LOB servers, it MUST do so while impersonating an account which has meaning to those “domain” systems. It must impersonate a DOMAIN account…

The SPR has in its configuration the ability to impersonate either of 2 accounts; it stores these designated accounts with the following configuration variables: �
1. portalSuperUser account (for writing/changing things); and
2. portalSuperReader account (for only reading things).

These should be non-human, domain-level service accounts defined by AD and SharePoint administrators with the above purposes in mind.

IMPORTANT (note- this is something about which I’m still NOT completely certain…):
The SPR maps the internal SHAREPOINT\System is mapped/bound to whatever account has been designated the Identity of the Application Pool hosting a given SharePoint web application.

During SharePoint 2010 installation, The Installation Program itself provides default settings for each of these accounts:
1. portalsuperuseraccount = <whatever the app pool ID is> ; and
2. portalsuperreaderaccount = “NT AUTHORITY\Local Service”

During SharePoint 2010 installation, The Installation Program sets the App Pool ID to whatever account was used to log into the server and start the installation; if this was a HUMAN account (e.g. PONDSCUM\mv1962), then the App Pool ID becomes “PONDSCUM\mv1962”

(Aside: When you run your code in under “elevated privileges” by SPSecurity.RunWithElevatedPrivileges, what is actually happening is that the code is running under the identity of the associated Application Pool, meaning this is as “powerful” as the code can get…)

IF a human (non-service domain) account was used during either SharePoint installation (which if you recall typically ends with the creation of a first web application, which includes creation of an application pool) or creation of a new web application (which also includes creation of a new application pool), then this account is what the SHAREPOINT\System account impersonates.
THIS is why when the person who installed SharePoint logs into SharePoint, the SPR (understandly) displays them as “System Account”;

WHEN/if you see “Access Denied” messages for the SHAREPOINT\System account, what is ACTUALLY happening is that the HUMAN account the SHAREPOINT\System account is IMPERSONATING is being DENIED access to a particular requested resource.

Typically SharePoint Administrators suffer for a long time, tear their hair out, then finally utter the following STSADM.exe commands:

1. Add 2  accounts in  Central Admin > Web Application Management > User Policy section.
2. After adding the accounts thru the Central Admin UI, execute the following scripts:
stsadm -o setproperty -pn portalsuperuseraccount -pv DOMAIN\user -url http://webappurl
stsadm -o setproperty -pn portalsuperreaderaccount -pv DOMAIN\user -url http://webappurl

The domain account(s) they specify are domain-level service accounts (NOT domain-level human accounts) with typically mad mad read privileges everywhere in their network universe, and SuperUser (Read|Write|Execute) privileges in the database server. From then on even the poor administrator who accidentally installed SharePoint 2010 with his/her OWN (human) account will now see their OWN names in the upper right hand corner of each SharePoint page, instead of “SHAREPOINT\System” or “System”…

And there’s the long answer to the short question.



Leave a Reply

Your email address will not be published. Required fields are marked *