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).
Application
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
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
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 - https://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.
Cheers,
John.
Comments
Anonymous
January 01, 2003
Pete - yes, you can. I've got a couple of examples in this series coming up. AZMan is fully scriptable - in fact HVRemote already does some basic scripting. I'll have some pointers in future articles to this series, but everything is documented in MSDN. Thanks, John.Anonymous
January 01, 2003
Theo - unfortunately Hyper-V Manager is limited to only being able to create a VM in the default scope. You can work around this by using a script to create a VM in a particular scope, using the Hyper-V WMI APIs. Thanks, John.Anonymous
January 01, 2003
Mike - thanks for your feedback and I'm glad you find HVRemote and articles such as this I write up useful. I don't have an good answer as for the main bulk of feedback through, and don't claim to be the "owner" of the auth model that Hyper-V users. Sure, I own many other areas, but not this one. We are working on improving many areas of Hyper-V for future releases (not that I can disclose what and when) where customers are seeing deployment issues and difficulties. Feedback such as yours helps provide weight when having to balance resources across Hyper-V as a whole and deciding on features and improvements. However, I would point out that the typical customer base for remote assist and Hyper-V are very different audiences. Not that it minimises your feedback though. Thanks, John.Anonymous
September 01, 2009
The comment has been removedAnonymous
September 07, 2009
Nice one John, and it begs the question... it seems fair to say we could create our own role-based security model for Hyper-V that suits our organization. Do you think it's feasible to script modifying default security, and if so, where should we start?Anonymous
September 09, 2009
john, without these articles i'm sure we'd all be at a complete loss. So thankyou for taking the time to write up about them and creating HVRemote. However, there is one question that needs to be asked? Why so difficult? I'm sure there are a million technical reasons why...but at the end of the day I can "Remote Assist" someone with a few simple clicks and maybe firewall checks, but with Hyper V one must first learn advanced pschology and be a yoga guru in order to both physically and mentally bend oneself to fit this strange model. It seems that the KISS model is seriously lacking in this product.Anonymous
October 20, 2009
The comment has been removedAnonymous
October 24, 2009
I have to be honest here... The Hyper-V security model explained here is far better than the Hyper-V Resource Kit - to be honest - I'm not kidding. Explanation in Hyper-V Resource Kit is not in plain engish and is very hard to understand. -NK