Windows Server and Client Network Connection

Get PEAP with MSCHAP v2 working with NPS on Windows Server

Greg Lindsay — Thu, 08 Feb 2018 23:16:06 GMT

This post provides a summary of how PEAP with MSCHAP v2 works, and provides links to some topics that can help you deploy and troubleshoot PEAP authentication on a network. PEAP with certificate based authentication (PEAP with EAP-TLS) is not discussed. Background: PEAP with MSCHAP v2 is a certificate-based authentication method used to gain access to local and remote networks. With PEAP-MS-CHAPv2, the network access server provides proof of identity with a certificate, while the end user provides password-based credentials as proof of identity during the authentication process. This authentication method is commonly used for VPN connections and for networks using 802.1X enabled switches and access points. PEAP is an acronym for Protected Extensible Authentication Protocol. MSCHAP is an abbreviation for Microsoft Challenge Handshake Authentication Protocol.

How PEAP works:

There are five basic components required for the PEAP authentication method to work securely and correctly:

A client device: This can be a computer or mobile device.
A network access point:
- For VPN connections, this is a VPN server.
- For 802.1X based connections, this is a wireless access point or wired switch.
A RADIUS server: Microsoft's RADIUS server is called Network Policy Server (NPS).
A server certificate: A certificate must be installed on NPS that can be validated by the client device. You can use a Microsoft certification authority (CA) to issue this certificate, or you can purchase a certificate from a public CA such as VeriSign or Thawte.
A user database: The database must support MSCHAP v2. This is typically Active Directory.

For PEAP to work correctly, the following must be configured:

The network connection on the client computer must be configured to perform PEAP authentication.
The network access point must be configured to forward (aka pass-thru) authentication requests to the RADIUS server. This typically also requires that a shared secret is configured on the network access point which matches a corresponding shared secret on the RADIUS server.
A certificate with the server authentication purpose and correct subject alternative name must be installed on NPS. Note: This procedure must be completed prior to configuring PEAP on NPS (step 4 below).
NPS must be configured to perform PEAP authentication. The preferred method to configure NPS is using the scenario wizard in the NPS console. To use the wizard, click NPS in the console tree and then under Standard Configuration in the right-hand pane, select an item from the drop-down list that matches the type of network connection used by the client device (ex: VPN or wireless). When the configuration scenario is selected, click the corresponding Configure text that is displayed under the drop-down to launch the wizard.

Note: Server certificate validation can be disabled on client devices. However, in order for PEAP authentication to be secure, the client device must be configured to validate the server's certificate. This validation occurs when the client verifies that the certificate (which was installed in step 3 above) meets either of two requirements:

The certificate is found in the Enterprise NTAuth store.
The certificate is found in the client's Trusted Root Certification Authorities container, and it is marked as trusted.

If the certificate is found in the Trusted Root Certification Authorities container (but not NTAuth) and it is not marked as trusted, the client device receives a warning. The warning message is intended to provide the client an opportunity to mark the CA as trusted. The client should only receive this message once, provided the certificate is marked as trusted. If the certificate is not found in the Trusted Root Certification Authorities Container or the Enterprise NTAuth store, a PEAP error is generated and authentication fails.

References:

NPS reason codes

Server certificate requirements (14065/28365 in Windows Server 2003 retired content)

PEAP Overview

Certificate Requirements for PEAP and EAP

Always On VPN and DirectAccess Features Comparison

James McIllece — Tue, 17 Oct 2017 19:03:28 GMT

Windows Server and Windows 10 version 1709 are now released, and with these releases come some great new features for Virtual Private Networks in Windows 10. With Windows 10 VPN, you can create Always On VPN connections so that remote computers and devices are always connected to your organization network when they are turned on and Internet connected. You can use this new topic to gain an understanding of how Windows Server and Windows 10 VPN features map to DirectAccess features, including details about the increased flexibility provided by new VPN features. You can also use this topic for an overview of how Windows 10 VPN provides some advantages over DirectAccess deployments, such as the ability to support mobile device management and Azure Active Directory joined devices. For more information, see Always On VPN and DirectAccess Features Comparison.

