AZIdentity

I've seen several support cases recently where someone wants to update a Key Vault via template but not disturb the existing access policies. The problem is that if you deploy a resource of type Microsoft.KeyVault/vaults, that will replace any existing access policy.

This is by-design of ARM Templates.  

In speaking with the product team, I learned of a special child resource for ARM template which allows the addition of new access policies without affecting existing access policies.

When you deploy a resource of type Microsoft.KeyVault/vaults/accessPolicies with the name “add”, it will merge in your changes. This special child resource type was created to allow Managed Service Identity scenarios where you don’t know the identity of a VM until the VM is deployed and you want to give that identity access to the vault during deployment. 

An incremental deployment can be used along with this json to achieve the objective:

{
    "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "vaultName": {
            "type": "string"
        }
    },
    "resources": [
        {
            "type": "Microsoft.KeyVault/vaults/accessPolicies",
            "name": "[concat(parameters('vaultName'), '/add')]",
            "apiVersion": "2016-10-01",
            "properties": {
                "accessPolicies": [
                    {
                        "tenantId": "dfe47ca8-acfc-4539-9519-7d195a9e79e4",
                        "objectId": "5abe9358-10ae-4195-ba23-d34111430329",
                        "permissions": {
                            "keys": ["all"],
                            "secrets": ["all"],
                            "certificates": ["all"],
                            "storage": ["all"]
                        }
                    }
                ]
            }
        }
    ],
    "outputs": {
    }
}

I hope this helps you out when using the Azure Key Vault!  Please follow us on Twitter and retweet!
@WinDevMatt @AzIdentity

Several support cases have come in where an Azure customer purchases an App Service Certificate via the portal and then wants to download the certificate from the Key Vault and use it in other systems.  Three things commonly occur in these cases:

1. The customer is unable to find the App Service Certificate in the Key Vault
2. The customer is unable to use a certificate downloaded from the Key Vault because the password does not work
3. The customer needs the certificate in .cer/.key format rather than .pfx

Luckily, I have the solution for all three of these scenarios.

1. You are unable to find the App Service Certificate in the Key Vault
   Many customers who are using Azure App Services do not have much experience with an Azure Key Vault, but most every website has a need for an SSL certificate.  Going through the process of purchasing an Azure App Service Certificate requires you to store the certificate in a Key Vault, which is how most people become first familiar with the Key Vault.
   
   
   
   After purchasing the certificate, customers sometimes want to download it for use elsewhere, so they go into the Key Vault, look under the certificates blade, and find the following (the Key Vault pictured here does in fact hold an App Service Certificate):
   
   
   This is definitely confusing to the person unfamiliar with Key Vault. The reason behind this is simple:  when the programming for App Service Certificates was being done, certificates as objects that could be stored within the Key Vault was not available.  Since then, Certificates are now available, but the process behind the App Service Certificate purchase has not changed yet.  This is coming in the future.
   
   Customers should be able to find their App Service Certificates in the Secrets blade, and I do see the secret of type pkcs12 (certificate) stored there:
   
   
   
2. You are unable to use a certificate downloaded from the Key Vault because the password does not work
   Now that you've found the certificate, you want to download it and use it on another machine.  This should be simply done by using this button:
   
   
   
   It's easy to download this certificate as a .pfx file.  You do so, but when you want to install it, you have no idea what the password is:
   
   
   
   In fact, even if you uploaded the .pfx as a secret yourself, you may find that the password that you do know does not work.  The solution is to download the certificate (as a secret) from the Key Vault using Powershell, then convert that secret into an actual certificate with its own password. 
   
   

   Login-AzureRmAccount
   
   $vaultName  = "<NameOfKeyVault>"
   $keyVaultSecretName = "<NameOfTheSecretWhereCertificateIsStored>"
   
   $secret = Get-AzureKeyVaultSecret -VaultName $VaultName -Name $keyVaultSecretName
   
   $pfxCertObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList @([Convert]::FromBase64String($secret.SecretValueText),"",[System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
   
   $pfxPassword = -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 50 | % {[char]$_})
   
   $currentDirectory = (Get-Location -PSProvider FileSystem).ProviderPath
   [Environment]::CurrentDirectory = (Get-Location -PSProvider FileSystem).ProviderPath
   [io.file]::WriteAllBytes(".\KeyVaultCertificate.pfx", $pfxCertObject.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $pfxPassword))
   
   Write-Host "Created an App Service Certificate copy at: $currentDirectory\KeyVaultCertificate.pfx"
   Write-Warning "For security reasons, do not store the PFX password. Use it directly from the console as required."
   Write-Host "PFX password: $pfxPassword" 
   

   
   Now you have the certificate and its password for use anywhere you want.
   
   
