ESXi version of esxcfg-auth?

[admin]

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

[a_p_ · Accepted solution]

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é

[lamw]

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.

[admin]

A-ha, thanks Andre'!

Drew

[admin]

"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

[admin]

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

[joshp]

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.

[Cyberfed27]

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.

[joshp]

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.

[joshp]

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.

[Cyberfed27]

ESXi build is 4.1.0, 433742 fully patched.

[mborrego]

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).

[DonChino]

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: