ESX User Authentication and Password Management

Even if you use AD to authenticate your users, ESX will still check it’s local authentication mechanism for the user and their password. You can see this activity when you look in /var/log/messages after a login. For example, on my servers, when I login there are two messages…one from pam_unix saying that authentication failed and another from pam_kerberos (Active Directory) saying that authentication succeeded.

What this behaviour means is that you can have users on your ESX system that are not authenticated via Active Directory, thereby bypassing any password requirements (complexity, reuse, expiration, etc) settings you have there. Unless you adjust the default password settings in ESX, these users can have pretty much any extremely unsecure password they want, which is bad. Additionally, depending on who you work for (US Gov’t, finance, health care, etc) there may be some security compliance issues you must deal with, which usually include password requirements.

Even with Active Directory authentication, there is a local user on the ESX host for authorization. If that local user also has a local password, then the user can use either credential to login to the ESX server. Your box is only as secure as the weakest password.

This only applies to ESX, not ESXi, as there isn’t normally any console for users to login to. I haven’t played with ESXi, or it’s unsupported busybox interface, so if you’ve enabled ssh via busybox, I can’t help.

The main tool for configuring user authentication on an ESX server is the esxcfg-auth command. There are a multitude of options to this command, including the ability to connect your box to NIS domains, Active Directory / Kerberos, and LDAP (for Sun Directory Services and/or Redhat Directory Services and their derivitives presumably). I’m not going to go over those here. I’ve covered AD integration here and Scott Lowe added a link to his excellent post on the same topic in the comments.

If you work in a shop with NIS, you should already know how to configure ESX to connect with it, since I am assuming you are already a linux administrator. Same with SDS and RDS.

Before I go into my recommended settings I should mention character classes. There are four character classes: lower case letters (abc, etc), upper case letters (ABC, etc), numbers (012, etc), and special characters (!@#, etc). With each additional character class required for a password (along with the length) it becomes exponentially more difficult to crack/bruteforce. There is an excellent series of charts here that shows how as you add additional characters and length to passwords the amount of time expected to take to break the password by bruteforce. Near the bottom of the page, you can see where with an eight character password using all four classes, even the class F attack takes nearly 3 months to bruteforce a single password.

For password complexity, I like a 12 character password with at three classes or 8 characters with four classes using the pam_passwdqc library to enforce password strength.

pam_cracklib is also available, but is a less sohpisticated library, and therefore pam_passwdqc is recommended above it (though you’re certainly free to do what you want).

The second series of settings that you want to configure is password expiration. There are three settings here, max days, min days and warn age. Max days is the longest a user can have a password before they must change it, i.e. time before expiration. Min days is the minimum amount of time before a user can change their password again. Warn age is the number of days before the user’s password expires that the server will start asking the user to change their password.

The final option that I will commonly set is max failed logins. This is the number of login attempts before a user’s account is locked.

This setting can cause some issues I have found. Occasionally (very occasionally…) the vCenter user (vpxuser) will lock itself out. When this happens the host will appear as “disconnected” or “unresponsive” in vCenter. At any time you can check the number of failed login attempts a user has by using the faillog command. If you enable this setting and are having problems, you can disable the failed login count by setting it to zero.

You can preemptively reset vpxuser’s fail count using cron if you like, or you can use cron to periodically send an email with the fail counts (which is kind of a good idea anyway so you can see if any users are having a lot of problems).

All of these settings help to keep your ESX hosts secure during an attack, but they are only a small part. If you are concerned about keeping your boxes secure, then I highly recommend using the plethora (courtesy of DISA) of hardening guides available (that one’s from NSA’s SNAC office!!), including VMware’s own hardening guide. These sources will provide an excellent start to securing your ESX servers, and provide valuable resources for securing your virtual machines as well. Security is a never ending task that is often neglected and over looked until an incident occurs, then the policies and procedures that have been put in place are a life saver.

Leave a Reply