Permissions for installing K2 in an on-premises SharePoint Environment
This topic details the permissions needed to successfully install K2 and use the K2 for SharePoint App in an on-prem SharePoint environment.
It is important to use different accounts to install and design K2 applications using K2 for SharePoint. Using the same account may cause issues due to invalid security tokens.
When using the K2 for SharePoint App, use an account other than the K2 Service account. Using the service account results in the SharePoint App user being used for all actions in SharePoint. If the K2 Service account is the Administrator, use a different user than the K2 Service account.
When using the K2 for SharePoint App, use an account other than the K2 Service account. Using the service account results in the SharePoint App user being used for all actions in SharePoint. If the K2 Service account is the Administrator, use a different user than the K2 Service account.
- Local admin, as the AppDeployment.exe application in the setup folder requires this.
- Site Collection Administrator / Contributor on the required App catalog sites to view and deploy to the catalogs.
-
To execute any SharePoint PowerShell command against a resource (where the resource is a Service Application or site / web application etc.) you need to be a member of SPShelladmin DB role on that resource’s database.
- SharePoint_Shell_Access role, as the user requires permissions to execute the PowerShell cmdlet from the TechNet article:
- http://technet.microsoft.com/en-us/library/ff607596(v=office.15).aspx
- $contentDBId = (Get-SPDatabase | ?{$_.Name -eq "WSS_Portal"})
- Add-SPShellAdmin -UserName {DOMAIN\UserName} -database $contentDBId
- When you run this cmdlet to add a user to the SharePoint_Shell_Access role, you must have membership in the securityadmin fixed server role on the SQL Server instance, membership in the db_owner fixed database role on all affected databases, and local administrative permission on the local computer.
This cmdlet is intended only to be used with a database that uses Windows authentication. There is no need to use this cmdlet for databases that use SQL authentication; in fact, doing so may result in an error message. - In order to use Windows PowerShell 3.0 for SharePoint 2013, a user must be a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2013 is installed. However, the result of running this cmdlet is that the user specified with the UserName parameter will have the db_owner role access on the affected databases as described below. Therefore, you should carefully plan which users are given this access.
- When you run this cmdlet to add a user to the SharePoint_Shell_Access role, you must have membership in the securityadmin fixed server role on the SQL Server instance, membership in the db_owner fixed database role on all affected databases, and local administrative permission on the local computer.
- Running this script results in the following database roles:
- Content_database (On a Denallix system this database is called WSS_Portal and refers to the content database for the Portal Web application)
- Public
- SharePoint_Shell_Access
- SPDataAccess
- SharePoint_AdminContent_[Guid]
- Public
- SharePoint_Shell_Access
- SPDataAccess
- SharePoint_Config
- Public
- SharePoint_Shell_Access
- SPDataAccess
For more information on adding the App to a SharePoint Site and running it, see the K2 Application Permissions in SharePoint topic in the K2 for SharePoint User Guide.
- Content_database (On a Denallix system this database is called WSS_Portal and refers to the content database for the Portal Web application)
How to set the permissions:
- Browse to Central Admin > Manage App Catalog > View site settings.
- In the App Catalog site settings, select Site collection administrators.
- Add Administrator user.
