Accounts used in a K2 Installation

This topic describes the various accounts that are necessary when installing, configuring and running K2. For more information on the permissions required for the accounts described in this table, please refer to the topic Required permissions.

When planning the user accounts for your K2 environment, consider that some accounts might need to be unique for different environments within your organization. This usually applies when your organization has separate Development, Test and Production K2 environments. K2 recommends that you create separate accounts for the runtime services in each environment (i.e. separate Service Accounts, Web Site Application Pool Accounts for each environment), to allow granular control of the security for each environment. Aligning with the STRIDE security model, the best practice recommendation is to use dedicated accounts for each environment, and avoid using global service accounts. For example, an account like K2SitesDev could serve all K2 web sites in your development K2 environment, and an account like K2SitesProd could serve all K2 web sites in your production K2 environment. An account like K2ServiceDev could run the K2 service in your development K2 environment, and an account like K2ServiceProd could run the K2 service in your production K2 environment. This approach is useful because you can then easily restrict the Development K2 Service Account from modifying data in the Production environment, by applying permissions in each environment.
Some organization use multiple domains to separate Service Accounts from User Accounts. Please refer to the topic Multiple Active Directory Domains if this applies to your environment.

Make sure that no accounts used for installing K2 have the following two local policies set:

  • Deny log on locally
  • Deny log on through Remote Desktop Services
Account Purpose Practice Recommendation Other Considerations
K2 Service Account The K2 Service Account is the account under which the K2 application service (the "K2 Server" service) runs. Dedicate a new account for each environment, e.g DEV, TEST, PROD.
  • Unless configured differently, server events and other server-side code inside workflows will execute in the security context of this account.
  • When Service Account is selected as the Authentication Mode for a Service Instance, interaction with the target system will happen in the security context of this account.
  • If this service account's password expires, the K2 Service will not operate as expected. You may want to establish a policy where this account's password does not expire, or if it does, that the password is updated before it expires.

    • Using single and double quotes (' and ") in the password of your K2 Service Account are unsupported.
Installation Account The installation account is the account used by operators to install and configure K2 on various servers in a topology A dedicated K2 Setup account is not required, but using an account that is an administrator on the system is encouraged. Alternatively, you may install K2 while logged in as the K2 Service Account, provided that account has the necessary Required permissions to both install and run K2.
  • This account must be a domain user account
  • This account should be in the same domain as the service accounts, and, if possible, the user accounts as well, because the domain hosting the Installation Account will be set as the domain associated with the default “K2” security label for the AD User Manager.
  • If Multiple Domains are used, please refer to the topic Multiple Active Directory Domains.
  • Depending on an organization’s policy, K2 client components may be installed by their intended users.
  • Use the same account for installing all K2 server components and use the same account for subsequent K2 reconfiguration or updates.
K2 Administrator Account This account or group is used for basic administration of the K2 Server, such as setting security for the environment, accessing the K2 Management Site, and managing a K2 environment. Using an Administration Account, or Group, supports separation of service accounts from user accounts. Establish an AD Group for administrative activities that members of the group will perform on K2 components. One principal authority group may be adequate for all areas of the K2 product suite, but it does not preclude additional separation of duties. Consider a different authority group for each environment, i.e. “K2 DEV Administrators, K2 PROD Administrators.”
  • This account could be the same as the K2 Service Account, but it is recommended that the Service Account and Administrative accounts are separate accounts
K2 Web Service Account This account serves as the identity for application pools that run various K2 web server components, such as the K2 Web Services. Establish a dedicated account for all K2 web server components and application pools in a specific environment. For example, an account like “K2ServiceDev” could serve all K2 web server components and application pools in your development environment. While you use an account like “K2ServiceProd” on your production environment.  
K2 Designer Site Application Pool Identity This account is used as the Application Pool Identity for the K2 Designer web site, which is installed when you install K2 Five (5.3). Name the application pool to represent its role with K2. e.g. K2 Designer App Pool. A single account such as “K2 Designer App Pool” could serve all environments, depending on variances in the organizational planning.
  • A custom application pool is required where Managed Pipeline mode must be set to Integrated.
  • K2 Application Pools need to run on the .NET Framework v4.0.30319
  • Application Pool accounts will require elevated permissions to run the application pools
K2 Runtime Site Application Pool Identity This account is used as the Application Pool Identity for the K2 Runtime web site, which is the website used by end users to access SmartForms. The application pool identity and pool may be shared between the K2 Designer and K2 Runtime web sites when the web sites are all on the same host. If your organization wishes to implement a topology where additional Runtime sites will exist, additional accounts and application pools may be considered to separate security, especially if you intend creating a dedicated Runtime site that is exposed to the internet and configured for Anonymous Access.
  • A custom application pool is required where Managed Pipeline mode must be set to Integrated.
  • K2 Application Pools need to run on the .NET Framework v4.0.30319
  • Application Pool accounts will require elevated permissions to run the application pools
SharePoint Service Accounts These accounts are used in a SharePoint 2013/SharePoint 2016 environment. It is recommended that SharePoint Accounts are not also used as the K2 Service account. The K2 Service Account will need additional rights and access into SharePoint not normally assigned to service accounts in a standard SharePoint installation.
  • The SharePoint 2013 Service Account probably already exists in your environment and is already associated with your SharePoint 2013 installation.
  • 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.
  • The Installation Account is used to execute the installation and configuration for K2 for SharePoint 2013.
K2 for SharePoint App Upload User Account This account is used to upload the K2 for SharePoint App to the App Catalog.  
  • 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.
  • The Installation Account can be used to add the K2 for SharePoint App to the App Catalog
K2 for SharePoint Registration User Account This account is used when adding the K2 for SharePoint App to a Site Collection in SharePoint.    
Domain Users This refers to user accounts for users that will interact with K2.    
Exchange Impersonation Account This account is required for Microsoft Exchange 2010 integration, to be able to impersonate users for sending meeting requests and creating tasks.    

See also:

Related Topics