Azure Key Vault Universal Orchestrator Extension

Support · Installation · License · Related Integrations

Overview

The Azure Key Vault Universal Orchestrator extension enables seamless integration between Keyfactor Command and Microsoft Azure Key Vault. This extension facilitates remote management of cryptographic certificates stored in Azure Key Vault, ensuring organizational security and compliance requirements are met. With this extension, users can manage certificates remotely by performing various operations such as inventory, addition, removal, and discovery of certificates and certificate stores.

Azure Key Vault is a cloud service that provides secure storage for secrets, including cryptographic keys and certificates. Certificates in Azure Key Vault are utilized to secure communications and safeguard data by managing the associated cryptographic keys and policies.

Defined Certificate Stores of the Certificate Store Type in Keyfactor Command represent the individual or grouped certificates managed within a specific remote location, such as Azure Key Vault. Each Certificate Store is configured to interface with an Azure Key Vault instance, allowing the orchestrator to perform the required certificate management operations.

Compatibility

This integration is compatible with Keyfactor Universal Orchestrator version 10.1 and later.

Support

The Azure Key Vault Universal Orchestrator extension is supported by Keyfactor. If you require support for any issues or have feature request, please open a support ticket by either contacting your Keyfactor representative or via the Keyfactor Support Portal at https://support.keyfactor.com.

If you want to contribute bug fixes or additional enhancements, use the Pull requests tab.

Requirements & Prerequisites

Before installing the Azure Key Vault Universal Orchestrator extension, we recommend that you install kfutil. Kfutil is a command-line tool that simplifies the process of creating store types, installing extensions, and instantiating certificate stores in Keyfactor Command.

Setup and Configuration

The high level steps required to configure the Azure Keyvault Orchestrator extension are:

1. Configure client access; permissions and authentication

2. Create the Store Type in Keyfactor

3. Install the Extension on the Orchestrator

4. Create the Certificate Store

⚠️ If you are still using the (deprecated) Windows Orchestrator, you can find instructions for migrating by searching previous versions of this README.

---

Configure the Azure Keyvault for client access

In order for this orchestrator extension to be able to interact with your instances of Azure Keyvault, it will need to authenticate with a identity that has sufficient permissions to perform the jobs. Microsoft Azure implements both Role Based Access Control (RBAC) and the classic Access Policy method. RBAC is the preferred method, and currently the default used by Azure. It allows the assignment of granular level, inheretable access control on both the contents of the KeyVaults, as well as higher-level management operations. For more information and a comparison of the two access control strategies, refer to this article.

RBAC vs Access Policies

Azure KeyVaults originally utilized access policies for permissions and since then, Microsoft has begun recommending Role Based Access Control (RBAC) as the preferred method of authorization.
New KeyVaults created via this integration are created with the default authorization method that is configured in the Azure environment.

The access control type the KeyVault implements can be changed in the KeyVault configuration within the Azure Portal. New KeyVaults created via Keyfactor by way of this integration will use the default that is configured in your Azure environment (as of February 2026, if not specified, RBAC).

❗ Additional guidance regarding the minimum permissions needed for each job and sample RBAC policy definitions with descriptions can be found here.

Endpoint Access / Firewall

At a minimum, the orchestrator needs access to the following URLs:

