MID Server Azure Key Vault integration

  • Release version: Australia
  • Updated March 12, 2026
  • 5 minutes to read

    • The MID Server integration with the Azure Key vault enables Orchestration, Discovery, and Service Mapping to run without storing any credentials on the instance.

    Before you begin

    To install the required application on the instance, navigate to Plugin Manager > External Credential Storage and Management.

    Set-up indicator for security phaseEnsure that the MID Server can connect to elements inside and outside your networkDownload and install the MID Server on a Linux or Windows hostConfigure your MID ServerConfigure MID Server securityEnsure that the MID Server can connect to elements inside and outside your networkDownload and install the MID Server on a Linux or Windows hostConfigure your MID ServerConfigure MID Server security

    Role required: External Credential Storage and Management application Scope ID is required: com.sn_mid_extcredstrg

    About this task

    When setting up access to the Azure Key Vault, the MID Server is either within the Azure environment or it is on an external virtual machine. An external virtual machine is any server that is not hosted in the Azure cloud environment, such as an on-premises server or a VM in another cloud provider. External virtual machines can't use Azure Managed Identity and must authenticate to Azure Key Vault using an App Registration with a client ID, tenant ID, and client secret or certificate.

    This procedure covers setting up the Azure Key Vault for a MID Server within the Azure environment.

    For more information about specific Azure and Azure Key Vault procedures, see the Azure Key Vault documentation.

    Procedure

    1. Within the Azure cloud environment, create a virtual machine.
    2. Navigate to the Identity section of that virtual machine.
    3. Enable system assigned identity.
      Once it is enabled, you have the option to assign a role for that identity.
    4. Navigate to the Add role assignment menu.
    5. Set the scope to your Subscription.
    6. Add the Key Vault administrator role.
    7. Set the resource to the key vault that you want to integrate with the MID Server.

    Azure Key Vault Integration for External Virtual Machine MID Servers

    The MID Server integration with the Azure Key vault enables Orchestration, Discovery, and Service Mapping to run without storing any credentials on the instance.

    Before you begin

    Role required: External Credential Storage and Management application (Scope ID:com.sn_mid_extcredstrg) is required.

    About this task

    When setting up access to the Azure Key Vault, the MID Server is either within the Azure environment or it is on an external virtual machine. This procedure covers setting up the Azure Key Vault for a MID Server that is on an external virtual machine.

    For more information about specific Azure and Azure Key Vault procedures, see the Azure Key Vault documentation.

    MID servers can use the Vault Credential Resolver to consume secrets directly from Vault for the purpose of performing discovery. The External Credential Storage and Management Application offers out-of-the-box integration to external credential providers. MID Servers support certificate-based authentication when connecting to Azure Key Vault. This provides a more secure and flexible way to authenticate, especially for enterprise environments that prefer certificate credentials over client secrets. For more information on managing certificates, see MID Server unified key store.

    Procedure

    1. In the Azure portal, navigate to App registrations.
    2. Create a new application for the MID Server.
    3. Take a note of the tenant id and client id because these are used later.
    4. Provide API Permission for Azure Key Vault to the application.
    5. Navigate to Certificates and Secrets for the new application.
    6. Generate a new client secret and take a note of that client secret.
      At this point, you should have the client_id, tenant_id, and secret_key for the application registration.
    7. Add the following parameters to the MID Server config.xml using the recorded values. 
      <parameter name="ext.cred.azure.vault_name" secure="false" value="<azure_key_vault_name>"/> (optional) 
