SharePoint Developer Environment Security Primer

  • Article

SharePoint Developer Environment Security Primer

Confusion often surrounds what privileges must be granted to developers to build and deploy solutions on a development server. It would seem the developer can be added to both the local machine administrator and farm administrator groups; and then be able to do anything. Unfortunately, the first time the developer tries to deploy a solution to a web application there are access denied errors. What’s going on here? Shouldn’t local administrator group and farm administrator group membership allow the developer unlimited access? To answer this question we need to have a high level picture of the security model.

Homework Assignment

First, I strongly encourage reading the TechNet Article, SharePoint 2010 Architectures Overview (https://technet.microsoft.com/en-us/library/gg552610.aspx). If you don’t have time to read the entire article, at least read the first 3 paragraphs of the section entitled Worker Processes, Farm Solutions, and Sandboxed Solutions; in fact, read it over-and-over until you have it memorized. This is time well spent.

Parallel Universes (The Twilight Zone)

Have you finished this homework assignment? OK, let’s jump into some of the security complexities.

Think of security as 3 parallel universes (remember the old Twilight Zone TV show?). A user in one universe may be blissfully unaware of the other universes; for example, a machine administrator can be denied access to the SharePoint universe and/or SQL universe, and vice versa.

  • Universe One is the local server itself.
  • Universe Two is SharePoint farm, logically hosted on the local server.
  • Universe Three is the SQL Server, either a local or remote SQL instance. 

For a Universe One (local server) or Universe Three (SQL Server user) to cross into Universe Two (SharePoint farm), that user must be granted privileges within SharePoint; for example:

  • Added to the farm administrators group through Central Administration
  • Added to a web application user policy through Central Administration
  • Added to as a service application administrator through Central Administration
  • Added to a Site Collection group by a Site Collection administrator
  • Granted database access with the Add-SPShellAdmin cmdlet.

For a Universe One (local server) or Universe Two (SharePoint farm) user to cross into Universe Three (SQL Server), that user must be granted a SQL Server login and made a database user for one or more databases. SQL access is normally granted as a side effect of granting a user access to the SharePoint farm. See the prior bullets for ways this can happen. If you feel you have to directly grant database access, then you probably have something else wrong in your security design.

For a Universe Two (SharePoint farm) user to cross into Universe One (local server), the user must be added to local machine groups. This normally occurs automatically as part of SharePoint installation, or as a side effect of other actions such as executing the Add-SPShellAdmin cmdlet which implicitly makes the named user a local administrator (be sure this is what you intended). If you feel you have to directly add SharePoint users to local machine groups, with few exceptions you probably have something else wrong in your security design. An example of an exception where manual group addition is required is to add developers to the Remote Desktop Users group so the developers can RDP onto the server without having to be local administrators.

These disjoint, parallel universes is why a local administrator who is added to the SharePoint farm administrators group after the original installation cannot deploy solutions -- the user account cannot get from the SharePoint universe to the SQL Server universe.

Visual Studio 2010 Deployment

Visual Studio 2010 has a great automatic deployment feature. The developer can right click a project to deploy to a designated web application and Site Collection. Unfortunately, in situations where the developer is not a local administrator, this fails. Why?

To answer that question, we need to understand what Visual Studio 2010 is doing during the deployment. With the Visual Studio 2010 solution open, display the project properties, select the SharePoint tab, and then click the View button in the Edit Configurations section. This lists the steps being executed on the right side under Selected Deployment Steps.

Let’s take the default steps one-by-one.

  • Run Pre-Deployment Command:
    This is a non-issue. It will always work (barring pathological problems like running out of disk space or memory).
  • Recycle IIS Application Pool:
    Must be a machine administrator. This is why you need to start Visual Studio 2010 as an administrator. This also prevents Visual Studio 2010 deployment if you don’t want the developer to be an administrator – unless you remove this step.
    You must also be a member of the dbowner role for the content database(s) associated with the application pool which hosts the target web application; that is, the site you specified when setting up the project. A simple way to do this is to run the cmdlet:
    Add-SPShellAdmin -user <domain\account> -database <content-database-guid>
    See the following PowerShell topic for details.
  • Retract Solution:
    Member of the farm administrators group for farm solutions.
    Site Collection administrator for Sandbox solutions.
  • Add Solution:
    Member of the farm administrators group for farm solutions.
    Site Collection administrator for Sandbox solutions.
  • Activate Features:
    Depends upon the feature scope.
    Global (farm): farm administrator group member
    Web Application: farm administrator or member of Web Application full control user policy
    Site Collection: Site Collection administrator or owner
    Site: Site administrator or owner
  • Run Post-Deployment Command:
    Again this is a non-issue. It will always work (barring pathological problems like running out of disk space or memory).

So we see Visual Studio 2010 deployment has stringent permission requirements. It is possible to work around some of these requirements by creating your own deployment steps, an exercise left for the reader.

PowerShell

Now we come to the often misunderstood cmdlet, Add-SPShellAdmin. Unfortunately, the Get-Help text does not clearly explain what this cmdlet does. It is not a general solution for SharePoint security permission issues. This cmdlet has a focused purpose; which is, to allow the designated user to run PowerShell commands that impact a particular database. Side effects are the user is also added to the database db_owner role and to the local machine WSS_ADMIN_WPG group, so again, be sure this is what you intend. This command does NOT add the user to either the local administrators groups or the Farm Administrators group; in other words, it grants least privileges.

If you execute the command WITHOUT a database parameter, the user will be able execute PowerShell commands that affect the Config database, but NOT content databases.

If you execute the command with a database parameter for a content database, the user will be able to execute PowerShell commands affecting that content database (and the config database).

To get the content database GUID to pass to the cmdlet, execute the Get-SPDatabase cmdlet. The following example shows UserNo115 granted permission to run PowerShell commands against the configuration database, and UserNo116 granted permission to run PowerShell commands against the WSS_Content_My content database.

The following 2 screen shots show the result of these commands as view through the SQL Management Studio. Note both users are now members of the Config database db_owners role; but only UserNo116 has access to the My Site content database.

What Can the User Do?

A useful troubleshooting tool is the command whoami. Logon to the server with the user’s credentials (or start a command prompt as the user), then open a command prompt and enter whoami /all. This will show the user’s group memberships and explicit privileges on the server. If the user is not in the expected groups, review the prior information to determine what went wrong. You should very rarely have to manually add users to groups except for Remote Desktop Users group.

The following output is for an administrative user, as seen by membership in the BUILTIN\Administrators group.

This example is for a user added to the farm administrator group through Central Administration. Note the absence of membership in the local administrators group, which is by design.

What about WSS Local Groups?

You may have noticed this discussion has not mentioned local groups like WSS_ADMIN_WPG, WSS_RESTRICTED_WPG_V4, and WSS-WPG. This was intentional. Membership in these groups is maintained automatically by Central Administration pages and PowerShell commands.

If you feel it necessary to modify these group memberships, my advice is STOP, take a deep breath, and review your overall approach to see what’s wrong with your security design. Modifying these groups’ membership is like putting a Band-Aid on a gushing wound. You have bigger problems.