MID Server Azure Key Vault integration
- UpdatedJul 31, 2025
- 4 minutes to read
- Zurich
- MID Server
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 .
![]() |
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. 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
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
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
Supported Credentials for Azure Key Vault Integration
The MID Server supports specified credentials for integration with the Azure Key vault.
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
Related Content
- MID Server certificate check policies
MID Server uses three kinds of security checks to secure external traffic. The security checks use TLS/SSL certificate validation, hostname validation, and OCSP validation to improve security. Control these security checks with the MID Server certificate check policies table.
- Encrypt or decrypt MID Server configuration file values
The value of any MID Server parameter in the config.xml file can be encrypted. The attributes for all encrypted values are managed from within the configuration file, including the security attribute of the login password.
- MID Server configuration file security
Sensitive MID Server configuration data can be protected using several different schemes, including internal and external data encryption and external data storage.
- MID Server authentication credentials and SOAP requests
Set basic authentication credentials to update the web service invocation data. For added security, you can enforce basic authentication on each incoming SOAP request to the MID Server.
- MID Server unified key store
The MID Server unified key store allows all products on the MID Server to use common certificates and key pairs. This feature allows applications to use the same secure communication channel to the MID Server that the MID Server uses to connect to the instance.
- Enable MID Server mutual authentication
Configure the MID Server to use a client certificate for authenticating to the instance. This avoids the need to create a basic authentication credentials in the Key Store for the MID Server's configuration.
- MID Server command audit log
The command audit log records the commands run by the MID Server for the Discovery application. Review the commands to check for anomalies or errors.
- Rekey a MID Server
Rekey a MID Server to generate a new private key. Private keys are used to decrypt automation credentials, so that MID Servers can transmit information securely. Key pairs are initially generated when a MID Server is validated, and MID Servers should be rekeyed periodically to meet security requirements.
- Add SSL certificates for the MID Server
Configure the MID Server to connect to a source over SSL.
- MID Server SSH cryptographic algorithms
The MID Server utilizes SSH clients to perform many discovery actions. During the SSH handshake, both the client and server first determine which algorithms both parties support, then client picks the highest priority algorithm. For the Host Key Algorithm, the client picks highest priority algorithm which both parties support that matches the key type.
- Attach a script file to a file synchronized MID Server
You can attach a script file to synchronize to a connected MID Server. Windows Internet Explorer enhanced security blocks downloaded files that it determines are potentially dangerous. However synchronizing the files avoids this security problem.
- MID Server FIPS Enforced Mode
The MID Server supports the National Security Cloud (NSC) IL-5 environment, which requires all utilized cryptography to be FIPS validated. The MID server can be run in FIPS Enforced Mode, where only cryptographic algorithms which are FIPS validated are utilized.
- MID Server Governance
Improve MID Server security by setting an automatic timeout to invalidate and shut down inactive MID Servers. You can enable this feature and set the inactivity timeout period globally and for each MID Server.
