A few weeks ago I saw on an internal email thread an ask from a customer via their VMware sale engineer. The customer was using AutoDeploy and Host Profiles. As part of this process, they were creating a local user on their ESXi hosts and when they connected to the host via the vSphere Client application on Windows, they were worried to see that the user was created with Shell Access already granted! As you can imagine, that’s probably not something you want done by default. Even more so when you’re in an environment that has compliance concerns. And especially when you have the Security Guy looking over your shoulder!
Well, like our friends from Down Under would say, “No Worries Mate”. What you are seeing here is a UI bug in the vSphere Windows Client. As you know, the vSphere Windows Client has been superseded by the new vSphere Web Client. But at the moment, it’s the main tool for configuration by those who connect to ESXi servers. With the vSphere Web Client being the current and future client user interface for vCenter Server managed objects and resources, the “old” vSphere Client may, at times, not be as current as we’d like.
In vSphere 5.1 we changed how we handled user permissions in ESXi. Prior to 5.1, it was done similar to how Unix does it. Usernames/passwords/groups all in different files in the /etc. directory. With 5.1, this was deprecated in favor of using vSphere API’s, Roles and Permissions. My colleague, Kyle Gleed, wrote a great blog post on this entitled “vSphere 5.1 – Full Admin Support of Named User Accounts”. As of 5.1, you can also use Named Accounts with full “root” privileges. (and like Kyle, I’d encourage you to add your hosts to an AD domain so you can use AD accounts and policies for those users)
Unfortunately, with these changes, the UI of the Windows Client was not updated to match and because the direction is the Web Client, the UI is not expected to be changed. Let me go into some detail about the changes and why the UI is not a concern.
Let’s take the example above. I have a user, TestUser. You can see that after I create the user, the checkbox is checked. (You will also note that the “Group” pull-down is empty as we are no longer using /etc/groups)
In the following videos we will go through some steps that show that the user does not have shell access unless they are in the Administrators group.
The first video shows that the user has the “Grant shell access” checkbox checked but because they are not in the Administrators group, they are unable to login via SSH to the ESXi server.
This video shows that “Grant shell access to this user” is a UI issue.
In the second video, I have added TestUser to the Administrators role. Upon doing that, TestUser can now SSH into the ESXi server. Easy enough, eh?
This video shows the process of granting the ESXi Administrator Role to a user
Now here’s something I found out when writing this blog. In the third video, I clone the Administrator role and assign TestUser to that role. When I try to SSH into the ESXi server, I’m denied. That’s because only users in the group Administrators can SSH into the ESXi server.
This video shows that granting a clone of the ESXi Administrator role to a user does not mean a user can SSH into the ESXi shell
I hope that shows you that despite the UI bug, things are actually better by being able to leverage Role Based Access Controls (RBAC) at the ESXi level. Your ability to be more finely grained in what users can change is enhanced.
Further settings for SSH access are contained in the vSphere Hardening Guide. Some of those are:
esxi-set-shell-interactive-timeout
esxi-set-shell-timeout
esxi-disable-ssh
esxi-enable-lockdown-mode
esxi-remove-authorized-keys
esxi-verify-admin-group (if you are using Active Directory)
It’s good practice to use the shell timeout settings. Note that using lockdown mode does NOT disable SSH, nor does it prevent root users from accessing a host using SSH user authorization keys. More info can be found in the vSphere Hardening Guide.
If you have an Active Directory infrastructure, I’d highly recommend using the AD Directory Services. If only for dealing with password policies and user management via a centralized mechanism. Consistency is key!
To wrap up, let’s review what we’ve learned.
ESXi no longer uses /etc/group
User permissions are now governed by Roles and Permissions
The UI was not updated to reflect that change
Many thanks to my colleague William Lam who helped out in this blog.
