Active Directory tenant identity sources & vCloud Application Director 6.0.1

Recently, I encountered an issue while trying to add a cloud provider in vCloud Application Director 6.0.1. It turns out that, depending on the vCloud Automation Center identity source, you may need to capitalize the domain name in the user’s UPN. (See this post about attempting to add a cloud provider with a down-level username vs. a UPN.)

If the vCAC tenant’s identity source is Active Directory (not Native Active Directory), you can login using the username format of username@fqdn-domain. If the identity source is Native Active Directory, you must use the username format of username@FQDN-DOMAIN. So, damian@lab.dns vs. damian@LAB.DNS. As you can see below, the SAML response returned from vCenter SSO has the domain name capitalized when using Native Active Directory, and not capitalized when using Active Directory.

This only happens when using the default vsphere.local tenant in vCloud Automation Center, as additional tenants can only use Open LDAP or Active Directory.

Adding a cloud provider using Active Directory identity source

Log from vCenter 5.5.0U1a’s SSO vmware-identity-sts.log, located at /var/log/vmware/sso:

TRACE com.vmware.identity.sts.auth.impl.UNTAuthenticator] Starting to authenticate principal: damian.karlson@lab.dns
DEBUG com.vmware.identity.sts.auth.impl.UNTAuthenticator] Authenticated principal: {Name: damian.karlson, Domain: lab.dns} at time: Thu Jun 26 16:50:57 UTC 2014
DEBUG com.vmware.identity.sts.impl.STSImpl] Authenticated principal: {Name: damian.karlson, Domain: lab.dns} at time: Thu Jun 26 16:50:57 UTC 2014
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] 5 attributes retrieved for {Name: damian.karlson, Domain: lab.dns}
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=givenName, value=[Damian]] retrieved for {Name: damian.karlson, Domain: lab.dns}
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://rsa.com/schemas/attr-names/2009/01/GroupIdentity, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=Groups, value=[lab.dns\Domain Admins, lab.dns\vCenter Admins, lab.dns\Domain Users, lab.dns\Denied RODC Password Replication Group, vsphere.local\Administrators, vsphere.local\Everyone]] retrieved for {Name: damian.karlson, Domain: lab.dns}
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://schemas.xmlsoap.org/claims/UPN, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=userPrincipalName, value=[damian.karlson@lab.dns]] retrieved for {Name: damian.karlson, Domain: lab.dns}
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=surname, value=[Karlson]] retrieved for {Name: damian.karlson, Domain: lab.dns}
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://vmware.com/schemas/attr-names/2011/07/isSolution, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=Subject Type, value=[false]] retrieved for {Name: damian.karlson, Domain: lab.dns}

XML SAML response snipped farther down in the log:

<saml2:Subject>
	<saml2:NameID Format="http://schemas.xmlsoap.org/claims/UPN">damian.karlson@lab.dns</saml2:NameID>
	<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
		<saml2:SubjectConfirmationData xsi:type="saml2:KeyInfoConfirmationDataType">
			<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
				<ds:X509Data>
					<ds:X509Certificate>snipped</ds:X509Certificate>
				</ds:X509Data>
			</ds:KeyInfo>
		</saml2:SubjectConfirmationData>
	</saml2:SubjectConfirmation>
</saml2:Subject>

Log from vCloud Application Director’s catalina.out, located at /home/darwin/tcserver/darwin/logs/catalina.out:

INFO com.vmware.darwin.service.catalog.CloudProviderHelper - Logging in cloud url=https://iaas01.lab.dns with user=damian.karlson@lab.dns
INFO com.vmware.darwin.flow.engine.CloudServiceConnectionImpl - Generating SAML for user='damian.karlson@lab.dns' 
INFO com.vmware.darwin.cal.api.CALSessionFactory - Found cloud driver: type = vcac6_0 class = com.vmware.darwin.cal.driver.vcac6_0.VCACBackCloudDriver
INFO com.vmware.darwin.cal.driver.vcac6_0.VCACHelper - VCACCloudDriver instantiating...
INFO com.vmware.darwin.cal.driver.vcac6_0.VCACHelper - VCACCloudDriver instantiated successfully!

Adding a cloud provider using Native Active Directory identity source

