Grant Access and Create Service Accounts for Keyfactor Command

The user who runs the Keyfactor Command installation must have appropriate permissions on the Keyfactor Command server(s) or Kubernetes cluster. For Windows installs, the user needs local Administrator permissions. You can either grant these permissions to an existing user or you can create a Keyfactor Command installer account and grant the appropriate permissions to this account.

Additionally, for Windows installs, the user installing Keyfactor Command must have the SeBackupPrivilege and SeRestorePrivilege rights on the Keyfactor Command server. Normally, administrators are granted these permissions by default, but you should confirm the permissions prior to starting the install. These permissions can be set through Group Policy or Local Security Policy, and can be found under “Local Policies\User Rights Assignment” as “Back up files and directories” and “Restore files and directories”.

For more information on this from Microsoft, see:

Keyfactor Command relies on a Microsoft SQL database. This database is typically created as part of the installation process, though it can be staged ahead of time. For Windows installs where Windows authentication for SQL will be used, the user installing Keyfactor Command must be granted appropriate permissions in SQL. For installs where SQL authentication will be used, credentials for an account in SQL with appropriate permissions to create databases need to be available. For more information, see Grant Permissions in SQL.

Keyfactor Command supports synchronization of certificates and certificate enrollment Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA). from EJBCA certificate authorities by configuring either a client certificate issued from the EJBCA CA A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. or an authentication token (client ID and secret) on the CA record in the Management Portal. This client certificate or authentication token needs to be associated with an end entity in EJBCA that can be assigned sufficient permissions to perform all necessary CA tasks from Keyfactor Command.

Keyfactor Command supports synchronization of certificates and certificate enrollment from EJBCA certificate authorities either directly or via a CA Connector The Keyfactor CA Connector is installed in the customer environment to provide a connection between a CA and Keyfactor Command when a direct connection is not possible. It is supported on both Windows and Linux and has versions for Microsoft (Windows only) or EJBCA CAs. Client. If a CA Connector Client is used, an instance of RabbitMQ is required and either a service account using basic authentication (username and password) or a service account using token authentication (client ID and secret) are required to authenticate Keyfactor Command to RabbitMQ.

Keyfactor Command supports synchronization of certificates and certificate enrollment from Microsoft certificate authorities either directly (Windows installs only) or via a CA Connector Client. If a CA Connector Client is used, an instance of RabbitMQ is required and either a service account using basic authentication (username and password) or a service account using token authentication (client ID and secret) are required to authenticate Keyfactor Command to RabbitMQ.

When Keyfactor Command is installed using an OAuth identity provider, a client needs to be created in the identity provider as the primary OIDC client connector for Keyfactor Command. The primary client account is used for the main authentication from Keyfactor Command to the identity provider. For an example client, see Configuring Keyfactor Identity Provider and Collecting Data for the Keyfactor Command Installation. This client is created automatically for Keyfactor Identity Provider implementations.

When Keyfactor Command is installed using an OAuth identity provider, a client needs to be created in the identity provider to allow Keyfactor Command to make API An API is a set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command. requests to itself. For an example client, see Service Accounts. If desired, the OIDC Client may be used for this role.

The Keyfactor Command Service (a.k.a. the timer service) runs on the Keyfactor Command services server. It synchronizes certificates to the SQL database and initiates notification and reporting tasks. This service runs in the context of an Active Directory or local service account.

The user with this role will be granted permission on each of the SQL schemas (dbo, ssl, ssh, cms_agents, etc.) and permission on the encryption certificate in SQL through the keyfactor_db_role which is created during configuration.

The user with this role must have the “Log on as a service” right on the Keyfactor Command server. Normally, this permission is granted automatically as part of the installation process. You can confirm the permissions through Group Policy or Local Security Policy in “Local Policies\User Rights Assignment”. Validate that the user associated with the Keyfactor Command Service has been added to “Log on as a service” directly or indirectly (via group membership).

The user with this role needs to be able to create log files and write to them. During installation, this permission is granted by granting “Create files / write data” and “Create folders / append data” permissions on the log directory (C:\Keyfactor\logs) to the local users group on the assumption that the local users group will contain either “NT AUTHORITY\authenticated users” or “DOMAIN\Domain Users” and that the service account user will be granted permissions via at least one of these. If this is not the case, permissions for the service account user will need to be granted manually to the log directory.

The user with this role needs to be granted permissions on any certificate authorities from which certificates will be synchronized. Additional certificate authority A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. permission may be needed depending on the features that will be used. For more information, see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs.

The Keyfactor Command Management Portal uses an application pool under IIS to operate. This application pool runs in the context of an Active Directory or local service account.

