Explaining the Hyper-V authorization model, part one

Hyper-V uses a role based authorisation model for access checks. This series of articles takes a look at the model; defines the available primitives; and walks through a couple of examples. (I actually wrote most of this series many months ago – only finally found the time to post it up!).

Quick links: Part1; Part 2; Part 3; Part 4 

As the term ‘Role Based Authorisation Model’ implies, Hyper-V has an authorisation layer which performs access checks to grant or deny an account access to operations based on roles the account is a member of. That is not to say everything in Hyper-V has an authorisation protection layer – we also use traditional NT ACL-based security mechanisms. However, this series of articles concentrates just on the authorisation model.

A term I should introduce at this point is “AZMan”. AZMan is, in short, an engine and toolset for making role based access checks and defining policy. AZMan is a component built into Windows. Hyper-V uses AZMan to control role based authorisation.

When you install Hyper-V, the system is configured with a policy store, the policy store being nothing more than a file on disk called ‘InitialStore.xml’. InitialStore.xml contains the most simple of authorisation policies: local administrators are authorised to perform all operations protected by a policy check.

There are two registry keys Hyper-V uses to define attributes about the policy store. They are both under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Virtualization.

StoreLocation points to a file called InitialStore in a hidden directory c:\ProgramData.
ServiceApplication defines which application in the policy store is used.


Before looking at the contents of InitialStore.xml, let’s define some primitives which Hyper-V uses in AZMan.

(Note that AZMan is a very flexible model, and Hyper-V does not use all the primitives available in AZMan. Also these articles do not cover more advanced modeling capabilities where you can, to some extent, build nested models).


Policy stores define the authorisation model for zero or more applications. An application is top-level container which contains all the other primitives used by an application. Examples of applications could be ‘My Financials Application’ or (not by any coincidence!) ‘Hyper-V services’.


Operations are specific items or actions being guarded by an access check in an application. For example, when a user tells a system to “Create a Virtual Machine”, Hyper-V makes an access check.

Role Definitions

As the name implies, this is the definition of a specific role, such as a Hyper-V administrator, or a Hyper-V Network Administrator, or standard user. It is defined by a name and zero or more operations which are permissible in this role definition.  So with the examples I just gave, you could choose to setup the store such that an administrator role definition contains all operations, a network administrator role definition contain the operations for altering, creating or deleting virtual networks, and standard users can only connect and interact with virtual machines.

Role Assignments

Role assignments are where users and groups are placed or “assigned” in the model. A role assignment can be stand alone or linked to one or more role definitions.
A standalone role assignment doesn’t make too much sense, as without any role definition links, it is nothing more than an orphaned grouping of accounts.
When you link a role assignment to a role definition, you are saying that the accounts in the role assignment have would pass access checks for the operations defined in the linked role definition.  If you link a role assignment to multiple role definitions, accounts in the role assignment would pass access checks for the superset of operations defined by all the linked role definitions.
Role assignments can be created at multiple levels or “scopes”.


Scopes are a more advanced feature in the authorisation model. Scopes can be thought of as the “level” where role definitions, role assignments and other AZMan primitives reside. Each AZMan policy store contains a single top level scope. A good way to think of the top level scope is the place where global policy is defined.

Side note Internally on the Hyper-V team, this tends to be referred to as the ‘default’ or ‘root’ scope. Whether that is correct or not in AZMan terminology is another question! I believe the correct term is “Application” scope.

You can also create additional “more constrained” scopes, and place virtual machines in them. For the purposes of Hyper-V, it makes sense to think of these as VM specific scopes, or VM Scopes for short. Using VM scopes is a topic I’ll cover in more detail in later parts of this series.

So with knowledge of those primitives, let’s take a look at the out-of-box policy store. To use the management tools for AZMan requires a full installation of Windows Server rather than server core. (Or you can take a copy of the file across to a separate Vista or Windows 7 installation). As the policy store is in a hidden and ACL’d directory, you need to be a local administrator to open the file.

Start azman.msc


Right click on Authorisation Manager in the tree view on the left and select Open Authorisation Store. Navigate, or enter the path, to InitialStore.xml (again, note \ProgramData is a hidden directory – you can type it in though).


Once open, the first thing to notice is that there is a single application defined:  ‘Hyper-V services’.


This matches the registry key ‘ServiceApplication’ in the screenshot higher up this article. Next, I’ve expanded out a couple of nodes so that you can see where Role Definitions and Role Assignments fit in to the hierarchy.

(Note the Hyper-V authorisation model does not use Task Definitions or Authorisation Rules, and I won’t be talking about Groups in this series of articles)


You can see that we have a single role definition ‘Administrator’ and a single role assignment ‘Administrator’ defined. First, examine the ‘Administrator’ role definition by right clicking on it, selecting properties and choosing the Definition tab.

This is where we can see which operations are covered by a role definition. There are 33 operations in Hyper-V in Windows Server 2008 and Microsoft Hyper-V Server, and 34 operations in Windows Server 2008 R2 and Microsoft Hyper-V Server R2.

If you select a role assignment, Authorisation Manager displays a list of accounts who are members of that role assignment – the default being the builtin administrators group.

As an aside – if you are walking through this and are using a domain joined machine (the above screenshot is from a workgroup machine), the default accounts listed in the “Administrator” Role Assignment will be domainname\administrators. This is actually a bug (as far as I can tell) in the AZMan console. You can verify this by opening InitialStore.xml in an editor:

You’ll notice that the SID listed is S-1-5-32-544 which is the SID (Security Identifier) of the builtin\administrators group - http://support.microsoft.com/kb/163846 has more information.

So that explains how the default policy in Hyper-V is setup such that local administrators have access to all operations. With an understanding of the primitives, it is trivial to extrapolate how to modify the model to grant other accounts full access to Hyper-V without needing to be local administrators on the Hyper-V machine itself – you simply need to add accounts to the ‘Administrator’ role assignment in the default scope. This is exactly what Ben blogged about in January last year.

In the next part, I’ll take a look at scopes.