Home > Homelab, SSL > Planning and building the “nasty” SSL/SSO lab – Part 2

Planning and building the “nasty” SSL/SSO lab – Part 2

January 4th, 2015 Leave a comment Go to comments

As indicated in the last post this one will deal with the actual install and setup of the lab infrastructure. We will need 4 VMs as the basic minimum configuration. So let’s start by building out the Domain Controller machine.

I am using Workstation 11 for this lab build (basically just to test out the new Workstation version at the same time, the amount of free time I got to do so will rapidly decrease starting next week when support calls come in again). The laptop I am running this lab on has some horse power (8 Cores a 2.4GHz, 16GB RAM, 256GB SSD) but the lab should still perform somewhat decent on slower hardware as well. To save on disk space I will be using linked clones. If you want to do the same on ESXi check out the awesome post by William Lam (@lamw) explaining how to use the API to create linked clones using vSphere.

The base template will have a size of 1 vCPU, 2 GB RAM, 25GB HDD and 1 NIC attached to a custom network in Workstation (I do like to have my labs isolated just in case… don’t mess with the production network of a multi national company). Some tools like Notepad++ and Google Chrome will be installed to make life a bit easier (especially for the copy and paste of certificates to be done later on in the tasks, notepad and wordpad are not the primary choice of doing this).

After that base install was done I just checked with SpaceSniffer if something obvious could be removed to make the base template a bit smaller. Seems like nothing much apart from the pagefile. As I don’t expect the system to be swapping at all I removed it on the base template and will add it to the vCenter machine again as the RAM will be kinda capped there.

Capture2After deleting the swap file and the obligatory reboot, I also cleaned out the temp directory, shut down the server and reclaimed the wasted space on the virtual disks using Workstation. This made for a very small base installation to be used across all Windows VMs of around 7GB size.


In order to create linked clones the main VM needs to be snapshotted. Next up I cloned 3 VMs off that base VM and resealed all of them using sysprep (I have run into issues before not sysprepping my cloned VMs so I just do it on every deploy now, even if it should not be necessary). The only thing that needs to be customized now is that the vCenter VM will get an up to date version of Java and jXplorer. I have both as offline installers on a ISO image that I mount, otherwise you could connect the VM to the internet if feasible as well. jXplorer is needed in some of the labs later on to actually take a look at vmdir. Additionally the .NET 3.5 feature in Server Manager will be installed on the vCenter VM, as this is a prerequisite for the vCenter Server installation.



After all VMs are installed and resealed it’s time to rename the machines and give proper IP addresses from the diagram found in the first post of this series. After this is done the domain controller can be set up. Server 2008 R2 still allows to use dcpromo for a quick domain controller set up, while 2012 will need you to go through the actual server manager for this. Once the wizard is started (or you just use Powershell…) create a new domain in a new forest and basically accept defaults (I put the functional level to 2008 R2 though). I called my domain “training.local”. For those familiar how to use dcpromo with an unattended answer file can copy and paste the following for their setup to replicate.

; DCPROMO unattend file (automatically generated by dcpromo)
; Usage:
; dcpromo.exe /unattend:C:\Users\Administrator\Documents\settings.txt
; New forest promotion
; Set SafeModeAdminPassword to the correct value prior to using the unattend file
; Run-time flags (optional)
; RebootOnCompletion=Yes

After that installation is done it is time to create the reverse lookup zone in DNS to fulfill the installation requirements for SSO and vCenter Server.


The only thing we are missing on our domain controller now are the certificate services. I will follow something I drafted up last year to install the CA and create a custom VMware template following the guidelines in the following KB.

Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 5.x (2062108)

After this is done we can continue to join the vCenter Server and both SSO machines to the domain. This should also update the DNS records after a successful join. You will want to add one more record though for the load balanced SSO DNS name.



With this you are done with the domain controller for now. The CA has been installed successfully, DNS is set up and AD should be working fine as well. Next up is setting up the NLB in the 2 SSO machines.

First off you want to install the feature (it’s not a role) on both your SSO servers.



The administrative tools will get a new option called “Network Load Balancing Manager”, you will want to open this and create a new cluster.



The initial configuration will be done on SSO1 which means we give the wizard the IP of the local machine ( if you are following this example).



Accept the defaults on the next page and enter the clustering IP address ( on the third page. On the cluster parameters choose the FQDN of the cluster address you put into DNS (sso.training.local in this example), switch the mode to Multicast (I had no issues with Unicast on ESXi but Workstation does not seem to like it).



You can leave the defaults for the port rules. You basically repeat the same process on the second SSO node except this time you will be joining an existing cluster, so all you need to do is to provide the load balanced FQDN from the first node which will open up the cluster on the second node. Right click the cluster and choose “Add host to cluster”, provide the local IP ( and next through the wizard. After a successful setup your NLB Manager should look something like this and you should still be able to ping sso, sso1 and sso2 from the DC or the vCenter Server machine.



You can verify the configuration by starting a continous ping (ping -t) to the load balanced FQDN (sso.training.local) and shut down one of the SSO nodes. The ping should continue just fine. Power back up the node and shut down the other SSO machine, there still should be a continuous ping. This concludes the settings that need to be made to all the Windows VMs. Depending on how much RAM you can allocate you might want to re-enable the swap file on the vCenter Server Windows system though.  So far the lab is using a total storage of 9GB, something that is gonna change once we start installing the vSphere components in the next post.


Categories: Homelab, SSL Tags: