Code, Code, Revolution!
I got involved in a mysterious user rights problem with a Sharepoint MOSS solution that we recently delivered to a customer. I wasn’t able to find much about this so I thought I’d share.
The problem was isolated to the main portal site collection which allowed everyone with an AD account to read pretty much all content in the site collection. All other site collections worked the way they were supposed to, which meant not allowing access unless it was given. Of course the first thing was to verify that anonymous access indeed was disabled and that the authenticated users group wasn’t given any rights. Further investigation gave the following confusing results:
After many hours of tests and code to check rights for different users against different sites etc I headed into the database to see if I could figure out what was allowing the access.
I’ve been poking around with user accounts in Sharepoint when I built a SAML 2.0 SSO service which included a provider for Sharepoint and also when moving a Sharepoint installation to a brand new AD which required syncing existing accounts. The problem was identified rather quickly in the “Perms”-table. Perms hold the ACL for different scopes (Sites/Lists etc) in a site collection. The portal site had a value in the AnonymousPermMask column and that was then inherited down to other sites. I have no idea how the perm mask ended up there nor why the administration GUI didn’t indicate that anonymous access was indeed activated. After verifying with Microsoft we took a backup of the database and simply removed the perm mask with an sql update. There has been no complications after that, everything works perfectly.
With this blog I try to provide useful tips and solutions for programming .NET, Objective-C and more. My name is Björn Sållarp, and I love writing code.
Chris
November 19th, 2009 at 8:32 am
I just a similar problem, any user was able to browse and have read-rights to everything. Problem only started when inheriting from the root site.
Problem was that the site was originally set up to use Anonymouse access, later that setting was changed within Central administration, the problem was that the setting stayed on the site, but pretty hard to find.
Finally I found the setting to set to allow anonymous access on the whole site:
http://URL/_layouts/setanon.aspx?obj=http%3A%2F%2FURL%2CWEB
I just set it to Nothing and it worked!
-chris