An interesting quirk was discovered at a customer site recently. They have a single SharePoint farm hosting their internet-facing public “www” site, and were using in-place web content management…. meaning they had a single web application that was extended to the “Internet” zone, and the internet zone had Anonymous enabled.

After deploying the environment it was discovered that any user could browse the internal WCM site…. which was a bit of a surprise. Authentication was turned on, and the users that appeared to have been granted access didn’t have any explicit rights on site. This was accurately reflected in the site itself… they could get in on the internal URL, but they couldn’t actually do anything on the site. The expectation was that, because no rights were granted users would see the typical “Access Denied” message… but this wasn’t happening. They could browse around at will.

After discussion with various people and some members of the SharePoint product group a realization was made: Anonymous access is controlled at the site collection level… and the site collection itself is shared between zones.

Why is this so important?

It has to do with what SharePoint considers an “Anonymous” person to be. In SharePoint 3.0/2007, an “Anonymous” user essentially amounts to (ignoring some technical details) “Any user that does not have explicit permissions either individually or through a group”. This allows the “Anonymous” user that is configured on each IIS site (generally “IUSR_xxxx”) and which varies on each machine to be able to access the SharePoint content without requiring a separate login.

This also makes any authenticated user that does not have explicit rights have the same permissions as those anonymous users. They may be “authenticated”, but they’re still essentially “unknown” to SharePoint… just as unknown as the IUSR_xxx anonymous account is… so SharePoint treats them as “anonymous” despite being authenticated.

The functional impact is fairly low… the authenticated-but-anonymous users can only see what they could otherwise see on the truly anonymous side (in the Internet zone)… there are no additional capabilities granted to them other than seeing the content in the Default zone. In this instance, the customer was very concerned about their authenticated users having access to this otherwise private side of the public site, and rules were created that facilitated this in the web.config file for that web application zone’s path… but I’m not sure I see what difference it makes.

Regardless, this was very interesting… and one of those strange quirks about SharePoint that can throw you for a loop. I’m still waiting to test this in 2010 to see if things are any different.