• The instance of Keyfactor Command
• 'login.microsoftonline.com' (or the endpoint corresponding to the Azure Global Cloud instance (Government, China, Germany).
  • this is only technically necessary if they are using Service Principal authentication.
• 'management.azure.com' for all management operations (Create, Add, Remove) as well as Discovery.
  • This is necessary for authenticating the ARM client used to perform these operations.

Any firewall applied to the orchestrator host will need to be configured to allow access to these endpoints in order for this integration to make the necessary API requests.

⚠️ Discovery jobs are not supported for KeyVaults located outside of the Azure Public cloud or Keyvaults accessed via a private url endpoint.
All other job types implemented by this integration are supported for alternate Azure clouds and private endpoints.

Authentication options

The Azure KeyVault orchestrator plugin supports several authentication options:

• Service Principal
• User Assigned Managed Identities
• System Assigned Managed Identities

Steps for setting up each option are detailed below.

Authentication via Service Principal

For the Orchestrator to be able to interact with the instance of Azure Keyvault, we will need to create an entity in Azure that will encapsulate the permissions we would like to grant it. In Azure, these intermediate entities are referred to as app registrations and they provision authority for external application access. To learn more about application and service principals, refer to this article.

To provision access to the Keyvault instance using a service principal identity, we will:

1. Create a Service Principal in Azure Active Directory

2. Assign it sufficient permissions for Keyvault operations

3. Generate an Access Token for Authenticating

4. Store the server credentials in Keyfactor

In order to complete these steps, you must have the Owner role for the Azure subscription, at least temporarily. This is required to create an App Registration in Azure Active Directory.

Create A Service Principal

Note: In order to manage key vaults in multiple Azure tenants using a single service principal, the supported account types option selected should be: Accounts in any organizational directory (Any Azure AD directory - Multitenant). Also, the app registration must be registered in a single tenant, but a service principal must be created in each tenant tied to the app registration. For more info review the Microsoft documentation.

For detailed instructions on how to create a service principal in Azure, see here.

Once we have our App registration created in Azure, record the following values

• TenantId
• ApplicationId
• ClientSecret

We will store these values securely in Keyfactor in subsequent steps.

Authentication via User Assigned Managed Identity

Authentication has been somewhat simplified with the introduction of Azure Managed Identities. If the orchestrator is running on an Azure Virtual Machine, Managed identities allow an Azure administrator to assign a managed identity to the virtual machine that can then be used by this orchestrator extension for authentication without the need to issue or manage client secrets.

The two types of managed identities available in Azure are System assigned, and User assigned identities.

• System assigned managed identities are bound to the specific resource and not reassignable. They are bound to the resource and share the same lifecycle.
• User assigned managed identities exist as a standalone entity, independent of a resource, and can therefore be assigned to multiple Azure resources.

Read more about Azure Managed Identities here.

Detailed steps for creating a managed identity and assigning permissions can be found here.

Once the User Assigned managed identity has been created, you will need only to enter the Client Id into the Application Id field on the certificate store definition (the Client Secret can be left blank).

Authentication via System Assigned Managed Identity

In order to use a System assigned managed identity, there is no need to enter the server credentials. If no server credentials are provided, the extension assumes authentication is via system assigned managed identity.

Running a Discovery Job

Now that we have the extension registered on the Orchestrator, we can navigate back to the Keyfactor platform and finish the setup. If there are existing Azure Key Vaults, complete the below steps to discover and add them. If there are no existing key vaults to integrate and you will be creating a new one via the Keyfactor Platform, you can skip to the next section.

1. Navigate to Orchestrators > Management in the platform.

   

2. Find the row corresponding to the orchestrator that we just installed the extension on.

3. If the store type has been created and the integration installed on the orchestrator, you should see the AKV capability in the list.

   

4. Approve the orchestrator if necessary.

Create the discovery job

1. Navigate to "Locations > Certificate Stores"

   

2. Click the "Discover" tab, and then the "Schedule" button.

   

3. You should see the form for creating the Discovery job.

   

Store the Server Credentials in Keyfactor

⚠️ The steps for configuring discovery are different for each authentication type.

• For System Assigned managed identity authentication this step can be skipped. No server credentials are necessary. The store type should have been set up without "needs server" checked, so the form field should not be present.

• For User assigned managed identity:

  • Client Machine should be set to the GUID of the tenant ID of the instance of Azure Keyvault.
  • User should be set to the Client ID of the managed identity.
  • Password should be set to the value "managed".

• For Service principal authentication:

  • Client Machine should be set to the GUID of the tenant ID of the instance of Azure Keyvault. Note: If using a multi-tenant app registration, use the tenant ID of the Azure tenant where the key vault lives.
  • User should be set to the service principal id
  • Password should be set to the client secret.

The first thing we'll need to do is store the server credentials that will be used by the extension. The combination of fields required to interact with the Azure Keyvault are:

• Tenant (or Directory) ID
• Application ID or user managed identity ID
• Client Secret (if using Service Principal Authentication)

If not using system managed identity authentication, the integration expects the above values to be included in the server credentials in the following way:

• Client Machine: <tenantId> (GUID)

• User: <app id guid> (if service principal authentication) <managed user id> (if user managed identity authentication is used)

• Password: <client secret> (if service principal authentication), managed (if user managed identity authentication is used)

Follow these steps to store the values:

1. Enter the Tenant Id in the Client Machine field.

   

2. Click "Change Credentials" to open up the Server Credentials form.

   

3. Click "UPDATE SERVER USERNAME" and Enter the appropriate values based on the authentication type.

   

4. Enter again to confirm, and click save.

5. Click "UPDATE SERVER PASSWORD" and update with the appropriate value (<client secret> or managed) following the same steps as above.

6. Select a time to run the discovery job.

7. Enter commma seperated list of tenant ID's in the "Directories to search" field.'

⚠️ If nothing is entered here, the default Tenant ID included with the credentials will be used. For system managed identities, it is necessary to include the Tenant ID(s) in this field.

1. Leave the remaining fields blank and click "SAVE".

Approve the Certificate Store

When the Discovery job runs successfully, it will list the existing Azure Keyvaults that are acessible by our service principal.

In this example, our job returned these Azure Keyvaults.

The store path of each vault is the <subscription id>:<resource group name>:<vault name>:

To add one of these results to Keyfactor as a certificate store:

1. Double-click the row that corresponds to the Azure Keyvault in the discovery results (you can also select the row and click "SAVE").

2. In the dialog window, enter values for any of the optional fields you have set up for your store type.

3. Select a container to store the certificates for this cert store (optional)

4. Select any value for SKU Type and Vault Region. These values are not used for existing KeyVaults.

5. Click "SAVE".

Add an existing Azure Keyvault certificate store

You can also add a certificate store that corresponds to an Azure Keyvault individually without the need to run the discovery / approval workflow. The steps to do this are:

1. Navigate to "Locations > Certificate Stores"

2. Click "ADD"

   

3. Enter the values corresponding to the Azure Keyvault instance.

• Category: Azure Keyvault

• Container: optional

• Client Machine: If applicable; Tenant Id.

  • Note: These will only have to be entered once, even if adding multiple certificate stores.
  • Follow the steps here to enter them.

• Store Path: This is the Subscription ID, Resource Group name, and Vault name in the following format: {subscription id}:{resource group name}:{new vault name}

• SKU Type: This field is only used when creating new vaults in Azure. If present, select any value, or leave blank.

• Vault Region: This field is also only used when creating new vaults. If present, select any value.

If the vault already exists in azure the store path can be found by navigating to the existing Keyvault resource in Azure and clicking "Properties" in the left menu.

• Use these values to create the store path
• Save the certificate store
• If an inventory schedule was provided, a new inventory job should appear in Orchestrators > Jobs.

Create a new Azure Keyvault

• Enter a value for the store path in the following format: {subscription id}:{resource group name}:{new vault name}
• Make sure that the "Create Certificate Store" box is checked.
• Optionally choose values for the SKUtype, Vault Region, Azure Cloud and Private Endpoint (as applicable).
  • The SKUType and Vault Region fields are only used when creating new KeyVaults.
• Save the certificate store -Navigate to Orchestrators > Jobs; you should see the "Management" job that was generated in order to create the Keyvault.
• Once this job completes, a new Keyvault should have been created

⚠️ The identity you are using for authentication will need to have sufficient Azure permissions to be able to create new Keyvaults.

---

AKV Certificate Store Type

To use the Azure Key Vault Universal Orchestrator extension, you must create the AKV Certificate Store Type. This only needs to happen once per Keyfactor Command instance.

The Azure Keyvault Certificate Store Type is designed to integrate with Microsoft Azure Key Vault, enabling users to manage and automate the lifecycle of cryptographic certificates stored in Azure Key Vault through Keyfactor Command. This Certificate Store Type represents the connection and configuration necessary to interact with specific instances of Azure Key Vault, allowing for operations such as inventory, addition, removal, and discovery of certificates and certificate stores.

This integration leverages Azure's robust security infrastructure, utilizing OAuth-based authentication methods including Service Principals, User Assigned Managed Identities, and System Assigned Managed Identities. This ensures that only authorized entities can manage the certificates stored within the Key Vault.

While this Certificate Store Type provides a powerful means of managing certificates, there are some important caveats to consider. For example, if your instance of Azure Key Vault utilizes private or custom endpoints, or is hosted outside of the Azure Public cloud (e.g., Government, China, Germany instances), certain functions like discovery job functionality may not be supported. Additionally, the configuration of access control through Azure's Role Based Access Control (RBAC) or classic Access Policies must be meticulously managed to ensure sufficient permissions for the orchestrator to perform its tasks.

The integration does not require a specific SDK, as it interacts with Azure services directly through their APIs. However, ensuring that the orchestrator has network access to Azure endpoints is crucial for smooth operation. Being mindful of these caveats and limitations will help ensure successful deployment and use of the Azure Keyvault Certificate Store Type within your organization’s security framework.

Supported Operations

Operation	Is Supported
Add	✅ Checked
Remove	✅ Checked
Discovery	✅ Checked
Reenrollment	🔲 Unchecked
Create	✅ Checked

Store Type Creation

Using kfutil:

kfutil is a custom CLI for the Keyfactor Command API and can be used to create certificate store types. For more information on kfutil check out the docs

Click to expand AKV kfutil details

Using online definition from GitHub:

This will reach out to GitHub and pull the latest store-type definition

# Azure Keyvault
kfutil store-types create AKV

Offline creation using integration-manifest file:

If required, it is possible to create store types from the integration-manifest.json included in this repo. You would first download the integration-manifest.json and then run the following command in your offline environment.

kfutil store-types create --from-file integration-manifest.json

Manual Creation

Below are instructions on how to create the AKV store type manually in the Keyfactor Command Portal

Click to expand manual AKV details

Create a store type called AKV with the attributes in the tables below:

Basic Tab

Attribute	Value	Description
Name	Azure Keyvault	Display name for the store type (may be customized)
Short Name	AKV	Short display name for the store type
Capability	AKV	Store type name orchestrator will register with. Check the box to allow entry of value
Supports Add	✅ Checked	Check the box. Indicates that the Store Type supports Management Add
Supports Remove	✅ Checked	Check the box. Indicates that the Store Type supports Management Remove
Supports Discovery	✅ Checked	Check the box. Indicates that the Store Type supports Discovery
Supports Reenrollment	🔲 Unchecked	Indicates that the Store Type supports Reenrollment
Supports Create	✅ Checked	Check the box. Indicates that the Store Type supports store creation
Needs Server	✅ Checked	Determines if a target server name is required when creating store
Blueprint Allowed	🔲 Unchecked	Determines if store type may be included in an Orchestrator blueprint
Uses PowerShell	🔲 Unchecked	Determines if underlying implementation is PowerShell
Requires Store Password	🔲 Unchecked	Enables users to optionally specify a store password when defining a Certificate Store.
Supports Entry Password	🔲 Unchecked	Determines if an individual entry within a store can have a password.

The Basic tab should look like this:

Advanced Tab

Attribute	Value	Description
Supports Custom Alias	Optional	Determines if an individual entry within a store can have a custom Alias.
Private Key Handling	Optional	This determines if Keyfactor can send the private key associated with a certificate to the store. Required because IIS certificates without private keys would be invalid.
PFX Password Style	Default	'Default' - PFX password is randomly generated, 'Custom' - PFX password may be specified when the enrollment job is created (Requires the Allow Custom Password application setting to be enabled.)

The Advanced tab should look like this:

For Keyfactor Command versions 24.4 and later, a Certificate Format dropdown is available with PFX and PEM options. Ensure that PFX is selected, as this determines the format of new and renewed certificates sent to the Orchestrator during a Management job. Currently, all Keyfactor-supported Orchestrator extensions support only PFX.

Custom Fields Tab

Custom fields operate at the certificate store level and are used to control how the orchestrator connects to the remote target server containing the certificate store to be managed. The following custom fields should be added to the store type:

Name	Display Name	Description	Type	Default Value/Options	Required
TenantId	Tenant Id	The ID of the primary Azure Tenant where the KeyVaults are hosted	String		🔲 Unchecked
SkuType	SKU Type	The SKU type for newly created KeyVaults (only needed if needing to create new KeyVaults in your Azure subscription via Command)	MultipleChoice	standard,premium	🔲 Unchecked
VaultRegion	Vault Region	The Azure Region to put newly created KeyVaults (only needed if needing to create new KeyVaults in your Azure subscription via Command)	MultipleChoice	eastus,eastus2,westus2,westus3,westus	🔲 Unchecked
AzureCloud	Azure Cloud	The Azure Cloud where the KeyVaults are located (only necessary if not using the standard Azure Public cloud)	MultipleChoice	public,china,government	🔲 Unchecked
PrivateEndpoint	Private KeyVault Endpoint	The private endpoint of your vault instance (if a private endpoint is configured in Azure)	String		🔲 Unchecked

The Custom Fields tab should look like this:

Tenant Id

The ID of the primary Azure Tenant where the KeyVaults are hosted

SKU Type

The SKU type for newly created KeyVaults (only needed if needing to create new KeyVaults in your Azure subscription via Command)

Vault Region

The Azure Region to put newly created KeyVaults (only needed if needing to create new KeyVaults in your Azure subscription via Command)

Azure Cloud

The Azure Cloud where the KeyVaults are located (only necessary if not using the standard Azure Public cloud)

Private KeyVault Endpoint

The private endpoint of your vault instance (if a private endpoint is configured in Azure)

Entry Parameters Tab

Name	Display Name	Description	Type	Default Value	Entry has a private key	Adding an entry	Removing an entry	Reenrolling an entry
CertificateTags	Certificate Tags	If desired, tags can be applied to the KeyVault entries. Provide them as a JSON string of key-value pairs ie: '{'tag-name': 'tag-content', 'other-tag-name': 'other-tag-content'}'	string		🔲 Unchecked	🔲 Unchecked	🔲 Unchecked	🔲 Unchecked
PreserveExistingTags	Preserve Existing Tags	If true, this will perform a union of any tags provided with enrollment with the tags on the existing cert with the same alias and apply the result to the new certificate.	Bool	False	🔲 Unchecked	🔲 Unchecked	🔲 Unchecked	🔲 Unchecked
NonExportable	Non Exportable Private Key	If true, this will mark the certificate as having a non-exportable private key when importing into Azure KeyVault	Bool	False	🔲 Unchecked	🔲 Unchecked	🔲 Unchecked	🔲 Unchecked

The Entry Parameters tab should look like this:

Certificate Tags

If desired, tags can be applied to the KeyVault entries. Provide them as a JSON string of key-value pairs ie: '{'tag-name': 'tag-content', 'other-tag-name': 'other-tag-content'}'

Preserve Existing Tags

If true, this will perform a union of any tags provided with enrollment with the tags on the existing cert with the same alias and apply the result to the new certificate.

Non Exportable Private Key

If true, this will mark the certificate as having a non-exportable private key when importing into Azure KeyVault

Installation

1. Download the latest Azure Key Vault Universal Orchestrator extension from GitHub.

   Navigate to the Azure Key Vault Universal Orchestrator extension GitHub version page. Refer to the compatibility matrix below to determine the asset should be downloaded. Then, click the corresponding asset to download the zip archive.

   Universal Orchestrator Version	Latest .NET version installed on the Universal Orchestrator server	rollForward condition in Orchestrator.runtimeconfig.json	azurekeyvault-orchestrator .NET version to download
   Older than 11.0.0			net6.0
   Between 11.0.0 and 11.5.1 (inclusive)	net6.0		net6.0
   Between 11.0.0 and 11.5.1 (inclusive)	net8.0	Disable	net6.0
   11.6 and newer	net8.0		net8.0

   Unzip the archive containing extension assemblies to a known location.

   Note If you don't see an asset with a corresponding .NET version, you should always assume that it was compiled for net6.0.

2. Locate the Universal Orchestrator extensions directory.

   • Default on Windows - C:\Program Files\Keyfactor\Keyfactor Orchestrator\extensions
   • Default on Linux - /opt/keyfactor/orchestrator/extensions

3. Create a new directory for the Azure Key Vault Universal Orchestrator extension inside the extensions directory.

   Create a new directory called azurekeyvault-orchestrator.

   The directory name does not need to match any names used elsewhere; it just has to be unique within the extensions directory.

4. Copy the contents of the downloaded and unzipped assemblies from step 2 to the azurekeyvault-orchestrator directory.

5. Restart the Universal Orchestrator service.

   Refer to Starting/Restarting the Universal Orchestrator service.

6. (optional) PAM Integration

   The Azure Key Vault Universal Orchestrator extension is compatible with all supported Keyfactor PAM extensions to resolve PAM-eligible secrets. PAM extensions running on Universal Orchestrators enable secure retrieval of secrets from a connected PAM provider.

   To configure a PAM provider, reference the Keyfactor Integration Catalog to select an extension and follow the associated instructions to install it on the Universal Orchestrator (remote).

The above installation steps can be supplemented by the official Command documentation.

Defining Certificate Stores

Store Creation

Manually with the Command UI

Click to expand details

1. Navigate to the Certificate Stores page in Keyfactor Command.

   Log into Keyfactor Command, toggle the Locations dropdown, and click Certificate Stores.

2. Add a Certificate Store.

   Click the Add button to add a new Certificate Store. Use the table below to populate the Attributes in the Add form.

   Attribute	Description
   Category	Select "Azure Keyvault" or the customized certificate store name from the previous step.
   Container	Optional container to associate certificate store with.
   Client Machine	The GUID of the tenant ID of the Azure Keyvault instance; for example, '12345678-1234-1234-1234-123456789abc'.
   Store Path	A string formatted as '{subscription id}:{resource group name}:{vault name}'; for example, '12345678-1234-1234-1234-123456789abc:myResourceGroup:myVault'.
   Orchestrator	Select an approved orchestrator capable of managing AKV certificates. Specifically, one with the AKV capability.
   TenantId	The ID of the primary Azure Tenant where the KeyVaults are hosted
   SkuType	The SKU type for newly created KeyVaults (only needed if needing to create new KeyVaults in your Azure subscription via Command)
   VaultRegion	The Azure Region to put newly created KeyVaults (only needed if needing to create new KeyVaults in your Azure subscription via Command)
   AzureCloud	The Azure Cloud where the KeyVaults are located (only necessary if not using the standard Azure Public cloud)
   PrivateEndpoint	The private endpoint of your vault instance (if a private endpoint is configured in Azure)

Using kfutil CLI

Click to expand details

1. Generate a CSV template for the AKV certificate store

   kfutil stores import generate-template --store-type-name AKV --outpath AKV.csv

2. Populate the generated CSV file

   Open the CSV file, and reference the table below to populate parameters for each Attribute.

   Attribute	Description
   Category	Select "Azure Keyvault" or the customized certificate store name from the previous step.
   Container	Optional container to associate certificate store with.
   Client Machine	The GUID of the tenant ID of the Azure Keyvault instance; for example, '12345678-1234-1234-1234-123456789abc'.
   Store Path	A string formatted as '{subscription id}:{resource group name}:{vault name}'; for example, '12345678-1234-1234-1234-123456789abc:myResourceGroup:myVault'.
   Orchestrator	Select an approved orchestrator capable of managing AKV certificates. Specifically, one with the AKV capability.
   Properties.TenantId	The ID of the primary Azure Tenant where the KeyVaults are hosted
   Properties.SkuType	The SKU type for newly created KeyVaults (only needed if needing to create new KeyVaults in your Azure subscription via Command)
   Properties.VaultRegion	The Azure Region to put newly created KeyVaults (only needed if needing to create new KeyVaults in your Azure subscription via Command)
   Properties.AzureCloud	The Azure Cloud where the KeyVaults are located (only necessary if not using the standard Azure Public cloud)
   Properties.PrivateEndpoint	The private endpoint of your vault instance (if a private endpoint is configured in Azure)

3. Import the CSV file to create the certificate stores

   kfutil stores import csv --store-type-name AKV --file AKV.csv

PAM Provider Eligible Fields

Attributes eligible for retrieval by a PAM Provider on the Universal Orchestrator

If a PAM provider was installed on the Universal Orchestrator in the Installation section, the following parameters can be configured for retrieval on the Universal Orchestrator.

Attribute	Description
ServerUsername	Username to use when connecting to server
ServerPassword	Password to use when connecting to server

Please refer to the Universal Orchestrator (remote) usage section (PAM providers on the Keyfactor Integration Catalog) for your selected PAM provider for instructions on how to load attributes orchestrator-side.

Any secret can be rendered by a PAM provider installed on the Keyfactor Command server. The above parameters are specific to attributes that can be fetched by an installed PAM provider running on the Universal Orchestrator server itself.

The content in this section can be supplemented by the official Command documentation.

License

Apache License 2.0, see LICENSE.

Related Integrations

See all Keyfactor Universal Orchestrator extensions.