Tag Archives: Microsoft SharePoint

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.

SharePoint Custom Content & Structure Report

I came across some really cool functionality in SharePoint 2007 today…. 

One of my clients has a deep hierarchy of sites and pages maintained in SharePoint – this hierarchy drives content management for their web site.  Most of the publishing pages on their site have an embedded boolean field, called “Appear on Home Page” as part of the page content type, which controls whether elements of the data contained in the page are featured on the site home page. 

My client wanted a roll-up view across the whole site of all pages where the “Appear on Home Page” field was set to “yes” so they could administer home page articles in one location rather than searching across the hierarchy manually.

Those of you familiar with WCM in SharePoint 2007 may know about the various “Content and Structure Reports,” available via either “Site Actions” menu or within the “Content and Structure” view under the view menu.  These reports traverse the site hierarchy looking for pages meeting certain criteria and display the matching pages as a list.  Users can then view/edit/delete these pages, like they would any other collection of pages contained within document libraries. 

How neat it’d be to create custom reports similar to those shipped with MOSS.


Turns out that adding your own “Content & Structure Report” into SharePoint is trivially easy:

  1. Access the “Content and Structure Reports” list at /Reports%20List/AllItems.aspx
  2. Add a new list item and set the CAML query field to the expression required, in my case:

    <Where><Eq><FieldRef Name=”Appear_x0020_on_x0020_Home_x0020_Page”></FieldRef><Value Type=”Integer”>1</Value></Eq></Where>

  3. Presto, the new report is available.

“Submit” ASP.NET and SharePoint

One of my developers and I ran into an interesting problem today – we’d migrated a web site over to SharePoint 2007 (using a popular content migration tool) and found that all page postback calls in SharePoint were giving JavaScript errors, specifically:

Object doesn’t support property or method.

Turns out that our master page and page layouts contained input controls (text boxes) with name/id as “submit”.  Use of this reserved name sent ASP.NET’s JavaScript code into a tailspin and wrecked havoc with any postback submissions.

So, when you develop web sites in ASP.NET and/or SharePoint, be inventive with names for your buttons, text boxes and hidden fields – how about btnSubmit 😉

I read somewhere else that naming the main ASP.NET form “default” is a no-no also.

SharePoint Designer and SharePoint Out of Sync

If you ever find yourself in a situation where SharePoint Designer insists that a master page, page layout, or CSS file is checked out and the same file in the SharePoint Gallery is shown as checked in then there is a problem with your SPD web cache.  Attempting to check the file in through SPD gives the error:

“Cannot perform this operation. The file is no longer check out or has been deleted.”


Locate the WebsiteCache directory below and delete it:

Vista: %UserProfile%AppDataLocalMicrosoftWebsiteCache

Windows 2003/XP: %UserProfile%Local SettingsApplication DataMicrosoftWebsiteCache

MOSS – Save Publishing Site as Template

Those of you who like to use the “Save Site as a Template” functionality in SharePoint might wonder where the option disappeared to; when the site you have in mind for your template is a Publishing Site (Web Content Management)…

The official word from Microsoft is that this functionality is not supported for publishing sites and the option is removed from the site settings.  However, the link to the ASPX page still exists, so the following URL snippet will enable you to save a publishing site as a template – real handy if you’ve customized the hell out of your site with content types:


SharePoint Fixes and SP1

I’m sure I’m not the first and I’ll not be the last to mention that SharePoint SP1 is now available – think of this post as Rob’s own personal reminder.  If you know about this news then all is good, if not then you learnt something today.


In addition below is a neat blog post with a whole list of hot fixes for WSS and MOSS, some part of SP1 and some not, thanks Sammy:


but wait… there’s more….

Official MS site about MOSS hot fixes:


Office MS site about WSS hot fixes:


..and of course I’d be rude not to link to the official SharePoint Group Blog:



Speaking Engagement – SharePoint User’s Group DC

I shall be speaking at the SharePoint User’s Group for DC (http://www.sugdc.org) on October 28, 2007.  If you’re signed up then I hope to see you at the event, otherwise it is not too late to get your ticket:  http://www.sugdc.org/events/conference.aspx

I shall be introducing the audience to Web Content Management in Microsoft Office SharePoint 2007.

Now that I’ve got the blog post out I better work on the slide deck for next weekend 😉

SharePoint 2007 – Lock down your site

Scenario:  You have a public facing web site in SharePoint 2007, and you have added form-based authentication for access to the secure areas of your site.

The problem with SharePoint 2007 is that out of the box behavior assumes access to the application pages (_layouts) for authenticated users.  Security trimming will prevent access to pages that users have no access, but not all of the application pages.  It would be jolly nice if you could lock down your site and prevent access to all application pages unless you are an super admin.  Fortunately there is a nice STSADM command that will perform this action for you:

Turn on lockdown mode for a site collection

stsadm -o activatefeature -url <site collection url> -filename ViewFormPagesLockDownfeature.xml

Turn off lockdown mode for a site collection

stsadm -o deactivatefeature -url <site collection url> -filename ViewFormPagesLockDownfeature.xml

Lockdown mode reduces permissions as follows:

SharePoint 2007 Web Services and Forms Authentication

It is probably no secret to most SharePoint developers that Microsoft provides web services to access SharePoint services. Unlike the traditional, object model approach, these web services provide a level of flexibility – client code does not have to execute on the same server as the queried SharePoint site. Client code can query SharePoint services from anywhere remote as long as the /_vti_bin/ relative URL of the SharePoint site is accessible.

Accessing a SharePoint web service usually involves an authentication step because some of the queried objects (lists) are not accessible to anonymous users, regardless of the access permissions of the web service.

When using the default NTLM/Windows authentication scheme, assigning a new System.Net.NetworkCredential object to the Credentials property of the service proxy object is enough to get you on the road. Thus so (C#):

proxyObj.Credentials = new NetworkCredential(“username”, “password”, “domain”);

However, if your site used forms-based authentication you need to do a little more work:

   1: // Authenticate
   2: Authentication auth = new Authentication();
   3: auth.CookieContainer = new CookieContainer();
   4: LoginResult result = auth.Login("username", "password");
   5: if (result.ErrorCode == LoginErrorCode.NoError)
   6: {
   7:     // No error, so get the cookies.
   8:     CookieCollection cookies = auth.CookieContainer.GetCookies(new Uri(auth.Url));
   9:     Cookie authCookie = cookies[result.CookieName];
  10:     Lists lists = new Lists();
  11:     lists.CookieContainer = new CookieContainer();
  12:     lists.CookieContainer.Add(authCookie);
  13:     lists.GetListCollection();
  14: }

In the example code above, Authentication is the proxy object to the /_vti_bin/Authentication.asmx service and Lists is the proxy object to

/_vti_bin/Lists.asmx service.

The authentication service passes the supplied credentials to SharePoint, which in turn uses the current membership provider tied to the forms-authentication scheme. Upon successful authentication, the code above extracts the returned cookie (containing the security ticket) and passes it to the lists web service as part of the subsequent call.