WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Administrator password expiration in new VCSA 5.5

09.05.2013 by William Lam // 4 Comments

A new security enhancement that you should be aware of when deploying the new vCenter Server Appliance (VCSA) 5.5 is that there is now a password expiration that is enabled for the administrator account (root) after powering on the VCSA. By default, the password will expire 90 days after and if the password is not changed before the expiration, the account will be locked out of the VAMI interface and the SSH console. From a security point of view, this is a nice feature to have to ensure administrative passwords are automatically rotated, however this can also be an administrative challenge if you are not aware of this new change and you suddenly notice you can no longer login after 90 days.

You can find the password expiration settings under the Admin tab of the VAMI interface. You have the ability to enable or disable the feature as well as change the number of days the password is valid for. If you decide to change the default number of days, you will be required to enter an email address which will be used to email you 7 days prior to expiration which is the default.

In addition to using the VAMI interface to configure these settings, I was also interested to see if these settings can be automated through the command-line and with a bit of digging, these options can be completely controlled through the CLI!

We will be using the chage utility which manages user account expiry. To view the default settings for the root account or any other account, run the following command:

chage -l root

We can see from the screenshot above, the maximum days before expiration is 90 and the number of days to warn before expiration is 7 which matches the VAMI UI.

Lets say we want to change the maximum days before expiration to 120 and instead of warning 7 days before expiration, we want to change it to 12, you can do so by running the following command:

chage -M 120 -W 12 root

If you wish to completely disable account password expiry, you can do so by running the following command:

chage -M -1 -E -1 root

You can also configure the email address through the command-line which is used to warn X days before password expiry. To add or update the email address, you will need to create a file called /etc/vmware-vpx/root.email that contains the email address.

From an operational perspective, you will want to ensure you configure an SMTP server in your vCenter Server after deploying the VCSA and ensure you add an email address so you can be notified before the root account password expires. You should also configure the maximum number of days before the password expire and the number of days to warn to match your internal security policies.

In the event that you lock yourself out, how do you go about recovering from this since you will not be able to login to the VAMI interface nor the SSH console? I have purposely configured one of my VCSA to expire the password in 1 day, so stay tune for a future article on how to recover from this.

Here is How to recover VCSA 5.5 from an expired administrator account article.

Categories // VCSA, vSphere 5.5 Tags // chage, lockout, password, security, vami, VCSA, vcva, vSphere 5.5

vSphere Security Hardening Report Script Updated for vSphere 5.1

03.25.2013 by William Lam // 10 Comments

A public draft of the vSphere Security Hardening Guide for vSphere 5.1 was released a few weeks back by my colleague Mike Foley. Since then I have been asked by several people if I had a chance to update my vSphere Security Hardening Report Script. The answer was unfortunately no due to other projects I had been working on and this script as well as others are maintained outside of my normal day job. I finally found some time this past weekend to go through the 5.1 revision of the hardening guide and make the necessary updates to my script which includes a few additional checks.

The script continues to provide backwards compatibility to previous releases of the vSphere Security Hardening Guide for vSphere 5.0, 4.1 and 4.0. Maintaining this compatibility is actually quite a challenge due to small minor changes in the hardening guide from previous versions, but I am please to say the latest 5.1 draft has now been implemented.

Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.  

Here is a sample output for the Security Hardening Report for a subset of my vSphere 5.1 home lab environment using "profile1" check:
vmwarevSphereSecurityHardeningReport-SAMPLE.html

For more details about the security hardening script, please refer to the documentation here.

If you have any feedback/questions on the vSphere Security Hardening Guide itself, make sure you to leave your comments and questions here. If you have any feedback/questions regarding the script, please join the vSphere Security Hardening Report VMTN Group for further discussions.

Categories // Uncategorized Tags // ESXi 5.1, hardening guide, security, vSphere 5.1

vSphere Security Hardening Report Script for vSphere 5

04.23.2012 by William Lam // 10 Comments

The much anticipated vSphere 5 Security Hardening Guide was just released last week by VMware and includes several new guidelines for the vSphere 5 platform. In addition to the new guidelines, you will also find that the old vSphere 4.x guideline identifiers (e.g. VMX00, COS00, VCENTER00) are no longer being used and have been replaced by a new set of identifiers. You might ask why the change? Though I can not provide any specifics, but rest assure this has been done for a very good reason. There is also a change in the security guidance levels, in the vSphere 4.x guide, you had enterprise, SSLF and DMZ and with the vSphere 5 guide, you now have profile1, profile2 and profile3 where profile1 provides the most secure guidelines. To get a list of all the guideline changes between the 4.1 and 5.0 Security Hardening Guide, take a look at this document here.

I too was impacted by these changes as it meant I had to add additional logic and split up certain guidelines to support both the old and new identifiers in my vSphere Security Hardening Script. One of the challenges I faced with the old identifiers and creating my vSphere Security Hardening Script is that a single ID could be applicable for several independent checks and this can make it difficult to troubleshoot. I am glad that each guideline is now an individual and unique ID which should also make it easier for users to interpret.

To help with your vSphere Security Hardening validation, I have updated my security hardening script to include the current public draft of the vSphere 5 Security Hardening Guide. You can download the script here.

Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.  

The script now supports both a vSphere 4.x environment as well as vSphere 5.0 environment. In addition to adding the new guideline checks and enhancing a few older ones, I have also included two additional checks that are not in Hardening Guide which is to verify an ESX(i) host or vCenter Server's SSL certificate expiry. I recently wrote an article on the topic here, but thought this would be a beneficial check to include in my vSphere Security Hardening Script. If you would like to see the verification of SSL certificate expiry in the official vSphere 5 Security Hardening Guide, please be sure to provide your feedback here.

Here is a sample output for the Security Hardening Report for a vSphere 5 environment using "profile2" check:
vmwarevSphereSecurityHardeningReport-SAMPLE.html

UPDATE (06/03/12): VMware just released the official vSphere 5 Security Hardening Guide this week and I have also updated my script to include all modifications. If there are any feedback/bug reports, please post them in the vSphere Security Hardening Report VMTN Group.

If you have any feedback/questions, please join the vSphere Security Hardening Report VMTN Group for further discussions.

Categories // Uncategorized Tags // ESXi 5.0, ESXi 5.0, hardening guide, security, vSphere 5.0

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025