3. You need the certificate in .cer/.key format rather than .pfx
   There are times when you want the certificate in a .cer and .key format, such as for use on the Apache web server.  This can be accomplished by the use of OpenSSL.  A Windows version of the open-source binaries can be found here: http://slproweb.com/products/Win32OpenSSL.html.
   
   Once installed, it is only necessary to run the following two commands at a command prompt in order to convert your files:
   

   openssl pkcs12 -in KeyVaultCertificate.pfx -nocerts -out KVCert.key
   
   openssl pkcs12 -in KeyVaultCertificate.pfx -clcerts -nokeys -out KVCert.cer

   Note that your .pfx file may have a different name.  You should also plan on having the certificate in the same folder as the openssl command, or use the full path to the certificate.
   
   You will be required to use the password for the .pfx when converting.  Here's a successful run of these commands:
   
   
   Notice that there's no "private key" associated with this certificate - that's because the .cer file does not contain the key - the whole purpose of this exercise.
   
   I hope this helps you out when using the Azure Key Vault!  Please follow us on Twitter and retweet!
   @WinDevMatt @AzIdentity

There are occasions when the Incubation team gets support cases for problems that occur in the Azure portal. It's greatly preferable to document these for public consumption rather than have you open a support case to figure out what to do. This problem sees quite a few support cases:

"The directory currently selected differs from this key vault's directory"

Although it's technically correct, it does not explain what happened and why you're seeing the problem.  It occurs when the internal "Tenant Id" value of the Key Vault does not match the Tenant Id of the subscription that currently owns the Key Vault.  It's probable that one of these things happened:

1. The Key Vault was deployed to a subscription using an ARM Template that contains a different Tenant Id
2. The subscription that owns the Key Vault was moved to a different Tenant (much more likely).

When the subscription is moved to a new tenant, the Key Vault's internal "Tenant Id" is not changed, and that's so the existing access policies (which point to Service Principals in the in old tenant) do not automatically fail.  When the Tenant Id of the Key Vault is changed to the new value, access policies for Service Principals in the old Tenant Id will no longer work.

It is possible to update the Tenant Id and get rid of this message by following these instructions:
https://docs.microsoft.com/en-us/azure/key-vault/key-vault-subscription-move-fix

Update on 8/15/2019
The Key Vault product team has made a change to the DNS validation process.  If a DNS name is in an orphaned state, on the first attempt at claiming it, it will still fail.  However, after 20 minutes, a second attempt will allow you to reuse the name if it's in the same region as the original vault.

Please follow us on Twitter and retweet!
@WinDevMatt @AzIdentity

The Azure Identity Incubation team is a small group of Microsoft Support Engineers who work on improving the Azure Active Directory support experience. We do this by carefully documenting of our support processes;  meeting with the development team to discuss product bugs, feature requests, and improvements to the UX; working on more difficult support cases. We also ensure that other support engineers are trained on the various technologies that make up Azure Active Directory.

We've found that there are common issues or techniques that may be useful for the end user to have that may not be already documented, or that we can simplify from the official Microsoft documentation.  We want to get these into blog posts for you to consume and hopefully prevent from creating new support cases.

We will be posting on a regular basis, and have a twitter handle for you to follow:  @azidentity