WilliamLam.com

Search Results for: kickstart

Quick Tip - Automating ESXi local user passwords using SHA512 encrypted hashes

by // Leave a Comment

For those that automate their ESXi installations using Kickstart aka ESXi scripted installation should be quite familiar with the ability to configure the root password as part of the installation. As described in the official ESXi documentation, the --rootpw option can either contain a plain text password (not recommended) or with the use of the additional --iscrypted option, a SHA512 hash of the password can also be used, which is definitely recommended and more secure.

However, when managing additional local users via ESXCLI system account, which I recently blogged about here, I noticed that you can only provide a plain text password either on the command-line (not recommended) or interactively, which prevents this process from being automated. As mentioned in the blog post, you could store the password and the commands into another script file and this will at least hide the password from being stored in the ESXi Shell log file (/var/log/shell.log) but this is far from ideal.

While sharing this feedback with Engineering as part of a feature enhancement request, I came to learn about a nice little utility that can be used with both ESXi 7.x and 8.x that can update local user by simply providing the encrypted SHA512 hash.

[Read more...]

Nested ESXi installation using HTTPS boot over VirtualEFI in vSphere 8

by // 2 Comments

In vSphere 7.0 Update 2, an enhancement was made to the Virtual Machine's UEFI firmware called VirtualEFI that would enable ESXi to run in a VM (Nested ESXi) and perform an HTTP Boot given the ESXi bootloader URL without requiring any traditional PXE infrastructure.

This was especially useful for anyone testing or developing ESXi automation for use with ESXi Kickstart, where you can quickly prototype your automation without additional infrastructure dependencies and once the automation has been vetted, you can then leverage that exact same automation in your physical ESXi provisioning infrastructure.

The original solution had only supported HTTP and I recently came to learn that we can now also support HTTPS in vSphere 8!

[Read more...]

Applying additional security hardening enhancements in ESXi 8.0

by // 14 Comments

While responding to a few ESXi security configuration questions, I was referencing our ESXi Security documentation, which includes a lot of useful information and latest best practices. It is definitely worth re-reviewing this section from time to time to take advantage of all the ESXi security enhancements to help protect and secure your vSphere environment.

In certain areas of the ESXi security documentation, I noticed that it mentions CLI and API, but it does not always provide an example that customers can then reference and use in their Automation, which is really the only guaranteed method to ensure configurations are consistent across your vSphere environment. After answering some of the security related questions, especially on the Automation examples, I figure it would be useful to share this information more broadly so that folks are aware of some of the new and existing security enhancements along with some of their implications if you are not implementing them.

Speaking of new ESXi security enhancements, one of the new features that was introduced in ESXi 8.0 is the ability to disable ESXi Shell access for non-root users. While this might sound like a pretty basic feature, applying this towards the vCenter Server service account vpxuser can help add another layer of protection for your ESXi hosts against attackers. It turns out that users with ESXi Shell access can also modify other local users password on ESXi host including the root user. By restricting ESXi Shell access for the vpxuser, you prevent attackers, which can also be insiders who have access to vCenter Server the ability to just change the ESXi root password without knowing the original password. As a result, this can lock you out of your ESXi hosts or worse, enable an attacker to encrypt your workloads, especially as the rise ransomeware attacks has been increasing.

[Read more...]