Wednesday, November 23, 2011

"Authenticated users" and the taxonomy hidden list

When provisioning a new SharePoint site, a few groups are automatically created for you. With most templates you automatically get a visitors, members and owners group. On publishing sites and record centers you get a lot more.

For a new Team Site, the "All Groups" page initially looks like this:


5 groups, most of them are pretty obvious. But what is this "Authenticated Users" group doing here? Basically, this is a group that is available through IIS and contains every user that can be authenticated by IIS, i.e., have their identity verified. For instance, all AD users automatically fall into this category.

From TechNet:
SID: S-1-5-11
Name: Authenticated Users
Description: A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.

If you want to know what permissions a group has within your site, SharePoint 2010 offers us the very useful "Check Permissions" option in the Site Permissions screen:


This shows us the Authenticated Users haven't got any permissions on our site.

So... an over-active user with spring cleaning in mind, could be forgiven for deleting this group from the site collection. This is pretty easy and you only get a very nondescript warning message:




However, the permission listing does not take permissions on hidden lists in account. Specifically the Taxonomy Hidden List (which is used for caching fields from the managed metadata service application), has some interesting permissions:


(Reach this list at [site]/lists/taxonomyhiddenlist)

Removing the Authenticated Users from your site will also remove their permissions from this list. It will cause strange behavior in your site. List views with managed metadata columns will suddenly have blank values. Edit and view forms for list items may show unauthorized exceptions. However, for site collection administrators everything will continue to work, so the problem may not be directly obvious. And when the action and the moment problems are reported lay further apart, trouble shooting becomes a challenge.


Bottom line: never remove the SharePoint groups that have been created for you by features or deployment

Further reading: A good post on the inner workings of the Taxonomy Hidden List


Update: The same problem can occur with the masterpage gallery. The publishing feature sets some limited reading rights on the gallery for all authenticated users. Removing these permissions will result in access denied on edit mode for pages for all users, including associated owners. Only site collection admins will still be able to edit pages.

10 comments:

  1. Great, saved my day!

    ReplyDelete
  2. Great to know. I was about to delete the group as part of figuring out why custom sitemapnodes were still displaying even though a user does not have rights to the target URL.

    ReplyDelete
  3. On my site there still are no anonymous access to a managed navigation termset. I'm using the JSOM to get the values and authenticated users can see it but not anonymous users. The list you mentioned shows that anonymous users have "view items" access and there really isn't a way to do more than that without giving them add or delete or something.

    ReplyDelete
    Replies
    1. Hi Matt,

      I'm not sure you will be able to expose the contents of the term set to anonymous users via the web services. This is a different scenario then using the OOTB managed navigation controls which do the access to the term store server side (which does work).

      Delete
  4. Hi, I have this issue that visitor's can't see the metadata navigation top bar. I granted access to he TaxonomyHiddenList to all authenticated users but it still remains hidden for visitors.
    I don't want to add read permissions to authenticated users on web application level as I don't want them to access some subsites.
    Besides it doesn't help (it's still hidden).
    Can you please help me?

    ReplyDelete
    Replies
    1. This article is pre SharePoint 2013. I'm actually not sure how the permissions for metadata navigation are resolved. I would start at the permissions on the Managed Metadata Service Application and the term stores used for navigation.

      Delete
  5. great information!

    ReplyDelete

Rating