Manage Learn to apply best practices and optimize your operations.

Managing Hyper-V's security permissions

While the default settings for Hyper-V's security permissions can work well in smaller settings, you may need to adjust these settings in larger environments. This tip outlines setting configuration with Hyper-V's not-so-intuitive Authorization Manager, or Azman.

The burdens of managing security permissions are rarely seen as exciting, but they're an essential duty to which...

we systems administrators are sworn to carry out. In this tip, I'll talk about how you can configure and manage permissions for your Hyper-V host servers.

We all rely on a variety of different security methods to ensure that only authorized users can access data center resources. Specific components of overall security range from physical access limitations to network authentication and permissions management. Virtualization brings with it some new requirements, namely the ability to specify which types of actions users can take on host systems.

It's certainly possible for administrators to manage virtual machines when they don't have access to the guest OSes themselves. The ability to granularly define authorization rules is essential for production servers. Fortunately, Hyper-V provides methods for defining and maintaining these permissions. But, as you'll soon see, it's not an entirely intuitive approach.

Default permissions in Hyper-V
By default, Hyper-V is configured to allow members of the local server's administrators group to have full permissions on the Hyper-V installation. In domain environments, individuals that are members of the domain admin's group will, by default, have full permissions to create and manage VMs on host servers. Members of the users group have a much more limited set of functions, including connecting to and starting virtual machines.

While these default settings might work well in smaller environments and for test labs, it's often necessary to grant additional permissions – such as the ability to start and stop VMs – to other users who should not also have full administrative permissions. Let's look at how that's done.

Introduction to Authorization Manager
Unless you have specifically looked for this information, the way in which you assign permissions on Hyper-V servers might not be apparent. You can't, for example, simply right-click on a host server or VM object and set permissions in a properties page as you could with a file system folder. Authorization Manager, also known as AzMan (not to be confused with Cosmo Kramer's infamous license plate on Seinfeld), is the primary method for defining and managing permissions for Hyper-V.

Authorization settings can be stored in XML files (the default for new Hyper-V installations), or within the Active Directory domain database. The default location for the permissions settings is in the following path: %ProgramData%\Microsoft\Windows\Hyper-V\InitialStore.xml. If you're planning to make changes to the settings, I highly recommend you create a backup (just make a copy of the initial configuration file and store it someplace safe).

Using Authorization Manager
Windows Server 2008 does not include an Administrative Tools shortcut for accessing the Authorization Manager, so you'll have to add it manually. To access the AzMan Snap-In on full installations of Windows Server 2008, follow these steps:

  1. Click Start  Run and then type MMC and press Enter. This will launch a new, default Microsoft Management Console (MMC) shell.
  2. To add Authorization Manager, Add/Remove Snap-In from the File Menu. Select Authorization Manager and then click the Add button. Note that you can also include other snap-ins, such as the Hyper-V Manager, the Services applet, and anything else you tend to use often.
  3. By default, AzMan is not connected to any specific security data store. To access the default Hyper-V settings, right-click on the Authorization Manager object and select Open Authorization Store. Select the XML File option and then browse to %ProgramData%\Microsoft\Windows\Hyper-V\InitialStore.xml. Note that you can also access security settings that are stored in Active Directory or in a SQL Server database.
  4. At this point, you can save this new MMC view by selecting the Save As option in the File menu. This will allow you to quickly access Authorization Manager from the Administrative Tools program group (or wherever else you choose to save it).

At this point, you're ready to start managing settings.

Managing role assignments
Authorization Manager uses a role-based permissions model that should be familiar to anyone who is used to managing security in Windows. The first stop on our guided tour of Authorization Manager is the single default role assignment called Administrator (see Figure 1).


Figure 1: Accessing role assignments using AzMan

Despite the name, it's important not to confuse this role assignment with a built-in Windows or Active Directory user or group. To give non-administrator users full permissions on Hyper-V, simply right-click the Administrator object and select "Assign Users And Groups". Note that you can add Windows security principals, or AzMan roles (which I'll mention later in this tip).

Creating role definitions
Often, you'll want to allow specific users to perform a limited set of operations on a Hyper-V server. To do this, you should start by creating new role definition objects. Each role definition can include a set of permissions that apply to members of the role. Figure 2 shows the default operations options that are included with Hyper-V.


Figure 2: Viewing available operations for new role assignments.

The names of most of them are self-explanatory and should meet most security admins' needs. A few checkmarks are all that is needed to, for example, create a role that allows for creating, starting and stopping VMs without permissions to manage virtual network and other server settings.

Other AzMan features
Despite its seemingly basic user interface, Authorization Manager allows you to perform many other security-related features. I won't go into these in depth, but here's a sample of some of the options:

  • Creating tasks: While Hyper-V does not include any Tasks by default, you can create your own set of operations that define which types operations can be performed. We already saw the list of built-in operations which will meet most basic security needs. However, the Tasks approach provides a quick and organized method of defining groups of settings based on the needs of your organization.
  • Managing scopes: By default, permissions will apply to the entire Hyper-V server. But what if you want specific users to have control over specific VMs? Scopes allow you to define specific objects to which permissions apply so you can, for example, allow a user to start and stop only test/development VMs.
  • Application groups: If you find that you're often assigning the same permissions to a specific group of individuals, you can define Application Groups within AzMan. Using these groups, you can avoid having to create Windows or Active Directory groups, while efficiently managing permission assignments.
  • Auditing: You can enable auditing of changes to AzMan-based security settings to keep track of when permissions are changed. Of course, you can also manage which users have access to make changes to security settings using AzMan.
  • Scripting and automation: You can use VBScript, JScript, and/or Windows PowerShell to automate the creation and management of security permissions. This is especially helpful if you need to propagate changes to a large number of host servers.
  • Summary
    The process for managing Hyper-V permissions isn't something that you're likely to stumble upon by accident and it might seem rather arcane at first. Using AzMan requires numerous steps (at least the first time you access it). What it lacks in intuitive appeal, though, Authorization Manager makes up for in security-related flexibility. Using this tool, you can define which users have permissions to which operations and actions – an important aspect of managing production virtualization host servers. Remember, I never claimed that security was exciting, but that doesn't make it any less necessary.

    About the author: Anil Desai is an independent consultant based in Austin, TX. He specializes in evaluating, implementing, and managing IT solutions. He has worked extensively with Microsoft's Server products and the .NET development platform and has managed environments that support thousands of virtual machines. Anil is an MCITP, MCSE, MCSD, and MCDBA, and a Microsoft MVP.

This was last published in September 2008

Dig Deeper on Server virtualization risks and monitoring



Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Great article
Still have problem , the users that not in Admin Group do not see the list of the virtual machines