Hey All,
I was working through the vSphere 4.1 Hardening Guide and found the esxcfg-auth commands (designed for hardening the password policies for the Service Console).
I checked in /sbin on ESXi and did not see an ESXi version of "esxcfg-auth."
We used to harden password policies on ESX by editing the /etc/pam.d/common-password file. When I try to edit /etc/pam.d/system-auth, the file resets itself back to default after a reboot.
Is there a method in ESXi to harden the password policies (similar to esxcfg-auth)?
It seems crazy to me to have a password policy file (/etc/pam.d/system-auth) that resets itself to 8 character passwords after a reboot.
Thanks !!!
Drew
See http://kb.vmware.com/kb/1012033
Note: To ensure that changes to the file persist upon reboot, run this command before making edits to the /etc/pam.d/system-auth file: chmod +t /etc/pam.d/system-auth.
André
See http://kb.vmware.com/kb/1012033
Note: To ensure that changes to the file persist upon reboot, run this command before making edits to the /etc/pam.d/system-auth file: chmod +t /etc/pam.d/system-auth.
André
Take a look at this post - http://www.virtuallyghetto.com/2010/07/esxi-41-major-security-issue.html and specifically UPDATE4 towards the bottom, there is a patch from VMware that you should apply to fix the 8 character password issue.
A-ha, thanks Andre'!
Drew
"Take a look at this post - http://www.virtuallyghetto.com/2010/07/esxi-41-major-security-issue.html and specifically UPDATE4 towards the bottom, there is a patch from VMware that you should apply to fix the 8 character password issue."
Lamw,
I am using 4.1u1, so I think I am safe. I will test it either way to be sure.
Thanks,
Drew
Looks like I spoke too soon.
I tried to chmod +t the /etc/pam.d/system-auth file, and it still seems to get overwritten on reboot. The file gets overwritten and a file with a Jan 13 datestamp is put in its place.
I tried to chmod u+w the file, then vi to edit, then saved it and verified the current date stamp. After reboot, it just gets replaced, regardless of chmod +t.
I think on one or two tests, the file has peristed for one reboot, but then it gets overwritten ont he next one.
Crazy...
Drew
Late response here....but, VMware engineering has confirmed this to be a bug in the latest release of ESXi 4.1 Update 1 (and possibly some earlier builds of 4.1). The bug fix will be released in Update 2. You can try the chmod +t method or the chmod 644 method and neither will persist the changes. Here is VMware's official response:
We confirmed that in ESXi, the /etc/pam.d/system-auth file is not user
editable and hence the changes made to /etc/pam.d/system-auth file does not
persist across reboots.
You can now edit the password settings by making changes to the
/etc/pam.d/passwd file which is resolved in the U2 release.
I did a CHMOD 755 system-auth
and then the chmod +t /etc/pam.d/system-auth
I made changes to 12 character PWs and rebooted the ESXi host.
The settings stayed like I had set them. They did NOT revert back.
Running ESXi 4.1 update 1 all latest patches installed as of this post.
Cyberfed27, just curious, what is the exact build number you are running on ESXi? I noticed build 433742 seems to retain settings; however, previous builds are not. Trying to narrow this down a little. Thanks for the response.
Set the permissions on the file back to where they need to be using [chmod 444 /etc/pam.d/system-auth], then reboot, and the file will revert back to default.
ESXi build is 4.1.0, 433742 fully patched.
We are running ESXi 4.1 433742, fully patched.
Changes to system-auth persist after a single reboot. On subsequent reboots, the changes do not persist (used chmod).
Did they ever resolve this?
I am now on 4.1 Update 2 and basically any changes to the system-auth file are NOT saved. It will save for one reboot but then revert back, so has everyone upgraded to 5.0 and forgotten about this?
I did the chmod BEFORE making the changes to the file also, but once again it will work for ONE reboot and then revert on subsequent reboots so is there a fix for this or what?
Hosts:
ESXi 4.1 702113
Server:
vCenter 4.1 491557
:smileyangry: