Explaining the Hyper-V authorization model, part four

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 parts two and three, I walked through a specific scenario. However, you’re probably asking after having read them how I knew what operations are needed, and when, and in what scope. Well, luckily I can walk across the corridor and speak to our development team. Obviously this isn’t practical for most of you reading this, but there are, of course other ways of discovering which access checks are failing. A great resource recently published on Technet is https://technet.microsoft.com/en-us/library/dd282980(WS.10).aspx. However, there’s a sneakier way….  Let’s take a step back through part three, and delete the role assignment and role definition “Service Access” I created to cause a deliberate access check failure.

Next, I turned on auditing for object access. (I’m ignoring the fact that local policy may be over-ridden by group policy in a domain environment – this walkthrough so far is entirely on a workgroup configuration). Start the Local Security Policy snap-in under Administrative tools, and navigate to Security Settings/Local Policies/Audit Policy and change to auditing Success and Failure.

 

Once done, log back on as user Joe or John and start Hyper-V Manager to validate the user gets the familiar ‘You do not have the required permission to complete this task.’ message.

 

Now log on as a user with local admin rights and start the event viewer.  Select the Security log under Windows Logs, and optionally apply a filter for just events 4665-4667 (actually just 4666 is probably enough).

What you’ll see is the following Audit Failure message for event ID 4666: Joe failed an access check to operation Read Service Configuration (operation ID 100) in scope “blank” (ie the default scope).

 

So with that knowledge, it’s easy to debug issues in authorisation models that you develop.

In the next part of this series, I’ll look through a really useful change in Windows Server 2008 R2 (and Microsoft Hyper-V Server 2008 R2) which leads me in to a walkthrough in part six of an authorisation policy example I use on my home servers.

Cheers,
John.