Defense in Depth: Authentication and Authorization

On the 7/29 Virtualization Security podcast we continued our discussions on defense in depth. We discussed authentication and authorization with IdentityLogix. IdentityLogix provides a unique solution that correlates users and groups against VMware vSphere’s own role based access control stores. In other words, IdentityLogix can identify if a user or group within active directory has more access to VMware vSphere’s management tools than they were intended to be allowed based not only on the user’s username but on the groups in which the user belongs. Why is this important to know?
We have discussed Role Based Access Controls (RBAC) in the past when we have discussed HyTrust on the virtualization security podcast. Where HyTrust provides a single point to enforce RBAC, IdentityLogix provides a way to ensure the enforcement is as desired. By inspecting active directory users and groups and correlating them to VMware vCenter’s and vSphere’s authorization store, IdentityLogix can determine exactly what access a user (who most likely belongs to many groups) has within the system. You may be surprised to find that non-virtualization administrators have administrative access to your virtual environment. If this is the case, they present one more attack point.
Limiting access is a crucial part of any virtual or cloud environment defense in depth with knowledge of what access has been granted being a key component of your defense. Without a tool such as IdentityLogix, you are required to go by hand through each granted access and determine which users are within what groups within your directory store. But what complexes everything for large environments is that groups can be parts of groups, users can be part of sub-groups, etc. Unless you have the time to map everything out on a regular basis is is better to use a tool. But what about the groups which you do not know about? The ones that are unknown to most people such as the ESX Admins group? This group may not be within  your directory service now, but is known to most ESX hosts. This group, if a user is placed within it, grants administrative rights to the users within that group if AD integration is enabled on your ESX hosts. And by the way, the VMware Hardening Guide for vSphere says to enable AD integration on your vSphere hosts.
Why we should enable AD integration is unknown to me. To me access to your virtualization host consoles should be a break glass situation. In other words, no one should be logging in to manipulate your virtualization hosts without everyone knowing it is happening. The last time I had to manage my hosts from the vSphere console was when vNetwork distributed switches broke my system and I had to move vCenter off to a standard vSwitch. A break-glass situation.
Even so, there is some merit to having non-root service accounts on your vSphere boxes so that in a break glass situation you can track who did what, when, where, and how. The issue is should those users be tied to active directory or not. Think of a catch-22 situation that could happen if the Active Directory server resides upon the host with issues? Hopefully you have multiple AD servers so that you get redundancy but if you do not, there is only one way to login, using the root account. Which is a break glass situation unless you have also seeded local administrator accounts.
With vSphere 5.1, VMware has allowed the creation of local named accounts which can run commands as the administrative user. This gives the ability to track access by user instead of everyone using the same account. This is a big win for auditing, but creates even more authorization issues. Are those users part of AD? Is AD Integration enabled?
If a directory service is used to provide authentication, and groups from that directory service are used as part of authorization and RBAC then it is important to inspect your directory service and authorization mechanisms to limit access to such critical systems.