How to Automate a PKI Configuration for an Existing Azure VM in Microsoft Azure

This article is contributed. See the original author and article here.

Hi Cloud automation friends. This is Preston K. Parsard again, and in this post we’ll cover configuring PKI on an existing Active Directory domain-joined Windows Azure Virtual Machine in Microsoft Azure.

Now before being scared by the term PKI, like zombies shuffling towards you at twilight, it’s really not that bad this time. In fact, I’ve provided a link in the references section of this post to a short video demonstration as well. Feel free to skip to it now if you prefer, but the rest of this post does provide some background and sets the context for this type of configuration.

DISCLAIMER: These instructions are primarily meant for an informal dev/test or training lab environment intended to experiment or learn about technologies which may rely on a basic certificate authority service. For a more formal and extensive reference for Windows PKI, please see the Windows PKI Documentation Reference and Library link in the references section at the end of this article. Also my esteemed colleague Daniel Metzger wrote Building the Totally Network Isolated Root Certificate Authority, which is a great article for production environments and is also referenced at the end.

By configuring an enterprise certificate authority server in your test and development or lab environment, you can reproduce scenarios that require certificates for web server, code signing or document encryption. One example may include building a simulated on-premises Desired State Configuration (DSC) pull server and auto-enrolling the virtual machines in the domain for document encryption certificates.

Now I realize that it’s more likely that if you have workloads in Azure and you need to leverage desired state configuration, you already have the option to use the native Azure automation state configuration feature for this purpose. So you wouldn’t really need to build a traditional on-premises simulated DSC pull server after-all and consequently would not require a certificate server as well.

The idea behind our scenario however is simply to provide the added flexibility to experiment with setting up a small PKI infrastructure to evaluate, train or prepare for any certificate services related technologies. Most medium and large enterprise customers I’ve worked with have separate IT operations and PKI teams, and IT ops folks are not usually exposed to the mechanics and experience of the PKI integration, relying fully on the PKI teams instead for these services. This solution aims to now empower the IT ops staff to learn and gain better insights and appreciation for any PKI related technologies their projects may rely on. Who knows? It may even encourage greater dialogue and collaboration between both teams when ops can more explicitly elaborate their requirements to the PKI team and the PKI folks can see exactly how and why ops will be using these services if they need such information for approving certificate requests.

Adatum Consulting Overview

First, let’s visit our fictitious company, Adatum Consulting, which is a global provider of cloud architecture and automation consulting services for its manufacturing customers. Adatum has recently created a consolidated development environment where they can develop, test, reproduce and prototype solutions for their clients.

Opportunity

To accommodate this requirement, Jason, the infrastructure team lead, has asked Jessica to deploy certificate services on an existing Azure VM to act as the enterprise certificate authority for this environment. By implementing a simple single tier certificate services PKI infrastructure, the team can quickly issue certificates for these secure web applications or to reproduce configuration management solutions. In fact, to configure the certificate services server, Jessica will actually use the Azure automation state configuration capability, but the really cool part about this option is that Azure based DSC does not require first configuring a certificate authority itself, because certificate services for this feature is already built into Azure!

Jessica

Target State Diagram

Here is the target state diagram, which is based on the existing Project 0026 solution in GitHub. If you want to use this solution to automatically provision the dev.adatum.com environment so you can follow along, please use these links below and return to this article when you’re ready to continue.

Blog

Code

Requirements

So let’s review the sequence of steps that Jessica will take to configure certificate services on an VM in their existing dev.adatum.com domain, right after we outline the requirements and assumptions below.

An Azure subscription is needed, which will include at least a domain controller and a new installation of a domain-joined Windows Server 2019 Virtual Machine in the dev.adatum.com domain. If you want to follow along, you will just need to use your own domain with an available Windows Server 2019 image. This subscription must have an automation account since the state configuration feature will be used later to apply the configuration on the target virtual machine.

We’ll assume that an internet connection from Adatums’ enterprise or Jessica’s home office to connect to her company’s Azure subscription is available.

Windows PowerShell version 5.1 or greater. Note that Jessica may be able to use PowerShell (version 7+), but some refactoring of the code may be required. This solution has only been tested on Windows PowerShell 5.1 specifically.

The account that Jessica will use to run the PowerShell script must be a member of the local administrators group on the machine from which the script is executed. This is because the Az module installations, if required will need this permission.

During the script execution, Jessica will be prompted to upgrade from the AzureRM modules, in case she still uses these legacy cmdlets, to the newer Az modules from the PowerShell gallery repository.

A final prompt will appear when the script runs for Jessica to supply credentials for an account that will be used to configure the Active Directory Certificate Services server. This account must actually be members of both the enterprise administrator and root domain administrator for dev.adatum.com in our scenario.

Workflow

1. Download Script

