get-admin

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.

Continue Reading »

In order to facilitate my ability to configure all aspects of an ESX host automatically, I wanted to adjust the amount of memory that is assigned to the COS without having to use VI Client. The perl below is the result of that effort.

As always, I am not responsible for any damage caused to your infrastructure, I recommend you put your host in maintenance mode and move all VMs off of it before attempting any significant action upon it (there should be little risk involved with this script though…). The change will not take effect until you reboot the host (which can be accomplished with the hostops.pl sample script provided as a part of the Perl Toolkit).

Continue Reading »