When Active Directory Domain Controllers run as virtual machines on top of VMware vSphere, virtualization, storage and backups admins may be considered equal to enterprise admins in Active Directory, because they have the equivalent of physical access to Domain Controllers.

Admittingly, you don’t want everyone to use root or administrator@vsphere.local to manage the virtualization platform, so you do want to make use of single sign-on.

The challenges with vCenter single sign on

In large and enterprise deployments with different teams and different responsibilities, it may not be desirable that fabric admins (responsible for storage and the virtualization platforms) and backup admins are equal to Active Directory admins. or to have people sign in with their Active Directory credentials to the vSphere Web Console.

Harder to troubleshoot issues

Issues with Active Directory are rarely easy to spot and remediate. When fabric admins and backup admins have access to the configuration, disks or networking of virtual Domain Controllers, these avenues for introducing changes can’t be easily eliminated from the troubleshooting equation.

Harder to audit

When the number of admins increases, auditing complexity and costs increase too. Many auditing solutions use a pay-per-GB-ingest model. Scoping certain auditing events to a smaller group of privileged people, makes auditing more effective and more cost-effective.

Breaking the model of least privileges

I’m a firm believer of removing permissions that people don’t need. As a consultant, I review my admin credentials into my customers’ Azure AD tenants at the end of each month. This way, I can’t be responsible for what people in the organization do, and potentially mess up.

vCenter admins vs. Active Directory admins

In organizations where vCenter management and Active Directory management are split between two different teams, this method has its caveats:

1. Active Directory admins can reset the passwords for vCenter admins and lock the latter group out of managing vCenter.
2. Active Directory admins can stop the VMware Tools services on Domain Controllers.
3. Active Directory admins can remove the group membership(s) that provide vCenter admins access.
4. vCenter admins can stop virtualized Domain Controllers
5. vCenter admins can create snapshots and revert to snapshots, wreaking havoc on the Active Directory integrity by introducing USN bubbles and lingering objects, if Domain Controllers can’t deploy the Active Directory safeguards.
6. vCenter admins can run code on virtualized Domain Controllers, although there are ways to mitigate this particular risk.
7. vCenter admins can add additional admins outside of the assigned groups in Active Directory (both locally and from Active Directory) and even add additional groups permissions without these permissions ever being acknowledged within Active Directory, creating shadow admin privileges.

A data leak waiting to happen

It seems that many organizations have yet to embrace separation of duties. Only some organizations have implemented the Active Directory Administrative Tiering model. When these two processes have not been implemented, a breach of one single account in the Active Directory or Azure AD might hand over privileged access to an attacker.

When this account has privileges at the fabric level or the backup level, the organization will have a data leak on its hands.

Approaches for single sign on

There’s three approaches to single sign on, that organizations can use when securing access to virtual Domain Controllers:

1. Use a different or separate Identity provider for vSphere Single Sign-on
2. Use a different or separate vSphere cluster to run virtualized Domain Controllers, use a different virtualization platform or run Domain Controllers on physical hardware
3. Use VM Encryption and assign non-Enterprise Admins the No cryptography admin role

A different Identity Provider

An organization can opt to implement a separate Active Directory forest of LDAP v3-compatible identity store to manage roles in vCenter. This way, vCenter admins become the Active Directory admins of their own environment.

It solves the ‘vCenter admins vs. Active Directory admins’ challenge, but also places vCenter administration outside of the Identity and Access Management (IAM) processes. Strict bookkeeping should be applied to make sure vCenter accounts are deprovisioned when a person leaves the organization. It also solves the data leak issue, and has no consequences on many auditing implementations as these charge per GB ingested, not per Active Directory source.

It is however, the most expensive option, in terms of knowledge management, admin labor and harmonization of admin processes.

A different virtualization platform

Active Directory admins can also chose to not side with the vCenter admins. In that case, they could set up their own virtualization platform or move to a different virtualization fabric altogether.

In organizations moving to Infrastructure-as-a-Service (IaaS), it is not uncommon for Active Directory admins to have the Domain Controllers running in their own subscription and having vnet-to-vnet (peering) / VPN connections to the virtual machines and services run by the cloud service department.

This approach is more labor intensive for the Active Directory admins.

VM encryption and No cryptography admins

The easiest way is to deploy virtual machine encryption and make Domain Controllers VM-encrypted in vCenter. Then, only vCenter admins with the right knowledge and high standing will be provided with the full admin privileges in vCenter, and other admin can be provided with the No cryptography admin role.

This latter role prevents management of VM-encrypted virtual machines throughout the vCenter scope. VM-encrypted virtual machines can not be stopped, changed or managed by admins in the No cryptography admin role.

Concluding

Deji Akomolafe, Matt Liebowitz and I have presented on virtualizing Domain Controllers at VMware VMworld events for the last years. We also conducted many Ask the Experts session. The most common question we get after the presentation is how to provide a robust role-based access control solution. Here you go.