Running Virtual Machines under alternate user credentials on a Domain Controller
Introduction
Recently, I was experimenting with Team Foundation Server 2008, setting it up with SSL and running it within a test domain. For the Team Foundation Server, I couldn't use the host installation as it runs Windows Server 2003 R2 x64 edition and TFS doesn't support (see the TFS installation guide, under 'Overview of Team Foundation Architecture', '64-bit Support in Team Foundation') this setup in a single server scenario. So, I installed Virtual Server 2005 R2 SP1, installed TFS on top, configure SSL and voila, a working TFS setup.
When I shut down the host computer, I want the virtual machine of TFS to save state and come back up again when the host is turned on again. This can be done in Virtual Server using an alternative use running the actual Virtual Machine instance. Trying to set this up in a least privilege way proved not to be obvious from documentation, so this blog entry documents what I did for posterity (and myself ;-)).
Outline
Here's what needs to be done in order to circumvent obscure error messages:
1. We need a new user group so the account we'll use doesn't belong to default domain users and inherits no permissions.
2. We need a new user to run the Virtual Machine instance, the user should belong to this group only.
3. The user needs to be given 'Local on locally' rights.
4. Permissions need to be set on the folder containing network configuration information for Virtual Server.
5. Permissions need to be set on the folder containing the Virtual Machine and the actual files (*.vhd, .vmc) making up the Virtual Machine.
6. The Virtual Machine needs to be configured to use the new user.
Instuctions
Let's configure the necessary elements.
1. Create a new group
Create a new group within the Active Directory Users and Computers MMC snapin (found under Administration Tools):
2. Create a new user
Create the user which is to run the specific Virtual Machine (done from the same MMC snap-in), add it to the 'empty' group, set the 'empty' group as it's Primary Group and remove the 'Domain Users' group from the list. After this, your user overview should resemble this image:
3. Assign 'Log on locally' rights to the user
This step is critical in getting the Virtual Machine running under the new user context. Steps to achieve the appropriate right setting are described here. If the user doesn't receive the 'Log on locally' right, Virtual Server will display an error: 'The account name and password could not be set. The virtual machine account could not be set. The account has not been granted the requested logon type. '. Make sure the security policy is updated before using the account.
4. Set permissions for the used virtual network interface
Now that we have the user and it's group configured, let's set the appropriate permissions for the user to make use of the configured network. Mind you, these instructions will only allow the user to use the network it's given access to from the instructions, the 'local network only' et al will not work as the user has no rights on the files used for those configurations.
The virtual network configuration files for Virtual Server are stored in %SystemDrive%\Documents and Settings\All Users\Application Data\Microsoft\Virtual Server\Virtual Networks. The user needs permissions as specified in order to use the network. If permissions are set incorrectly, the Virtual Machine will not have network access.
5. Set permissions on Virtual Machine folders and files
In order to start up the Virtual Machine, save state, etc, the new user needs access rights on the folder storing the actual files making up the Virtual Machine as well as specific rights on the Virtual Machine files. The folder structure containing my Virtual Machine files is:
%SystemDrive%\vms\<Virtual Machine>
First, let's set the appropriate rights on the folder hosting all Virtual Machines:
Now, let's set the permissions for the appropriate Virtual Machine ('tfs') folder:
Lastly, set up permissions for the Virtual Machine files (my TFS has 3: tfs.vmc, tfs.vhd and sql.vhd):
6. Configure the Virtual Machine
All permissions are set, we're ready to configure Virtual Server to run the Virtual Machine under the new user context:
Wrap up
That's it! We've configured the Virtual Machine to run under a user context which has the least amount of privileges it needs to function correctly. The Virtual Machine will save it's state when the host is shut down and will automatically turn back on when the host comes back online.
HTH