Integrating Microsoft Active Directory authentication in the ESX Service Console used to be somehwhat of a daunting task. Today, however, the steps have been greatly condensed and I find it a cinch. It basically boils down to two steps for each ESX host you wish to integrate AD with (which can be scripted I might add):
- Create a local user account on the ESX host for each AD user account you would like to authenticate
- /usr/sbin/useradd yourusername
- Execute an authentication configuration command on the ESX host to be integrated with AD
- /usr/sbin/esxcfg-auth –enablead –addomain yourdomain.com –addc yourdc.yourdomain.com –krb5realm=yourdomain.com –krb5kdc yourdc.yourdomain.com –krb5adminserver yourdc.yourdomain.com –enablekrb5
- Assuming your AD environment has multiple domain controllers, consider adding redundant –addc yourdc.yourdomain.com parameters to the command line above in case one of your DCs become unavailable on the network
- /usr/sbin/esxcfg-auth –enablead –addomain yourdomain.com –addc yourdc.yourdomain.com –krb5realm=yourdomain.com –krb5kdc yourdc.yourdomain.com –krb5adminserver yourdc.yourdomain.com –enablekrb5
Be sure to repeat the steps above for each ESX host you wish to integrate AD with. As new VI administrators come and go in your environment you’ll need to repeat step 1 above to add new administrator accounts on each ESX host. For administrators that have terminated, you’ll need to remove their account (and home directory if it exists) from each ESX host using the console command /usr/sbin/userdel -r username. -r specifies the removal of the respective home directory if it exists.
For a thorough explanation of the esxcfg-auth command, execute the command man esxcfg-auth in the Service Console.
Warning: One thing to watch out for would the existance of a root account in AD in which you are not the owner of. By implementing AD authentication, a root account in AD is going to be granted root level Service Console access on the ESX host! Take the necessary precautions here.
You can exclude the local accounts from attempting AD authentication by adjusting the /etc/pam.d/system-auth file.
Edit the line that begins with: “auth sufficient /lib/security/$ISA/pam_krb5.so” and append “minimum_uid=100”.
If you only want to exclude the root account, set the minimum UID to 1.
Good post Jason!! One thing to add is you do not have to name a server by name “yourdc.yourdomain.com” You can use just the domain name “yourdomain.com” This way ESX will connect to the closest working DC and you do not have to worry if “yourdc.yourdomain.com” is down or not.
Cheers
Steve Beaver
Jason,
Great post and easy to follow how to. Just curious, would you not prefer your domain users to connect thru vCenter if available? What scenarios have you ran into in the past for allowing direct admin of ESX hosts?
Thanks Jason, (and Steve) post works perfectly!!
Thank you for shedding light on the additional configuration solutions. Value added.
@rbrambley: In my experience, I have logged on at the Service Console of the ESX host for various reasons. Running ESXTOP, changing of the root password, viewing logs, etc.
I run a forest called pironet.com with several subdomains let say us.pironet.com, eur.prionet.com, etc…
My ESX hosts are splitted over all the sub domains.
Now I want a single user sitting in us.pironet.com for instance to be able to logon to a ESX hosts in eur.pironet.com, how do I do that ?
Thx,
It depends on where the user objects are in AD. If they are truely in an AD subdomain us.pironet.com, then us.pironet.com is the domain suffix to be used in the esxcfg-auth script. Keep in mind that AD subdomains are not the same as DNS namespace subdomains.
Looks like actually ESX AD authentication doesn’t support (yet) cross domain authentications, nor it supports domain\username or username@domain type of usernames.
With –adddomain=pironet.com ESX searches within that domain only.
Cheers,
Have you tried adding multiple domains?
–adddomain=pironet.com –adddomain=us.pironet.com –adddomain=eur.pironet.com
Jason,
I guess I did not ask that question very clearly. So, in the distributed administrative model you assign local ESX server management responsibilities to the local or department engineers? I’ve mostly seen the “forest administrators” type approach where a select few have “the keys”.
@rbrambley: You don’t have to have a distributed or delegated model to integrate AD authentication.
There are a very select few who have the keys and those who have the keys sometimes need to log on to the ESX Service Console. There are plenty of *nix admins who will go to their grave saying “rarely ever log on using root!”. That’s what AD integration is for – anyone who would need to log onto the service console, even the most trusted of administrators.
Logging on as root doesn’t identify who actually used the root account. Logging on with AD integration leaves an audit trail.
Wasn’t thinking about the audit trail – that makes sense. I create an esxadmin account during install and select few have that password so root is not used. Thanks.
@rbambley: There’s no difference between having an “esxadmin” account that multiple users have access to and multiple users having access to root…there’s no way to tell who is doing what on the box.
The ideal setup is to have the administrators who are authorized to use the command line login with their own account, then use sudo to execute the CLI commands that are needed to administer the box. Sudo leaves messages in the log to show who executed what command, when, and from where (remote host and file system locations) to provide information should something destructive occur (purposely or accidentially).
http://get-admin.com/blog/?p=16
Good article, Jason! You can find more information and a technique for eliminating the need for local accounts on my web site:
http://blog.scottlowe.org/2007/07/10/esx-server-ad-integration/
Even with “full” AD integration using both esxcfg-auth and LDAP, I will still echo Andrew’s thoughts–you need to configure sudo to track what the admins are doing once they reach the Service Console.
Similar post here: http://malaysiavm.com/blog/vmware-esx-35-authentication-login-using-active-directory/
@Steve Beaver
It doesn’t work…
ESX auth searched the first domain listed and either returns a user doesn’t exist or password is not valid.
To have multiple domains authentication, you have to be able, like in windows, to enter domain\username or username@domain. And this is not possible for the moment.
Thus authentication against a single domain so far in ESX.
Thx,
Nice post, in the end after not getting the VMware instructions to work in our environment, we decided to go with an ISV solution from Centrify. They have a video chalktalk at http://www.centrify.com/resources/securing-vmware-esx-with-active-directory.asp that walks you through the limitations of the native AD integration that VMware provides. Product literature can be found at http://www.centrify.com/directcontrol/vmware_esx.asp