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

VMware Certified Professional – VMware Cloud Foundation Administrator 2024

Not just another badge on the CV, but a key role with far-reaching consequences.

Until recently, members of the VMware vExpert Program had access to a wide range of VMware trial licenses. This ensured that these specialists could gain practical experience with VMware software and pass on this knowledge in the form of blogs, lectures or video tutorials.
This still applies, but with one restriction:
VMware’s core product VMware Cloud Foundation (VCF) is excluded from this.
In order to obtain test licenses for this product, vExperts must also be qualified as VMware Certified Professioanl (VCP) for VCF.
The same applies to holders of VMUG Adavantage membership.
Here, too, VCF licenses will only be available in future against proof of VCP-VCF certification (2V0-11.24 or later).
As a VMware trainer, there is another implication. One of the (many) requirements to be allowed to teach VCF courses in the future is also the VCP-VCF.

To learn the basics, Broadcom offers on-demand training.

But this training and certification is not only important in terms of licenses.
Everyone who will be working with this product in the future will gain basic knowledge of the VCF architecture, deployment and Day-2-Operations.

VMware Validated Design Guide (VVD) discontinued

Anyone who has ever been involved in the design of IT concepts based on VMware products should be familiar with the VMware Validated Design Guide (VVD).

VMware Validated Design is a collection of data center design recommendations that span compute, storage, networking, and management which can be used as a reference guide for implementing a Software-Defined Data Center (SDDC). The VVD documentation consists of a series of documents that build on each other for all stages of the SDDC lifecycle. The VVD documentation can be used as an extension of the VMware Cloud Foundation (VCF) documentation. Each version of the VVD Guide correlates with a particular VCF version.

VMware Validated Design has been discontinued after VMware Validated Design 6.2 and VMware Cloud Foundation 4.2. VMware Validated Solutions (VVS) will take over the succession of VVD.

VMware Validated Solutions

VMware Validated Solutions are validated technical implementations designed to assist in building a secure and stable infrastructure based on VCF. Each VVS includes a detailed design with design decisions, as well as implementation instructions. VMware Cloud Foundation SDDC Manager is required to implement VMware Validated Solutions.

Finally, this means that anyone interested in a VMware validated solution in the future needs to take a look at VCF.

Heads up! Watch your NIC order when adding more hosts to VCF

VMware Cloud Foundation is a unified SDDC platform for the hybrid cloud. It is based on VMware’s compute, storage, and network virtualization.

VCF can be expanded with more workload domains by adding further hosts, or it can be stretched over two availability zones (AZ). The expansion is initiated by and under control of the SDDC-Manager. The procedure is fairly straightforward and SDDC-Manger does all the configuration tasks in the background, i.e. forming vSAN clusters, networks, kernel ports, vCenters and NSX control planes.

  • setup hosts with ESXi base image
  • confige a management IP address
  • set root credentials
  • configure DNS and NTP
  • import new hosts into SDDC-Manager
  • deploy new WLD

There is a pitfall that can be easily overseen: The order of the new host’s NICs. Before we can import new hosts, we’ll get to see a checklist about the host requirements. The hosts need to have two NICs with at least 10 GBit.

While reading the list there’s a little detail that is often overlooked. Traditional numbering means that both NICs must have numbers vmnic0 and vmnic1. Unfortunately this seems to be hard coded and cannot be changed (as of current version 4.2). To make matters worse, many server systems have onboard 1 GBit network adapters. There’s a KB article that explains how VMware ESXi determines the order in which names are assigned to network devices. It’ll start with onboard NICs and then continues with PCIe cards. As a result you’ll might end up with two 1 GBit onboard NICs as vmnic0 and vmnic1. In this case the bringup of the VCF expansion will fail.

While you can choose NICs during initial VCF bringup, this is not possible during expansion and this time there’s no such thing as a bringup sheet. You can’t select more than two NICs either when using SDDC-Manager. In that case you’ll need to use API-calls.

Workaround

Currently there’s no other way than to disable onboard NICs in the system BIOS. If your desired NICs still show a higher number you’ll need to put the PCIe card into a lane with lower number.