Secure the Network Controller

Applies to: Windows Server 2019, Windows Server 2016

In this topic, you learn how to configure security for all communication between Network Controller and other software and devices.

The communication paths that you can secure include Northbound communication on the management plane, cluster communication between Network Controller virtual machines (VMs) in a cluster, and Southbound communication on the data plane.

Northbound Communication. Network Controller communicates on the management plane with SDN-capable management software like Windows PowerShell and System Center Virtual Machine Manager (SCVMM). These management tools provide you with the ability to define network policy and to create a goal state for the network, against which you can compare the actual network configuration to bring the actual configuration into parity with the goal state.

Network Controller Cluster Communication. When you configure three or more VMs as Network Controller cluster nodes, these nodes communicate with each other. This communication might be related to synchronizing and replication of data across nodes, or specific communication between Network Controller services.

Southbound Communication. Network Controller communicates on the data plane with SDN infrastructure and other devices like software load balancers, gateways, and host machines. You can use Network Controller to configure and manage these southbound devices so that they maintain the goal state that you have configured for the network.

Northbound Communication

Network Controller supports authentication, authorization, and encryption for Northbound communication. The following sections provide information on how to configure these security settings.

Authentication

When you configure authentication for Network Controller Northbound communication, you allow Network Controller cluster nodes and management clients to verify the identity of the device with which they are communicating.

Network Controller supports the following three modes of authentication between management clients and Network Controller nodes.

If you are deploying Network Controller with System Center Virtual Machine Manager, only Kerberos mode is supported.

Kerberos. Use Kerberos authentication when joining both the management client and all Network Controller cluster nodes to an Active Directory domain. The Active Directory domain must have domain accounts used for authentication.

X509. Use X509 for certificate-based authentication for management clients not joined to an Active Directory domain. You must enroll certificates to all Network Controller cluster nodes and management clients. Also, all nodes and management clients must trust each others’ certificates.

None. Use None for testing purposes in a test environment and, therefore, not recommended for use in a production environment. When you choose this mode, there is no authentication performed between nodes and management clients.

You can configure the Authentication mode for Northbound communication by using the Windows PowerShell command Install-NetworkController with the ClientAuthentication parameter.

Authorization

When you configure authorization for Network Controller Northbound communication, you allow Network Controller cluster nodes and management clients to verify that the device with which they are communicating is trusted and has permission to participate in the communication.

Use the following authorization methods for each of the authentication modes supported by Network Controller.

Kerberos. When you are using the Kerberos authentication method, you define the users and computers authorized to communicate with Network Controller by creating a security group in Active Directory, and then adding the authorized users and computers to the group. You can configure Network Controller to use the security group for authorization by using the ClientSecurityGroup parameter of the Install-NetworkController Windows PowerShell command. After installing the Network Controller, you can change the security group by using the Set-NetworkController command with the parameter -ClientSecurityGroup. If using SCVMM, you must provide the security group as a parameter during deployment.

X509. When you are using the X509 authentication method, Network Controller only accepts requests from management clients whose certificate thumbprints are known to Network Controller. You can configure these thumbprints by using the ClientCertificateThumbprint parameter of the Install-NetworkController Windows PowerShell command. You can add other client thumbprints at any time by using the Set-NetworkController command.

None. When you choose this mode, there is no authentication performed between nodes and management clients. Use None for testing purposes in a test environment and, therefore, not recommended for use in a production environment.

Encryption

Northbound communication uses Secure Sockets Layer (SSL) to create an encrypted channel between management clients and Network Controller nodes. SSL encryption for Northbound communication includes the following requirements:

All Network Controller nodes must have an identical certificate that includes the Server Authentication and Client Authentication purposes in Enhanced Key Usage (EKU) extensions.

The URI used by management clients to communicate with Network Controller must be the certificate subject name. The certificate subject name must contain either the Fully Qualified Domain Name (FQDN) or the IP address of the Network Controller REST Endpoint.

If Network Controller nodes are on different subnets, the subject name of their certificates must be the same as the value used for the RestName parameter in the Install-NetworkController Windows PowerShell command.

All of the management clients must trust the SSL certificate.

SSL Certificate Enrollment and Configuration

You must manually enroll the SSL certificate on Network Controller nodes.

After the certificate is enrolled, you can configure Network Controller to use the certificate with the -ServerCertificate parameter of the Install-NetworkController Windows PowerShell command. If you have already installed Network Controller, you can update the configuration at any time by using the Set-NetworkController command.

If you are using SCVMM, you must add the certificate as a library resource. For more information, see Set up an SDN network controller in the VMM fabric.

Network Controller Cluster Communication

Network Controller supports authentication, authorization, and encryption for communication between Network Controller nodes. The communication is over Windows Communication Foundation (WCF) and TCP.

You can configure this mode with the ClusterAuthentication parameter of the Install-NetworkControllerCluster Windows PowerShell command.

Authentication

When you configure authentication for Network Controller Cluster communication, you allow Network Controller cluster nodes to verify the identity of the other nodes with which they are communicating.

Network Controller supports the following three modes of authentication between Network Controller nodes.

If you deploy Network Controller by using SCVMM, only Kerberos mode is supported.

Kerberos. You can use Kerberos authentication when all Network Controller cluster nodes are joined to an Active Directory domain, with domain accounts used for authentication.

X509. X509 is certificate-based authentication. You can use X509 authentication when Network Controller cluster nodes are not joined to an Active Directory domain. To use X509, you must enroll certificates to all Network Controller cluster nodes, and all nodes must trust the certificates. In addition, the subject name of the certificate that is enrolled on each node must be the same as the DNS name of the node.

None. When you choose this mode, there is no authentication performed between Network Controller nodes. This mode is provided only for testing purposes, and is not recommended for use in a production environment.

Authorization

When you configure authorization for Network Controller Cluster communication, you allow Network Controller cluster nodes to verify that the nodes with which they are communicating are trusted and have permission to participate in the communication.

For each of the authentication modes supported by Network Controller, the following authorization methods are used.

Kerberos. Network Controller nodes accept communication requests only from other Network Controller machine accounts. You can configure these accounts when you deploy Network Controller by using the Name parameter of the New-NetworkControllerNodeObject Windows PowerShell command.

X509. Network Controller nodes accept communication requests only from other Network Controller machine accounts. You can configure these accounts when you deploy Network Controller by using the Name parameter of the New-NetworkControllerNodeObject Windows PowerShell command.

None. When you choose this mode, there is no authorization performed between Network Controller nodes. This mode is provided only for testing purposes, and is not recommended for use in a production environment.

Encryption

Communication between Network Controller nodes is encrypted using WCF Transport level encryption. This form of encryption is used when the authentication and authorization methods are either Kerberos or X509 certificates. For more information, see the following topics.

Southbound Communication

Network Controller interacts with different types of devices for Southbound communication. These interactions use different protocols. Because of this, there are different requirements for authentication, authorization, and encryption depending on the type of device and protocol used by Network Controller to communicate with the device.

The following table provides information about Network Controller interaction with different southbound devices.

Southbound device/service	Protocol	Authentication used
Software Load Balancer	WCF (MUX), TCP (Host)	Certificates
Firewall	OVSDB	Certificates
Gateway	WinRM	Kerberos, Certificates
Virtual Networking	OVSDB, WCF	Certificates
User defined routing	OVSDB	Certificates

For each of these protocols, the communication mechanism is described in the following section.

Authentication

For Southbound communication, the following protocols and authentication methods are used.

WCF/TCP/OVSDB. For these protocols, authentication is performed by using X509 certificates. Both Network Controller and the peer Software Load Balancing (SLB) Multiplexer (MUX)/host machines present their certificates to each other for mutual authentication. Each certificate must be trusted by the remote peer.

For southbound authentication, you can use the same SSL certificate that is configured for encrypting the communication with the Northbound clients. You must also configure a certificate on the SLB MUX and host devices. The certificate subject name must be same as the DNS name of the device.

WinRM. For this protocol, authentication is performed by using Kerberos (for domain joined machines) and by using certificates (for non-domain joined machines).

Authorization

For Southbound communication, the following protocols and authorization methods are used.

WCF/TCP. For these protocols, authorization is based on the subject name of the peer entity. Network Controller stores the peer device DNS name, and uses it for authorization. This DNS name must match the subject name of the device in the certificate. Likewise, Network Controller certificate must match the Network Controller DNS name stored on the peer device.

WinRM. If Kerberos is being used, the WinRM client account must be present in a predefined group in Active Directory or in the Local Administrators group on the server. If certificates are being used, the client presents a certificate to the server that the server authorizes using the subject name/issuer, and the server uses a mapped user account to perform authentication.

OVSDB. There is no authorization provided for this protocol.

Encryption

For Southbound communication, the following encryption methods are used for protocols.

WCF/TCP/OVSDB. For these protocols, encryption is performed using the certificate that is enrolled on the client or server.

WinRM. WinRM traffic is encrypted by default using Kerberos security support provider (SSP). You can configure Additional encryption, in the form of SSL, on the WinRM server.

Network security: Allow Local System to use computer identity for NTLM

Applies to

Describes the location, values, policy management, and security considerations for the Network security: Allow Local System to use computer identity for NTLM security policy setting.

Reference

When services connect to devices that are running versions of the Windows operating system earlier than WindowsВ Vista or Windows ServerВ 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will authenticate anonymously. In Windows ServerВ 2008В R2 and WindowsВ 7 and later, if a service connects to a computer running Windows ServerВ 2008 or WindowsВ Vista, the system service uses the computer identity.

When a service connects with the device identity, signing and encryption are supported to provide data protection. (When a service connects anonymously, a system-generated session key is created, which provides no protection, but it allows applications to sign and encrypt data without errors. Anonymous authentication uses a NULL session, which is a session with a server in which no user authentication is performed; and therefore, anonymous access is allowed.)

Possible values

Setting	Windows ServerВ 2008 and WindowsВ Vista	At least WindowsВ ServerВ 2008 R2 and WindowsВ 7
Enabled	Services running as Local System that use Negotiate will use the computer identity. This value might cause some authentication requests between Windows operating systems to fail and log an error.	Services running as Local System that use Negotiate will use the computer identity. This is the default behavior.
Disabled	Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously. This is the default behavior.	Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.
Neither	Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.	Services running as Local System that use Negotiate will use the computer identity. This might cause some authentication requests between Windows operating systems to fail and log an error.

Location

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default values

The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.

Server type or Group Policy object (GPO)	Default value
Default domain policy	Not defined
Default domain controller policy	Not defined
Stand-alone server default settings	Not defined
Domain controller effective default settings	Not applicable
Member server effective default settings	Not applicable
Effective GPO default settings on client computers	Not defined

Policy management

This section describes features and tools that are available to help you manage this policy.

Restart requirement

None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.

Policy conflict considerations

The policy Network security: Allow LocalSystem NULL session fallback, if enabled, will allow NTLM or Kerberos authentication to be used when a system service attempts authentication. This will increase the success of interoperability at the expense of security.

The anonymous authentication behavior is different for Windows ServerВ 2008 and WindowsВ Vista than later versions of Windows. Configuring and applying this policy setting on those systems might not produce the same results.

Group Policy

This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.

Security considerations

This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.

Vulnerability

When a service connects to computers running versions of Windows earlier than WindowsВ Vista or Windows ServerВ 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will use NULL session. In Windows ServerВ 2008В R2 and WindowsВ 7 and later, if a service connects to a computer running Windows ServerВ 2008 or WindowsВ Vista, the system service uses the computer identity.

When a service connects with the computer identity, signing and encryption are supported to provide data protection. When a service connects with a NULL session, a system-generated session key is created, which provides no protection, but it allows applications to sign and encrypt data without errors.

Countermeasure

You can configure the Network security: Allow Local System to use computer identity for NTLM security policy setting to allow Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.

Potential impact

If you do not configure this policy setting on Windows ServerВ 2008 and WindowsВ Vista, services running as Local System that use the default credentials will use the NULL session and revert to NTLM authentication for Windows operating systems earlier than WindowsВ Vista or Windows ServerВ 2008. Beginning with Windows ServerВ 2008В R2 and WindowsВ 7, the system allows Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.