October 01, 2021

#CyberAwarenessMonth: Audit Users & Groups

On Day 1 of the Cybersecurity Awareness Month we audit our vCenter Server users and groups to make sure only the right people have access, and to add isolation from our corporate Active Directory.

(It’s October so that means it’s #CyberAwarenessMonth! We should all be working to improve our security posture throughout the rest of the year, but October is a good time to talk about it collectively. We’ll be publishing a post every weekday with something actionable you can do RIGHT NOW to help make your security better.)

When is the last time you looked at who has access to vCenter Server?

I bet it’s been a while. Same here. I used to create a calendar invite for myself every quarter to do some routine tasks like this, rotate passwords, check group membership, that sort of thing. If you’re part of a team it might be fun to do it as a group exercise, everyone take an onerous task and get it done together. If you record who does the job this time then next time you can rotate, which spreads out the work, ensures knowledge transfer & training, and helps prevent errors and fraud (separation of duties).

Check Your Administrators group

Take a look at who’s in your administrators group for vCenter Server. To do this, you want the Administration Menu, then Single Sign On->Users and Groups:

vSphere SSO AD Group Administrators

See anyone that doesn’t belong there? Get rid of them.

This is how mine looks, which is a problem for three reasons. First, I can’t see who’s in that group because it’s coming from Active Directory (AD). Now I need to ask the AD folks who is in that group, which is what I suggest doing right now if this is also the case for you.

Second, it also means that anyone with access to my Active Directory installation can potentially be a vSphere Admin. Not good. Centralized directories like AD are giant targets for attackers because they are the gateway to everything else. Because of their central role in enterprises they’re often not patched in a timely fashion out of fear that something will break, despite critical vulnerabilities and reports of active exploits. An attacker gains access to AD through a hijacked account, elevates their own permissions to Domain Admin... game over.

Last, anyone in the organization with the ability to change group membership in AD can be a vSphere Admin, too, which makes it easier for an insider threat to operate, either maliciously or without authorization but trying to be helpful. Sure, you can see their logins in audit logs, but by then it’s too late.

Reduce Trust, Increase Isolation

So let’s fix the situation. Once you get the list of who’s in that AD group from the AD admins you can just add them to the SSO Administrators group:

vSphere SSO Users Administrators 0

This way you still get the centralized management of users via AD, but an attacker needs to explicitly find and compromise a vSphere Admin’s account.

Do you notice something else I did? I am using a separate administrator account, rather than using the account I have on the domain for my desktop PC. This is a great idea because if my personal, day-to-day account gets compromised the attacker won't instantly have access to everything else. Us vSphere Admins might think we're above having our accounts compromised, but in reality we're not. We're also big targets for attackers.

I made these changes manually, which is fine for a couple of vCenter Servers, but if you have a lot of vCenter Servers check out the VMware.vSphere.SsoAdmin PowerCLI module our PowerCLI team wrote!

Tune in next week for more ways to make October the month you improve your security!

Filter Tags

Security Cloud Foundation Cloud Foundation 3.9 Cloud Foundation 4 Cloud Foundation 4.2 Cloud Foundation 4.2.1 Cloud Foundation 4.3 Cloud Foundation 4.3.1 ESXi ESXi 6.5 ESXi 6.7 ESXi 7 vCenter Server vCenter Server 6.5 vCenter Server 6.7 vCenter Server 7 vSphere vSphere 6.5 vSphere 6.7 vSphere 7 Blog