Create Service Accounts for the Keyfactor CA Connector
The 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 makes use of up to two service accounts to allow it to communicate with the on-premises 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.(s) and the Keyfactor Command server. The CA Connector Client on the CA Connector Client server runs as one service account. A second service account may be configured in the Keyfactor Command Management Portal to allow the CA Connector Client to make a connection to the CA to read certificate records, enroll for new certificates, and perform management functions such as revocation. Under some circumstances, the same service account may be used for both roles.
In addition to these service accounts, a client account in your OAuth authentication mechanism is needed to provide for token authentication from the CA Connector Client to Keyfactor Command (see Identify the CA Connector Client Access Token).
The service account(s) need to be created prior to installation of the CA Connector Client software (except as noted below for installations on Linux), and the person installing the CA Connector Client software needs to know the domain (if applicable), username and password of each service account.
CA Connector Client Service
-
Windows
When the CA Connector Client is installed on Windows, you may use either the built-in Network Service account or a custom service account to run the service. The custom service account may be either an Active Directory service account or a local machine account. Of the custom service account choices, an Active Directory account is more typically used unless the machine is not domain-joined. If you use an Active Directory service account, it needs to be a service account in 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 the CA Connector Client is installed.
The CA Connector Client on the server on which the CA Connector Client is installed runs as the service account you select for this role. The service account requires local “Log on as a service" permissions.
-
Linux
For the purposes of this documentation, it is assumed that Linux machines will be non-domain joined and will use a local account to run the CA Connector Client.
For Linux systems, Keyfactor recommends running the service as an account other than root. The default account of keyfactor-caconnector will be created automatically during the install if the force option is used. If you prefer not to use the force option, you may create a local service account before running the installation script.
CA Connection Access
-
Microsoft CAs
When each Microsoft CA is configured in the Keyfactor Command Management Portal, a service account from the on-premises forest may configured (with the Use Explicit Credentials option) to allow communications between Keyfactor Command and the on-premise CA via the CA Connector Client to be made in the context of this user. If you do not opt to enable the Use Explict Credentials option in the CA record(s) in Keyfactor Command, communications between Keyfactor Command and the on-premise CA via the CA Connector Client will be made in the context of the service account user configured to run the CA Connector Client service.
-
EJBCA CAs
When each EJBCA CA is configured in the Keyfactor Command Management Portal, either a client certificate may be selected to authenticate Keyfactor Command to the EJBCA instance via the CA Connector Client or OAuth authentication may be selected. If a client certificate is selected, it needs to be issued from the EJBCA CA and associated with an EJBCA end entity. An end entity may be created specifically for this role, or an existing end entity may be used.