Set password policy for VMware Linux appliances

The point of changing passwords regularly is debatable. I think that forcing users to assign a new password every x days, which must be very different from the previous one, is counterproductive. But that’s another topic.

The scenario I want to talk about looks like this: a non-production lab environment where the password always expires when you have more important things to do. Appliance xy gives me the virtual middle finger and forces me to enter a new password, which must contain at least 5 special Klingon characters. Grrr! This is a non-productive lab and I use the same password for all – yes, all – services and logins. It’s about feasibility – not security.

Before anyone gets me wrong: 
Yes, in production that would be a very stupid idea.

Password Expiration

The first step is to set the password expiry time to zero (caution! not for VCF!) or a very long period of time. By default, I set 9000 days here. That’s the equivalent of about 24 years and 7 months. That should be enough πŸ˜‰

Often this value cannot be configured in the GUI. Then the CLI is required. In most Linux variants, the setting is hidden in a configuration file called login.defs. We can make a quick query on the shell.

cat /etc/login.defs | grep PASS

PASS_MAX_DAYS 90
PASS_MIN_DAYS 0
PASS_MIN_LEN 8
PASS_WARN_AGE 7

Voila! PASS_MAX_DAYS is our password expiration time.

We have to use vi in order to make changes, as other editors are rarely available in these systems. But don’t be scared of vi. It’s actually quite nice. πŸ™‚ We open the configuration file with:

vi /etc/login.defs

Now keep calm and just press the i key (for insert). Now look for the line with PASS_MAX_DAYS and change the value to 9000, for example. If you wish, you can also set the minimum age PASS_MIN_DAYS to 0. This allows the password to be changed again without waiting.

To save our changes, press the ESC key and then the key with the colon. A colon appears at the bottom left, indicating that we are in command mode. We enter the characters wq (write, quit) and press Enter.

Special case NSX-T with VCF

The expiry time of the predefined accounts admin, root and audit under NSX-T are set on the shell of the NSX manager with a separate command. To do this, you connect to the virtual IP (VIP) of the management cluster via SSH and you’ll be forwarded to the current master node.

To set the expiry time of the three accounts to 9000 days, enter the following three commands:

set user admin password-expiration 9000
set user root password-expiration 9000
set user audit password-expiration 9000

In NSX-T environments without VCF, the password expiry times may be completely deactivated.

Attention! With NSX-T in conjunction with VCF, however, this leads to problems during the upgrade. For the sake of completeness, here are the commands for deactivation:

clear user admin password-expiration
clear user root password-expiration
clear user audit password-expiration

Control

The expiry time in NSX-T can be queried with these commands:

get user admin password-expiration
get user root password-expiration
get user audit password-expiration

Password History

Normally the above changes are sufficient. However, if we have missed the expiration date and had to set a new password when logging in, we cannot switch back to our old password. The system remembers a defined number of recent passwords and does not allow recycling. But we can change this too. In many Linux variants, there is a daemon for pluggable authentication modules (pam.d). The configuration is located under /etc/pam.d/common-password. Systems with root access can also have the configuration in /etc/pam.d/system-password instead.

vi /etc/pam.d/system-password

Here I set the value remember=0. This allows the desired password to be reset immediately. As root user, the command on the shell is sufficient:

passwd

NSX Manager – Changing Certificates

After installing NSX-T Data Center, the NSX managers and cluster use self-signed certificates. These can and should be replaced with trusted certificates from an enterprise CA. The new certificates can be imported into the UI of the NSX Manager. Unfortunately, replacement is done exclusively via an API call. This can usually be done nicely with utilities such as Postman. However, there are environments that are very restrictive and in which neither an application such as Postman is available nor any other Linux system from which the API calls could be issued.

We will outline how we can do this without any special utilities using only the CURL command directly from the NSX Manager appliance.

Continue reading “NSX Manager – Changing Certificates”

VMware NSX Legacy Load Balancing is Going Away – Migrate to Avi

VMware will be sunsetting the NSX native load balancers. Customers should be migrating to the currently supported NSX Advanced Load Balancer (Avi) which simplifies operations today while getting you ready for your multi-cloud and container strategies tomorrow. Avi works across all environments beyond the NSX framework, expanding use cases to public cloud, containers and app security while adding capabilities for GSLB, WAF and analytics. A migration tool will be available to make the migration of your existing configuration to the current technology easy and painless.

ESXi Configuration Restore fails with blank DCUI

Backing up and restoring an ESXi host configuration is a standard procedure that can be used when performing maintenance on the host. Not only host name, IP address and passwords are backed up, but also NIC and vSwitch configuration, Object ID and many other properties. Even after a complete reinstallation of a host, it can recover all the properties of the original installation.

Recently I wanted to reformat the bootdisk of a host in my homelab and had to fresh install ESXi for this. The reboot with the clean installation worked fine and the host got a new IP via DHCP.

Now the original configuration was to be restored via PowerCLI. To do this, first put the host into maintenance mode.

Set-VMhost -VMhost <Host-IP> -State "Maintenance"

Now the host configuration can be retored.

Set-VMHostFirmware -VMHost <Host-IP> -Restore -Sourcepath <Pfad_zum_Konfigfile>

The command prompts for a root login and then automatically reboots. At the end of the boot process, an empty DCUI was welcoming me.

I haven’t seen this before. I was able to log in (with the original password), but all network connections were gone. The management network configuration was also not available for selection (grayed out). The host was both blind and deaf.

Continue reading “ESXi Configuration Restore fails with blank DCUI”