Packer vmware-iso builder on ESXi without DHCP

When you are building Windows Server 2012 R2 base images (vSphere Templates) using packer on vSphere (using vmware-iso packer builder); the process usually relies on the windows server to get an IP address automatically via DHCP. This allows the packer builder to then communicate to the server over WinRM and complete the provisioning.

What happens when there is no DHCP available in your vSphere VM Network?

The easy solution is to have the bootstrap of the windows server set a static IP for the server.
This would allow the packer builder to then communicate to the server over WinRM and complete the provisioning.
I already provide an Autounattend.xml to the windows server via the packer floppy_files stanza for the vmware-iso builder.

These user variables are populated with the environment specific floppy files:

I pass the config json file into the packer build command as shown below. This allows us to pass in different config per environment to the same build template for packer.

packer.exe build -var-file=Config-VMWare.json .\PackerBaseWin2012R2-VMWare.json

The Autounattend.xml executes the file a:\vmware-userdata.ps1 as the last step of the FirstLogonCommands setting of the Autounattend process.

The script for this particular environment then uses powershell cmdlets to configure the required static IP address allocated to the Packer Build VM:

Note: If you don’t wait long enough for the boot process to complete; the vmware-iso builder may detect the self assigned IP (169.x.x.x) prior to the userdata script setting the Static IP.
To solve this you can set the vmware-iso builder boot_wait to wait a bit longer, e.g. 10 mins.

This solves how to use packer on vSphere for Windows Server 2012 R2 bootstrapping where you don’t have a DHCP server on the subnet.

Windows 10 UEFI USB Boot in VMWare Fusion 7

You’ve downloaded your purchased Windows 10 ISO from Microsoft, and you’ve managed to create a bootable UEFI USB stick.
Now you’ve decided to run Windows 10 in VMWare Fusion Pro on your Mac. Yet the USB stick can NOT be booted from.
There is a solution. VMWare fusion has some (unsupported) EFI options you can enable to effect a USB boot.
First you’ll want to create a Windows 10 VM in VMWare Fusion.
Create a new VM, and select the more options icon:

Select Create a custom virtual machine and select Continue:

Select Windows 10 as the operating system, and select Continue – x64 is selected here as I’m 64 bit all the way:

Leave the virtual disk options and select Continue:

On the Summary Screen, you can use the Customize Settings button to change your VM defaults. I updated my RAM to 8GB, my CPU Cores to 2, and changed the VM Disk size to 100GB (60GB may be a bit small for most power users).

Before you start the VM; you’ll need to modify the vmx file directly.

1. In the Virtual Machine Library, right click on the Windows 10 VM and select Show in Finder.
2. Right click on the vmwarevm container and select Show Package Contents
3. Edit the *.vmx file using your favourite text editor
4. Append the following options to the configuration to enabled EFI booting:

firmware = "efi"
efi.legacyBoot.enabled = "true"


The Legacy boot option allows VMWare to see the USB device in some cases; and was required for me.
Boot your new VM:

You’ll find that the new EFI boot loaders are picked up, but not yet the USB. Since you couldn’t attach a USB before starting, you can do it now. Open the VM preferences and attach the USB containing the EFI Boot files:

VMWare will now boot into the Windows 10 setup.

Thanks to a post by A Virtual Den for pointing me in the right direction for the VMX LegacyBoot option!

ADFS2 is not always SAML 2.0 standards compliant

Now the madness with ADFS2 SAML assertions via WS-Trust 1.3 – and how they are not valid for use with Amazon Web Services (AWS).

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion
A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Responses must contain SubjectConfirmatonData with a Recipient and NotOnOrAfter

This failed due to a missing Recipient attribute on the SubjectConfirmationData element. Of course; I can’t modify the assertion to add the missing Recipient; as the SAML token is signed:

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion
A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Response signature invalid

Second fail is because I’ve modified the assertion to add the missing attribute; but now the signature is invalid.

When you get an assertion from the ADFS Identity Provider via the IdP Web Landing Page, for AWS, the assertion includes a “recipient”:




When you ask for an assertion from the WS-Trust 1.3 endpoint; it is missing:




Seems to be a common problem with ADFS2 whereby ADFS1 did it correctly. It’s not just me…

In the original SAML 2.0 Core spec – Line 725 – Recipient is an optional attribute in the SubjectConfirmationData element. However in subsequent errata for the specification, Errata 02 in May 2007, made it mandatory. Errata 05 still includes this requirement.

At lease one bearer element MUST contain a element that itself MUST contain a Recipient attribute containing the service provider’s assertion consumer service URL

Of course; Amazon adhere to the Standard:

The value of the Recipient attribute inside the SubjectConfirmationData element must match the AWS endpoint (https://signin.aws.amazon.com/saml)

It seems that ADFS2 doesn’t provide valid SAML 2.0 assertions issued via the WS-Trust 1.3 endpoint. Since this has been a standard since for almost 8 years, how does ADFS2 even claim to be standards based.

SAML assertion from ADFS2 via SOAP endpoint

According to Wikipedia, Microsoft Active Directory Federation Services (ADFS) is:

… a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and implement federated identity.

ADFS can provide Single sign as an identity provider to users, but what if a developer needs the same sign on outside of “browser land”? One option is to scrape webpage responses, but a better option is receiving a SAML Assertion using SOAP endpoints exposed via Microsoft ADFS, as long as they are enabled. You can use SOAP 1.2 with WS-A Addressing and mixed message security with the username/password in the SOAP headers secured over HTTPS, and get a valid SAML assertion.

There is Mex Endpoint (Anonymous by default) provided by ADFS2 or greater (if not disabled) at
https://youradfsserver.com.au/adfs/services/trust/mex
If you want to play with SOAP based claim requests, use a tool like SoapUI and consume the Mex endpoint as the WSDL. You can then construct Soap messages, and see if you get a valid response – which would contain an assertion.

The SOAP Endpoint for requesting a SAML token using WS-Trust 1.3 and mixed security would be
https://youradfsserver.com.au/adfs/services/trust/13/usernamemixed

The client credentials are included in the header of a SOAP message. Confidentiality is preserved at the transport layer (SSL/TLS); hence a usernamemixed endpoint.

Here is an example SOAP request for usernamemixed:

You can also use curl to post the soap request as shown:

Given all that; this actually won’t work for AWS; given ADFS2 actually breaks the SAML2.0 standards updated in 2012. Next post will detail this.