Reza Alirezaei’s Blog

These days many public-facing sites allow users to view pages and perform some limited actions anonymously against various functionalities those site offers to their audience. Turning on anonymous access really requires thorough considerations and planning in advance because everyone visiting your site will be able to access the landing page at minimum and from there they have limited access to other parts of your site. This potentially can lead to a situation in which unauthenticated users can contribute to your site to an extent, use up server resources, discover users personal information and the content that you may not want them to be exposed to the public. Fortunately, in both Moss and WSS , you not only have the option to enable/disable anonymous access , you also have a fantastic granular control over how anonymous user experience should be when interacting with your site. This makes it a lot easier to turn a SharePoint site to a public-facing site exposed via internet which was one of the main goals in WSS 3.0 and MOSS 2007. In this article, I would like to give you a quick tour of how to enable anonymous access and what issues you or your anonymous users might face during this exercise. In part 2, I will be writing about some of the existing workarounds and solutions and finally in Part 3 I will be demonstrating how to turn them all into an even better (more real life) solution by coding the missing parts.

Through out these articles I assume that you have a basic understanding of forms based authentication (a.k.a FBA), you have created a site in default zone (a.k.a authoring zone) and extended it to an Internet zone (a.k.a public facing zone). Your default zone in protected either by NTLM or Kerberos and your internet zone is using a custom authentication provider. Now that you are ready , let’s get rolling!

Anonymous access must be granted at the web application level at the time that you create the web application and zones. It is a check box that you select and the end result is a <allow users=”*”/> element that is added to the web.config of the Zone for which anonymous access is enabled. Yes, you can always go back and enable or disable this by going to “Authentication Providers” page in Central Admin as illustrated in picture 1.

Picture 1

Here is what would be added to the web.config when anonymous access is enabled.

For anonymous users to be able to get to your SharePoint site via internet they have to cross two barriers:

I) IIS barrier : As I alluded to earlier, IIS barrier is handled in the web.config when you set up the zone to allow anonymous access in Administration Site.

II) SharePoint barrier : Site Administrators have to tell SharePoint to allow anonymous access by browsing to http://yoursite/_layouts/setanon.aspx and granting the right access control for anonymous users (Picture 2). You need to repeat this for all sites unless permission inheritance is turned on.

NOTE: if the <authorization> tag is not present in the web.config, then setannon.aspx has all its options grayed out.

Picture 2

In additions to the settings in setannon.aspx page , each document library or list has separate settings for anonymous users in order to control how they can access and interact with the content.

Document Library :

Picture

Custom List (Called Annon List):

Picture 4

As saying goes, the devil always lies in the details. Okay , what are the problems regarding the annonymous users in SharePoint? I am glad that you asked!

1) Anonymous access relies on the anonymous user account on the web server (IUSR anonymous account).

• In an FBA scenario where users are authenticated against a custom identity store and not AD , there is not a real configurable identity for anonymous user. This makes audience targeting at anonymous users (MOSS only) a bit challenging. For example when showing a web part targeted at people who have not signed in or a message shown to anonymous users only.
• Even in the default zone where IUSR anonymous account can be resolved, audience targeting at this account won’t work.

2) No matter what kind of permissions you grant to your anonymous users , there are still some restrictions when they interact with your site:

• Anonymous users can not upload, edit or attach files in Document libraries including Wiki libraries. This applies to both your authoring zone (which is always supposed to be protected by Windows Integrated Authentication) and FBA zone such as Internet zone. Look at the picture 3 above and note how some of the options are grayed out by default.
• Anonymous users can not fully contribute to Lists, discussions or surveys. For example , they cannot attach files to the list items (FBA zone only). As shown in the picture 4 above , in custom lists you can specify that Anonymous users CAN add items to a list. Well, an item might include an attachment right? , but in actuality when they attach a file to the item they will be redirected to a log in page. It simply means that they CAN NOT. 😉

I have tried above limitations in our custom list and for both zones. below is the result:

Picture 5

I don’t really mean to insult your intelligence , but just as FYI , thumbs are not part of the List – I just added them to the picture to show you which operations went through without requiring anonymous user to log in 🙂

3) (Credit to Doug Ware – See his comment below and his post here) Turning on anonymous access in one zone has the unfortunate behavior of giving all authenticated users the same rights as an anonymous user on all of the zones in the web application.I (as Doug Ware :)) encountered this recently when I had one zone set up that did not allow anonymous access and the Restricted Read permission level. I extended the site to another zone and configured it for anonymous access to the entire site. The members on the original zone were then able to browse the list because the configuration gave them more rights than Restricted Read even though the zone they were using was not configured for anonymous access! Based on my reading of the documentation it was by design.

Now that you know some of the issues with regards to anonymous access in SharePoint, let me walk you through couple of solutions in part 2.