Log from vCenter 5.5.0U1a’s SSO vmware-identity-sts.log:

TRACE com.vmware.identity.sts.auth.impl.UNTAuthenticator] Starting to authenticate principal: damian.karlson@lab.dns
DEBUG com.vmware.identity.sts.auth.impl.UNTAuthenticator] Authenticated principal: {Name: damian.karlson, Domain: LAB.DNS} at time: Thu Jun 26 18:53:22 UTC 2014
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] 5 attributes retrieved for {Name: damian.karlson, Domain: LAB.DNS}
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=givenName, value=null] retrieved for {Name: damian.karlson, Domain: LAB.DNS}
com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=surname, value=null] retrieved for {Name: damian.karlson, Domain: LAB.DNS}
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://vmware.com/schemas/attr-names/2011/07/isSolution, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=Subject Type, value=[false]] retrieved for {Name: damian.karlson, Domain: LAB.DNS}
com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://rsa.com/schemas/attr-names/2009/01/GroupIdentity, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=Groups, value=[lab.dns\Domain Users, lab.dns\vCenter Admins, lab.dns\Domain Admins, lab.dns\Denied RODC Password Replication Group, vsphere.local\Administrators, vsphere.local\Everyone]] retrieved for {Name: damian.karlson, Domain: LAB.DNS}
TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://schemas.xmlsoap.org/claims/UPN, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=userPrincipalName, value=[damian.karlson@LAB.DNS]] retrieved for {Name: damian.karlson, Domain: LAB.DNS}

XML SAML response snipped farther down in the log:

<saml2:Subject>
	<saml2:NameID Format="http://schemas.xmlsoap.org/claims/UPN">damian.karlson@LAB.DNS</saml2:NameID>
	<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
		<saml2:SubjectConfirmationData xsi:type="saml2:KeyInfoConfirmationDataType">
			<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
				<ds:X509Data>
					<ds:X509Certificate>snipped</ds:X509Certificate>
				</ds:X509Data>
			</ds:KeyInfo>
		</saml2:SubjectConfirmationData>
	</saml2:SubjectConfirmation>
</saml2:Subject>

Log from vCloud Application Director’s catalina.out:

INFO com.vmware.darwin.service.catalog.CloudProviderHelper - Logging in cloud url=https://iaas01.lab.dns with user=damian.karlson@lab.dns
INFO com.vmware.darwin.flow.engine.CloudServiceConnectionImpl - Generating SAML for user='damian.karlson@lab.dns' 
ERROR com.vmware.darwin.flow.engine.CloudServiceConnectionImpl - Error occured while generating SamlToken for the user=damian.karlson@lab.dns
com.vmware.darwin.csp.exception.CspException: Use damian.karlson@LAB.DNS for Username field instead of damian.karlson@lab.dns

Environment:

  • vCloud Application Director 6.0.1.0 Build 1571033
  • vCloud Automation Center 6.0.1 Build: 1571033, using vCenter’s SSO
  • vCenter Server Appliance 5.5.0.10100 Build 1750781

Adding a cloud provider in vCloud Application Director 6.0.1

If you’ve tried to add a new cloud provider within vCloud Application Director 6.0.1, you may have run into an issue where the credentials can’t be validated. The (less than helpful) UI error message is: Could not connect to the Cloud Provider at https://iaas01.lab.dns: Unable to login to cloud provider. Please verify the user credentials as well as other parameters you entered.

