I recently delivered a presentation on the vSphere Management Assistant 5 (vMA 5) to the Chicago VMUG during a meeting to discuss various vSphere 5 topics. One of the VMUG members had a question as to the behavior of the vMA when a host was set to lockdown mode. Adoption of the vMA is relatively low, so I have not yet seen an environment using lockdown mode hosts and a vMA appliance. I did find that infamous scripting blogger William Lam has discussed lockdown mode with vMA 4 in his post “ESXi Lockdown mode does not play nice with vMA” (which had logging functionality), but I thought it good to see if anything has changed in vMA 5.

Lockdown Mode?

Lockdown mode is a feature of a vSphere host that limits access to essentially vCenter and the Direct Console User Interface (DCUI). Per the vSphere 5 documentation, not much has changed:

When you enable lockdown mode, no users other than vpxuser have authentication permissions, nor can they perform operations against the host directly. Lockdown mode forces all operations to be performed through vCenter Server.

When a host is in lockdown mode, you cannot run vSphere CLI commands from an administration server, from a script, or from vMA against the host. External software or management tools might not be able to retrieve or modify information from the ESXi host.

Here is a matrix on the various changed that occur when a host is set to lockdown mode.

Wait … What Happened to vilogger?

Logging capabilities (vilogger) have been removed in vMA 5, I assume due to vSphere 5 shipping with its own Syslog Collector as an optional install along with the vCenter 5 ISO. The king of videos, Eric Sloof, has a great video up on YouTube (also embedded below) which showcases how you can get rolling quickly with the Syslog Collector in vSphere 5.

Sloof’s videos are top notch!

vMA Still Has Value

Even with an environment that uses lockdown mode, the vMA has a lot of value in that it can tie to the vCenter servers and execute commands that reference hosts. I recommend joining the vMA appliance to your domain and then using adauth (AD authentication) to funnel any host commands through vCenter.

Joining vMA and the Host to AD

In order to get the vMA appliance onto your AD domain, use the following command:

sudo domainjoin-cli join domain.name domain-account

Here is an example from my lab:

You can also use the query argument to verify the domain.

This can be helpful as it displays the DN (Distinguished Name) of where the appliance lives.

I also added my ESXi 5.0 server to the domain. Go to the configuration tab of the host in vCenter (or connect directly to the host if you wish) and choose the Authentication Services Settings. Adding the host to the domain really just requires the domain name and an account that can join objects to the domain. The results should look like this:

Adding vCenter as a Target

Now, you’ll need to add vCenter as a target to the vMA appliance and use AD authentication (adauth) as the policy. The command to use is:

vifp addserver fqdn.of.vcenter --authpolicy adauth

If you are able to resolve the FQDN, the next prompt should be to enter a user name in a DOMAINaccount format.

Note: If you use the –username argument, make sure to use the DOMAIN\account format (the first backslash escapes the second backslash character).

At this point, I’ll put my ESXi 5.0 host into lockdown mode to verify that any command I run is indeed still working with lockdown mode enabled.

Ok, let’s try some vMA commands using vCenter as a target.

Verifying vMA Works with AD Authentication through vCenter

You might have to restart the vMA appliance before this works (I did in the process of troubleshooting another issue, so I don’t know for sure if it’s required or not).

First, target the vCenter server:

vifptarget -s vcenter.name

Then, as a test, issue a simple command to list the nics of a host, and use your connection to vCenter via the vMA to do the work:

esxcli --vihost host.name network nic list

Nothing too hard about that. And this shows that even in lockdown mode, you can still script against a host as long as you have a connection to vCenter with your vMA.

Thoughts

I found the AD authentication piece to be a major pain in the rear in respect to getting it operational with vCenter. It worked fine directly to a host, but would ask for credentials when using vCenter. Ultimately I did a lot of reboots and tinkered with DNS until I got it working so I’m not sure specifically what my issue was, but being a lab environment, things can tend to get a tad unstructured at times. 😉