[ISSUE]
A customer was running into a strange issue with documents that were located in a document library which had strict permissions, but the documents were returned in the search results to all users AND users were able to open them. So it looked like SharePoint didn't obey the security settings.
[SITUATION]
In the past someone played around with the anonymous access setting. Because the environment is used as an intranet this was not supposed to be configured, so we disabled anonymous access on web application level. A few weeks ago, we noticed that users were able to open sites and documents even though they did not have permissions to it.
[CAUSE]
After some investigation and checking with Microsoft it turns out that SharePoint had some left over anonymous settings. Even though anonymous access was disabled at web application level, users were still able to access the documents anonymously.
As it turns out does the disabling anonymous access on the web application level only remove the administration pages of anonymous access, it does not remove all settings that have been configured before that. To make matters worse, we even ran into an extra issue:
After we re-enabled anonymous access, configured anonymous access on site level to None instead of Entire Web Site and a full crawl ran, the documents were still returned and available for users. Some more investigation turned out that, just like permissions, the anonymous access settings were also copied when breaking inheritance. Picture the following situation:
- Enable anonymous access on the web application
- Configure anonymous access on a top level site to Entire Web Site
- Break the permissions inheritance of a document library and change the permissions
- Set anonymous access on a top level site back to None
- Disable anoymous access on the web application
In this situation, because the permissions inheritance was broken when its parent has anonymous access configured, the document library also has anonymous access configured. The only way to correct this through the GUI is to enable anonymous access on the web application level AND site level, so the anonymous access administration pages are enabled again on the document library.
[BACKGROUND]
Basically what happens: If you remove anonymous access form the web application only, on the webs it remains set. In case of the document library. By default it inherits permissions form its parent. The permission inheritance most probably was broken on the doclib when anonymous access was still enabled. The permissions were copied from the parent and the anonymous access remained enabled.
[SOLUTION]
In order to fix this issue, I have written a PowerShell script which loops through the site collection, checking each web and each library or list. If it encounters a web or list that has anonymous access configured, it disables that access.
[Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
$site = new-object Microsoft.SharePoint.SPSite("http://<site collection url>")
foreach ($web in $site.AllWebs) {
$web.Url
if ($web.AnonymousPermMask64.ToString() -ne "EmptyMask") {
$web.AllowAnonymousAccess
$web.AnonymousPermMask64
$web.AnonymousPermMask64 = [Microsoft.SharePoint.SPBasePermissions]::EmptyMask
$web.Update()
}
foreach ($list in $web.lists) {
if ($list.AnonymousPermMask64.ToString() -ne "EmptyMask") {
$list.DefaultViewUrl
$list.AnonymousPermMask64
$list.AnonymousPermMask64 = [Microsoft.SharePoint.SPBasePermissions]::EmptyMask
$list.Update()
}
}
$web.dispose()
}
More info