The documentation says to use a down-level logon in the format of domain\username, which is incorrect. [Source: http://pubs.vmware.com/appdirector-6/topic/com.vmware.appdirector6.using.doc/GUID-0D61812D-98F7-4D0C-83C1-AF55678EFA53.html]

If you examine Application Director’s tcserver catalina.out log, located at /home/darwin/tcserver/darwin/logs/, you’ll see the following (surprisingly helpful!) error message.

Jun 24 2014 17:18:40.703 INFO  [http-bio-8443-exec-10] [damian.karlson@lab.dns] com.vmware.darwin.service.catalog.CloudProviderHelper - Logging in cloud url=https://iaas01.lab.dns with user=lab.dns\damian.karlson
Jun 24 2014 17:18:40.703 INFO  [http-bio-8443-exec-10] [damian.karlson@lab.dns] com.vmware.darwin.flow.engine.CloudServiceConnectionImpl - Generating SAML for user='lab.dns\damian.karlson' 
Jun 24 2014 17:18:42.134 ERROR [http-bio-8443-exec-10] [damian.karlson@lab.dns] com.vmware.darwin.flow.engine.CloudServiceConnectionImpl - Error occured while generating SamlToken for the user=lab.dns\damian.karlson
com.vmware.darwin.csp.exception.CspException: Use damian.karlson@lab.dns for Username field instead of lab.dns\damian.karlson

Environment:

  • vCloud Application Director 6.0.1.0 Build 1571033
  • vCloud Automation Center 6.0.1 Build: 1571033, using vCenter’s SSO
  • vCenter Server Appliance 5.5.0.10100 Build 1750781

Search-Cloud is cooler than you might think

PowerCLI 5.0.1 delivered new vCloud Director functionality including a cmdlet named Search-Cloud. If you’ve taken a look at Get-Help Search-Cloud, you’ll see a parameter named -QueryType used to “Specify what types of objects you want to search for”. That’s great, but what types of objects *can* you search for? The help, sadly, isn’t very helpful.

There are a couple different ways to find out. One of them is specific to PowerCLI 5.0.1 and is the Cmdlet Reference. By drilling into the All Cmdlets section and locating Search-Cloud, you’ll see that the parameter named QueryType is of the type QueryType, which is a .NET Enum. Click on the QueryType and you’ll see all the cool things that you can search for using Search-Cloud. Very nice!

AdminAllocatedExternalAddress
AdminCatalogItem
AdminCatalog
AdminGroup
AdminMedia
AdminOrgNetwork
AdminShadowVM
AdminTask
AdminUser
AdminVAppNetwork
AdminVApp
AdminVAppTemplate
AdminVM
AdminVdc
AllocatedExternalAddress
BlockingTask
CatalogItem
Catalog
Cell
DatastoreProviderVdcRelation
Datastore
DvSwitch
Event
Group
Host
Media
NetworkPool
Network
OrgNetwork
Org
OrgVdc
OrgVdcResourcePoolRelation
Portgroup
ProviderVdcResourcePoolRelation
ResourcePool
Right
Role
StrandedUser
Task
User
VAppNetwork
VAppOrgNetworkRelation
VApp
VAppTemplate
VM
VMWProviderVdc
VirtualCenter

;

There are a few other ways to figure out what the type of parameter -QueryType is, and the expected values. One of them is quite simple, use an invalid -QueryType.


PS C:\>; Search-Cloud -QueryType me
Search-Cloud : Cannot bind parameter 'QueryType'. Cannot convert value &quot;me&quot; to type &quot;VMware.VimAutomation.Cloud.View
s.QueryType&quot; due to invalid enumeration values. Specify one of the following enumeration values and try again. The p
ossible enumeration values are &quot;User, AdminVAppNetwork, AdminUser, BlockingTask, Cell, Host, AdminCatalogItem, Vm, A
dminCatalog, Group, AllocatedExternalAddress, OrgVdcResourcePoolRelation, AdminVApp, DvSwitch, Organization, VAppTem
plate, AdminAllocatedExternalAddress, OrgNetwork, Catalog, VirtualCenter, ResourcePool, Right, StrandedUser, Portgro
up, AdminVM, Media, AdminVAppTemplate, AdminOrgVdc, OrgVdc, CatalogItem, Event, VApp, AdminOrgNetwork, VAppNetwork,
AdminShadowVM, Datastore, ProviderVdc, DatastoreProviderVdcRelation, AdminMedia, ExternalNetwork, NetworkPool, Admin
Group, Task, AdminTask, VAppOrgNetworkRelation, Role, ProviderVdcResourcePoolRelation&quot;.
At line:1 char:24
+ Search-Cloud -QueryType <;<;<;<;  me     + CategoryInfo          : InvalidArgument: (:) [Search-Cloud], ParameterBindingException     + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,VMware.VimAutomation.Cloud.Commands.Cmdlets.SearchCloud 

Another would be to find the ParameterType, which shows us it’s VMware.VimAutomation.Cloud.Views.QueryType. This can be accomplished in steps:

 PS C:\>; Get-Command search-Cloud | Select-Object -ExpandProperty Parameters

Key                                Value
---                                -----
Name                               System.Management.Automation.ParameterMetadata
Filter                             System.Management.Automation.ParameterMetadata
QueryType                          System.Management.Automation.ParameterMetadata
Property                           System.Management.Automation.ParameterMetadata
Server                             System.Management.Automation.ParameterMetadata
Verbose                            System.Management.Automation.ParameterMetadata
Debug                              System.Management.Automation.ParameterMetadata
ErrorAction                        System.Management.Automation.ParameterMetadata
WarningAction                      System.Management.Automation.ParameterMetadata
ErrorVariable                      System.Management.Automation.ParameterMetadata
WarningVariable                    System.Management.Automation.ParameterMetadata
OutVariable                        System.Management.Automation.ParameterMetadata
OutBuffer                          System.Management.Automation.ParameterMetadata

And then:


PS C:\>; (Get-Command search-Cloud | Select-Object -ExpandProperty Parameters).QueryType

Name            : QueryType
ParameterType   : VMware.VimAutomation.Cloud.Views.QueryType
ParameterSets   : {[__AllParameterSets, System.Management.Automation.ParameterSetMetadata]}
IsDynamic       : False
Aliases         : {}
Attributes      : {__AllParameterSets, System.Management.Automation.ValidateNotNullOrEmptyAttribute}
SwitchParameter : False

And


PS C:\>; (Get-Command search-Cloud | Select-Object -ExpandProperty Parameters).QueryType.ParameterType

IsPublic IsSerial Name                      BaseType
-------- -------- ----                      --------
True     True     QueryType                 System.Enum

Now that we know it’s an enum, we can do a couple different things. The code below will list out all the names in the enum.


[Enum]::GetNames(&quot;VMware.VimAutomation.Cloud.Views.QueryType&quot;)

We’ll get effectively the same information back in this way, too.


[VMware.VimAutomation.Cloud.Views.QueryType] | Get-Member -Static -MemberType Property

PowerCLI: Remove all vmnics from a vSwitch

You can tell I’m getting rusty with the PowerCLI, which is something I intend to fix. In the meantime, I needed a PowerCLI way to remove all vmnics from a host’s vSS. If you take a look at the PowerCLI cmdlet documentation, you’ll find the syntax for Set-VirtualSwitch. It’s pretty simple; whatever NIC you pass along with the -Nic parameter overwrites whatever’s there already.

Example:


Get-VirtualSwitch -VMhost host1.lab.local -Name vSwitch1 | Set-VirtualSwitch -Nic vmnic4

The above code will replace whatever vmnics are currently connected to the vSwitch with vmnic4. But what if you want to remove all the nics from the vSwitch? The answer is simple; pass an empty array to the -Nic parameter.


$nic = @() //creates an empty array called $nic

Get-VirtualSwitch -VMhost host1.lab.local -Name vSwitch1 | Set-VirtualSwitch -Nic $nic

Voila!

#vBrownBag: vCloud Director & the AutoLab

If you listen to or attend the #vBrownBags on a regular basis, then chances are you’ve heard of the AutoLab. If you haven’t, then allow me. DUDE, you should check out the AutoLab! 🙂

The AutoLab is brought to you by APAC vBrownBag host Alastair Cooke (web/twitter), and our mad genius behind the boards, Nick Marshall (web/twitter). Its mission is simple: to provide an easy way to deploy a vSphere lab on ESXi or Workstation. If you have a laptop with about 8GB RAM and a modern CPU, then you can probably run the AutoLab! Sure, it won’t be like running a quad-socket 8 core beast with 1TB of RAM and EFD, but it’ll get you labbing, and that’s all that counts. If you’d like to get started, head over to labguides.com and download the AutoLab. I won’t go into detail on getting it setup, but I do want to outline a few minor alterations I did to get vCloud Director up and running.

First, I changed up the way Workstation manages the memory. I only have 8GB of RAM in this laptop, so overhead is a bit tight, especially if I’m running my WinXP VM as well, which I use as a personal VM inside my corporately imaged laptop. The AutoLab instructions say to go into Workstation’s Preferences menu and set the memory to “Fit all virtual machine memory into reserved host RAM”, which is essentially a memory reservation within Workstation. That approach works well, and I imagine that it helps to reduce swapping, especially on computers with spinning disks. Since my laptop runs SSD, I wanted to have more VMs running at once without having Workstation complain about running out of memory. I changed the memory setting to “Allow most virtual machine memory to be swapped”.

Another change I had to make was to increase the memory allocated to the Host1 and Host2. Staying with the default 2GB works for vSphere labbing, but once you install vCloud Director, you might want some memory available to power on VMs within vCD. I also went into the DC VM’s DHCP panel and increased the lease times. My reasoning for that is since I’m using the vCloud Director appliance; it does all of it’s setup business based on the DHCP addresses it receives at first power-on. If those addresses change, your vCD won’t run. Sure, you can go in and fix it, but it’s a PITA (IMO), so why bother? 🙂

After your AutoLab is setup, download the vShield Manager and vCloud Director appliances. The vShield Manager appliance has a EULA that goes crazy on my copy of Workstation, so I “fixed” it by unzipping the ova (it’s a zip file, after all, just a different extension), deleting the .mf & .cert files, and removing all the text between the <License> tags within the .ovf file’s XML. Before you delete the EULA, you should probably read and understand what you’ll be agreeing to. 🙂 Don’t bother rezipping into an .ova, just open the .ovf file with Workstation, agree to the now non-existent license (remember, you agreed when you read then deleted it) and let the install complete. Once it finishes, change the network from Bridged to the VMnet3 you created when you deployed the AutoLab, and set the memory to 384MB instead of 3GB. Power on the vShield Manager VM and wait for the startup to complete. Login to the vShield VM using the credentials of admin/default, enter privileged mode with the en command and the password default and type setup. You’ll be presented with a setup wizard of sorts; I used 192.168.199.8 for the IP, 255.255.255.0 for the subnet mask, 192.168.199.2 for the gateway, 192.168.199.4 for DNS, and lab.local for the DNS domain search list. After the vShield Manager setup completes, go over to the DC VM’s DNS panel and create a forward and reverse lookup for the vShield Manager VM, whose hostname will be manager by default. You may also want to setup a DHCP reservation for that IP address (if you want to be extra sure it won’t lose its IP); you can find the vShield Manager’s MAC address by logging into privileged mode and issuing the command show interface.

If you haven’t installed vCD previously, or if you have previous vShield experience outside of vCloud Director, the process is a bit different when using vShield in conjunction with vCenter. First, you won’t need to register your vShield Manager VM within vCenter, as it will be controlled by vCloud Director. Second, if you need to license it for whatever reason, the licensing is handled via vCenter’s Licensing panel. vCenter becomes aware of it once you connect vShield to vCloud Director and vCloud Director is connected to a vCenter.

Next up, open the vCloud Director appliance’s .ova file and add it to Workstation. Be sure to change the two bridged network adapters over to VMnet3, or your appliance will either wait forever for an IP address, or get one from the DHCP server on your Workstation’s LAN. Either way, at this point it’s simpler just to delete the VM and start over. The vCloud Director initial setup will take a while, so be patient until it completes. Interrupting it will most likely break it, so you’ll be back to the “delete and re-install shuffle” if you’re impatient. You’ll know it setup correctly if you can browse to the address displayed on the VM console (minus the 5480 port) and see the vCloud Director setup page.

At this point you can complete the vCloud Director web-based setup, but don’t go so far as to connect vCenter. If you have any troubles with name resolution to either vCenter or your vShield Manager VM, check DNS. When that is done, hop back over to the vCloud Director VM’s console and choose the Configure Network option. Change the hostname to something other than localhost, take note of the IP addresses it pulled from DHCP, save your changes and exit the network configuration screen. Next, choose the Login option, use the root/Default0 credentials and issue the command ifconfig to get the MAC addresses for the network interfaces if you want to do DHCP reservations over on the DC VM. You will want to add forward and reverse DNS records for the vCloud Director VM.

Once all the setup is completed, you can head over to the VC VM and use that to launch the vSphere client and point the browser towards the vCloud Director web page. If the rest of your lab is up and running, feel free to connect vCenter and start building out your provider virtual datacenter.

Happy AutoLabbing!