In a PowerShell console, opened in the context of administrator, Jessica first creates a target folder named C:Project0067 on her machine to download the script from a public GitHub repository.

New-Item -Path C:Project0026 -ItemType Directory -Verbose

Start-Process -FilePath https://github.com/autocloudarc/0067-ConfigurePKI

Next, she downloads the zip file, extracts only the Configure-PKIonVMinAzure.ps1 script and copies it to the new directory named C:Project0067. She then unblocks it assuming that her PowerShell execution policy is set to RemoteSigned so it can be executed locally.

Set-Location -Path c:project0067 -Verbose

Unblock-File -Path .Configure-PKIonVMinAzure.ps1 -Verbose

2. Execute Script

Next, Jessica executes the C:Project0067Configure-PKIonVMinAzure.ps1 script from her existing Windows PowerShell 5.1 session. She uses the command below to specify the automation account name and resource group that contains the dev.adatum.com environment and the target VM that will be configured.

. .Configure-PKIonVMinAzure.ps1 -aaaName <AutomationAccountName> -rgpName <ResourceGroupName> -Verbose

A prompt will appear to upgrade from the legacy AzureRM to the newer Az PowerShell modules so that the most up-to-date PowerShell Azure cmdlets can be used for this configuration. Jessica will enter ‘y’, or ‘yes’, which is not case sensitive, to proceed with the upgrade if it is required.

3. Authenticate to Subscription

The script then presents a prompt for Jessica to enter her Azure subscription credentials. Since Jessica has multiple subscriptions, a secondary prompt also asks her to specify which subscription associated with her credentials she wants to use. She chooses the subscription in which the dev.adatum.com target PKI virtual machine resides.

4. Select Virtual Machine

Based on the resource group used in the parameter -rgpName for this script shown in step 2 above, which was rg10, the virtual machines in that resource group is then listed so that Jessica can select the appropriate target VM that she wants to configure. She chooses AZRPKI1001. The naming convention used here is AZR = three letter cloud service provider code ([A][Z]u[R]e), PKI = virtual machine function code ([P]ublic [K]ey [I]nfrastructure), and the remaining characters are 1001, where 10 represents the resource group identifier in rg[10] and 01 is the series number.

5. Provide Credentials

Jessica enters the username for this domain as adm.infra.user@dev.adatum.com, which is a member of the Enterprise Admins and Domain Admins in the root (and only) domain for this forest. This is a requirement to install and configure Active Directory Certificate Services.

6. Download Configuration

The script will now automatically download both the pkiConfig.ps1 as well as the configuration data file pkiConfigData.psd1 as artifacts from the public GitHub project.

The pkiConfigData.psd1 information are the set of DSC related parameter values that are associated with the pkiConfig.ps1 configuration script. When the configuration is imported and compiled, it will include these configuration data parameters and used to specify properties of the PKI server. Some examples of these properties include; the CACommonName, the cryptographic provider, hash algorithm and key length for the CA root certificate.

7. Import Modules

Before the configuration script can be imported and compiled, the DSC resource modules it requires must first be imported from the PowerShell gallery into the Azure automation account. The script also does this automatically as shown in the image below.

8. Import and Compile Configuration

The script will also import and compile the configuration with the configuration data associated. Both the import and compilation steps are initiated from a single command in PowerShell, which is show below in line 404.

The output in the PowerShell console shows that the PkiConfig compilation has started.

The automation account will also confirm that the configuration was compiled.

9. Register Node

Since the script has now completed the compilation of the configuration, it proceeds to register or on-board the target virtual machine that will be configured. In this example this process took less than 5 minutes, but there may be other factors that may make it take longer. As with most of the previous steps, no manual intervention is required here either. Recall from step 4 that this is the AZRPKI1001.dev.adatum.com virtual machine. This is the last step in the configuration process where the configuration is actually applied to the PKI server and then restarted to finalize that configuration.

10. Get Results

The script then provides a set of instructions to perform the final verification and prompts Jessica to open the transcript. This transcript provides all the details of the script output that was shown in the console and Jessica decides to open the transcript to see if there are any errors she may have missed. The transcript opens with notepad in a new window and the script completes.

From the Azure portal, Jessica confirms that the target node applied the PkiConfig.localhost node configuration and that the node itself is compliant.

11. Verify Configuration

For the final verification that PKI was properly setup on this target VM, Jessica will log into the VM with RDP over HTTPs using the Azure bastion service.

She then starts a PowerShell session and types certsrv.msc to open the certificate authority MMC console and validates that this certificate services feature was installed and configured correctly.

Summary

So to quickly setup a simple PKI server, we can just download and execute a script from a public GitHub repository. Once executed, this script will automatically retrieve, import artifacts and modules, compile a configuration and register a target domain joined virtual machine in Azure to configure it as a certificate authority server. I hope this information was useful and feel free to leave a comment. Thanks for reading and happy automating!