The user with this role will be granted permission on each of the SQL schemas (dbo, ssl, ssh, cms_agents, etc.) and permission on the encryption certificate in SQL through the keyfactor_db_role which is created during configuration.

The user with this role must have the “Log on as a batch job” and “Impersonate a client after authentication” rights on the Keyfactor Command server. In a typical IIS installation, these rights are granted to the IIS_IUSRS group and the user running any application pool created in IIS inherits these rights without being added to the IIS_IUSRS group. For more information about the IIS_IUSRS group, see:

You can confirm the permissions or set them manually for the application pool user through Group Policy or Local Security Policy in “Local Policies\User Rights Assignment”. Validate that either the IIS_IUSRS group or the user associated with the Keyfactor Command application pool has been added to “Log on as a batch job” and “Impersonate a client after authentication” directly or indirectly (via group membership).

The user with this role needs to be able to create log files and write to them. During installation, this permission is granted by granting “Create files / write data” and “Create folders / append data” permissions on the log directory (C:\Keyfactor\logs) to the local users group on the assumption that the local users group will contain either “NT AUTHORITY\authenticated users” or “DOMAIN\Domain Users” and that the service account user will be granted permissions via at least one of these. If this is not the case, permissions for the service account user will need to be granted manually to the log directory.

The user with this role needs to be granted permissions on any certificate authorities from which certificates will be synchronized. Additional certificate authority permission may be needed depending on the features that will be used. For more information, see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs.

The Logi Analytics Platform uses a service account to allow Logi to connect to Keyfactor Command via the Keyfactor API to display the dashboard information. This uses an application pool under IIS to operate. The application pool runs in the context of an Active Directory or local service account. A separate application pool is needed for this service, though the same service account may be used for both.

The Keyfactor Command Orchestrators API IIS application accepts connections from Keyfactor Command orchestrators and uses an application pool under IIS to operate. This application pool runs in the context of an Active Directory or local service account. If this role will be installed on the server hosting the Keyfactor Command Management Portal role, a separate application pool is needed for this service, though the same service account may be used for both.

The Keyfactor Command Keyfactor API uses an application pool under IIS to operate. This application pool runs in the context of an Active Directory or local service account. The Keyfactor API is an integral part of Keyfactor Command and is not an optional installation. The Keyfactor API can be configured to support custom applications. If the Keyfactor Command Keyfactor API role will be installed on the server hosting the Keyfactor Command Management Portal role, a separate application pool is needed for this service, though the same service account may be used for both.

For implementations using an identity provider other than Active Directory, the claims proxy proxies authentication tokens between the Management Portal and the Keyfactor API to enable communications between the portal and the API. This application pool runs in the context of an Active Directory or local service account. A separate application pool is needed for this service, though the same service account may be used for both.

This role does not exist in implementations using Active Directory as an identity provider.

Keyfactor Command supports the use of substitutable special text tokens in workflow A workflow is a series of steps necessary to complete a process. In Keyfactor Command, it refers to the workflow builder, which allows you to automate event-driven tasks such as when a certificate is requested, revoked or found in a certificate store. and alert emails, conditions, and data manipulation steps to replace a variable with data from the certificate request, certificate, or certificate metadata Metadata provides information about a piece of data. It is used to summarize basic information about data, which can make working with the data easier. In Keyfactor Command, the certificate metadata feature allows you to create custom metadata fields that allow you to tag certificates with tracking information about certificates. at processing time. For tokens that relate to the certificate requester, this involves querying the identity store to retrieve information about the requester. If you’re using Active Directory as an identity provider, this query is done in the context of the Keyfactor Command Management Portal application pool user (see Keyfactor Command Management Portal Application Pool (Windows Installs Only)), which must be running as an Active Directory user in that case. If you’re using an OAuth identity provider, queries cannot be completed to the identity provider for substitutable special text tokens and tokens requiring this are not supported.

Keyfactor Command supports synchronization of certificates and certificate enrollment from Microsoft certificate authorities in remote forests (forests other than the forest An Active Directory forest (AD forest) is the top most logical container in an Active Directory configuration that contains domains, and objects such as users and computers. in which Keyfactor Command is installed which are not in a two-way trust with the Keyfactor Command forest) by configuring a service account from the forest in which the CA resides on the CA record in the Management Portal. All communication to retrieve existing certificates, enroll for new certificates, revoke certificates, and recover certificate keys from the remote CA is done in the context of this service account. Explicit credentials for remote CA access is configured in the Keyfactor Command Management Portal after installation is complete rather than in the configuration wizard.