In-Depth

Virtual Server Permissions: Getting Granular

Here's a way to delegate varying levels of server permissions with Microsoft's Virtual Server.

• By Todd Mera
• 04/08/2009

For example, the Virtual Server Administration Web site allows an administrator to assign view rights on a Virtual Server, thus allowing the group to see all virtual machines running on a server. But it doesn't allow you to assign view rights to individual virtual machines. In this article, I'll show you how to bypass the restriction and get the control you need. To do this, we'll use Virtual Server to provision isolated test labs to different groups of users on the same piece of hardware.

Before we begin, let's start with a basic understanding of how Virtual Server organizes its virtual resources, like virtual machines configuration files, virtual networks, hard drives, etc. and how it applies permissions to these resources.

When Microsoft Virtual Server is installed, it creates a set of folders and files that are used to configure, secure and control the Virtual Server and its resources. Let's take a look at these folders and files one at a time.

Virtual Server folder
The Virtual Server folder contains two files and two folders located in C:\Documents and Settings\All Users\Application Data\Microsoft\:

• Virtual Server configuration (Options.xml) -- This file contains Virtual Server property information, such as Search Paths, VMRC settings and Scripting setting.
• Virtual Server license (VSLicense.xml) -- This one is pretty obvious; the file contains the license signature, version information, etc.
• Virtual Machines -- This folder contains shortcuts to the configuration files of the virtual machines that have been added to the Virtual Server. Users need read access to this folder in order to see their virtual machine. We will assign this control via the Microsoft Virtual Server Administration Web site. As we will see later in this article, just because a user has permission to read the contents of this folder does not necessarily mean they will be able to view all of the virtual machines that have been added to the Virtual Server.
• Virtual Networks -- It's similar to the Virtual Machines folder but it contains shortcuts to the configuration files for virtual networks. Users need read access to this folder to see the virtual networks. We'll assign this control via the Microsoft Virtual Server Administration Web site.

Shared Virtual Machines and Networks folder
We'll be doing most of our work in two folders: Shared Virtual Machines and Shared Virtual Networks, located by default in C:\Documents and Settings\All Users\Documents\. When you create a new virtual machine, the virtual machine configuration file (vmc) and the virtual hard drive (vhd) will be located in a subfolder under the Shared Virtual Machines folder. So, if I create a typical virtual machine and call it VirtualOne, you'll see C:\Documents and Settings\All Users\Documents\Shared Virtual Machines\VirtualOne. The VirtualOne folder will contain VirtualOne.vmc and VirtualOne.vhd. The Virtual Server Administration Web site will automatically create a shortcut in C:\Documents and Settings\All Users\Application Data\Microsoft\Virtual Server\Virtual Machines folder pointing to the new virtual machine's configuration file.

Creating a virtual network works much the same way as creating a virtual machine. You create the virtual network file (vnc) in the C:\Documents and Settings\All Users\Documents\Shared Virtual Networks folder. A shortcut to the configuration file is then created in the C:\Documents and Settings\All Users\Application Data\Microsoft\Virtual Server\Virtual Networks folder.

Now that you have a basic understanding of how Virtual Server stores and secures virtual resources and configuration files, let's look at our scenario and how to assign granular control to users.

Getting to the Heart of the Virtual Server
In our scenario, we install Virtual Server 2005 R2 SP1 onto one server. We used default options and added two users, Rachael and Steve, who need a couple of servers for their current projects. We are going to provision these machines for them but need to make sure the servers meet the following requirements via the Virtual Server Administration Web site:

• Users should not be able to change Virtual Server settings
• Users should not be able to add, create or delete virtual machines.
• Each user should be able to stop, start, pause and turn off his virtual machines.
• Each user should only be able to see his or her machines and no other machines.
• Each user can use only the virtual network assigned to him.

With that, let's get started with delegating control to those virtual machines.

Granting View Access
In our current configuration, the administrator is the only one with access to the Virtual Server Administration Web site. So, the first thing you need to do is give your two users access to that Web site. To simplify future administration, let's create a security group called VSView. Users of this group will be able to connect to and view the Virtual Server Administration Web site. Here are the steps:

1. Create the VSView security group and add Rachael and Steve as members.
2. Go to the SVA and login as administrator.
3. Under Virtual Server, click Server Properties.
4. Click Virtual Server security.
5. Add an entry for VSView. You'll maintain the default permissions, View and Control.
6. Click OK

So, what did we just do? First, let's take a look at the View and Control permissions. View allows the group to read Virtual Server configuration information, the Virtual Server event logs and configuration information for virtual machines. To be more specific it gives the VSView group Read and Execute, List Folder Contents and Read permissions on the following folders:

• C:\Documents and Settings\All Users\Application Data\Microsoft\Virtual Server
• C:\Documents and Settings\All Users\Application Data\Microsoft\Virtual Machine Helper
• C:\Documents and Settings\All Users\Application Data\Microsoft\Virtual Server Webapp
• C:\Documents and Settings\All Users\Documents\Shared Virtual Machines
• C:\Documents and Settings\All Users\Documents\Shared Virtual Networks

