SharePoint Security for the contents in _layouts, _controltemplates and _vti_bin directories in the context of SharePoint NTLM authentication

A SharePoint web application can be accessed through multiple IIS web sites with different authentication such as NTLM, Kerberos and Form. It is important to differentiate a SharePoint Web Application and the IIS Web Sites accessing the SharePoint Web Application. Typically, each IIS Web Site accessing a SharePoint Web Application will correspond to a zone in SharePoint's Alternate Access Mapping. Each zone has a public address and multiple internal addresses. The multiple internal addresses typically map to addresses for load balancing.

The article discusses the authorization on accessing the files in _layouts (application pages and resources), _controltemplates (user controls and resources) , _vti_bin ( web services) in the context of an IIS Web Site or Zone configured with NTLM authentication.

If an IIS Web Site to access a SharePoint Web application is configured with NTLM authentication, the authorization to the contents in those directories is mostly determined by ASP.NET 2.0 Windows authentication mechanism.

When a SharePoint IIS web site is configured with NTLM authentication, the web.config file of the web site has "Windows" as its authentication method. In Windows authentication, Asp.NET 2.0 actually relies on IIS to perform authentication (basic, digest and integrated). The IIS will produce a security token after the authentication and then pass the security token to ASP.NET. Then, ASP.NET will perform two types of authorization using the identity encapsulated in the security token.

1. URL authorization (You can edit the web.config files in _layouts, _controltemplates and _vti_bin to define URL authorization)
2. ACL authorization. This authorization does not occur for Form authentication.

It is important to realize both authorizations will apply. Therefore, even if a user has URL authority to access an ASPX or image file, he/she may still not be able to access them due to the failure of ACL authorization.

Notice, the "impersonate" will not affect the above process. It will only affect when you write server side code, for example, when you try to open a local file in your web part. SharePoint always has "impersonate" as true.

In SharePoint NTLM (not Form) authentication, accessing the files and resources in _layouts, _controltemplates and _vti_bin pretty much follows the two authorization methods (URL and ACL) of ASP.NET 2.0. However, there is just one exception to the rule. For ASPX pages in the layouts directory that inherits from out-of-box class Microsoft.SharePoint.WebContorls.LayoutsPageBase, the class will check if the current SharePoint user has "View Application Pages" permission. So, it is the third authorization methods applied to those pages.

Now add anonymous users to the mix. Like authenticated users, the authorization for anonymous users is pretty much determined by ASP.NET 2.0 with one exception that is the pages inheriting from Microsoft.SharePoint.WebContorls.LayoutsPageBase. There are some interesting things worth metioning:

1. URL authorization will use question mark "?" to denote anonymous users;
2. ACL authorization will use IUSR_MachineName account. (This account is configurable in IIS);
3. Anonymous users can never load pages inheriting from Microsoft.SharePoint.WebContorls.LayoutsPageBase;

The first two are just typical ASP.NET 2.0 way of handling security. The third one is really a surprise. SharePoint anonymous users by default should have "limited access" permission level that should have "View Application Pages" permission. However, anonymous users still cannot access the pages inheriting from Microsoft.SharePoint.WebContorls.LayoutsPageBase even with the "View Application Page" permission. I could not explain why and just remember that this as an exceptional scenario. To expose SharePoint Application Page to anonymous users, do not use Microsoft.SharePoint.WebContorls.LayoutsPageBase as its base page class.