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

Jessica, our (fictitious) cloud engineer at our (fictitious) Adatum consulting firm, has just built an Azure development lab environment using Infrastructure-As-Code, and feels quite pleased, but now her team lead Jason is asking her what their plan is for development scenarios that require PKI services. She gasps, stalls and looks up with a pensive expression as if the answer was somehow written on the ceiling and in a foreign language, where she must continue to pause even a moment longer so she can interpret it first. After what seemed to her like an uncomfortable but useful silence, she confidently exclaimed: "We'll configure PKI on one of the existing VMs that was just provisioned!" Jason responds appreciatively: "Great! And can you also automate the process so we can quickly reproduce, reference and offer the code for all our customers while preserving it in source control?"

 

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. 

 

1. Blog 
2. 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. 

 

1. 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. 
2. 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. 
3. 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. 
4. 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. 
5. 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. 
6. 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 

 

Jessica then executes the C:\Project0067\Configure-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.

 

If you prefer to maintain a greater degree of control on the source code and artifacts, you can just clone or import this public repository and place it under your own source control solution within your personal lab or enterprise development environment because this solution has an MIT license. In addition, you would need to modify the code and simply eliminate the steps to download the DSC configuration and parameters data files. 

 

I hope this information was useful and feel free to leave a comment. Thanks for reading and go build something great!

 

Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

 

References 

 

1. Video for this article. 
2. Code for this article. 
3. How to build an Azure Automation Lab: Article 
4. How to build an Azure Automation Lab: Code 
5. Check out my other blog articles at https://aka.ms/AutoCloudArc 

 

Other Links 

 

1. Windows PKI Documentation Reference and Library 
2. Building the Totally Network Isolated Root Certificate Authority 
3. Azure Automation:  https://docs.microsoft.com/en-us/azure/ 
4. Desired State Configuration:  https://docs.microsoft.com/en-us/powershell/dsc/overview