Summary: Microsoft PFEs, Raimund Andree and Per Pedersen, talk about using Windows PowerShell to automate the deployment of a PKI environment as it would typically be deployed in a production environment.
Microsoft Scripting Guy, Ed Wilson, is here. Today is Part 5 of a series by Microsoft PFEs, Raimund Andree and Per Pedersen. 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
- AutomatedLab Tutorial Series Part 4: Install a Simple PKI Environment
Following up on Part 4, this post explains how to deploy a public key infrastructure (PKI) environment as it would typically be deployed in a production environment. The PKI environment will be deployed using two servers. One server will be a root certification authority (CA) and the other will be a subordinate CA server.
The root CA will be in a workgroup and the subordinate CA will be in a domain. Subsequently, you will be able to request and issue certificates from the subordinate CA server 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 2012R2
- 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.
For more information about the overall installation process, refer to the previous posts.
Prerequisites for installing CA servers 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.
Defining the lab machines
For the subordinate server, a domain is needed. Hence, a domain controller needs to be installed. The installation is the same as in Part 4. The domain and the domain controller are 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'
Then the root CA needs to be installed. This server will be a stand-alone CA server—it is not joined to any domain.
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
The lab machine can be defined by using the selected role, for example:
Add-LabMachineDefinition -Name S1ROOTCA1 `
-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'
Next, the subordinate CA server needs to be defined. This is the command:
$role = Get-LabMachineRoleDefinition -Role CaSubordinate
The lab machine can be defined by using the selected role. This command is the same as defining the root CA—only the content of the $role variable is different.
Add-LabMachineDefinition -Name S2SUBCA1 `
-MemoryInMb 512 `
-Network $labNetworkName `
-IpAddress 192.168.81.12 `
-DnsServer1 192.168.81.10 `
-DomainName test1.net `
-IsDomainJoined `
-Roles $role `
-InstallationUserCredential $installationCredential `
-ToolsPath $labSources\Tools `
-OperatingSystem 'Windows Server 2012 R2 SERVERDATACENTER'
When all the machines have been defined, start the installation of the lab as usual:
- Export the lab definition.
- Import it (which also validates the configuration and reports any errors).
- 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 two Enterprise CA servers. Now, you can request and issue certificates (from the subordinate CA) for use in your lab!
Customize the configuration of the CA servers
The first installation was very easy because the entire configuration is automatic when you call Install-Lab -CA. Nowlet’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 of all, the current lab needs to be removed:
Remove-Lab -Path <path to the 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 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 = “4096”
ValidityPeriod = "Year"
ValidityPeriodUnits "20"}
The lab machine can be defined by using the selected role with the customized configuration.
Add-LabMachineDefinition -Name S1ROOTCA1 -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'
Lastly, the machine for subordinate CA needs to be defined. This command is the same as we used previously—only the content of the $role variable is different:
$role = Get-LabMachineRoleDefinition `
-Role CaRoot @{CACommonName = "MySpecialRootCA1"
KeyLength = “4096”
ValidityPeriod = "Year"
ValidityPeriodUnits "20"}
To define (add) the machine, type the following command. This command is the same as the command we used to define the root CA—only the content of the $role variable is different.
Add-LabMachineDefinition -Name S1SUBCA1 -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'
Use the following script to perform the actual installation of the lab:
Export-LabDefinition -Force -ExportDefaultUnattendedXml
Import-Lab -Path (Get-LabDefinition).LabFilePath
Install-Lab -NetworkSwitches -BaseImages -VMs
Install-Lab –Domains
Install-Lab -CA
Also notice that the command for installing the CAs is almost the same as the command we previously used. The difference is that now the parameters specified in the Role parameters will be passed to the CA installation script.
The lab is ready with a domain controller (hosting a domain) and with a complete two-tier PKI hierarchy 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 1-tier and 2-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.
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 = 'PKITypical1'
#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 S1ROOTCA1 `
-MemoryInMb 512 `
-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
#the thrid will be a member server configured as Subordinate CA server. Everything in $labSources\Tools get copied to the machine's Windows folder
$role = Get-LabMachineRoleDefinition -Role CaSubordinate
Add-LabMachineDefinition -Name S2SUBCA1 `
-MemoryInMb 512 `
-IsDomainJoined `
-DomainName test1.net `
-Network $labName `
-IpAddress 192.168.81.30 `
-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 discusses how to manage software inside your lab and how to run custom tasks by leveraging the AutomatedLab infrastructure.
Thanks to Raimund and Per. This is really helpful stuff. Please join us tomorrow for Part 6.
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