Create Service Accounts for Keyfactor Command

The user who runs the Keyfactor Command installation must have local administrator permissions on the Keyfactor Command server(s) and must be granted permissions in SQL if Windows authentication for SQL will be used during the installation (see Grant Permissions in SQL). 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, 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:

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 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. 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 the context of Keyfactor Command, it refers to the workflow builder, which allows you automate event-driven tasks when a certificate is requested or revoked. 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 the context of 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)), which must be running as an Active Directory user in that case. If you’re using an identity provider other than Active Directory, 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 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 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. on the CA record in the Management Portal. This client certificate 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 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.