The Control permission allows the group to access the Component Object Model interface, which is used by the Virtual Server Administration Web site. Without this permission, the group can't use the Virtual Server Administration Web site, even though the group can still use the VMRC client to connect to their virtual machines.

What can Rachael and Steve do at this point? They can view the virtual machines via the VSA Web site, read Virtual Server properties, see events and connect to running virtual machines using the VMRC client. But Rachael and Steve can't start or stop virtual machines and can't add or create virtual machines, networks or virtual hard disks. This task takes care of the first and second goals in our scenario.

Granting Access to Virtual Machine
Now, let's give Rachael and Steve access to their own set of virtual machines. To do this, we need to create a directory for Rachael and Steve's virtual machines, grant the appropriate permissions and provision the virtual machines. Let's set up Rachael first, with folder structure and permissions:

1. Create a folder in C:\Documents and Settings\All Users\Documents\Shared Virtual Machines and name it Rachael.
2. Right-click the new folder and select Properties.
3. Click the Security tab and then click Advanced.
4. In the Advanced window uncheck Allow inheritable permissions from parent to propagate to this object... When asked if you would like to copy or remove the existing security entries, select Copy and click OK.
5. You should be back at the main Security window. At this point we need to remove the security entry for VSView that was copied over from the previous step. Recall that this entry was originally added when we gave the VSView group View and Control permissions using the VSA Web site. Next add a security entry for Rachael giving her Modify, Read and Execute and List folder contents permissions.

Repeat the same steps above in order to provision Steve's virtual machine folder. Once you've done this, the administrator can copy Virtual Server images to Rachael's and Steve's folders and add the virtual machines using the VSA Web site.

Rachael and Steve will have limited access to any machine that exists in their respective folders. For example, Rachael will be able to perform the following actions only on machines in the ...\Shared Virtual Machines\Rachael folder and subfolders:

The left pane of Fig. 1 shows the Administrator logged in to the VSA Web site; notice that she is able to see both machines. The top right pane shows what Rachael sees; Steve sees only what's in the bottom right pane. So, at this point we've just taken care of our third and fourth goals.

[Click image to view larger version.]

Figure 1. The Virtual Server Administration Web site on the left; Rachael's view at top right; Steve's view at bottom right.

Limiting the use of Virtual Network
We have one more task, and that's creating virtual network devices for each user. We will also assign different DHCP scopes to each virtual network, so that we can isolate each user's set of virtual machines from the other.

When Virtual Server is first installed, it creates a virtual network for each of the physical network cards on the machine as well as an internal network device. For our scenario, we will use the VSA Web site and remove the preinstalled virtual networks. Here's how to do this:

1. Using the VSA Web site, mouse over Configure under the Virtual Networks area in the left navigation bar. Click View All.
2. From the list of virtual networks, mouse over the default virtual networks and click remove.

You've just removed the virtual networks from Virtual Server. However, the virtual network files still exist in C:\Documents and Settings\All Users\Documents\Shared Virtual Networks. If necessary the virtual networks can be made available to Virtual Server at any time by an administrator.

Next is creating one virtual network for each user. We will then assign the appropriate permissions to the network card. Follow these steps for configuring the virtual network card for Rachael and then repeat for Steve:

1. Using the VSA Web site, click Create under the Virtual Networks area in the left navigation bar.
2. Give the virtual network a name; in this example, we'll call it Virtual Network - Rachael. For the Network adapter on physical computer setting, select either the physical network adapter or None (Guest Only). Click OK.
3. You're now presented with the Virtual Network Properties page. For our example, let's click the DHCP Server link and enable the DHCP server in the virtual network and keep all the default settings. Note: When we repeat this procedure for our next user, the DHCP scope by default will be different for each virtual network. This will allow us to isolate our users' virtual machines from each other.

At this point, you're done with creating the virtual network devices and those devices are isolated from each other.

Next, we need to configure the appropriate permissions so each user can only see and access their virtual network:

1. Using Explorer, locate the C:\Documents and Settings\All Users\Documents\Shared Virtual Networks folder. You will see the virtual network files that you just created, Virtual Network - Rachael.
2. Right-click the Virtual Network - Rachael.vnc file and select Properties.
3. Click the Security tab and then click Advanced.
4. In the Advanced window uncheck Allow inheritable permissions from parent to propagate to this object... When asked if you would like to copy or remove the existing security entries select Copy and click OK.
5. When you're returned to the main Security screen, you need to remove the security entry for VSView that was copied over from the previous step. Recall that this entry was originally added when we gave the VSView group View and Control permissions using the VSA Web site. Next add a security entry for Rachael giving her Read & Execute and Read permissions.

Now Rachael can add or remove the virtual network Virtual Network - Rachael from her virtual machine, but she is prevented from modifying its properties or seeing any other virtual network adapters. We have accomplished our fifth and final goal.

With an understanding of Virtual Server permission and how it secures resources, you can allow different groups of users to gain granular access to machines on a single Virtual Server. These users will be able to use and control their own virtual machines without interfering with other machines on the same server.