Wednesday, September 23, 2009

[MOSS/WSSv3] Anonymous access causes documents to appear in search and accessible for users

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.

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.

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.

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.

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=, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
$site = new-object Microsoft.SharePoint.SPSite("http://<site collection url>")

foreach ($web in $site.AllWebs) {
if ($web.AnonymousPermMask64.ToString() -ne "EmptyMask") {
$web.AnonymousPermMask64 = [Microsoft.SharePoint.SPBasePermissions]::EmptyMask

foreach ($list in $web.lists) {
if ($list.AnonymousPermMask64.ToString() -ne "EmptyMask") {
$list.AnonymousPermMask64 = [Microsoft.SharePoint.SPBasePermissions]::EmptyMask

More info

Tuesday, September 22, 2009

[MOSS/WSSv3] Error 1387 when removing users from Farm Administrators group

Today I tried to remove the user accounts from the Farm Administrators group, that have left the company a while ago. Unfortunately I was unable to do so, SharePoint presented me with an error 1387.

Using Google I ran into the following blog post Unable to remove user from SharePoint Farm Administrators group : Error 1387. Here Tim was talking about the fact that the accounts were deleted and SharePoint was performing some kind of check.

After temporarily recreating the accounts of the users, I was able to delete the accounts from the group successfully!

Tuesday, September 08, 2009

[MOSS/WSSv3] SharePoint 2007 build numbers

Here a list of build number of SharePoint 2007. Based on the build number you can determine which patchlevel your SharePoint environment is on: - MOSS 2007/WSS 3.0 June '09 Cumulative update - MOSS 2007/WSS 3.0 April '09 Cumulative update - MOSS 2007/WSS 3.0 SP2 - MOSS 2007/WSS 3.0 February '09 Cumulative update - MOSS 2007/WSS 3.0 December '08 Cumulative update - MOSS 2007/WSS 3.0 August '08 Cumulative update - MOSS 2007/WSS 3.0 Infrastructure Update - MOSS 2007/WSS 3.0 post-SP1 hotfix - MOSS 2007/WSS 3.0 SP1 - MOSS 2007/WSS 3.0 October '07 public update - MOSS 2007/WSS 3.0 August 24 '07 hotfix package - MOSS 2007/WSS 3.0 RTM

You can find the build number of your environment via:
Central Admin > Operations > Servers in Farm

[MOSS2007/WSSv3] "The expected version of the product was not found on the system" while installing update

I just tried to install the June Cumulative Update on a test environment. After the "Running detection" step, I got the following error:

"The expected version of the product was not found on the system"

Some troubleshooting revealed that we had installed SP2 for WSS and MOSS on the environment, but not for the installed language packs. After we installed SP2 for the WSS and MOSS Language Packs, the update installed just fine.