Pages

Friday, September 28, 2018

How to setup Azure Key Vault with Dynamics 365 for Finance and Operations

Azure Key Vault is a service that allows you to store secret keys, like passwords or certificates for external web-services, to be used by your different apps. When stored in Key Vault, none of your apps need to know details about or store these secrets by themselves. No more passwords laying around in code, in your version control system, in configuration files etc.

You can read more about Key Vault here.

Dynamics 365 for Finance and Operations has integration with key vault. It's just not very well documented and for now it seems only used a few places for integrations with different authorities.

I can't find any documentation on docs about the setup of Key Vault with Dynamics 365 for Finance and Operations, but I was able to find this support guide in stead: https://support.microsoft.com/en-us/help/4040294/maintaining-azure-key-vault-storage

If you follow the guide you'll be able to do the necessary setup on Azure.

In Dynamics you can find the setup form under System administration / Setup / Key vault parameters:


Let's try to figure out how to add a configuration to this form.

I have created a key vault called "PallesVault":


The "DNS Name" from the vault is what you enter in the "Key Vault URL" field.

I have registered my Dynamics instance as an app, as described in the support article. And I have added a Key to the registration. The Application Id and the secret key I have added goes into the "Key vault client" and "Key vault secret key" fields.


I have added single secret to my vault, which is my phone number ("Telefonnummer" is danish for phone number):


The address of the secret goes into the "Secret" field, as "vault://pallesvault/PallesTelefonnummer"

So, to get the value of this key from Dynamics the setup looks like this:



And here is some quick and dirty test code:

public static void main(Args _args) 

    KeyVaultCertificateTable keyVaultCertificateTable; 

    select firstonly KeyVaultCertificateTable 
        where KeyVaultCertificateTable.Name == "Telefon"; 

    str secretValue = KeyVaultCertificateHelper::getManualSecretValue(KeyVaultCertificateTable.RecId); 

    info (secretValue); 
}

In regards to pricing for the key vault, there is a Standard and a Premium tier. Standard is nearly free and Premium will set you back around 1$ a month.

Go secure your secret keys.

8 comments:

Munib Ahmed said...

Another useful link https://support.microsoft.com/en-ca/help/4040305/setting-up-azure-key-vault-client

Mötz Jensen said...

Great stuff!

One of the major advantages of the key vault is that you have a centralized management solution for handling the secrets across your entire IT landscape.

A not so trivial advantage if you ask me.

I would have expected that Microsoft had pushed this design pattern a bit harder to all ISV's. Currently we are seeing a classic approach across several vendors where they store all the secrets inside the D365FO database.

Let us hope that you blog post gets some attention and others will follow along the journey of using the Azure Key Vault.

Unknown said...

The only issue is that this table has SaveDataPerCompany=Yes
so you need to create separate key vault per AX company

Mötz Jensen said...

For most scenarios I would say that it makes sense.

In edge cases it will increase the complexity of handling secrets, but with the right automation tools in place it shouldn't be an issue.

Unknown said...

Please also note that KeyVaultCertificateHelper::getManualSecretValue() doesn't exist in standard 8.0

knishat said...

Thanks for the post! I've tried these steps but it doesn't seems to work in 8.o version. With a manual key as shown in the example (telephone no.), the validation from D365 throws an error "Unable to find the digital certificate". I proceeded to add a pfx certificate as a secret to Key vault using powershell and that validated correctly. This makes me think support for manual keys is not there anymore (the getManualSecretValue() method doesn't exist as well as the property on the certificate table which specifies that it's a manual key). So, not sure how this works in 8.0! Would appreciate any guidance for newer versions.

knishat said...

Thanks for the post! I've tried these steps but it doesn't seems to work in 8.o version. With a manual key as shown in the example (telephone no.), the validation from D365 throws an error "Unable to find the digital certificate". I proceeded to add a pfx certificate as a secret to Key vault using powershell and that validated correctly. This makes me think support for manual keys is not there anymore (the getManualSecretValue() method doesn't exist as well as the property on the certificate table which specifies that it's a manual key). So, not sure how this works in 8.0! Would appreciate any guidance for newer versions.

Mötz Jensen said...

Just to clarify for anyone finding this post. The code is present in 8.1 or higher.