AutomatedLab Tutorial Series Part 4: Install a Simple PKI Environment

Summary: Learn how to easily deploy a PKI environment by using AutomatedLab.

Microsoft Scripting Guy, Ed Wilson, is here. Welcome back Microsoft PFEs, Raimund Andree and Per Pedersen, and their series about AutomatedLab. Read their previous posts here:

• AutomatedLab Tutorial Part 1: Introduction to AutomatedLab
• AutomatedLab Tutorial Part 2: Create a Simple Lab
• AutomatedLab Tutorial Part 3: Working with Predefined Server Roles

This blog post shows how to use AutomatedLab to easily deploy a public key infrastructure (PKI) environment. The PKI environment will be a single server, which is installed with the certification authority (CA) role. Subsequently, you will be able to request and issue certificates to all computers and users in your lab. Also, if you want to sign Windows PowerShell scripts in the lab, a certificate can be created for this purpose.

Installation

If you have a version of AutomatedLab that is earlier than AutomatedLab 2.5, please uninstall it and install the latest version. You can find what you need on Microsoft TechNet: AutomatedLab.

The installation process for AutomatedLab is explained in AutomatedLab Tutorial Part 2: Create a Simple Lab.

Prerequisites for AutomatedLab

AutomatedLab requires Hyper-V and Windows PowerShell 3.0 (or higher). Hence, you need one of the following operating systems on the host where you want to install the lab:

• Windows Server 2012 R2
• Windows Server 2012
• Windows 8.1
• Windows 8

     Note  Although Windows Server 2008 R2 could work, and Windows 10 hasn’t been tested, at this time, we recommend
     that you use one of the listed operating systems on the host machine.

AutomatedLab scripts need to be running directly on the host where the lab environment (the virtual machines) will be created.

Prerequisites for installing a CA in the lab

The only prerequisite for the certification authority (CA) installation is that the server needs to be running Windows Server 2012 R2 or Windows Server 2012.

There are two types of certification authorities: Stand-alone or Enterprise. There are two major differences for the installation for the Enterprise CA:

• It requires the server to be domain joined.
• The account used during the installation of the role needs to have Domain Admin permissions.

In this post, we install an Enterprise CA.

Define the lab machines

For simplicity, we will use two machines. One machine will be become a domain controller and the other machine will become the certification authority server. The domain controller is defined as follows:

$role = Get-LabMachineRoleDefinition -Role RootDC `

   -Properties @{DomainFunctionalLevel = “Win2012R2”

                 ForestFunctionalLevel = “Win2012R2”}

Add-LabMachineDefinition -Name S1DC1 -MemoryInMb 512 `

    -Network $labNetworkName -IpAddress 192.168.81.10 -DnsServer1 192.168.81.10 `

    -DomainName test1.net -IsDomainJoined `

    -Roles $role `

    -InstallationUserCredential $installationCredential `

    -ToolsPath $labSources\Tools `

    -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’

     Note  Refer to the previous posts in this series for details about defining machine roles.

The certification authority (like the domain controller) is a role in AutomatedLab, and this role needs to be specified when defining the lab machine. The role is selected by using the Get-LabMachineRoleDefinition cmdlet as follows:

$role = Get-LabMachineRoleDefinition -Role CaRoot

Next, the lab machine can defined using the selected role.

Add-LabMachineDefinition -Name S1CA1 `

    -MemoryInMb 512 `

    -Network $labNetworkName `

    -IpAddress 192.168.81.11 `

    -DnsServer1 192.168.81.10 `

    -DomainName test1.net `

    -IsDomainJoined `

    -Roles $role `

    -InstallationUserCredential $installationCredential `

    -ToolsPath $labSources\Tools `

    -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’

After defining the lab machines, start the installation of the lab as usual:

1. Export the lab definition.
2. Import it (which also validates the configuration and reports any errors).
3. Start the installation, which will create the virtual network, create base images, create virtual machines running Hyper-V, and install the roles found in the lab.

The script looks like this:

Export-LabDefinition -Force -ExportDefaultUnattendedXml

Import-Lab -Path (Get-LabDefinition).LabFilePath

Install-Lab -NetworkSwitches -BaseImages -VMs

Install-Lab -Domains

At this point, the domain controller is installed and ready. Now the installation of the certification authority needs to be started. This is done like this:

Install-Lab -CA

Notice that you do not need to instruct the Install-Lab cmdlet about how to install the CA and how it should be configured. This is done automatically.

The lab is ready with a domain controller (hosting a domain, of course) and with an Enterprise CA. You can request and issue certificates from the subordinate CA for use in your lab.

Customize the configuration of the CA

The first installation was very easy because the entire configuration is automatic when you call Install-Lab -CA. **Now **let’s try installing a PKI environment where we define some of the CA configuration. Even though the default installation will work in the majority of situations for a test lab, it could be necessary to specify certain parts of the configuration for the PKI environment.

First the current lab needs to be removed:

Remove-Lab -Path lab.xml file>

The Remove-Lab cmdlet turns off and removes the virtual machines, the disks, and the network adapter.

The domain and the domain controller need to be defined as they were previously:

$role = Get-LabMachineRoleDefinition -Role RootDC `

