WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Quick Tip - Using ovftool to connect to vCloud Director behind a 2-Factor Authentication portal

06.08.2015 by William Lam // 2 Comments

A couple of months back I ran into an issue while trying to upload a couple of files to VMware's internal OneCloud environment which uses vCloud Director. The issue that I encountered was that our OneCloud environment no longer supported basic username/password authentication, which I hoping to automate using ovftool. Instead, it is now front-ended with VMware Application Manager which requires 2-Factor Authentication (2FA) and once authenticated, a SAML token is then passed to vCloud Director which then automatically logs you in.

ovftool-vcloud-director-SAML-authentication-0
The problem with this is that ovftool can not be used to directly login to vCloud Director as it does not have support for 2FA, which makes automating operations against our OneCloud environment pretty difficult. After spending a few days looking for an alternative and not having any luck, my last hope was to reach out to the ovftool developers to see if they had seen this before.

After a few email exchanges, although ovftool does not support 2FA, you can however get this to work using session ticket authetnication which it does support using either the --I:sourceSessionTicket or --l:targetSessionTicket option. To get more details on these options, you can run the following ovftool command:

ovftool --help integration

In order to use this session ticket mechanism to authenticate into a 2FA environment, you must first login manually using a web browser. Once you have successfully logged in, you will need to either use browser developer tool or something like Firebug to record the authenticated vCloud Director cookie which will then be passed to ovftool.

In this example, I am using Chrome and you can find the Developer Tools by going to Options->More Tools->Developer Tools. Next, refresh the webpage so you are able to see the web requests between your browser and vCloud Director. Now navigate to Network->Cookies option and select any one of the requests to the left of the screen such as "amf".

ovftool-vcloud-director-SAML-authentication1
What you will be looking for is the value to the cookie named "vcloud_session_id" which is is the authenticated session that we will use to provide to ovftool. Once you have that value, you can then specify the connection to ovftool using the following:

ovftool --I:targetSessionTicket=[VCLOUD_SESSION_ID_VALUE] vcloud://...

I had known that ovftool supported session based tickets, however I did not realize it could be used to authenticate behind a 2FA solution like VMware Application Manager. For folks interested in using ovftool and session based tickets directly with vSphere, check out this awesome post by my good friend Jake Robinson who demonstrates this using PowerCLI, ovftool and the AcquireCloneTicket() vSphere API method.

Categories // Automation, OVFTool Tags // ovftool, SAML, vcd, vcloud director, vSphere API

How should bulk operations such as adding ESXi hosts work?

06.04.2015 by William Lam // 4 Comments

I had a meeting yesterday with a couple of Engineers to provide some feedback on a new project they were working on and they were interested in getting feedback on their  workflows but also my overall impression of the user experience (UX). One area that we had spent some time covering was on adding new resources such as an ESXi host which is performed using either a UI/API/CLI. In the case of adding an ESXi host, this was done sequentially and a user would need to specify multiple parameters like the hostname, IP Address, credentials, etc. and perform this task N-number of times until you had added all of the ESXi hosts that you wanted. Many of you are probably already familiar with this workflow as it exists in many of the current VMware products today when requiring to add a resource like an ESXi host.

I was wondering why this was the case and why not support a bulk add operation? This was not a new idea and in fact I and many others have asked about this in the past on why our own vSphere Web Client does not support bulk operations for some of the more common operations such as adding an ESXi host or provisioning a VM? In fact, I was actually reminded of this topic again this morning when I needed to mount an NFS Volume across multiple ESXi hosts and one of the new capabilities that was introduction in the vSphere Web Client over the vSphere C# Client was being able to bulk add an NFS Volume across multiple hosts.

Bulk support for adding NFS volumes across multiple ESXi host, still love this feature! Simple, yet powerful & useful pic.twitter.com/TZ7KeG52f6

— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) June 4, 2015

Not only is this a useful capability to have but when you need to perform the same operation multiple times, there is also an increase of risk for making a mistake. Sure, if you mount the wrong NFS volume, you would have it wrong across all the hosts but this is no different if you were to Automate it from an API/CLI. I am sure some of you are probably saying, a simple for loop would do the trick and though I agree that would be the easiest way. However, it would be really nice that some of these operations would actually have native support for bulk operations from an API standpoint, that way this is not limited to just a UI-only feature which it is today. Even in the case of a simple for-loop, you are still executing the individual operation N-number of times versus being able to pass in a list and perform a single request and then rely on the backend implementation to properly handle the operation which could be done in parallel or sequentially depending on the type of operation.

Thinking about this a bit more, it may not be as simple as just adding bulk operation support into an API but there are also other things to consider. What happens when the resource you are adding has varying configurations, a classic example of this is adding multiple ESXi hosts. If they all have the same username and password, then you can provide the credentials once and then a list of ESXi hosts. What happens when they differ or in the worse case scenario, they all have different passwords? What happens when only a subset of the hosts are added, do you continue or fail all together?

I am actually curious to hear what others think about this and what your expectations would be? Both from a UI standpoint as well as from an Automation standpoint which includes API/CLI. Would a simple JSON/YAML configuration file that contains all hosts and credentials be acceptable with the option of having common global configurations and ability to override for individual entries? Would love to hear your thoughts on this and what you would be expecting? Perhaps this is something I can also share back with the Engineering teams as this is something I have been wanting to see for quite some time, especially when it comes to common operations like adding ESXi hosts and provisioning VMs.

Categories // Automation, vSphere Web Client Tags // add host, bulk operation, ESXi

vCenter Server 6.0 Tidbits Part 10: Automating SSO Admin configurations

06.03.2015 by William Lam // 4 Comments

