NOTE: In this article, I discuss making some changes to SharePoint which are unsupported by Microsoft. As an employee within the Support realm, I want to stress that the CheckPermissions() solution below is currently unsupported by Microsoft — if you make the change, you are on your own. 🙂 That said, I have gone ahead and discussed some of the ramifications of making the change, because I think that the solution is a good one despite its being unsupported. In short — you’ve been warned.
You might have noticed that authenticated users granted Reader access to a SharePoint site also have access to the Site Settings page: _layouts/<LCID>/settings.aspx. Although these users will typically have no rights to access any of the pages linked therein, it might be desirable to remove access to the settings.aspx page altogether, so that non-Administrative users don’t even have the option to see what can be done from an administrative perspective. Honestly, I’m really not sure why this page is able to be viewed by non-Administrative users to begin with, but that’s irrelevant; it is viewable, and I want to change that.
I have two options, one supported and one unsupported
1) Somewhat complicated, but supported: write a wildcard-mapped ISAPI extension
2) Simple, but strictly not supported: drop a CheckPermissions() call onto the settings.aspx page
I’ve covered both of these options in more detail below:
Although writing an ISAPI extension isn’t a particularly simple task, and requires knowledge of C++ programming, etc., it is a possible (and supported) solution. Essentially, I would need to create an wildcard-mapped ISAPI extension that examined each request. I would start by checking the requested URL by looking in the VTI_SCRIPT_NAME server variable. If that request was for a _layouts page (settings.aspx in particular), my ISAPI extension could check the authentication type and/or authentication user from the server variables (AUTH_TYPE, and AUTH_USER).
If, for example, the AUTH_USER server variable were blank, the ISAPI extension could redirect by posting a 302 Redirect to some other URL — including, for example, a custom error page somewhere.
The IIS SDK includes ISAPI extension samples, including a wildcard-mapped ISAPI extension sample. Here’s a link to the Platform SDK Update site, where you can obtain any of the various platform SDK modules:
I would start with the WildcardMap sample provided in the SDK (…\Microsoft SDK\Samples\web\iis\ISAPI_6.0\WildCardMap). This sample is specifically designed to capture *every* request. To use this with IIS, I’ll need to register the built ISAPI extension within IIS.
NOTE: With Windows Server 2003 and with SharePoint Portal Server (or Windows SharePoint Services), there are some additional steps required to get the ISAPI extension functioning, which I cover below.
Once built, I can simply open up the IIS management console, right-click the web site I want to register the ISAPI with to get the web site properties, and choose the “Home Directory” (or “Virtual Directory” if this is a virtual directory rather than a web site) tab.
Click the “Configuration…” button to open the “Application Configuration” dialog. Under the “Wildcard application maps” section, choose “Insert…” and enter the path to my built DLL (or choose “Browse…” to find it). IMPORTANT: to use an ISAPI extension with Sharepoint, I must UN-check the “Verify that file exists” checkbox.
Apply all of those changes to the web site or virtual directory.
Next, in IIS management console, I select “Web Server Extensions.” This will bring up a list of the allowed and prohibited extensions. I’ll need to click on “Add a new Web service extension…” give the Extension a name, provide a link to the built DLL, and set the status to “Allowed.”
At that point, my ISAPI extension should be ready to work.
There *is* an alternative workaround, which — unfortunately — is not supported by Microsoft. If I open one of the various administrative ASPX pages in Visual Studio.NET (or Notepad, for that matter) and view the code, I can see that there is an explicit check for role-based permissions. For example, in User.ASPX, which is located at x:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Template\Layouts\1033\user.aspx, the line of code which checks permissions looks like this:
<% spWeb.Permissions.CheckPermissions(SPRights.ManageRoles); %>
This line checks to see if the current user has the ManageRoles right. If so, the user is allowed to view the page; if not, the user is prompted for authentication. In contrast, the Settings.aspx page — the first that a user sees after clicking on “Site Settings” in a WSS site — contains no such permissions check.
The SPRights enumeration is covered in the MSDN Library at the location below:
This enumeration contains various rights that can be assigned to a user. For example, the ViewPages right allows a user to view pages within a WSS Site. It would be possible — though, again, not supported — to add a line of code like the one above to the various administrative settings pages that you wanted to restrict to Administrative users only. For instance, if I wanted to restrict access to the Settings.aspx page only to users who have the ManageWeb right, I could include the following line of code in settings.aspx (existing/surrounding code included for reference, new code in bold):
SPWeb spWeb = SPControl.GetContextWeb(Context); %>
<% spWeb.Permissions.CheckPermissions(SPRights.ManageWeb); %>
With this code in place, when a user attempts to go to the settings.aspx page, Sharepoint will check to see if they have the ManageWeb right; if so, they can view the page — if not, they’ll be denied access and prompted for credentials.
The big caveat, as I’ve mentioned, is that this solution is not supported by Microsoft. We do not support making any direct modifications to the code used in any of the pages in the LAYOUTS directory. What this means is that if you were to apply this change and later were to run into any problems on your server, Microsoft PSS would require that the change be rolled back before any assistance could be given. Additionally, Microsoft has reserved the right to overwrite any of the default (out-of-the-box) files located in the LAYOUTS directory in any future service packs or updates. Such an overwrite would wipe out changes, so I would need to be aware of the changes that I’ve made so that I could re-implement in such a case.
There is one scenario in which this isn’t an issue: Anonymous access over the internet. If I have setup a SharePoint site to allow anonymous authentication, and a user browses to my site, they can view pages such as default.aspx just fine. As soon as they attempt to view settings.aspx, though, they will be prompted. Because the user is not on my domain, Windows Integrated authentication cannot negotiate authentication to settings.aspx, and the user will be prompted.