Site collection administrator rights or Full control on web application user policy to run powershell

Question

I have an admin account that I want to use to run PowerShell scripts toward a SharePoint site collection that has its own content database. I'm in a bit of doubt what permissions to give the account to be able to run my scripts. According to my tests, a basic requirement is that the account is given permissions with the command Add-SPShellAdmin towards the content database. But that is not enough. I can not run for example the cmdlet New-SPWeb. But if I make the same user Site collection administrator or if it is given Full control on User policy for the web application I can run scripts.

The thing is I thought I had Site collection admin permissions, because my user is member of an AD-group that I use for Site collection administrator permissions on all my site collections. But I still couldn't run PowerShell scripts. I found out it was because of our authentication setup. The AD-group was given site collection administrator rights as the claims adfs federated account c:0-.t|adfsfed|sp-all-shelladmin, meaning I had access when navigating the site collection from my local computer and authenticated through adfs. When I run PowerShell-scripts from the server I do that as the claims windows authenticated account c:0+.w|s-1-5-21-2979246621-1925778976-876374310-104813, this account is not site collection administrator.

The way I see it I have two options here.

1. Add the windows claims federated AD-group as site collection administrator. This will result in two groups with the same name as site collection administrators.
2. Give the windows claims federated user Full control permission on User Policy on the web application.

So, some of the questions I have are:

• Basically, what permissions are needed to be able to run PowerShell scripts towards a site collection and its content in SharePoint? Are there more alternatives than I have mentioned?
• What are the "pros and cons" of giving permission through user policy rather than site collection administrator?
• Any best practices for how to work with PowerShell-scripting in an SharePoint-environment with multiple authentication providers?

Thanks

Answer 1

There's different levels of permissions in SharePoint (names are mine, not official ones):

• Functionnal levels for contents: these are permissions you grant users from the sites (adding users/groups in roles, etc.), at the site collection level (define a user as a site collection Administrator) or even at the Web application scope (User Policy for the Web app). These permissions are checked by the SharePoint business logic when an operation is about to be performed by a user.
• Functionnal levels for administration: who can access the CA or issu commands from PowerShell. This is what Add-SPShellAdmin does for the shell access.
• Technical permissions: these are the permissions at the SQL level. When a user does something, SharePoint checks if the user is granted the right to do the action by the SP business logic, and after that SQL commands are issued to the DB server: these commands are authenticated with a Windows protocol. The identity used is:
  • either the application pool identity (in case the action is done from the Web UI). This is the content app pool's identity or, in case of the CA, the farm account,
  • or the farm account identity if the action is done by the OWSTIMER process (a job),
  • or the user who is logged on while running PowerShell.

This means that a user who tries to create, let's say, an SPWeb from the PowerShell command line needs access at two levels: functionnal one (is she/he allowed to do that action from the SP perspective) + technical one (connect to the content DB from a SQL point of view).

In your case, as soon as your user connects to the server to issue PowerShell commands, it becomes, IMO, a technical Administrator, thus diserving a technical access. What I mean: I don't see any problem adding her/him at the Web application level + DB level.

Adding her/him at the Web application level (User Policy) will grant her/him a very full access to all site collections in this Web application (regardless the DB).

Granting her/him a SQL access is something else, and only a DBA would argue in favor/against this... (but I bet a DBA will be much against than in favor)
Practically, this can be done on all content DBs attached to a given Web app by:

$w = Get-SPWebApplication -identity http://WebAppURL
$w.GrantAccessToProcessIdentity("domain\user")