Kerberos with Service Principal Name (SPN)
Applies to: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versions 21H2 and 20H2
Network Controller supports multiple authentication methods for communication with management clients. You can use Kerberos based authentication, X509 certificate-based authentication. You also have the option to use no authentication for test deployments.
System Center Virtual Machine Manager uses Kerberos-based authentication. If you are using Kerberos-based authentication, you must configure a Service Principal Name (SPN) for Network Controller in Active Directory. The SPN is a unique identifier for the Network Controller service instance, which is used by Kerberos authentication to associate a service instance with a service login account. For more details, see Service Principal Names.
Configure Service Principal Names (SPN)
The Network Controller automatically configures the SPN. All you need to do is to provide permissions for the Network Controller machines to register and modify the SPN.
On the Domain Controller machine, start Active Directory Users and Computers.
Select View > Advanced.
Under Computers, locate one of the Network Controller machine accounts, and then right-click and select Properties.
Select the Security tab and click Advanced.
In the list, if all the Network Controller machine accounts or a security group having all the Network Controller machine accounts is not listed, click Add to add it.
For each Network Controller machine account or a single security group containing the Network Controller machine accounts:
a. Select the account or group and click Edit.
b. Under Permissions select Validate Write servicePrincipalName.
d. Scroll down and under Properties select:
e. Click OK twice.
Repeat steps 3 - 6 for each Network Controller machine.
Close Active Directory Users and Computers.
Failure to provide permissions for SPN registration/modification
On a NEW Windows Server 2019 deployment, if you chose Kerberos for REST client authentication and don't grant permission for Network Controller nodes to register or modify the SPN, REST operations on Network Controller fails preventing you from managing the SDN.
For an upgrade from Windows Server 2016 to Windows Server 2019, and you chose Kerberos for REST client authentication, REST operations do not get blocked, ensuring transparency for existing production deployments.
If SPN is not registered, REST client authentication uses NTLM, which is less secure. You also get a critical event in the Admin channel of NetworkController-Framework event channel asking you to provide permissions to the Network Controller nodes to register SPN. Once you provide permission, Network Controller registers the SPN automatically, and all client operations use Kerberos.
Typically, you can configure Network Controller to use an IP address or DNS name for REST-based operations. However, when you configure Kerberos, you cannot use an IP address for REST queries to Network Controller. For example, you can use <https://networkcontroller.consotso.com>, but you cannot use <https://126.96.36.199>. Service Principal Names cannot function if IP addresses are used.
If you were using IP address for REST operations along with Kerberos authentication in Windows Server 2016, the actual communication would have been over NTLM authentication. In such a deployment, once you upgrade to Windows Server 2019, you continue to use NTLM-based authentication. To move to Kerberos-based authentication, you must use Network Controller DNS name for REST operations and provide permission for Network Controller nodes to register SPN.
Submit and view feedback for