vSphere 6.0 – Page 30

How to create custom ESXi boot menu to support multiple Kickstart files?

06.11.2015 by William Lam // 31 Comments

I recently received a question from one of my readers who was looking to migrate from ESXi 4.1 to newer version and one of the challenges they faced was around their ESXi scripted installs, better known as ESXi Kickstart. Previously, they had relied on using a custom syslinux boot menu to be able to select a specific Kickstart configuration file that resided locally on a bootable ESXi Image (USB, ISO or CDROM) as a PXE/DHCP environment was not allowed in their environment. There was a small change to how ESXi boot files were reference between ESXi 4.x and ESXi 5.x/6.x and a new boot.cfg configuration is now used which I had written about here with respect to scripted installs when ESXi 5.0 was first released.

Luckily, even with these changes one can still use a custom menu with ESXi 5.x/6.x and be able to select a specific Kickstart configurations based on user input. Here is a screenshot example of a custom ESXi Image that I built providing three different install options that could be selected which would map to three different Kickstart configurations which can be either local to the boot media or can also be retrieved remotely.

The first thing you should be aware of if you plan to boot the custom ESXi Image from local media such as USB, CDROM or ISO is that the path to the Kickstart file must be in all UPPER CASE which is mentioned in this VMware KB 1026373. The next caveat that I found in my testing is that if you plan to store the local Kickstart files inside of a directory within the ESXi Image, the name of the directory can not be too long. I would recommend using "ks" as "kickstart" apparently was too long.

After you have extracted the contents of an ESXi ISO which you have downloaded, you will want to create a root directory called "ks" which will contain the different Kickstart configuration files. Here is an example of what structure look like:

ks
├── ks1.cfg
├── ks2.cfg
└── ks3.cfg

Next, you will need to edit the isolinux.cfg file which comes by default within the ESXi ISO. This is where you will add the different Kickstart options that a user will be able to select from. In this first example, we will look at referencing the Kickstart files locally on the media which can be either USB or CDROM and you will need to ensure you specify the right boot option as shown here in the VMware documentation. The path to the Kickstart file needs to be appended to the line that contains boot.cfg reference and you must ensure you include "+++" at the end of that line.

Here is an example of referencing a Kickstart file that lives on a USB device under this path /ks/ks.cfg:

APPEND -c boot.cfg ks=usb:/KS/KS.CFG +++

Here is an example of my isolinux.cfg for the boot menu that I have shown above which provides three different options mapping to three different Kickstart configuration files:

DEFAULT menu.c32
MENU TITLE vGhetto Custom ESXi 6.0 Boot Menu
NOHALT 1
PROMPT 0
TIMEOUT 80
LABEL Ghetto Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=cdrom:/KS/KS1.CFG +++
  MENU LABEL ^1 Ghetto Install
LABEL A bit More Ghetto Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=cdrom:/KS/KS2.CFG +++
  MENU LABEL ^2 A bit More Ghetto Install
LABEL Super Ghetto ESXi Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=cdrom:/KS/KS3.CFG +++
  MENU LABEL ^3 Super Ghetto ESXi Install
LABEL hddboot
  LOCALBOOT 0x80
  MENU LABEL ^Boot from local disk

As I mentioned earlier, the Kickstart configuration file can either be retrieved locally or it can also be retireved remotely using one of the following supported protocols: http, https, ftp & nfs as shown here in the VMware documentation.

Here is an example of isolinux.cfg for a boot menu which references both a local kickstart as well as one that remotely lives on a web server:

DEFAULT menu.c32
MENU TITLE vGhetto Custom ESXi 6.0 Boot Menu
NOHALT 1
PROMPT 0
TIMEOUT 80
LABEL Ghetto Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=cdrom:/KS/KS1.CFG +++
  MENU LABEL ^1 Ghetto Install
LABEL A bit More Ghetto Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=http://172.30.0.108/ks/ks2.cfg +++
  MENU LABEL ^2 A bit More Ghetto Install
LABEL Super Ghetto ESXi Install
  KERNEL mboot.c32
  APPEND -c boot.cfg ks=http://172.30.0.108/ks/ks3.cfg +++
  MENU LABEL ^3 Super Ghetto ESXi Install
LABEL hddboot
  LOCALBOOT 0x80
  MENU LABEL ^Boot from local disk

For additional ESXi Kickstart resources and example, be sure to check out my pages here.

vCenter Server 6.0 Tidbits Part 11: Automate SSO Admin password change

06.09.2015 by William Lam // 1 Comment

After publishing my last article around the topic of Automating SSO Admin configurations using some simple LDAP commands which is applicable for both vSphere 5.5 and 6.0. It was pointed out to me by my buddy G. Blair Fritz who works over in our GSS Organization that another handy operation to share with customers is the ability to easily and quickly change an SSO Administrator password across multiple Platform Services Controllers (PSC). This is especially important for customers who have a password rotation policy set fourth by their Security team which most Enterprise customers have and are require to update their admin passwords every N-number of days.

Though you will not be able to query for an existing SSO Administrator's password (it is encrypted), you can however modify the password and this will require you to provide a valid SSO Administrator's account to connect with. 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. Make sure to also replace the dc=vghetto with the name of your SSO Site Name

dn: cn=administrator,cn=users,dc=vghetto,dc=local
changetype: modify
replace: userpassword
userpassword: VMware1!

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.60 -D "cn=administrator,cn=users,dc=vghetto,dc=local" -w 'VMware1!!'

The really nice thing about this is that you can quickly change the password for your SSO Administrators across multiple Platform Services Controller and across multiple SSO Domains with a couple slight modifications to the command. How cool is that!? Thanks to Blair for sharing this awesome tidbit!

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"

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

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:

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"

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

Token Policy

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!'

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.