<parameter name="ext.cred.azure.tenant_id" secure="true" value="<tenant_id_value>"/> 
<parameter name="ext.cred.azure.client_id" secure="true" value="<client_id_value>"/> 
<parameter name="ext.cred.azure.secret_key" secure="true" value="<secret_key_value>"/>

    Supported Credentials for Azure Key Vault Integration

    The MID Server supports specific credential types for integration with Azure Key Vault. Each credential is stored as a secret and must be a valid JSON string matching a supported credential type.

    Before creating secrets in Azure Key Vault, verify you have the appropriate permissions to create and manage secrets in your Key Vault instance. For instructions on creating and managing secrets, see the Microsoft Azure documentation.

    List of Credentials

    SNMPV3 Credentials
      {
    "type": "snmpv3",
    "user": "<user_value>",
    "authentication_key": "<authentication_key_value>",
    "privacy_protocol": "<privacy_protocol_value>",
    "privacy_key": "<privacy_key_value>",
    "authentication_protocol": "<authentication_protocol_value>",
    "snmp_context": "<snmp_context_value>"
  }
    VMWare Credentials
      {
    "type": "vmware",
    "password": "<password_value>",
    "user": "<user_value>"
  }
    SSH Credentials
      {
    "type": "ssh",
    "password": "<password_value>",
    "user": "<user_value>"
  }
    Windows Credentials
      {
    "type": "windows",
    "password": "<password_value>",
    "user": "<user_value>",
    "domain": "<domain_value>" // If it is null or empty, user name will become `.\user`
  }
    Azure Service Principal Credentials
      {
    "type": "azure",
    "client_id": "<client_id_value>",
    "tenant_id": "<tenant_id_value>",
    "secret_key": "<secret_key_value>"
  }
    SSH Private Key Credentials
      {
    "type": "ssh_private_key",
    "password": "<password_value>", // optional
    "user": "<user_value>",
    "ssh_certificate": "<ssh_certificate_value>",
    "ssh_private_key": "<ssh_private_key_value>",
    "ssh_passphrase": "<ssh_passphrase_value>" // optional
  }
    AWS Credentials
      {
    "type": "aws",
    "access_key": "<access_key_value>",
    "secret_key": "<secret_key_value>"
  }
    API Key Credentials
      {
    "type": "api_key",
    "api_key": "<api_key_value>"
  }
    Applicative Credentials
      {
    "type": "<applcation_type>", // generated by JSON builder: TODO
    "password": "<password_value>",
    "user": "<user_value>"
  }
    Azure Enterprise Agreement Credentials
      {
    "type": "ea_azure",
    "access_key": "<access_key_value>",
    "enrollment_number": "<enrollment_number>"
  }
    Azure SAS Credentials
      {
    "type": "azure_sas",
    "sas_key": "<sas_key_value>",
    "sas_key_name": "<sas_key_name_value>"
  }
    Basic Auth Credentials
      {
    "type": "basic_auth",
    "password": "<password_value>",
    "user": "<user_value>"
  }
    CIM Credentials
      {
    "type": "cim",
    "password": "<password_value>",
    "user": "<user_value>"
  }
    Cloud Foundry Credentials
      {
    "type": "sn_itom_pattern_pcf",
    "password": "<password_value>",
    "user": "<user_value>",
    "ssh_private_key": "<ssh_private_key_value>",
    "ssh_passphrase": "<ssh_passphrase_value>"
  }
    Google API Credentials
      {
    "type": "gcp",
    "email": "<email_value>",
    "secret_key": "<secret_key_value>"
  }
    SSL Keystore Credentials
      {
    "type": "keystore",
    "keystore_password": "<keystore_password_value>",
    "keystore_path": "<keystore_path_value>",
    "key_password": "<key_password_value>"
  }
    JMS Credentials
      {
    "type": "jms",
    "password": "<password_value>",
    "user": "<user_value>"
  }
    SNMP Community Credentials
      {
    "type": "snmp",
    "password": "<password_value>"
  }
    SSL Credentials
      {
    "type": "keystore",
    "user": "<user_value>",
    "password": "<password_value>",
    "additional_properties": "<additional_properties_value>",
    "key_password": "<key_password_value>",
    "keystore": "<keystore_value>",
    "keystore_password": "<keystore_password_value>",
    "keystore_type": "<keystore_type_value>",
    "ssl_provider_name": "<ssl_provider_name_value>",
    "security_protocol": "<security_protocol_value>",
    "truststore": "<truststore_value>",
    "truststore_password": "<truststore_password_value>",
    "truststore_type": "<truststore_type_value>"
  }
    IBM Credentials
      {
    "type": "ibm",
    "user": "<user_value>",
    "password": "<password_value>",
    "softlayer_user": "<softlayer_user_value>",
    "softlayer_key": "<softlayer_key_value>",
    "bluemix_key": "<bluemix_key_value>"
  }

    Gov Cloud Support for Azure Key Vault Integration

    You may need to override authentication and the vault URL when operating in government cloud environments. The following examples are for US government clouds.

    Auth endpoint:

    For US government clouds: https://login.microsoftonline.us/%s/oauth2/v2.0/token

    For US government cloud support: <paramter name="ext.cred.azure.vault_auth_endpoint" value="https://login.microsoftonline.us/%s/oauth2/v2.0/token"/>

    Scope:

    For US government clouds: https://vault.usgovcloudapi.net/.default

    <paramter name="ext.cred.azure.endpoint_scope" value="https://vault.usgovcloudapi.net/.default"/>

    For Germany government clouds: https://vault.microsoftazure.de/.default

    For Chinese government clouds: https://vault.azure.cn/.default