Virtualizing Active Directory - Security for AD vmdks

[MarkAllenP]

Hello,

I am a project manager for virtualizing some Active Directory servers. Currently they are all physical, and my approach is to build fresh VMs running Windows 2003 R2 64-bit with sufficient memory and disk space. The actual VM creation is not an issue. But what is an issue for our security people and the AD ops team is protecting the vmdk and associated files.

The current VSI (Virtual Server Infrastructure) has each VM using a LUN for the OS disk (C: drive), and another LUN for the Page file/temp files. Data files are also placed onto a seperate LUN. Now, the issue comes about since all the VMs for a single blade server (ESX host, HP BL685) are placed onto the same LUN, there will be a mix of server type files (apps, SQLs, ADs, etc.) in the data store. Meaning the C drives for all VMs on that blade are running under the same security policy.

If we lock down the datastore for AD people and other approved persons, then the normal ops support people (in a different country) don't get access to the files. Only the AD team has right to ADs and DCs, so I am trying to duplicate this security template.

So my idea is to have specific data stores just for ADs; providing one for the C: drive (SysVol, etc.) and another for the Page files. Then I can lock these down, and leave the others at their current security level.

Does this sound logical? Doable? Prefferable?

What are others doing about this issue? Or is it overkill?

Many thanks,

Mark-Allen

[krowczynski]

It is not required to have separate LUNs for AD server.

A vm is a vm.

You should only not have more than 10 vms per LUN.

[MarkAllenP]

Many thanks for your reply, but it addresses a technical point.

My question concerns more about: what type of additional protection is suggested for Active Directory VM files, above the normal permissions for basic application-related VMs.

Here is the way I see the difference: application server-related VMs have files, but normally no data. In many cases, it resides on SANs and NAS boxes, outside the VM files. Not always but is our case, yes.

But for Active Directoy servers (and NT4 Domain Controllers), the server IS the 'data'. Which is one of the reasons that only Domain Administrators and above can log onto a AD/DC. If you can get access to these files, copy them somewhere else, there is a good possibility you can bring the AD up, outside of the normal domain. This means you have access to every piece of information residing in the Active Directory; user names, addresses, company information, etc. This is a serious breach of security.

So, it is good practice to protect these VM files with more security and audit controls.

Now, I was just wondering what others had thought of this issue and how they have addressed it?

Many thanks,

Mark-Allen

[sjadapa]

Mark,

The following vmworld video can help you. Best practices for virtualizing AD

****If you find this or any other answer useful please consider awarding points by marking the answer CORRECT or HELPFUL ****

Jadapa RHCE, MCSA

http://linuxgurus.wordpress.com

[NTurnbull]

Hi Mark-Allen, by default the file level permissions for the .vmdk , .vswp , .nvram , vmsd and .vmfx are read write to local user root only. So anyone wanting to get into your host would have to have an account with root level access to do anything relating to the virtual machine in the ESX file system.

Bearing in mind you might want to check your VC permissions for that vm - destroy etc..

Thanks,

Neil

EDITED: changed a mistake in permissions Doh!!

[NTurnbull]

Unhappy with the wording in the previous post -

In the ESX file system by default the only user to have write access to the files is root. The .vmdk , .vswp , .nvram , .vmsd and .vmfx files are read/write to root only. The .vmx file is read/write/execute to root and read/exectute to all other users. The log files are read/write to root and read to everybody else.

Thanks,

Neil

[MarkAllenP]

Many thanks, NTurnbull.

This is very close to having the complete information.

So, it appears that anyone with root access can read the VM files and copy them (backup them up, whatever...) to another storage device. One must have a high-level of confidence in your VM team to allow this to be the standard for AD VMs. And I am not prepared to propose this to our risk managers. With a lot of support for VMs being done overseas (off-shore, near-shore, etc.), the number of people with all-area access increases, along with the risk.

Now, I would like to go back to the original post: what is a good solution for this?

How do I protect my AD VM files from unathorized access, and also audit their modification?

Would a separate data store allow for modified (and tightened) permissions, where only the AD team could have access (and approved others)?

My guess is that only the AD team would ever start/stop/etc a VM, so maybe this is possible.

I would like to thank everyone for their assistance in this matter.

Mark-Allen

[krowczynski · Accepted solution]

My guess is that only the AD team would ever start/stop/etc a VM, so maybe this is possible.

You can create a custom role on your vcenter and delegete permission to some users, who only will get access to some vms!

[MarkAllenP]

Hi krowczynski,

This seems to be my solution. And I would also like to thank Jadapa, who gave me a link to a VMWorld session that was explaining this specific point, as I was reading your post.

NTurnbull explained all about the files and permissions, so I extend my sincere thanks to him.

I wish all a nice day, and will close out this thread.

Mark-Allen

[NTurnbull]

For the ESX host level the only people who could gain access to the vmdk files are the people who know the root password. The root group don't have any permissions. If you go into a vm directory and do an ls -l you will get the following:

-rw------- 1 root root http://Filename.vmdk

The first bit -rw----- is the file level permissions the first - denotes it's a file (if it was a directory it would be a d not a - ) the remaining -

---

positions denote the permissions for the file owner (the next column, root), owner group (third column, root) and any others. There are 3 positions to each and they are rwx , you guessed it, read write and execute. If you see a log file the permission is -rw-rr-- then its (first block of 3) rw- means root user has read wrtite, second block r-- read to the owners group and the last three r-- is read to any other.

As for VC, you'd need to create a role that didn't allow people to copy, download or manipulate the datastore - If I log into VC I could potentialy browse datastore and download a copy of the vmdk. You'd have to give this some thought as to how you'd apply this as sometimes you might need to browse the datastore to re-register an orphaned vm. Don't forget that a role applied at a higher level can propogate down or conversly dis-allowed to propogate at a lower level. Take a look at the Basic sys admin guide on under the system administration section for more info on roles and VC permissions

Thanks,

Neil