A common request that I have heard from customers is to have the ability to automate vCenter Single Sign-On configurations from a programmatic standpoint. Unfortunately, this is currently not possible today as a public API does not exist for SSO. Having spent some time exploring the underlying vmdir database which is just an LDAP-based system (here & here) and learning about a way to update a particular key per KB2070433 within the vmdir database which I have shown here and I have found here, I wanted to see if it was possible to query for these specific SSO Admin configurations and also be able to update these properties.

Disclaimer: Please take extreme caution when connecting to the vmdird database. You should take extreme care in making changes while in the database else you can negatively impact your environment.

There are three main sections to the SSO Admin configurations that can be seen from the vSphere Web Client:

  • Password Policies
  • Lockout Policy
  • Token Policy

For each section, I have provided the specific ldapsearch query (please refer to this article as per-requisite) which can either be run directly on the VCSA if you are using that or a system that includes the ldapsearch command. You will need to replace the text highlighted in blue with your own environment details.

Password Policies & Lockout Policy

To view the following set of configurations, here is the ldapsearch query to use:

/opt/likewise/bin/ldapsearch -h 192.168.1.70 -w 'VMware1!' -x -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -b "cn=password and lockout policy,dc=vghetto,dc=local"

automate-sso-configuration-3
Here is a screenshot of the Password Policies as seen in the vSphere Web Client and their corresponding LDAP property names:

automate-sso-configuration-0

UI Setting LDAP Attribute Name
Maximum lifetime vmwPasswordLifetimeDays
Restrict reuse vmwPasswordProhibitedPreviousCount
Maximum lenght vmwPasswordMaxLength
At least special character vmwPasswordMinSpecialCharCount
At least alphabetic character vmwPasswordMinAlphabeticCount
At least uppercase character vmwPasswordMinUpperCaseCount
At least lowercase character vmwPasswordMinLowerCaseCount
At least numeric character vmwPasswordMinNumericCount
Identical adjacent Characters vmwPasswordMaxIdenticalAdjacentChars

Here is a screenshot of the Lock Policy as seen in the vSphere Web Client and their corresponding LDAP property names:

automate-sso-configuration-1

UI Setting LDAP Attribute Name
Maximum number of failed login attempts vmwPasswordChangeMaxFailedAttempts
Time interval between failures vmwPasswordChangeFailedAttemptIntervalSec
Unlock time vmwPasswordChangeAutoUnlockIntervalSec

Token Policy

To view the following configuration, here is the ldapsearch query to use:

/opt/likewise/bin/ldapsearch -h 192.168.1.70 -w 'VMware1!' -x -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -b "cn=Tenants,cn=IdentityManager,cn=Services,dc=vghetto,dc=local" -s sub "objectclass=vmwSTSTenant"

automate-sso-configuration-4
Here is a screenshot of the Token Policy as seen in the vSphere Web Client and their corresponding LDAP property names:

Token Policy

automate-sso-configuration-2

UI Setting LDAP Attribute Name
Clock tolerance vmwSTSClockTolerance
Maximum token renewal count vmwSTSRenewCount
Maximum token delegation count vmwSTSDelegationCount
Maximum bearer token lifetime vmwSTSMaxBearerTokenLifetime
Maximum holder-of-key token lifetime vmwSTSMaxHolderOfKeyTokenLifetime

Now that we know how to query for a particular SSO Configuration, here is how you can modify one of these properties. In the example below, we will be changing the life time of a password which dictates the frequency in which you need to change an SSO user's password. Using the "Password Policies" table above, we can see the that property name is called vmwPasswordLifetimeDays

To modify an LDAP entry, we will need to first create a file that contains the change, in the example here we are going to name it change.ldif and it should contain the following where the "replace" keyword shows which property is getting modified and the next line after shows the value that it will be changed to.

dn: cn=password and lockout policy,dc=vghetto,dc=local
changetype: modify
replace: vmwPasswordLifetimeDays
vmwPasswordLifetimeDays: 30

To apply the change, we will now run the following ldapmodify command and specifying our change.ldif configuration file:

/opt/likewise/bin/ldapmodify -f change.ldif -h 192.168.1.70 -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -w 'VMware1!'

automate-sso-configuration-5
If the change was successful, you can confirm by either querying the property again using the ldapquery command or just refreshing the SSO Configurations using the vSphere Web Client.

  • vCenter Server 6.0 Tidbits Part 1: What install & deployment parameters did I use?
  • vCenter Server 6.0 Tidbits Part 2: What is my SSO Domain Name & Site Name?
  • vCenter Server 6.0 Tidbits Part 3: Finding all deployed Platform Services Controller
  • vCenter Server 6.0 Tidbits Part 4: Finding all deployed vCenter Servers
  • vCenter Server 6.0 Tidbits Part 5: New method of patching the VCSA
  • vCenter Server 6.0 Tidbits Part 6: Customizing VCSA’s DCUI
  • vCenter Server 6.0 Tidbits Part 7: Connecting to SSO/PSC using JExplorer
  • vCenter Server 6.0 Tidbits Part 8: Useful ldapsearch queries for vmdird
  • vCenter Server 6.0 Tidbits Part 9: Creating & managing SSO users using dir-cli
  • vCenter Server 6.0 Tidbits Part 10: Automating SSO Admin configurations
  • vCenter Server 6.0 Tidbits Part 11: Automate SSO Admin password change
  • vCenter Server 6.0 Tidbits Part 12: New methods of downloading Support Bundles for VCSA / PSC

Categories // Automation, VCSA, vSphere 6.0, vSphere Web Client Tags // ldapmodify, ldapsearch, platform service controller, psc, sso, vCenter Server, vcenter server appliance, VCSA, vcva

  • « Previous Page
  • 1
  • …
  • 183
  • 184
  • 185
  • 186
  • 187
  • …
  • 224
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...