posted

2 Comments

ESXi 4.1 provides the ability to fully control all direct access to the host via the Host Configuration Tab in vCenter Server. Once a host has been joined to vCenter Server, every direct communication interface with the host is configurable as an independent service in the Security Profile section of the Configuration Tab for the host in vSphere client.  These interfaces include:

  • DCUI
  • Local Tech Support Mode
  • Remote Tech Support Mode

Each of these can be turned on and off individually.  (Tech Support Mode was described in an earlier blog post).

On the other hand, access based on the vSphere API — for example, the vSphere client, PowerCLI, vCLI and so on — is normally governed by granting local privileges to specific users. The root user is the only one that has an administrator role on the host by default; all other users must be explicitly granted a local role on the host in order to access it.

But, what if you wanted to disable all direct access to the host?  In other words, you wanted to force all interaction with the host to occur via vCenter Server, so that you could take advantage of the centralized roles and privileges, and event auditing?  

Lockdown Mode is a feature designed to provide this capability. When Lockdown Mode is enabled on the host, all direct remote access to the host is blocked, including:

  • Any vSphere API client, e.g. vSphere Client, vCLI, and PowerCLI
  • Tech Support Mode – actually both local and remote TSM are blocked

Even if Tech Support Mode is enabled, Lockdown Mode effectively overrides this by preventing any connection from succeeding. The only way to manage the host remotely is through vCenter Server. The interaction between the host and vCenter Server occurs through a special-purpose account called "vpxuser"; all other ordinary user accounts, including root, can no longer connect remotely.

Here is a video (courtesy of VMware video training author David Davis) that demonstrates the various ways in which Lockdown Mode can be enabled on an ESXi 4.1 host.

 

For the special case of hardware monitoring through the CIM interface, monitoring software must obtain this hardware information directly from the host. In order to do this, the monitoring software must be programmed to obtain a special authentication ticket from vCenter Server. This ticket allows the software to obtain the information from the host through the vCenter Server "vpxuser" account on a one-time basis.

With Lockdown Mode enabled, the only direct access to the host that remains open is through the DCUI. This provides a way to perform limited administrative tasks outside of vCenter Server, such as restarting management agents and viewing log files. In addition, you can also turn off Lockdown Mode from within the DCUI. This might be useful if vCenter Server is down or otherwise unavailable, and you wish to revert to direct management of the host. Normally, without Lockdown Mode, any user with the Administrator Role can log into the DCUI.  However, in Lockdown Mode, the root password is required; no other user can log in.  

In the extreme case, disabling of all direct access to the host may be desired. For example, you might want to prevent anyone with the root password from disabling Lockdown Mode and managing the host. In this case, you can take the additional step of disabling the DCUI for the host, through vCenter Server. After this is done, no direct interaction with the host, local or remote, is possible. It can be managed only through vCenter Server. If vCenter Server is down or otherwise unavailable, you cannot revert to direct management, because logging into the DCUI is no longer possible. If the vCenter Server cannot be restored, then the only way to revert to direct management is to reinstall the ESXi software on the host.

The following table shows the state of various services when Lockdown Mode is enabled.

Access mode

Normal

Lock down

vSphere API (e.g., vSphere client, PowerCLI, vCLI, etc)

Any user, based on local roles/privileges

None (except vCenter "vpxuser")

CIM

Any user, based on local role/privilege

None (except via vCenter ticket)

DCUI

Root and users with admin privileges

Root only

Tech support mode (local)

Root

None

Tech support mode (remote)

Root

None

 

Note that Lockdown Mode is not permanent; it can be disabled for any individual ESXi host at any time (provided that vCenter Server is running and able to connect to that host). The recommendation is that Lockdown Mode be used in ordinary day-to-day operations, but that it be disabled for a host if the need arises to interact with it directly. For example, if a troubleshooting situation is encountered, and the tools provided by vCenter Server are not sufficient, then Lockdown Mode should be disabled and more extensive diagnostics should be performed, using Tech Support Mode.

There are important differences between Lockdown Mode in vSphere 4.1 and vSphere 4.0 and earlier. Prior to vSphere 4.1, Lockdown Mode didn’t truly “lock down” the host, but simply disabled root access based on the vSphere API.  Non-root users could use the API and its clients freely, and other services such as Tech Support Mode were not affected.  Based on customer feedback, we made Lockdown Mode in vSphere 4.1 more absolute, and added the ability to do a total lockdown by disabling the DCUI. KB1017628 goes into more detail about the difference between the two versions, and how to re-create the 4.0 behavior in 4.1.  Since the behavior is so different between the two, KB1021935 was written to describe exactly what happens to Lockdown Mode settings during an upgrade from vSphere 4.0 to vSphere 4.1.

About the Author

Charu Chaubal is the Director of Technical Marketing for the Cloud Platform Business Unit at VMware, and runs the team that works on the vSphere product line. He has been at the company since 2006, and has been responsible for customer education and sales enablement for a wide range of datacenter technologies, such as hypervisor security, hyperconverged storage, and virtualization of data science applications. Previously, he worked at Sun Microsystems, where he had over 7 years experience with architecting distributed resource management and HPC infrastructure software solutions.