Give Us a Few Minutes to Lock it Down. Large Leak, Very Dangerous.

In This Post:

1. What is Lockdown mode?


2. When would I want to use it and when would I Not?


3. Caveats and quirks when switching Lockdown mode on/off (enabling/disabling).


4. Doing a partial or custom Lockdown.

Background

So I've been struggling for about a week trying to allow anonymous users to be able to post to a Sharepoint List.
The Site was already configured for anonymous access (TechNet article on configuring anonymous access), and anonymous users were successfully navigating throughout the site -- but try to go to a page with a form that posts to a list -- or even to the default List view itself, and it would prompt for credentials and deny access.

Lockdown Mode

Turns out there's this little hidden Feature (literally, the xml definition of the Feature marks it as hidden, so it won't show up on the Sharepoint Administration GUI for enabling/disabling installed Features), called "Lockdown". Most of the time, this Feature is disabled unless an administrator explicitly enables it -- the exception being if you base your site on the Publishing template, then it is enabled by default.
The purpose of this feature is to hide certain non-friendly/admin type pages from anonymous users. For the "official" details on Lockdown mode, including the stsadmin commands for enabling/disabling this feature, hit this TechNet article. So, for example, the "View all site Content" (ViewLsts.aspx) page -- under most circumstances, all users can see this page. If your site is configured for anonymous access, then even anonymous users can see this page. Permissions still work correctly, if the user clicks on a link from the All Site Content page to something they don't have permission for, it does correctly deny access -- but if you're really trying to make your site a public/anonymous access site, you probably wouldn't want them to even see this page. Hence the Lockdown feature, and hence why it is turned on by default on Publishing sites.
Unfortunately, this also has the side effect of blocking anonymous users from Lists. Arrg!

When to Use (or Not) Lockdown

Now, some of you are reading this and saying
"Aha! Lockdown! Brilliant! That's exactly what I need!", and some of you are saying
"Arg! Lockdown! $@*{#&%! That's the source of all my problems!"
If you are using Sharepoint solely for its content management features for a public/anonymous site, then Lockdown from lists, admin pages, and other forms is exactly what you want -- but if you want to take advantage of some (or even just one) of Sharepoint's other features on your anonymous site, you'll probably want to ditch Lockdown (and yes, if you read further, I'll tell you how to do a kind of "partial" Lockdown).

Problems with the Lockdown Switch

So here comes the real fun part -- after disabling the Lockdown Feature, it didn't seem to take affect! Everything still acted as though it was in Lockdown. After trial and error and some Googling, I found that whenever you change this Feature, you have to then disable and then re-enable Anonymous access for the Site before the change takes affect (or use the brute force method and reboot your whole farm). Fine and dandy, but then it still didn't seem to affect List access -- which was the whole reason I wanted to disable this feature in the first place. This sent me back to just "playing" with permission settings, turning the Lockdown Feature on/off and just generally spinning my wheels, until, suddenly, something I did gave anonymous users access to the List. So then I started backtracking to figure out what I did. Turns out that if your List is NOT inheriting permissions from parent (i.e. you have customized the List permissions), then it does not pick up the change in the Lockdown Feature. Similar to the Site level anonymous access, you have to revert the permissions to "Inherit from Parent" before the change in the Lockdown Feature takes affect on that List. In my case, I want anonymous users to be able to Add to the List, so I have to break inheritance on permission in order to grant them write access, but if we change the Lockdown feature, we will have to once again revert the list to Inherit, and then back to customized permissions for the Lockdown change to take affect. So, finally, I had anonymous write access to my Lists.

Partial Lockdown

Trouble was, now anonymous users had access to ViewLsts.aspx, and a couple of other things we would rather them not. There's no configuration to the Lockdown Feature, it's either On or Off (If there's anyone from the MS Sharepoint Dev team that happens to stumble across this article, being able to configure which parts of Lockdown are enabled, and maybe even doing it through the GUI for those with command-line-aphobia would be a nice-to-have).
So I reverted to the "old fashioned" .Net technique: edit the web.config file. Within the configuration section, you can place a location element that specifies Deny access to unknown/anonymous users. If you search in your web.config, there is likely already similar entries made by Sharepoint.

  <location path="_layouts/viewlsts.aspx">
    <system.web>
      <authorization>
        <deny users="?" />
      </authorization>
    </system.web>
  </location>

In the path attribute, you can specify a specific page/file, or a whole directory (no trailing slash) -- although wildcard characters in the filename did not seem to work (actually caused parsing errors). All paths are relative to the root of the Site.
Use it with caution, and test the result -- I tried locking down the entire "_layouts" folder, since our custom form for the List resided with the rest of our content under Pages, but weird promptings for credentials occurred even on pages that did not exist under "_layouts".
Note that [users="?"] means unknown/anonymous users, [users="*"] means All users. Deny access in the web.config trumps any permissions/access configured in Sharepoint.
A slight drawback, note that if you have multiple front-end web servers hosting this Site in your Sharepoint infrastructure, you will need to copy the web.config file to each of them.