-Properties @{DomainFunctionalLevel = “Win2012R2”

              ForestFunctionalLevel = “Win2012R2”}

Add-LabMachineDefinition -Name S1DC1 `

    -MemoryInMb 512 `

    -Network $labNetworkName `

    -IpAddress 192.168.81.10 `

    -DnsServer1 192.168.81.10 `

    -DomainName test1.net `

    -IsDomainJoined `

    -Roles $role `

    -InstallationUserCredential $installationCredential `

    -ToolsPath $labSources\Tools `

    -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’

When you define the CA, you have the option of specifying configuration parameters. Take a look at the following:

$role = Get-LabMachineRoleDefinition `

  -Role CaRoot @{CACommonName = “MySpecialRootCA1”

                 KeyLength = “2048”

                 ValidityPeriod = “Weeks”

                 ValidityPeriodUnits = “4”}

The lab machine can be defined by using the selected role with the customized configuration. This command is the same as we used previously—only the content of the $role variable is different:

Add-LabMachineDefinition -Name S1CA1 -MemoryInMb 512 `

    -Network $labNetworkName `

    -IpAddress 192.168.81.11 `

    -DnsServer1 192.168.81.10 `

    -DomainName test1.net `

    -IsDomainJoined `

    -Roles $role `

    -InstallationUserCredential $installationCredential `

    -ToolsPath $labSources\Tools `

                -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’

As previously, perform the actual installation of the lab by using:

Export-LabDefinition -Force -ExportDefaultUnattendedXml

Import-Lab -Path (Get-LabDefinition).LabFilePath

Install-Lab -NetworkSwitches -BaseImages -VMs

Install-Lab –Domains

Install-Lab -CA

Notice that the command for installing the CA is almost the same as we used previously. The difference is that now the parameters specified in the Role parameter will be passed to the CA installation code.

This time, the lab is ready with a domain controller (hosting a domain, of course) and with an Enterprise CA configured by using our customized parameters.

To see all the parameters that are possible to specify when you install a CA server in AutomatedLab, you can type the following:

Get-Help Install-LWLabCAServers -Parameter *

Or to see only the names of the parameters (without the detailed information), type:

(Get-Command Install-LWLabCAServers).Parameters.Keys

     Note  Changing the parameters for the CA servers requires that you know about how the corresponding configuration
     parameters for CA servers are working. Hence, it is only recommended to customize parameters if you know about
     the PKI and have the need to customize parameters.

Supported PKI configurations in AutomatedLab

AutomatedLab supports one-tier and two-tier deployments for the PKI. This means that you can solely deploy a root CA, or you can deploy a root CA with a subordinate CA to this root CA.

AutomatedLab supports only PKI deployments in the same Active Directory forest. That is, deployment of a root CA in one Active Directory forest and a subordinate CA in another Active Directory forest is not supported.

Use the CA in the lab

Now that your CA server is set up, you can request a certificate for a user, request a certificate for a computer, or configure automatic enrollment.

Request a certificate for a user

To make a manual request, we can use the Web Enrollment interface on the CA server. Open a browser on the CA server, and type http://localhost/CertSrv. The following website is displayed:

1. Open Internet Options, and on the Security tab, click Custom level, and Enable the setting called Initialize and script ActiveX controls not marked as safe for scripting.
2. Click Request a certificate, and then click User Certificate.

3. The following confirmation message appears. Click Yes.

4. Click Submit, and then click Yes.

5. Click Install this certificate. The following message appears:

6. Press the Windows key + R, type certmgr.msc, and press ENTER. The Certificate Manager console appears.

7. To see the certificate listed, select Certificates – Current User\Personal\Certificates.

8. Double-click the certificate name.

Congratulations! You now have a user certificate issued to contoso\Administrator installed locally on the CA server.

Request a certificate for a computer

It is also possible to request certificates for computers. We will make a manual request by using the certificates console on the CA server.

1. On the CA server, press Windows key + R, type mmc, and press ENTER.
2. Click the File menu, and then click Add/Remove Snap-in.
3. Click Certificates, and click on Add.

4. Select Computer account and click Next.

5. Click Finish. The root CA (license to be a certification authority) is present.

6. Under Certificates (Local Computer), double-click the Personal folder, right-click the Certificates folder, and click All Tasks, and then click Request New Certificate.

7. Click Next on the next two screens that appear.

8. Select the check box next to Computer, and click Enroll.

9. Click Details, and then click View Certificate.

Congratulations! Now you have issued a computer certificate for the CA server!

Enable automatic enrollment of certificates

Issuing the user and computer certificates was good fun. However, it will not be so much fun if you deploy a lab with 10+ computers and 50+ users and you need to enroll 60 certificates manually! Instead, you can configure automatic enrollment by following these steps.

1. On the CA server, press Windows key + R, type certtmpl.msc, and press ENTER.
2. All the Certificate Templates Console appears. These templates represent the types of certificates that are possible to be issued by the CA server.

3. Right-click the Computer certificate template, and click Duplicate Template.

4. In the Template display name field, type Computer Auto Enroll.

5. Click the Security tab, and then click Domain Computers.

6. In the Permissions for Domain Computers area, select the check boxes to allow Read, Enroll, and Autoenroll.

7. Add Domain Controllers with the same permissions.

8. Perform the same procedure for the User certificate template where permissions for Domain Users and the Administrator are modified to allow Read, Enroll, and Autoenroll.

9. Additionally, when duplicating the User certificate template…

    In User Autoenroll Properties, click the Subject Name tab, and clear the following check boxes:

• Include e-mail name in alternate subject name
• E-mail name

10. On the CA server, press Windows key + R, and type certsrv.msc, and press ENTER.

11. Right-click Certificate Templates, click New, and click Certificate Template to Issue.

12. Click the newly created certificate template, Computer Auto Enroll, and then click OK.

Follow the same procedure for the User Auto Enroll certificate template.

Configure a Group Policy setting

The certificate templates on the CA server are in place, and they will be issued by request. To make all computers and users automatically request certificates, you configure a Group Policy setting.

1. To open the Group Policy Management Tool, on the domain controller, press Windows key + R, type gpmc.msc, and then press ENTER.****
2. Click Forest: test1.net > Domains > test1.net.

3. Right-click the Default Domain Policy, and click Edit.

4. Click Default Domain Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.

5. In the Object Type area, double-click Certificate Services Client – Auto-Enrollment.

6. Change the Configuration Model to Enabled, then select both check boxes and click OK.

7. Perform the exact same changes for users under Default Domain Policy > User Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.

8. To test the auto enrollment, press Windows key + R, type mmc, and press ENTER.

9. Click the File menu and click Add or Remove Snap-ins.

10. Click Certificates, and then click Add.

11. Select Computer account, and then click Next.

12. Select Local computer, and then click Finish.

13. Click the Certificates tab again, and then click Add. This time, select My user account, and click Finish.

14. Click Certificate (Local Computer) > Personal > Certificates. The list contains three certificates, but none of these are issued from the certificate templates we created earlier.

15. Click Certificate (Current User) > Personal > Certificates. Only one self-signed certificate is present. There are no certificates from our CA server.

16. To update Group Policy, open a Windows PowerShell console and type:

gpupdate /force

A certificate has been automatically issued to the domain controller from our new certificate template. Also, user certificate has been issued!

