[SP2010/SPF] Required permissions to run command line tools or other tooling that uses the OM

[ISSUE]
With SharePoint in many cases the SharePoint administrators also are the Windows of the SQL server and/or SQL administrator. This means that those persons also having loads of permissions in SQL Server, which means that everything will work without issues. They can do anything they want, using any tool they want.

But what about a situation where you don't have permissions on SQL. You will see actions via the Central Administration site work fine, however certain things like console applications (custom like SharePoint Manage or default applications like stsadm), scripts via PowerShell and other tooling (basically everything that uses the object model) won't work.

This is caused by the fact that SharePoint requires the account to have certain permissions on the databases in order for it to work. When using the Central Administration, this is done via the application pool account which has sufficient permissions. When using the object model outside of the Central Administration, this is done under the account the command is executed with.

[SOLUTION]
Then which permissions are required? Here is where it becomes a little tricky!

PowerShell scripts:

• When you are running SharePoint 2010 and you are trying to use PowerShell, Microsoft has created a SharePoint internal group called ShellAdmins. By adding your account to this group (Add-SPShellAdmins) your account has sufficient permissions to run PowerShell scripts. Other activities via the object model still don't work.

Other tools:

• To enable all object model activities, grant the account the following permissions:
• SharePoint (Depending on the activities you are going to do)
• Farm Administrator
• Permissions in the site collection(s), for example site collection administrator or contributor to a list
• Database:
• Configuration database: WSS_Content_Application_Pools
• Content database:
• Db_datareader
• Db_datawriter
• GRANT EXECUTE
• NOTE: An alternative would be db_owner permissions on the content database, however from SQL administration perspective this might be unwanted/against policy

NOTE: I am assuming that the account already has local administrator permissions on the SharePoint server, how else will you be able to run tools or scripts on the SharePoint server :-)

More info: SharePoint 2010 PowerShell Permissions Explainedhttp://sharepoint.microsoft.com/Blogs/zach/Lists/Posts/Post.aspx?ID=56

[MOSS/WSSv3] Site Settings not visible, even when I am a site collection admin

[ISSUE]
Last week, I had to perform some restore activities for a site collection that became corrupt. When I was done, users reported that permissions were gone. After logging on I found out that I wasn't able to open the Site Settings. The Site Actions > Site Settings menu option was gone?!?!?!?

[SOLUTION]
After some troubleshooting I found out that during earlier steps, the site collection accidentally was set to Read-Only lock. That is why I wasn't shown any admin screens. When the lock was lifted, all started working again!

[MOSS] Event 5214 - The EXECUTE permission was denied on the object 'proc_FetchDocForUpdate'

[ISSUE]
The following event was occuring on our environment quite often:

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Database
Event ID: 5214
Date: 11/19/2009
Time: 4:28:54 PM
User: N/A
Computer: [SERVER]
Description:
Insufficient SQL database permissions for user '[account]' in database 'SharePoint_AdminContent_3995bd54-8091-4157-b162-8aaaf7116355' on SQL Server instance '[SQL SERVER]'. Additional error information from SQL Server is included below.

The EXECUTE permission was denied on the object 'proc_FetchDocForUpdate, database 'SharePoint_AdminContent_3995bd54-8091-4157-b162-8aaaf7116355', schema 'dbo'.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

[SOLUTION]
To solve this issue, perform the following steps:

• Open the SQL Management Studio
• Browse to the database in question, in our case "'SharePoint_AdminContent_3995bd54-8091-4157-b162-8aaaf7116355"
• Open the database and then Security > Roles > Database Roles
• In the right part of the window, right click the WSS_Content_Application_Pools role and click Properties
• Select the menu option "Securables"
• Click "Add"
• Select "Specific objects" and click "OK"
• Click "Object Types", select "Stored Procedures" and click "OK"
• Add the following stored procedures: proc_FetchDocForUpdate, proc_GetWebMetaInfo, proc_UpdateDirtyDocument, proc_UpdateListItem
• Click "OK" to add these stored procedures
• Select the added stored procedures and select "Execute" in the "Grant" column.
• Click "Add" once more
• Select "Specific objects" and click "OK"
• Click "Object Types", select "Views" and click "OK"
• Add the following view: UserData
• Click "OK" to add this view
• Select the added view and select "Select" in the "Grant" column.
• Click "OK" to complete

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

[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

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

[ISSUE]
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.

[CAUSE]
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.

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

[MOSS2007/WSSv3] Login box when a normal user logs on, but not with admin

[ISSUE]
A logon box constantly appears when a users is trying to log onto a SharePoint site. Whatever the user enters, he cannot get onto SharePoint.

[CAUSE]
The environment on which we experienced this behaviour was locked down according to security guidelines. One of these guidelines was to strip the "Read & Execute" permissions on the C:\Windows folder from the local users group. The .NET Framework requires Execute permissions on the C:\Windows directory to operate properly and because SharePoint relies on .NET, users were prompted for credentials.

[SOLUTION]
Add the Execute permissions for the Users group on the C:\Windows folder or restore the permissions on the C:\Windows directory to default:
- Open a command prompt.
- On a domain controller, run
secedit /configure /db c:\windows\temp\seceditsv.sdb /cfg "c:\windows\security\templates\DC security.inf" /log c:\windows\temp\seceditsv.log
- On a non-domain controller, run
secedit /configure /db c:\windows\temp\seceditsv.sdb /cfg "c:\windows\security\templates\setup security.inf" /log c:\windows\temp\seceditsv.log

[MOSS2007/WSSv3] SharePoint 2007 and Console Applications [UPDATED]

During a project, the developers created a console application which they wanted to schedule in Task Scheduler. This turned out to be a challenge because using console applications with SharePoint 2007 requires permissions on three locations. The service account will need to have the following permissions:

1.) Permissions on the SharePoint databases

• Open SQL Management Studio
• Go to Security > Logins
• Right click Logins and select New Login
• Enter account name and open User Mappings tab
• Select the master database, permissions public
• Select the config database (default SharePoint_Config), permissions public and WSS_Content_Application_Pools
• Select the content database (default format WSS_Content_), permissions public and db_owner

2.) Permissions on the SharePoint server

• Add the service account to the local administrator group (See update below)

3.) Permissions on the SharePoint site

• Grant the service account the required permissions in the SharePoint site
• For example: add to Site Owners group

[UPDATE] The service account doesn't need to be local admin on the server. You can use the following permissions as well:

• "Logon as batch job" in Local Security Policy
• Member of the local WSS_ADMIN_WPG group
• Grant the local group BATCH read permissions to C:\Windows\System32\cmd.exe to make sure the scheduled task can run batch scripts.