RAS Gateway GRE Tunnel Throughput and Performance

James McIllece — Tue, 17 Oct 2017 18:46:44 GMT

With today's release of Windows Server, version 1709, comes a new topic about Remote Access Server (RAS) Gateway performance when configured with Generic Routing Encapsulation (GRE). The performance tests discussed in this new topic were completed on Hyper-V hosts and Virtual Machines (VMs) running Windows Server 1709 in a non-Software Defined Networking (SDN) based test environment. Note: The Windows Server version number 1709 means year 2017, month September, or 09. RAS Gateway is a software router and gateway that you can use in either single tenant mode or multitenant mode. This topic discusses a single tenant mode, high availability configuration with Failover Clustering. The GRE tunnel performance statistics that are presented in this topic are valid for RAS Gateway in both singele tenant and multitenant modes. For more information, see RAS Gateway GRE Tunnel Throughput and Performance.

What's New in SDN for Windows Server 1709

James McIllece — Tue, 17 Oct 2017 18:20:54 GMT

Windows Server version 1709 released today, October 17, 2017 - and with this release there is a new feature for Software Defined Networking (SDN) named Virtual Network Encryption. Note: The Windows Server version number 1709 means year 2017, month September, or 09. Virtual Network Encryption provides the ability for the virtual network traffic to be encrypted between Virtual Machines that communicate with each other within subnets that are marked as "Encryption Enabled." This feature utilizes Datagram Transport Layer Security (DTLS) on the virtual subnet to encrypt the packets. DTLS provides protection against eavesdropping, tampering and forgery by anyone with access to the physical network. For more information, see the following topics in the Windows Server technical library.

Windows Container Networking for Windows 10 and Windows Server 2016

James McIllece — Mon, 18 Sep 2017 20:42:07 GMT

Windows Container Networking allows you to create and manage networks for connecting container endpoints on both Windows 10 and Windows Server hosts by using standard industry tools and workflows. Windows container networks support multiple topologies, including private, flat-L2, and routed-L3. Also supported are overlays that you can create locally on the host by using Docker, Kubernetes, or Windows PowerShell through plugins that communicate with the Windows Host Networking Service (HNS). You can create and manage multi-node cluster networks through higher level orchestration systems by communicating through a local agent to each node’s HNS. For more information, see Windows Container Networking.

SDN Troubleshooting: UDP Communication and Changing Network Controller Cert

James McIllece — Fri, 25 Aug 2017 19:02:21 GMT

In his fourth guest appearance on this blog, Microsoft Senior Program Manager Anirban Paul provides the following advice on how to restore failed UDP communication and how to change the certificate used by Network Controller. This information might be useful for you if you've deployed Software Defined Networking (SDN) with Windows Server 2016 Datacenter. ***** With this blog post, I wanted to highlight a couple of issues that we have encountered recently with SDN customer deployments in Windows Server 2016. Issue 1: UDP Communication Isn't Working when Outbound NAT is Configured Customer had configured outbound NAT access for his virtual network through SCVMM (this internally uses SDN Software Load Balancer), so that machines in the virtual network could access the Internet. The customer noticed that TCP traffic to the Internet was working fine, but all UDP traffic was getting dropped. Moreover, this only happened when the Software Load Balancer MUX was on a different HyperV host than the tenant VM. On deeper analysis, it was revealed that the destination VM was rejecting the packet because the UDP checksum was incorrect. Further investigations revealed a physical NIC issue. The customer was using a physical NIC which was not certified for SDN with Windows Server 2016. The NIC was incorrectly marking the UdpChecksumFailed flag when the inner packet had a valid checksum. If you are planning to use SDN with Windows Server 2016 Datacenter, please ensure that you use certified NICs. You can verify whether a network adapter is or is not certified by checking the Windows Server Catalog. Click Software-Defined Data Center (SDDC) Premium to filter the Windows Server Catalog LAN card list. Issue 2: Changing the Network Controller Server Certificate A customer wanted to change the Network Controller server certificate used for communication with the Northbound clients. He was using self-signed certificates and wanted to move to Certificate Authority based certificates. After installing the new certificate on all the Network Controller nodes, he used the Set-NetworkController Powershell command to point Network Controller to the new certificate. Although the command succeeded, Network Controller communication with SCVMM stopped working. This is due to a bug in the product where the certificate binding is only changed on one Network Controller node (where the command was run) and is not updated on the other nodes. We are planning to release a fix soon. As a workaround, you need to manually change the certificate binding on the other Network Controller nodes. Process is as follows:

