Accounts used in an Installation

This topic describes the various accounts that are necessary when installing, configuring and running the product system. 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 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 environments. We recommend 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 NintexSitesDev could serve all product web sites in your development environment, and an account like NintexSitesProd could serve all product web sites in your production environment. An account like NintexServiceDev could run the service in your development environment, and an account like NintexServiceProd could run the service in your production environment. This approach is useful because you can then easily restrict the Development 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 the product have the following two local policies set:

  • Deny log on locally
  • Deny log on through Remote Desktop Services
Account Purpose Practice Recommendation Other Considerations
Service Account The Service Account is the account under which the application service (the " 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 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.
  • To integrate the product with APIs, the Service Account requires the interactive logon permissions to be enabled. For API integration enable interactive logon permissions for the service account. For information see: Interactive Logon Authentication

    • Using single and double quotes (' and ") in the password of your Service Account are unsupported.
Installation Account The installation account is the account used by operators to install and configure the product on various servers in a topology A dedicated Setup account is not required, but using an account that is an administrator on the system is encouraged. Alternatively, you may install the product while logged in as the Service Account, provided that account has the necessary Required permissions to both install and run the product..
  • 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 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, client components may be installed by their intended users.
  • Use the same account for installing all server components and use the same account for subsequent reconfiguration or updates.
Administrator Account This account or group is used for basic administration of the Server, such as setting security for the environment, accessing the Management Site, and managing an 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 components. One principal authority group may be adequate for all areas of the product suite, but it does not preclude additional separation of duties. Consider a different authority group for each environment, i.e. “Nintex DEV Administrators, Nintex PROD Administrators.”
  • This account could be the same as the Service Account, but it is recommended that the Service Account and Administrative accounts are separate accounts
Web Service Account This account serves as the identity for application pools that run various web server components, such as the Web Services. Establish a dedicated account for all web server components and application pools in a specific environment. For example, an account like “NintexServiceDev” could serve all web server components and application pools in your development environment. While you use an account like “NintexServiceProd” on your production environment.
  • A custom application pool is required where Managed Pipeline mode must be set to Classic.
  • Application Pool needs to run on the .NET CLR version v2.0.50727
Designer Site Application Pool Identity This account is used as the Application Pool Identity for the Designer web site, which is installed when you install the product. Name the application pool to represent its role with the product. e.g. Designer App Pool. A single account such as “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.
  • Application Pools need to run on the .NET Framework v4.0.30319
  • Application Pool accounts will require elevated permissions to run the application pools
  • To integrate the product with APIs, the Application Pool Account requires the interactive logon permissions to be enabled. For API integration enable interactive logon permissions for the service account. For information see: Interactive Logon Authentication
Runtime Site Application Pool Identity This account is used as the Application Pool Identity for the 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 Designer and 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.
  • Application Pools need to run on the .NET Framework v4.0.30319
  • Application Pool accounts will require elevated permissions to run the application pools
  • To integrate the product with APIs, the Application Pool Account requires the interactive logon permissions to be enabled. For API integration enable interactive logon permissions for the service account. For information see: Interactive Logon Authentication
SharePoint Service Accounts These accounts are used in a SharePoint 2016/SharePoint 2019 environment. It is recommended that SharePoint Accounts are not also used as the Service account. The Service Account will need additional rights and access into SharePoint not normally assigned to service accounts in a standard SharePoint installation.
  • The SharePoint 2019 Service Account probably already exists in your environment and is already associated with your SharePoint 2019 installation.
  • When using the Nintex K2 for SharePoint App, use an account other than the Service account. Using the service account results in the SharePoint App user being used for all actions in SharePoint. If the Service account is the Administrator, use a different user than the Service account.
  • The Installation Account is used to execute the installation and configuration for Nintex K2 for SharePoint 2019.
Nintex K2 for SharePoint App Upload User Account This account is used to upload the Nintex K2 for SharePoint App to the App Catalog.  
  • When using the Nintex K2 for SharePoint App, use an account other than the Service account. Using the service account results in the SharePoint App user being used for all actions in SharePoint. If the Service account is the Administrator, use a different user than the Service account.
  • The Installation Account can be used to add the Nintex K2 for SharePoint App to the App Catalog
Nintex K2 for SharePoint Registration User Account This account is used when adding the Nintex K2 for SharePoint App to a Site Collection in SharePoint.    
Domain Users This refers to user accounts for users that will interact with the product.    

See also: