Showing posts with label Active Directory. Show all posts
Showing posts with label Active Directory. Show all posts

Thursday, January 26, 2012

Feature request: Add sudo to ESXi to make AD integration a success story

Recently I posted about (undocumented) improvements in the area of AD integration, but it looks like I missed a very important point:

You can log on to a local or remote console using an AD account that has administrative rights, but you won't have root privileges in this session, e.g. you cannot edit any configuration files, restart services etc. To gain root rights you need to use the su command, but that means that you still need to know and enter the password of the root user! From a compliance standpoint this is not acceptable, because the whole point of AD integration is that each VMware administrator uses his AD account for administration and does not even know the root password - to make sure that each change to the system can easily be related to a personal account (Well, for emergency cases e.g. when AD authentication is not available you still need someone who knows the root password or e.g. has it written down on a piece of paper in a sealed envelope).

The easiest way to achieve this would be to use the sudo command in the ESXi shell to run commands in root context without the need to know root's password. This is common practice when managing Unix/Linux servers. Now the point is: sudo used to be available in ESX, but it is not available in ESXi.

So I have a simple feature request for VMware: Add sudo to ESXi! It is the missing piece that would make AD integration a success story, finally.

If you agree and also feel bothered by this, please vote for this feature request in the VMware Community forums, where I opened this thread for that. Thank you all for voting/commenting and special thanks to Masa who brought this to my attention in the comments of my above mentioned post!

Friday, January 13, 2012

Undocumented parameters for ESXi 5.0 Active Directory integration

Since vSphere version 4.1 it is possible to integrate an ESXi host into a Microsoft Active Directory (AD). After the host is joined to the domain you can assign permissions to AD groups and users by connecting directly to the host with the vSphere client.
Instructions on how to do this (with ESXi 5.0) is available e.g. here in the VMware Online Documentation.

I first looked at AD integration when vSphere 4.1 was released and found one really annoying drawback in it that ruled it out from a possible implementation in our environment: When an ESXi 4.1 host is joined to a domain it will automatically (and repeatedly!) look up an AD group called "ESX Admins", and as soon as it finds this group it will grant this group Administrator permissions on the ESXi host. The real problem here is that the name ("ESX Admins") of this AD group is hard coded and can not be configured.
This may be a nice feature for small environments - you just need to create this group, fill in the necessary people and you are done. But if you think about an enterprise environment of a large company with lots of different sites, IT teams and vSphere installations, but only one Active Directory, you can not assume that all ESXi hosts in this company are managed by the same group of people.

When vSphere 5.0 was released I looked at the release notes and documentation to find out if this drawback was removed, but I did not find any positive information. Tests I did also showed that an ESXi 5.0 host behaves the same way, looks up the "ESX Admins" group and adds it with Administrator permissions.

However, recently I stumbled over the following when browsing the advanced configuration parameters of an ESXi 5.0 host:
Configuring the "ESX Admins" group
Yes, with ESXi 5.0 it is possible to change the name of the AD group that is automatically added by setting the advanced configuration option Config.HostAgent.plugins.hostsvc.esxAdminsGroup. You can even completely disable this functionality by setting the option  Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd to false.
I searched for this again in the VMware documentation and the Knowledge Base, but did not find it being mentioned anywhere. So it looks like at the time this is completely undocumented, but it works as expected (I could not resist from immediately trying this out)!