Install the new certificate in Personal store of LocalMachine account
Execute the Powershell command: Set-NetworkController -ServerCertificate
Retrieve the thumbprint of the new SSL certificate that you want to use with Network Controller.
Double click the certificate and click on Details, note the value of Thumbprint parameter. Remove any spaces in between.

The following illustration depicts the Thumbprint property of a certificate. On each Network Controller node, check the SSL binding by executing the following command from a command prompt: netsh http show sslcert If the result shows the thumbprint of the old certificate, change the binding by executing the following commands: netsh http delete sslcert ipport=0.0.0.0:443 netsh http add sslcert certhash= <thumbprint of the new certificate> appid=<application ID> ipport=0.0.0.0:443 certstorename=MY You can retrieve the appid from the output parameter Application ID of the netsh http show sslcert command. If the binding shows the thumbprint of the new certificate, no additional action is needed on that node. Additional Information Here are a few links to SDN topics to assist with your planning and deployment. If you want to assess your needs and environment for deploying SDN, see the topic Plan a Software Defined Network Infrastructure. If you want to deploy SDN using scripts, see Deploy a Software Defined Network Infrastructure Using Scripts. If you want to deploy SDN by using System Center Virtual Machine Manager, see Set up a Software Defined Network (SDN) infrastructure in the VMM fabric. If you have any questions or feedback about SDN, send an email to sdn_feedback@microsoft.com.

Guarded Fabric and Shielded Virtual Machines in Windows Server 2016

James McIllece — Fri, 18 Aug 2017 20:08:59 GMT

With the popularity of Hyper-V and Virtual Machines (VMs) deployed on virtual networks, it's important to ensure the security of the VMs that are running in your environment. As a Cloud Service Provider (CSP) or Enterprise private cloud administrator, you can use Guarded Fabric in Windows Server 2016 to provide a more secure environment for VMs. A guarded fabric consists of the following.

One Host Guardian Service (HGS) - which typically includes a cluster of three nodes
One or more guarded Hyper-V hosts
A set of shielded VMs.

For a great Guarded Fabric Deployment video that provides an overview of HGS, guarded Hyper-V hosts, and shielded VMs, see the Windows Server 2016 library topic Deploying the Host Guardian Service for guarded hosts and shielded VMs. For more information, see the Windows Server 2016 library section Guarded fabric and shielded VMs.

Central Management of Network Policies for All of Your Network Access Servers With NPS

James McIllece — Mon, 14 Aug 2017 18:04:05 GMT

Do you need to deploy a bunch of 802.1X wireless access points for your organization? Or maybe 802.1X-capable Ethernet switches? How about Remote Access VPN servers on physical computers or virtual machines (VMs)? Or maybe you're using dial-up servers? In all of these cases, you can use Network Policy Server (NPS) in Windows Server 2016 to create and centrally manage network policies instead of manually configuring policies at each individual network access server. Just ensure that your network access servers support the Remote Authentication Dial In User Service (RADIUS) protocol. After you install NPS in Windows Server 2016, you can configure NPS as a RADIUS server. As a RADIUS server, NPS can process connection requests that it receives from RADIUS Clients, like your network access servers. Notes

Client computers and user devices like tablets and smart phones are not RADIUS Clients. Network access servers are RADIUS Clients.
The NPS online documentation is now available in the Windows Server 2016 Networking Technical Library, at: Network Policy Server (NPS)

When NPS as a RADIUS Server processes connection requests, it performs authentication - which is verifying the identity of the user or computer that wants to connect - by validating credentials against the Active Directory user and computer accounts database. NPS also performs authorization - ensuring that the user or computer has permission to connect to the network, based on the policies that you define. And NPS performs accounting, logging the data that you specify to either a log file or a SQL Server database. NPS can also act as a RADIUS Proxy Server, forwarding requests to Remote RADIUS Server Groups that you define. This is useful for large Enterprise networks that include multiple domains, because you can configure the proxy servers to forward connection requests to the appropriate domain for processing by NPS servers in that domain. The following illustration shows NPS as a RADIUS Proxy between RADIUS Clients and RADIUS Servers. (Click image to enlarge.) Windows Server Editions and NPS NPS provides different functionality depending on the edition of Windows Server that you install. Windows Server 2016 Datacenter Edition With NPS in Windows Server 2016 Datacenter, you can configure an unlimited number of RADIUS clients and remote RADIUS server groups. In addition, you can configure RADIUS clients by specifying an IP address range. Windows Server 2016 Standard Edition With NPS in Windows Server 2016 Standard, you can configure a maximum of 50 RADIUS clients and a maximum of 2 remote RADIUS server groups. You can define a RADIUS client by using a fully qualified domain name or an IP address, but you cannot define groups of RADIUS clients by specifying an IP address range. If the fully qualified domain name of a RADIUS client resolves to multiple IP addresses, the NPS server uses the first IP address returned in the Domain Name System (DNS) query. Additional Information Here is some important additional information you need to know about NPS and NPS documentation in Windows Server 2016 and previous operating system versions:

Network Access Protection (NAP), Health Registration Authority (HRA), and Host Credential Authorization Protocol (HCAP) were deprecated in Windows Server 2012 R2, and are not available in Windows Server 2016. If you have a NAP deployment using operating systems earlier than Windows Server 2016, you cannot migrate your NAP deployment to Windows Server 2016 - but you can use Windows Server 2016 as a RADIUS server and RADIUS proxy.
If you are running Network Policy Server in Windows Server 2016, you can download the Network Policy Server (NPS) Technical Reference for Windows Server 2016 from TechNet Gallery.
If you are running Network Policy Server in Windows Server 2008 through Windows Server 2012 R2, you can download the Network Policy Server (NPS) Technical Reference for WS08-WS12 R2 from TechNet Gallery.

Manage Network Bandwidth Across Active Directory Infrastructure with QoS Policy

James McIllece — Fri, 21 Jul 2017 16:22:08 GMT

You can use QoS Policy as a central point of network bandwidth management across your entire Active Directory infrastructure by creating QoS profiles, whose settings are distributed with Group Policy. Policy-based QoS is the network bandwidth management tool that provides you with network control - based on applications, users, and computers. Policy-based QoS takes advantage of your existing management infrastructure, because Policy-based QoS is built into Group Policy. You can apply QoS policies to a user login session or a computer as part of a Group Policy object (GPO) that you have linked to an Active Directory container, such as a domain, site, or organizational unit (OU). QoS traffic management occurs below the application layer, which means that your existing applications do not need to be modified to benefit from the advantages that are provided by QoS policies. QoS Policy is supported in Windows Server operating systems from 2008 through Windows Server 2016. For more information, see the Windows Server 2016 Technical Library document set Quality of Service (QoS) Policy.

Deploy Always On VPN with Windows 10 Clients and Windows Server 2016

James McIllece — Mon, 10 Jul 2017 23:21:50 GMT

One of the new features of the Windows 10 Virtual Private Network (VPN) client is the ability to sustain an "always on" VPN connection to your organization network. The always on feature lets you remotely manage VPN clients, because if the remote computer is turned on and Internet connected, it's available to manage. This feature is also more convenient for users, who don't have to connect and disconnect their VPN connections manually. To celebrate this new feature, there is a new Windows Server 2016 Remote Access deployment guide that is now live on the web. You can use this guide to deploy Always On Virtual Private Network (VPN) connections for remote employees by using Remote Access in Windows Server 2016 and Always On VPN profiles for Windows 10 client computers. For more information, see the guide at the following locations.

Remote Access Always On VPN Deployment Guide for Windows Server 2016 and Windows 10 on the Web.
Always On VPN Deployment Guide for download in Word format on TechNet Gallery.