I just read about the new "feature" which involves an host constantly checking for a specific AD group and assigning it automatically the Administrators permission :
By default, the ESX host assigns the Administrator role to the "ESX Admins" group.
If the group does not exist when the host joins the domain, the host will
not assign the role. In this case, you must create the "ESX Admins"
group in the Active Directory. The host will periodically check the domain controller
for the group and will assign the role when the group exists.
I really hope I'm wrong, but according to me this means it is very easy for unauthorized personnel to get full admin rights on the hosts.
All ones needs is AD rights to create a group (and VMware admins unaware of this "feature"). They would just create the "ESX Admins" group, set them as a member of it and voila. Just need to wait for the ESX 4.1 hosts to detect it and grant them the full permissions.
Needless to say, a lot of IT (and even non-IT staff) can create groups in big AD environment, most of them not being domains admins nor VMware Admins (hotline operators comes to mind).
2 questions then :
1- am I missing something ?
2- if not, can we expect a fix to this security flaw ?
Just leave it in local mode until you have the group the way you want it.
I guess will not be integrating my hosts into AD then, unless this gets changed. "Just leave it in local mode until you have the group the way you want it." tells me that I do not have the ability to NOT use the group, which would not be acceptable. I don't want to use the ESX Admins group, but If that group gets created by the administrator of the other VI in the future, then my hosts would start to use it. That is not acceptable.
While an admin still has to enable the option, hard-coded dafaults are BAD. Yes, we know there are a number of others... e.g. root. However, it would be ideal in this case if the configuration instead asked the admin, "Enter AD Group Name: _____"
Enterprises have naming standards. "ESX Admins" doesn't conform to my standards. Defaults that can't be changed also tend to end up in audit reports...
Also, agree with OP. I was staggered to find this is the configuration that VMware have setup.
In a worldwide enterprise business with multiple Virtual Infrastructures but one AD this is a security risk waiting to happen, surely.
How do you manage membership of the ESX Admins group in this instance. I am not a AD administrator. Other people take care of that.
If in our enterprise a subdivision within the company read this documentation and ask for this group to be setup for their VI.
This in effect gives someone over the other side of the world in our company access into our VI if they were to browse AD for objects with a description of vCenter server against them.
VMware... the name of this group and ability to enable/disable should be a configurable choice.
This is all wrong from an Auditing, Naming point of view within AD.
vSphere 4.1 :
• ESX 4.1 Servers
• vCenter Server 4.1 (VM) :
- Windows Server 2008 64bit
- MS SQL 2005 (VCDB/VUMDB)
• NetBackup 6.5.5
- VCB 1.5 U2
• FC SAN
Totally and 100% seconded to both of the above. This is exactly what I was saying in other posts. This needs to be changed in an upcoming patch or in the next revision.
That is not really a helpful response based on the requirements:
A) You guys deprecated 'esxcfg-auth --enablead' so this no longer works in 4.1, not an option any longer, I'm going to try --enablekrb5, I've read this still works.
B) Multiple departments may have separate ESX clusters they manage and given one Active Directory domain its not possible to set this up securely when a VI admin is not familiar with the security implications
C) As people have said, some VI admins are not Domain Admins and vice versa. Locking down the group is not as easy as it sounds for a VI admin that is not familar with the security implications
D) 'ESX Admins' does not conform to everyone's naming standards
Another scary issue, if your AD account is in >30 groups and you try to log in (I was using SSH) the host crashes with an NMI (attached). See http://communities.vmware.com/message/1619126#1619126
So, I guess standard procedure should be to:
A) Create the 'ESX Admins' group, leave it empty. Try to put it in an OU that has locked down permissions
B) Give the 'ESX Admins' group the 'no access' role on the host
C) Use your standad AD group and assign to the host. Watch out if your user account is > 30 groups or BOOM.
D) Consider esxcfg-auth --enablekrb5
What several others have pointed out about a VMware Admin not necessarily having permissions in AD is very, VERY true. For those VMware admins who basically have no AD permissions, this current implementation of AD authentication is a huge back door waiting to be exploited. Sadly, for those admins, the reality is that they should not and will not use this feature as it currently exists. At least they will not use this feature after the first time a screwup take place because of unintentional inappropriate access.
My vote would be to retool this feature so that the VMware admin gets to specify BOTH the name of the security group(s), and also whether the group(s) added would be local computer-based or domain-based. This in addition to being able to set an alarm in vCenter to alert if/when the group(s) get modified. Again, the VMware admin needs to be able to monitor and control security on this application. As many have voiced here, VMware Admin does not automatically equate to having admin privileges in AD.
"It's not the load that breaks you down. It's the way you carry it." - Lena Horne
Interesting thread. In our test AD domain, we created the ESX Admins group and put a couple people in it - works great, including adding that group to /etc/sudoers (had to rely on someone's blog to figure that out though...).
Our Prod plan it to NOT create that group, and use a different one, manually adding it to the hosts with Administrator role. I think someone stated that the host will occasionally query AD to see if the ESX Admins group exists, and then add it as Administrator if it is found - did I understand that correctly?
I agree with the concensus that we should be able to control what group(s) to add, and not have a default like this.
I have just now tested the ESX Admins group in my lab. The security group does exist in AD. And ESXi hosts have been added to inventory of vCenter Server. The vCenter Server is a member of AD. Logging in as a member of the ESX Admins group did - as I hoped - fail. Logging on as root directly to the ESXi host, I confirmed that ESX Admins is NOT granted any permissions to the host at all. It is only after explicitly changing the authentication mechanism to Active Directory that the ESX Admins group is granted administrator privileges to the host. So good news there.
Still, hard coding a single, specific group name is a bad idea for all the reasons already stated by others. That needs changing. But the situation is not as extreme as some of us were concerned about.
"It's not the load that breaks you down. It's the way you carry it." - Lena Horne
I just added a different group to Administrators group on the host, then deleted ESX Admins. A minute later, it came back. So, sure enough, if that group exists in AD and you are using AD authentication, that will happen. I'm not all that worried about it - we never really planned to create that group in the poduction domain anyway, and the idea that bad guys will create it and populate it with evil users seems unlikely. But it sure is a strange design decision. Sounds like something they came up with on Friday after work, after a couple of pitchers.
I don't think the overriding worry is really about bad guys populating the group with evil users, but rather it is 1) a bad programming decision to hard code a specific group name that you cannot override and/or have control over, and 2) the fact that if you have 2 or more ESX infrastructures in one AD domain, you can only have this one group controlling access to both infrastructures, which you may not (probably don't) want.
Which would be the reason not to create that group in AD in the first place, and just use another one that you would have to manually add during the build process. Which, my guess, is what 95% of their customers are going to do.
I must agree with the OP. Setting something like this up without giving the VI admin a choice is bad security practice.
I know I am late to the party, but this seems ridiculous waste of paranoia. Why are yo so concerned about a server? So they are IT, so they have rights to change and add groups. so what?
Do you GIVE Administrators group rights to EVERY person in IT just because? I don't think so. That's what we are talking about. By DEFAULT ESX gives rights to the Administrators group and the Admin role. Again, so what? That's DEFAULT.
You don't want give access to your co-workers, then DON'T add them to the Administrators group on the vCenter server, it's that simple. Don't give the Administrator password to change their access, even if it's a member of the domain, you actually CAN restrict a domain admin from access this server just by removing domain admins from the Administrators group.
It really is JUST that simple...
Besides sounding condescending, what you are talking about is not the problem. The problem is that if I want to use AD authentication for my ESXi servers, and if I want to have a group in AD that I can use to assign admin rights, VMware has decided that this group will be called 'ESX Admins', and that is not configurable. Furthermore, if you have 2 or more infrastructures using the same AD, then all infrastructures will use the same 'ESX Admins' group. We should be able to use any group name we want, not just 'ESX Admins'. Then each infrastructure can use whatever group they want for that function. Furthermore, if the domain admin creates an 'ESX Admins' group for his or some other infrastructure, my ESX servers will automatically pick that up and give them rights to my infrastructure.
The solution to this particular issue is to configure the individual ESXi hosts as follows:
create a local group called "ESX Admins"
explicitly grant the "No Access" Role to this group
This will effectively override the default behavior, and even if someone creates an AD group called "ESX Admins", members of this group will NOT be able to manage the ESXi hosts.
Thank you for this information. Making the whole thing configurable would be best, but this would work. I just need a little clarification. I click the 'Permissions' tab on the ESXi host in the vCenter VI client and then right click and select 'Add permission'. I then click 'Add' under Users and Groups. When the dialog box comes up, it shows the local groups on the vCenter server. So, would I add the group 'ESX Admins' to the vCenter server, or would I need to run the VI client on each host individually and add the ESX Admins group locally on each host?
You would connect to each ESXi host individually using the vSphere Client and perform the two steps.
(Yes, making it configurable would be ideal. Feedback heard loud and clear!)
I just tried creating a local group callled ESX Admins on the host under Local Users & Groups and It won't lest me create a group with spaces in it.....
Am I doing this at the right location?
I think I had a mistake in my original procedure. I believe that you don't actually have to create the local group "ESX Admins" on ESXi. Instead, you just need to grant the "No Access" privilege to the AD group called "ESX Admins" (I believe this group does need to exist ahead of time, however).
If you try this out, please let us know if it works.