Tag Archives: Windows Server 2016

Nano Server No Longer Supported for Infrastructure Workloads

   When Windows Server 2016 was released last year, one of the features that I myself, and much of the community were excited about was the new installation option called Nano Server. The way I’ve always described Nano Server is that it’s like Windows Server Core, but on steroids. It is a completely gutted, only-what-you-need installation option, and it’s an installation option that really talked to my Linux and open-source roots. I loved the idea of having only what was absolutely necessary installed on a server, not just because of the attack surface reduction, but because of the reduction in software to maintain on the system as well. I remember running Gentoo Linux on some systems simply because it was a “compile from source” type of distribution and I loved the idea of again, only installing the needed bits, and with Nano Server I felt like we had arrived at… Read More»

Read the post here: Nano Server No Longer Supported for Infrastructure Workloads

Live Migration via Constrained Delegation with Kerberos in Windows Server 2016


Many Hyper-V customers have run into new challenges when trying to use constrained delegation with Kerberos to Live Migrate VMs in Windows Server 2016.  When attempting to migrate, they would see errors with messages like “no credentials are available in the security package,” or “the Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: no suitable credentials available.”  After investigating, we have determined the root cause of the issue and have updated guidance for how to configure constrained delegation.

Fixing This Issue

Resolving this issue is a simple configuration change in Active Directory.  In the following dialog, select “use any authentication protocol” instead of “use Kerberos only.”


Root Cause

Warning: the next two sections go a bit deep into the internal workings of Hyper-V.

The root cause of this issue is an under the hood change in Hyper-V remoting.  Between Windows Server 2012R2 and Windows Server 2016, we shifted from using the Hyper-V WMI Provider *v1* over *DCOM* to the Hyper-V WMI Provider *v2* over *WinRM*.  This is a good thing: it unifies Hyper-V remoting with other Windows remoting tools (e.g. PowerShell Remoting).  This change matters for constrained delegation because:

  1. WinRM runs as NETWORK SERVICE, while the Virtual Machine Management Service (VMMS) runs as SYSTEM.
  2. The way WinRM does inbound authentication stores the nice, forwardable Kerberos ticket in a location that is unavailable to NETWORK SERVICE.

The net result is the WinRM cannot access the forwardable Kerberos ticket, and the Live Migration fails on Windows Server 2016.  After exploring possible solutions, the best (and fastest) option here is to change the configuration to enable “protocol transition” by changing the constrained delegation configuration as above.

How does this impact security?

You may think this approach is less secure, but in practice, the impact is debatable.

When Kerberos Constrained Delegation (KCD) is configured to “use Kerberos only,” the system performing delegation must possess a Kerberos service ticket from the delegated user as evidence that it is acting on behalf of that user.  By switching KCD to “use any authentication protocol”, that requirement is relaxed such that a service ticket acquired via Kerberos S4U logon is acceptable.  This means that the delegating service is able to delegate an account without direct involvement of the account owner.  While enabling the use of any protocol — often referred to as “protocol transition” — is nominally less secure for this reason, the difference is marginal due to the fact that the disabling of protocol transition provides no security promise.  Single-sign-on authentication between systems sharing a domain network is simply too ubiquitous to treat an inbound service ticket as proof of anything.  With or without protocol transition, the only secure way to limit the accounts that the service is permitted to delegate is to mark those accounts with the “account is sensitive and cannot be delegated” bit.


We’re working on modifying our documentation to reflect this change.

John Slack
Hyper-V Team PM

Hyper-V Hot Topics – July

   Hello everyone! July is behind us and that means it’s time for another edition of our Hyper-V Hot Topics Series! Again, as a reminder, this series focuses on interesting links and news regarding Hyper-V from throughout the previous month, that I’ve found to be helpful and useful. In addition to this, I also like to post my Hyper-V Monday Minute recording from throughout the last month as well. For those that aren’t aware, I put on, what I call the Hyper-V Monday Minute every Monday at 2:00 PM Eastern time where I talk about some topic from the Hyper-V world. I’ve used a number of different formats for this, but have now finalized it on Facebook Live. if your interested in subscribing to that segment, you can do so by liking the Altaro Software facebook page HERE. The idea here is to serve as your one-stop-shop information source for… Read More»

Read the post here: Hyper-V Hot Topics – July