次の方法で共有

Explaining the Hyper-V authorization model, part three

  • [アーティクル]

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 

In part two, I started creating the scenario of separating the view two users have when opening Hyper-V Manager so that they only see their own VMs. To do that, I created two VM Scopes, one for each user, and moved the users’ VMs to the required VM scopes. I mentioned that some more steps were still required. This part of the series walks through those steps.

The first part of the additional steps I’ve pretty well covered to death in my remote management of Hyper-V series. As my two users, John and Joe are not local administrators; they need to be granted explicit access to WMI namespaces (and Distributed COM Users if managing remotely). By far the easiest way to achieve this is using HVRemote. (Note, I’m assuming you’re following best practice, and using remote management as the server is running Hyper-V Server, the standalone SKU, or a Server Core installation of Windows Server 2008/2008 R2.)

From an elevated command prompt when logged on as a local administrator, run

cscript hvremote.wsf /add:john

(Use /add:domain\account if the Hyper-V machine is domain joined)

azman-3-1 

If you look at the output carefully, note the line that says “Adding john to AZMan role Administrator” near the bottom. Apart from a typo I need to correct in a future version, what HVRemote has done is add john to the ‘Administrator’ role assignment in the default scope.  This is simply a limitation in HVRemote. At the time of writing, HVRemote cannot cope with VM Scopes.  (In fact it is hard coded to always update the role assignment called ‘Administrator’ in the default scope – on my big list and will be covered in the future).

If John and Joe are now administrators in the default scope, we’ve not performed any separation as administrators in the default scope can view all VMs. There are two ways to resolve this. Either we update policy using Authorisation Manager to undo the generalisation HVRemote has made here, or use a parameter available in HVRemote when adding the account.

Method 1 Use Authorisation Manager

Select the Role Assignment ‘Administrator’ in the root scope to find the user which has been added.

azman-3-2 

Right click on the user and choose delete (or simply hit the delete key)

Method 2 Use a parameter to hvremote

*Caveat this may not work in future releases – it does as of version 0.7 though.

From an elevated command prompt when logged on as a local administrator, run

cscript hvremote.wsf /add:john /noazman

(Use /add:domain\account if the Hyper-V machine is domain joined)

azman-3-3 

If you compare this output to the previous hvremote output, notice there is no role assignment update in AZMan.

The last part to get our user separation in place require a little thought to get your head around, and a little knowledge of the Hyper-V design.

We have a service called VMMS (Virtual Machine Management Service).  There are two operations in our authorisation model which are required to be able to perform operations on the VMMS. VMMS always performs its access checks for these operations in the default scope.

The operations are

  • Read Service Configuration, and
  • Reconfigure Service

What this means is that the users I’m separating, John and Joe, must be authorized to these operations in the default scope. It is not sufficient to just have them an ‘administrator’ in the VM Scope. Based on our knowledge from the previous parts, this is easily achieved:

  1. Create a Role Definition ‘Service Access’ containing the two operations in the default scope
  2. Create a Role Assignment ‘Service Access’ linked to the ‘Service Access’ role definition in the default scope
  3. Add John and Joe to the role assignment ‘Service Access’ in the default scope

Authorisation manager should look like the following when done:

azman-3-4

azman-3-5 

All that remains validate the configuration is to log on as those users and start Hyper-V Manager (or use Hyper-V Manager remotely in the case of a server core or Microsoft Hyper-V Server installation).

Here, I’m logged on as John

azman-3-6 

And here, I’m logged on as Joe

azman-3-7 

So that works as expected. With the information so far, I hope I’ve provided everything you need to enable you to build a model which makes sense for your own unique implementation. It’s a question of sitting down and working through how to map your organisational needs into authorisation model primitives.  There is no single right answer which fits everyone, so building a mapping is not something I can help you with!

In the next part of this series, I’ll take a look at how you could debug issues with a custom authorisation model you develop.

Cheers,
John.

Comments

  • Anonymous
    January 01, 2003
    Following your guidelines I've configured Hyper-V Server R2 without any issue and started working with it. It's a great walkthrough. Thanks! Today I found that standard users authorized to access only their own VMs cannot read the Network Adapter settings. I've enabled Object Access auditing as suggested on part 4 of this blog series using the following command (I cannot configure local security policy from a remote MMC): auditpol /set /category:{6997984A-797A-11D9-BED3-505054503030} /success:disable /failure:enable Then I found the Service Access role needs the following operations: View External Ethernet Ports, View Internal Ethernet Ports, View Switch Ports, View Switches, View VLAN Settings. Once I added these operations to the role, my standard users can see the network configuration of their VMs. Regars, Renato Massone

  • Anonymous
    January 01, 2003
    Theo - yes, this is expected. Using Hyper-V Manager, it is only possible to create VMs in the default scope, not in a user-specific scope. As the user does not have permission to create a VM in the default scope, this is expected. You can however use a script to create a VM in a scope directly using the Hyper-V WMI APIs. Thanks, John.

  • Anonymous
    November 12, 2009
    i have all done as described above... if i log on with user John I can see my machine, but i can't create a new machine... what's the reason for this problem? thanks theo