Understanding Kerberos and constraint Delegation in Hyper-V

While working on customer cases, I get to get confuse with the used Terminology, especially in the case of Shared Nothing Live Migration. I tried to understand the basics of it and decided to pen down all relevant information I gathered while browsing the internet and testing it in my lab.

We will try to touch the basics of Kerberos in terms of Hyper-V.

These blogs are a great place to start, if you are beginer like me

Understanding Active Directory for Beginners – Part 1
Active Directory: Concepts Part 1
Active Directory: Concepts Part 2
Active Directory: Concepts Part 3

To understand basics of Kerberos, these blogs may come handy.

Kerberos for the Busy Admin
Understanding Kerberos Double Hop

Kerberos Delegation aka Double-hop wrokflow

Principal Names:

1) User Principal Name (UPN)
– Only user accounts have UPN defined on thier account.
– UPN is derived from the combining of the two fields listed for “User logon name”.
– It should be unique across the entire forest otherwise when the KDC goes to look up the Users Account via UPN it will get back more than one account and cause authentication failures for all users that have the same UPN.
– The UPN of an AD object is an attribute of the object, and can only hold a single value. The attribute name is userPrincipalName. An example of a UPN is:

Get-ADUser -Filter * | findstr -i scvmmadmin
SamAccountName    : scvmmadmin
UserPrincipalName : scvmmadmin@xxxx.xxxx
DistinguishedName : CN=Svc-SCVMMAdmin,OU=2016,DC=xxxxx,DC=xxxx
GivenName         : Svc-SCVMMAdmin
Name              : Svc-SCVMMAdmin
SamAccountName    : Svc-SCVMMAdmin
UserPrincipalName : Svc-SCVMMAdmin@xxxx.xxxx

– Computer Object doesn’t have UPN Entry

    
> Get-ADComputer -Filter * | findstr -i scvmm2016
DistinguishedName : CN=SCVMM2016,OU=2016,DC=xxxxx,DC=xxxx
DNSHostName       : scvmm2016.xxxxx.xxx
Name              : SCVMM2016
SamAccountName    : SCVMM2016$

2) Service Principal Name (SPN)

– SPN MUST be unique across the entire Active Directory forest, and can be assigned to either User accounts or Computer accounts.
– Only computer accounts automatically have Service Principal Names defined.
– Service Principal Names define what services run under the accounts security context.

     File server / CIFS (Common Internet File System), 
     WSMAN
     MSServerClusterMgmtAPI/
     Hyper-V Replica Service
     TERMSRV
     Microsoft Virtual System Migration Service
     Microsoft Virtual Console Service
     RestrictedKrbHost
     HOST

– SPN can be defined on user accounts when a Service or application is running under that users Security context.
– Typically these types of user accounts are known as “Service Accounts”
* When SQL Server Service is using a user account or “Service Account” instead of the default of “LocalSystem”.
* When an IIS Web Application Pool is running as a specified user account rather than as the default of “Network Service”.

– Service Principal Names MUST be unique throughout the entire Active Directory forest.

Note : LDAP query for all objects with SPN in AD : LDP & LDIFDE
       SPNs are registered on a given object : ADSIEdit, or SetSPN

Kerberos tickets:

1) KDC (Key Distribution Center):
– Should be running on a DC
– The service name is “Kerberos Key Distribution Center”.
– KDC is the service that is responsible for authenticating users when Kerberos is used.

The KDC implements two server components.

Authentication Server (AS), and Ticket Granting Server (TGS). There are only two different types for tickets that the KDC issues.

  • Ticket Granting Ticket (TGT)
  • Service tickets from the Ticket Granting Server.

Please refer blog Kerberos for the Busy Admin, it has some great fundamentals available for steps to be followed.

How to enable Kerberos event logging

Klist

A Good Read

Set up hosts for live migration without Failover Clustering

Note : {{Delegation tab}} — is only going to be there is SPN is there.

  • This has to be done for source and Destination Hyper-V host, so let’s say I have 3 hyperv host named gogo-2, gogo-3, gogo-4
  • On Each host, let’s set following entries.

– To move virtual machine storage, select cifs.
– To move virtual machines, select Microsoft Virtual System Migration Service

  • On the delegation tab, select Trust this computer for delegation to the specified services only and then select Use any authentication protocol.
  • Check Names to verify it, and then click OK.

Steps to configure Host specific LM configuration using PS.

PS C:\> Enable-VMMigration
PS C:\> Set-VMMigrationNetwork _____________
PS C:\> Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos
PS C:\>Set-VMHost -VirtualMachineMigrationPerformanceOption SMBTransport

Delegation Functionality

  • The Kerberos protocol includes a mechanism called delegation of authentication. When this mechanism is used, the client (the requesting service) delegates authentication to a second service by informing the KDC that the second service is authorized to act on behalf of a specified Kerberos security principal, such as a user that has an AD directory service account. The second service can then delegate authentication to a third service.
  • The ms-DS-Allowed-To-Delegate-To attribute is added to service accounts to help enforce constrained delegation.
  • The ms-DS-Allowed-To-Delegate-To attribute lists the service principal names (SPNs) of other service accounts that a given service account is allowed to delegate to. When a Windows Server KDC processes a service ticket request via the constrained delegation extension, it will verify that the target service account is one that is listed in the ms-DS-Allowed-To-Delegate-To attribute.

Configuring Kerberos Constrained Delegation for Hyper-V Management

So, let’s take an example (Taken from above mentioned blog)

  1. Vmhost1 and vmhost2 are the Hyper-V hosts, fhost1 is the file server, mgmt1 is the ‘management server’ and they are part of the same domain.
  2. Configuring Hyper-V from mgmt1 I don’t run into any issues. I am remotely managing Hyper-V using my domain credentials. As long as my management operations stay ‘inside’ vmhost1 then there are no authentication issues.
  3. When the operation involves for example vmhost2, authentication fails and messages like ‘general access denied’ and ‘no credentials are available in the security package’ occur. Despite the fact that I am logged on as a domain administrator on mgmt1, I cannot perform any actions that involve vmhost2 when managing vmhost1. As you now know, KCD has not been configured yet.
  4. For this to succeed, KCD has to be configured on vmhost1. To be more precise, vmhost1 needs to be trusted for delegation to specific services on vmhost2. These services are:
 CIFS (SMB)
 Microsoft Virtual System Migration Service (migration capability of the  Virtual Machine Management Service.)
  • Now my ISO’s and VM data is hosted on SMBserver named fhost1, so I need                to entrust fhost1 to be trusted for delegation on vmhost1 for CIFS.
  • So similar steps need to configured for vmhost2 too.

————————————————————————-

How to validate msDS-AllowedToDelegateTo Attribute using powershell. {{AD Module needs to be there}}

Get-ADComputer -Filter * | fl name | findstr -i gogo
Get-ADComputer -Filter * -Properties msds-allowedtodelegateTo, TrustedforDelegation | Select Name, TrustedForDelegation, msDS-AllowedToDelegateTo

For Instance, I need to validate if gogo-3 host has constraint delegation configured, I can see that Gogo-3 has KCD configured for CIFS and Migration service against SPN of Gogo-4, Gogo-2.

Get-ADcomputer gogo-3 -Properties msDS-AllowedToDelegateTo, TrustedforDelegation | select Name -ExpandProperty  msds-allowedtodelegateTo | fl *
cifs/GOGO-4
Microsoft Virtual System Migration Service/GOGO-4
cifs/GOGO-3
Microsoft Virtual System Migration Service/GOGO-3
cifs/GOGO-2
Microsoft Virtual System Migration Service/GOGO-2

SMB3 Secure Dialect Negotiation
SMB3 PowerShell changes in Windows Server 2012 R2: SMB Delegation

On Windows Server 2016

  • “use any authentication protocol” instead of “use Kerberos only.”
    Reason :In Server 2016, MS shifted from using the Hyper-V WMI Provider *v1* over *DCOM* to the Hyper-V WMI Provider *v2* over *WinRM*.
WinRM runs as NETWORK SERVICE, while the Virtual Machine Management Service (VMMS) runs as SYSTEM.
The way WinRM does inbound authentication stores the nice, forwardable Kerberos ticket in a location that is unavailable to NETWORK SERVICE.

Configuring Constraint Delegation via Script

Live Migration via Constrained Delegation with Kerberos in Windows Server 2016


Advertisements