Home > AD, ESXi, vSphere > Active Directory authentication for ESXi v5.x

Active Directory authentication for ESXi v5.x

So you’ve got your nice little vSphere/ESXi v5.x environment going, and you’d like to add it to Active Directory.  This makes sense, as if you do, then you can control authentication to the host via AD and have some decent logging – like find out who shutdown the host or updated the SNMP parameters, etc.


Click on your host.  Click on the CONFIGURATION tab.  Click on AUTHENTICATION SERVICES.  Then finally click PROPERTIES.


Change the drop down from LOCAL to ACTIVE DIRECTORY.  Enter the FQDN of the domain, NOT the NetBIOS name (ie: NETWISE.CA vs NETWISE).  Click JOIN DOMAIN.  Enter the username/password and click JOIN DOMAIN.


When it has joined, you’ll see it gray out the options, and the button changes to LEAVE DOMAIN.  Click OK.

Okay so let’s do something with this.  Let’s use PuTTY and SSH into the host (I’ve previously configured it both to allow SSH and allow Root via SSH) using an AD account.


Well that’s odd.   Let’s try the FQN of the account, using the DOMAIN\user format.


Nope, no better.  Well that’s not terribly useful.

So we’ll go google this of course.  And then we’ll find this link – http://v-front.blogspot.co.uk/2012/01/undocumented-parameters-for-esxi-50.html.  Turns out that vSphere/ESXi wants to use a group called “ESX Admins” to provide access.  I guess that’s great and all, but maybe I have a small environment and I just want Domain Admins to have rights.  Or I have a large environment, and each cluster gets its own rights and groups, and so I want ESX Admins – ClusterA group, etc.

So let’s go back to the vSphere client, back to the host and the CONFIGURATION tab and click on ADVANCED SETTINGS.  Then browse to CONFIG –> HOSTAGENT –> PLUGINS –> HOSTSVC.  On the “Config.HostAgent.plugins.hostsvc.esxAdminsGroup” you can see it defaults to “ESX Admins”.   I’m going to change that to “Domain Admins” which my user is a member of and press OK.


So we’ll try SSH again and…..


That probably should have been expected.  We haven’t restarted anything so that the change takes effect.  From a root SSH session, I’ve chosen to run “services.sh restart” to restart the services.  Other options would be to simply restart the host (a little drastic) or use the Restart Management Services option from the DCUI.  Whatever gets the services restarted will do.


And now, it works.

Except there is a small problem still.  There is no “sudo” to run root commands.  And you’re not root.  So you can’t do anything really.


So you still have to run “su –“ to get to a root prompt.  This isn’t a total loss though.  While you won’t know who is running the commands as root, you CAN trace back through your logs from the one you’ve found that is your concern, back to who was the last person to su to become root, and you’d generally know who ran the commands.  It’s not exact, but it is better than nothing.  So you still need to share the root password with your admins, I’m afraid.  But you could in theory make it so that root cannot SSH into the host directly and users must enter as themselves and then su to root.

The same blog where I found the link about changing the group, also has a link to a VMware Community Forum post, where they’re asking for this feature to get fixed or enhanced – http://communities.vmware.com/thread/344466.  I’d really recommend that as many people as possible give this a shot.

BTW, the other reason you might want to add the host to have AD credentials:



Doesn’t quite work as you’d expect.  You CAN use your Windows Credentials, but you CANNOT check the box that says “Use Windows session credentials”.  This is because it wants to pass through your session to the host, and it doesn’t know how to deal with the no password I guess.  vCenter, does.  So if you do the same thing, but type in your username and password:


It will work just fine.

So, while you can’t do a lot from the command line with AD credentials and no root password, you CAN get into the console and manage everything through the vSphere client.  So as far as Tier 1 support staff getting in and checking on performance, and VM’s that are up, etc, (assuming they cannot via vSphere directly – maybe you have some ESXi development boxes or something), you could at least let those staff into the console this way and monitor who did what.  If you need to do any sort of triage on the host, then you call in the next Tier up, who has the root password.

Categories: AD, ESXi, vSphere
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: