SharePoint 2010 PowerShell Permissions Explained

SharePoint 2010 has increased flexibility for administrative privileges of command line operations.  The end result is that there is a bit more complexity in setting up your administrative privileges, so I wanted to create a post to try and clear up administration permissions for SharePoint 2010. 

Foremost, please keep in mind that I’m going to discuss the minimum required privileges for each role—so there are lots of additional configurations; this is the just bare requirements.

First we need to talk about Central Administration, as the different permissions often lead to confusion.  To access Central Administration, you need to be a Farm Administration—aka, a member of the “Farm Administrators Group”.  This is really a UI only permission (I recommend you think of “Farm Adminstration Privs” as “The ability to use Central Admin”.  The reason for this is that Farm Administrators have the ability to run operations via-the Central Administation Web Application; keep in mind that no operation actually runs against the Configuration Database as the user but rather as the App Pool account for the Web App.

With STSADM and PowerShell, all commands are run as the user who executes the command (not through the Central Admin Web Application).  The good part about this is that any command can be run from any machine (no CA required), but this means that the user themselves needs the proper permissions.  With STSADM, the user required Box, Farm, and SQL permissions—way too much to run a truly “Least Privs” environment.  With 2010 there is the flexibility to only require PowerShell & SQL permissions*. 

                *Note: Box permissions are required for a small subset of commands that touch the Windows filesystem or registry.  Also, Box and SQL are required for all “setup” operations.

On that note, there are only two requirements for most commands.  The user must be:

·         A member of the WSS_ADMIN_WGP group (this is a Windows Group on the machine the user is executing commands on)

·         A member of the “SharePoint_Shell_Access” role on the configuration database (this is a SQL Role)

To simplify the management of these roles we have created a set of PowerShell commands (noun is “SPShellAdmin”) to add and remove Shell Administrators.  You’ll notice that the commands allow you to designate a specific database, this is because the “Shell Admin” role by default only gives the user access to the Configuration Database; the shell admin must be given access to each individual service and content database they are “allowed to manipulate” (i.e.: to delete a content database, the user must be a shell admin on that database).

                *IMPORTANT: The Shell Admin commands in SharePoint 2010 Beta do not fully setup these roles; you need to add the WSS_ADMIN_WGP role manually.

Please keep in mind that each command is just running object model, so additional permissions may be required for specific commands.  For example, you may need Service Application permissions to run commands against a certain service application.

Hopefully I’ve made permissions a little easier to understand—but if you’ve still got questions, put them in the comments section below.