Congratulations! When new computers are joined to the domain, they will automatically get a certificate.

The full script

$start = Get-Date

#Some definitions about folder paths

#This folder contains two sub folders

# -ISOs – Stores all the DVD images

# -PostInstallationActivities – any scripts to customize the environment after installation

$labSources = ‘E:\LabSources’

$vmDrive = ‘D:’

$labName = ‘PKISmall1’

#this folder stores the XML files that contain all the information about the lab

$labPath = “$vmDrive\$labName”

#create the target directory if it does not exist

if (-not (Test-Path $labPath)) { New-Item $labPath -ItemType Directory | Out-Null }

#create an empty lab template and define where the lab XML files and the VMs will be stored

New-LabDefinition -Path $labPath -VmPath $labPath -Name $labName -ReferenceDiskSizeInGB 60

#make the network definition

Add-LabVirtualNetworkDefinition -Name $labName -IpAddress 192.168.81.1 -PrefixLength 24

#and the domain definition with the domain admin account

Add-LabDomainDefinition -Name test1.net -AdminUser administrator -AdminPassword Password1

#these images are used to install the machines

Add-LabIsoImageDefinition -Name Server2012 -Path $labSources\ISOs\en_windows_server_2012_r2_with_update_x64_dvd_4065220.iso -IsOperatingSystem

#these credentials are used for connecting to the machines. As this is a lab we use clear-text passwords

$installationCredential = New-Object PSCredential(‘Administrator’, (‘Password1’ | ConvertTo-SecureString -AsPlainText -Force))

#the first machine is the root domain controller. Everything in $labSources\Tools get copied to the machine’s Windows folder

$role = Get-LabMachineRoleDefinition -Role RootDC @{ DomainFunctionalLevel = ‘Win2012R2’; ForestFunctionalLevel = ‘Win2012R2’ }

Add-LabMachineDefinition -Name S1DC1 `

    -MemoryInMb 512 `

    -IsDomainJoined `

    -DomainName test1.net `

    -Network $labName `

    -IpAddress 192.168.81.10 `

    -DnsServer1 192.168.81.10 `

    -InstallationUserCredential $installationCredential `

    -ToolsPath $labSources\Tools `

    -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’ `

    -Roles $role

#the second will be a member server configured as Root CA server. Everything in $labSources\Tools get copied to the machine’s Windows folder

$role = Get-LabMachineRoleDefinition -Role CaRoot

Add-LabMachineDefinition -Name S1CA1 `

    -MemoryInMb 512 `

    -IsDomainJoined `

    -DomainName test1.net `

    -Network $labName `

    -IpAddress 192.168.81.20 `

    -DnsServer1 192.168.81.10 `

    -InstallationUserCredential $installationCredential `

    -ToolsPath $labSources\Tools `

    -OperatingSystem ‘Windows Server 2012 R2 SERVERDATACENTER’ `

    -Roles $role

#This all has created the lab configuration in memory. Next step is to export it to XML. You could have made the

#lab definitions in XML as well or can do modifications in the XML if this seems easier.

Export-LabDefinition -Force -ExportDefaultUnattendedXml

#Set trusted hosts to ‘*’ and enable CredSSP

Set-LabHostRemoting

#Now the XML files needed to be reimported. Some basic checks are done for duplicate IP addresses, machine names, domain

#membership, etc. If this reports errors please run “Test-LabDefinition D:\LabSettings\Lab.xml” for more information

Import-Lab -Path (Get-LabDefinition).LabFilePath

#Now the actual work begins. First the virtual network adapter is created and then the base images per OS

#All VMs are diffs from the base.

Install-Lab -NetworkSwitches -BaseImages -VMs

#This sets up all domains / domain controllers

Install-Lab -Domains

#Install CA server(s)

Install-Lab -CA

#Start all machines what have not yet started

Install-Lab -StartRemainingMachines

$end = Get-Date

Write-Host “Setting up the lab took $($end – $start)”

What’s next?

The next post describes how to install a typical PKI hierarchy the way it is typically set up in production. This means there will be two CAs—one Stand-alone (the root CA) and one Enterprise (the subordinate CA).

~ Raimund and Per

Be sure to join us tomorrow when Raimund and Per bring us Part 5.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy