SharePoint Identity

SharePoint user identity is sometimes confusing for developers….

  • When connecting to external resources (like a SQL database via BDC) what user identity does SharePoint use? 
  • How does SharePoint impersonate when using forms-based authentication?
  • What’s the difference between a Windows user and a WSS User?
  • What is SPSecurity.RunWithElevatedPrivileges?

It’s questions like those above the can often lead to confusion – throw IIS authentication settings into the mix and developers too often find themselves scratching their heads as to why BDC (Business Data Catalog) or external resource access is not working.

My attempt at explaining impersonation within SharePoint is best summarized with the following table:

Authentication Windows Account WSS Account
Elevated FBA App Pool User SHAREPOINTSystem
Windows Windows User Windows User
Elevated Windows App Pool User SHAREPOINTSystem


SharePoint keeps track of two different user account types – Windows account identity, and internal WSS account.  SharePoint uses the WSS account to grant access to secured SharePoint objects – lists, documents etc.  The ASP.NET runtime, which SharePoint sits atop, impersonates the Windows account identity when executing a SharePoint web application, and it is this impersonation that dictates whether web parts or custom code logic is able to access external secured resources (files, SQL server etc).

Taking a closer look at the web.config for a virgin SharePoint site shows the following XML node:

    <identity impersonate=”true”/>

The above node allows the ASP.NET runtime to impersonate the windows account passed by IIS  (setting this to false restricts ASP.NET to run under the default worker process – typically the ASPNET local account).

Windows Authentication – SharePoint is configured by default to use Windows authentication (NTLM or Kerberos).  When the user attempts to access a secured page within SharePoint an HTTP 401 status code is passed back through IIS, which then causes the familiar Windows credentials prompt to appear in the browser.  After passing successful credentials; IIS authenticates the user and passes the windows user token on to SharePoint.  The SharePoint web site executes within this new authenticated user context.  In this authentication scheme the WSS account and windows identity account are synonymous – line 3 in the table above.

Forms Based Authentication – FBA is a completely different animal to Windows Authentication and is managed by ASP.NET rather than IIS.  By default IIS passes the standard IUSER_MACHINENAME local user account token to ASP.NET.  ASP.NET is configured to authenticate using forms by the following XML in the web.config file:

    <authentication mode=”Forms”/>

When ASP.NET detects FBA and a secured pages is requested by a user; the runtime looks for a known cookie, if the cookie is present the authentication succeeds, otherwise ASP.NET redirects the user to a login page.  Upon successful authentication the SharePoint web application runs under the IUSER_MACHINENAME user context.  The WSS account is depicted by the forms authentication identity, which is dependent on the membership provider configured in ASP.NET.  Example WSS account identities under FBA are SQL member accounts via the Local SQL Membership Provider or AD members accounts via the AD Membership Provider. 

Note: Authenticating against Active Directory using the AD forms-based membership provider is NOT the same as authenticating via Windows NTLM or Kerberos – in the former case the user context is still IUSR_MACHINENAME, where as Windows authentication receives the user token for the authenticated user from IIS.

Elevated Privileges

Anyone who has played with SharePoint object model has probably used the SPSecurity.RunWithElevatedPrivileges function.  This function allows access to secured SharePoint objects from the object model by changing the WSS user account context to SHAREPOINTSystem – a highly privileged user in SharePoint.  Calling this function also has the effect of changing the current windows user context to the current application pool user, configured in IIS.  In typical SharePoint farm installations, the application pool user is an AD user with restricted permissions and limited access to external resources, although typically this user has more permissions than the local IUSR_MACHINENAME user.

Good Practice

If you’re not concerned with FBA and/or anonymous access to your SharePoint sites then the anonymous account used by IIS is of no concern to you.  All you need to remember is that the elevated privilege method switches the current authenticated windows user to the app pool user, which is probably desirable if the app pool user is configured for external resources via BDC.  Most developers use this method to gain them access to secured SharePoint objects, but it is just as useful if you need access to external resources.

When setting up FBA with anonymous authentication scenarios it is important to be aware of the IUSR_MACHINENAME windows account in context.  For example, if you reference custom ASCX files in SharePoint page templates and these ASCX user controls live in a secured directory on the server; then you’re going to see request for credentials on your anonymous site. If you have a web part that needs to access a third party system or network resource then the IUSR_MACHINENAME account will prevent your web part from working.  Generally I suggest the use of SPSecurity.RunWithElevatedPrivileges function when accessing network/external resources.  However,  if you want to avoid a potential security hole because your code can now access any SharePoint object via SHAREPOINTSystem, then an alternative is to configure the IIS anonymous account as an AD domain account.

Hopefully this blog post has distilled the common confusion surrounding SharePoint identity, I know that I’ll be coming back to the above table from time to time.

5 thoughts on “SharePoint Identity

  1. Mina Shawky

    Thanks for this article… It is really helping me out… But I have something weird that I need to solve as it’s giving me a headache…

    I have a Sharepoint site… I enabled FBA, and I create my own Registration, login, modules (Normal aspx pages)… When a user registers for the site, he is added to the site using Elevated Privillages…

    The problem is when the user tries to login… he gets the Access Denied page… When I recycle the App Pool, login with an FBA Administrator account, then login with the newely created user… everything works fine… But when the session time ends, I must repeat the previous steps again…

    Do you have any idea what is happening here, cuz i’m getting lost

  2. Artur

    Sometimes it is better to run some of your pages in another application than Sharepont (just to have isolation). Then you may easily create your own IIS Web Application with your own IIS Application Pool and use <identity impersonate=”false”/> – all your code will be running under your Application Pool Identity then. In code you still may easily check who is accessing your site and which context you are running with this example

  3. robgarrett


    THe problem with your approach is as follows:

    1. You cannot make any calls to the SharePoint object model that uses SPContext.
    2. Calls directed to SharePoint using SPSite with a Guid or URL still fall under the issue of identity because depending on the identity of the code running the OM call, still need to use SPSecurity.RunWithElevatedPrivileges
    3. If you control has any UI component, hosting outside of SharePoint means using the Page Viewer web part, which a packaged IFRAME control – subpar at best
    4. The blog post you refer only works for Windows authentication, FBA is a different animal
    5. Hosting a separate application outside of SharePoint in an isolated application pool incurrs unecessary overhead to run two app pool process. Intercommunication requires remoting or WCF to communicate across the process boundary.

    On a general note, I really would not recommend your approach.

Comments are closed.