Note: This article covers material present in Version 1 Revision 3 and below. Topics found below may be mitigated in the most current version of the ESXi 5 STIG. Ensure you are using the most current version of the DISA STIG documents.
Here we will review the password complexity requirements in the ESXi 5 Server STIG. These are somewhat problematic, and scattered. I’ll combine things here so it’s a little easier to implement.
Note: Be very aware of what you are doing here. You can easily introduce a restriction that will puzzle you later. I'll cover more below, but make sure your admins are aware of this change.
So, let’s get to it. First a list of the STIG IDs we will be covering here. I’ll be doing this in a couple different groups, pointing out the issues as we go.
SRG-OS-000069-ESXI5, SRG-OS-000070-ESXI5, SRG-OS-000071-ESXI5, SRG-OS-000078-ESXI5, SRG-OS-000266-ESXI5
The above settings have to do with password complexity in terms of character classes. Now, I have a strong sense of caution to bestow upon you now….
Once you make this change and are enforcing a longer, more complex, password you must be cognizant of this if errors are seen, such as, while preparing a host from within vCloud Director. The change to PAM is immediate, and only affects new passwords being set, therefore you can throttle it back for your failing operation, then turn it back to the STIG mandated setting as needed. See here for an example: Setting up a provider in vCloud Director fails with the error: Cannot prepare host
For the STIG IDs above you should have the following set for your min line within the /etc/pam.d/passwd file. You can make the change now, or wait until later in this article where I will give you the entire changed file. There are a couple more settings to go over first. Essentially this line just sets passwords to be at least 14 characters and they must contain an upper, lower, number, and special character.
SRG-OS-000072-ESXI5 and SRG-OS-000077-ESXI5
Ah, similar and past password restrictions. The STIG wants you to set the similar to deny and the password history to five (5). There’s a trick here though, one is the STIG being extremely vague, and another you may not know.
First off, similar=deny. This is set against the pam_passwdqc.so and should look like the line below.
password requisite /lib/security/$ISA/pam_passwdqc.so similar=deny retry=3 min=disabled,disabled,disabled,disabled,14
Next is the password history setting remember=5. The problem here is that the STIG does an absolutely horrific job telling you where to set this. I’ve had several customers thus far that have set this in the wrong place, then had PAM error out on password changes. The reason is that it’s being set in the wrong place. Remember is a keyword against pam_unix.so, not the previous pam_passwdqc.so. So, all together now, here’s what your /etc/pam.d/passwd file should look like when it’s all said and done.
password requisite /lib/security/$ISA/pam_passwdqc.so similar=deny retry=3 min=disabled,disabled,disabled,disabled,14 password sufficient /lib/security/$ISA/pam_unix.so use_authtok nullok shadow sha512 remember=5 password required /lib/security/$ISA/pam_deny.so
We’ve already covered the catch around the complexity with things like host preparation and vCloud Director, but there’s one more to make you aware of. The keywords similar=deny and remember=5 do absolutely nothing for you on ESXi 5+. We do not track password history on the console, so similar password checks and password history offer no additional functionality. You can set the keywords, per the STIG, and be compliant under the “seeing is believing” principle, but the functionality isn’t there. Know this if you are testing after setting these and see no difference. Please follow up here with a comment if you have a question, concern, or different results.
SRG-OS-000120-ESXI5 – Password Hashes Must Use FIPS 140-2 Approved Hashing
This one is simple, and I include it here since you are already in the /etc/pam.d/passwd file. Just make sure sha512 is listed in the file. It is, by default, so you’re good.
Both compliant due to settings above.