CHAPTER 14
Network Policy and Access Services, Routing and Remote Access and DirectAccess
IN THIS CHAPTER
Deploying Network Policy and Access Services
Enforcing Policy Settings with a Network Policy Server
Verifying the Client-Side Configuration
Deploying a Virtual Private Network Using RRAS
Deploying DirectAccess Services
The goal of an NPS is to enforce remote or VPN-based network connection policy settings defined by the administrator. For example: You can configure NPS to block remote clients from connecting if they try to connect at certain times of the day, or block clients if their machines are not members of certain groups, or block client if they demonstrate certain IP settings.
This chapter thus covers the Network Policy Server and Access Services and the Network Policy Server (NPS) role.
In earlier versions of Windows Server, the NPS role service handled NAP functions. This is no longer the case because NAP was discontinued for Windows Server 20216, going forward. The NPS role now only provides services for RADIUS clients and servers and network connection policy enforcement.
In Windows Server 2016, you can also deploy DirectAccess on the same server. DirectAccess is for supported clients. So between both RRAS and DirectAccess, you can provide connectivity to both supported and unsupported clients. DirectAccess clients include Windows 10 Enterprise, 10 Enterprise 2015 Long Term Servicing Branch (LTSB), Windows 8 Enterprise, Windows 7 Ultimate, and Windows 7 Enterprise.
In Windows Server 2008 R2 and Windows Server 2008, Network Policy and Access Services included the Routing and Remote Access Service (RRAS) role service, but since Windows Server 2012, Remote Access became a separate role just named RRAS.
Installing a Network Policy Server
Installation of the Network Policy and Access Services role installs the Network Policy Server component. To install, follow these steps:
1. Open Server Manager.
2. Click Manage and select Add Roles and Features.
3. On the Before You Begin page, click Next.
4. Select Role-Based or Feature-Based Installation and click Next to continue. On the Select Destination Server page, select a server from the server pool.
5. On the Add Features modal dial, check the option to add the features. Click Add Features to continue.
7. On the Select Role Services page shown in Figure 14.1, click Next to continue.
Adding the Health Registration Authority role service requires the IIS Web Server role to be installed on the server as well as a valid certificate (and potentially the Active Directory Certificate Services role). Selecting the role service might prompt you to install these services, as well.
8. On the Confirm Installation page, choose whether to reboot the server automatically and select Install.
9. Click Close when the wizard completes.
Understanding RADIUS Support on a Network Policy Server
As previously mentioned, installing the Network Policy and Access Services role adds support for the RADIUS protocol, an industry-standard authentication mechanism supported by a wide range of clients.
NOTE
The NPS role in Windows Server 2016 was once the legacy Internet Authentication Service (IAS) role. The old IAS role provided simple RADIUS authentication support to Active Directory sources.
RADIUS authentication allows for Active Directory users to be authenticated using RADIUS authentication, rather than AD DS authentication. This is commonly used in scenarios where VPN access requires RADIUS authentication or when other devices cannot use AD-based authentication.
Deploying a Virtual Private Network Using RRAS
A common method of securing information sent across unsecured networks is to create a virtual private network (VPN), which is effectively a connection between two private nodes or networks that is secured and encrypted to prevent unauthorized snooping of the traffic between the two connections. From the client perspective, a VPN looks and feels just like a normal network connection between different segments on a network—hence the term virtual private network.
Data that is sent across a VPN is encapsulated, or wrapped, in a header that indicates its destination. The information in the packet is then encrypted to secure its contents. The encrypted packets are then sent across the network to the destination server, using what is known as a VPN tunnel.
The Windows Server 2016 Remote Access role allows for the creation of VPNs and integrates with the NPS role to provide for validation of clients before creating a VPN session.
VPN support in Windows Server 2016 provides for simple VPN tunnels to be created. For more complex scenarios where specific rules need to be created and application-layer filtering of the VPN traffic is needed, look at Microsoft’s Forefront Edge line of products, which includes the Forefront Threat Management Gateway and the Forefront Unified Access Gateway products.
Exploring VPN Tunnels
The connection made by VPN clients across an unsecured network is known as a VPN tunnel. It is named as such because of the way it “tunnels” underneath the regular traffic of the unsecured network.
VPN tunnels are logically established on a point-to-point basis, but can be used to connect two private networks into a common network infrastructure. In many cases, for example, a VPN tunnel serves as a virtual wide-area network (WAN) link between two physical locations in an organization, all while sending the private information across the Internet. VPN tunnels are also widely used by remote users who log on to the Internet from multiple locations and establish VPN tunnels to a centralized VPN server in the organization’s home office. These reasons make VPN solutions a valuable asset for organizations, and one that can be easily established with the technologies available in Windows Server 2016.
NOTE
VPN tunnels can either be voluntary or compulsory. In short, voluntary VPN tunnels are created when a client, usually out somewhere on the Internet, asks for a VPN tunnel to be established. Compulsory VPN tunnels are automatically created for clients from specific locations on the unsecured network, and are less common in real-life situations than are voluntary tunnels.
Tunneling Protocols
The tunneling protocol is the specific technology that defines how data is encapsulated, transmitted, and unencapsulated across a VPN connection. Varying implementations of tunneling protocols exist and correspond with different layers of the Open System Interconnection (OSI) standards-based reference model. The OSI model is composed of seven layers, and VPN tunneling protocols use either Layer 2 or Layer 3 as their unit of exchange. Layer 2, a more fundamental network layer, uses a frame as the unit of exchange, and Layer 3 protocols use a packet as a unit of exchange.
The most common Layer 2 VPN protocols are the Point-to-Point Tunneling Protocol (PPTP) and the Layer 2 Tunneling Protocol (L2TP), both of which are fully supported protocols in Windows Server 2016.
PPTP and L2TP Protocols
Both PPTP and L2TP are based on the well-defined Point-to-Point Protocol (PPP) and are consequently accepted and widely used in VPN implementations. L2TP is the preferred protocol for use with VPNs in Windows Server 2016 because it incorporates the best of PPTP, with a technology known as Layer 2 Forwarding. L2TP allows for the encapsulation of data over multiple network protocols, including IP, and can be used to tunnel over the Internet. The payload, or data to be transmitted, of each L2TP frame can be compressed, as well as encrypted, to save network bandwidth.
Both PPTP and L2TP build on a suite of useful functionality that was introduced in PPP, such as user authentication, data compression and encryption, and token card support. These features, which have all been ported over to the newer implementations, provide for a rich set of VPN functionality.
L2TP/IPSec Secure Protocol
Windows Server 2016 uses an additional layer of encryption and security by utilizing IP Security (IPsec), a Layer 3 encryption protocol, in concert with L2TP in what is known, not surprisingly, as L2TP/IPsec. IPsec allows for the encryption of the L2TP header and trailer information, which is normally sent in clear text. This also has the added advantage of dual-encrypting the payload, adding an additional level of security into the mix.
L2TP/IPSec has some distinct advantages over standard L2TP, namely the following:
L2TP/IPSec allows for data authentication on a packet level, allowing for verification that the payload was not modified in transit, as well as the data confidentiality that is provided by L2TP.
Dual-authentication mechanisms stipulate that both computer-level and user-level authentication must take place with L2TP/IPSec.
L2TP packets intercepted during the initial user-level authentication cannot be copied for use in offline dictionary attacks to determine the L2TP key because IPSec encrypts this procedure.
An L2TP/IPSec packet contains multiple, encrypted header information and the payload itself is deeply nested within the structure. This allows for a great deal of transport-level security on the packet itself.
Enabling VPN Functionality on a Remote-Access Server
By installing the Remote Access role on the server, the ability to allow VPN connections to/from the server is enabled. The following type of VPN connections can be created:
VPN gateway for clients—The most common scenario, this involves the RRAS server being the gateway into a network for VPN clients. This scenario requires the server to have two network cards installed.
Site-to-site VPN—In this scenario, the RRAS server creates a VPN tunnel between another RRAS server in a remote site, allowing for traffic to pass unimpeded between the networks, but in an encrypted state.
Dial-up RAS server—In this layout, the server is installed with a modem or pool of modems and provides for dial-in capabilities.
NAT between networks—On an RRAS server installed in Routing mode, this deployment option provides for Network Address Translation (NAT) between network segments. For example, on one network, the IP addresses might be public, such as 12.155.166.x, while on the internal network, they might be 10.10.10.x. The NAT capability translates the addresses from public to private and vice versa.
Routing between networks—On an RRAS server installed in Routing mode, this deployment option allows for direct routing of the traffic between network segments.
Basic firewall—The RRAS server can act as a simple Layer 3 router, blocking traffic by port. For more secure scenarios, use of an advanced Layer 7 firewall such as Microsoft’s Forefront Threat Management Gateway (previously called Internet Security and Acceleration or ISA Server) is recommended.
NOTE
Setting up a VPN connection requires the server to have at least two network cards installed on the system. This is because the VPN connections must be coming from one network and subsequently passed into a second network, such as from the demilitarized zone (DMZ) network into the internal network.
To install the Remote Access role, follow these steps:
1. In Server Manager, click Manage, and then click Add Roles and Features.
2. On the Before you Begin page, click Next.
3. On the Select Installation Type page, click Role/Feature Based Install, and then click Next.
4. On the Select Destination Server page, click Select a Server from the Server Pool, click the names of the servers onto which you want to install the Remote Access role, and then click Next.
5. On the Select Server Roles page, click Remote Access, and then click Next three times. On the Select Role Services page, click Direct Access and VPN (RAS), and then click Next.
6. On the Confirm Installation Selections page, click Install.
7. On the Results page, verify that the installation succeeded.
To set up the Remote Access server for the most common scenario, VPN gateway, follow these steps:
1. Open the Routing and Remote Access management console from the Tools menu in Server Manager.
2. Select the local server name or connect to a remote Remote Access server by right-clicking Routing and Remote Access and selecting Add Server.
3. Click Action, Configure, and Enable Routing and Remote Access.
4. Click Next at the Welcome page.
5. Choose from the list of configuration settings, as shown in Figure 14.2. Different scenarios require different settings. For example, if setting up a site-to-site VPN, you should select the Secure Connection Between Two Private Networks option. In this case, we are setting up a simple VPN, so we select Remote Access (Dial-Up or VPN).
6. On the Remote Access page, check the box next to VPN. If enabling dial-up, such as in scenarios when the VPN box has a modem attached to it. Click Next to continue.
7. On the VPN Connection page, select which network card is connected to the network where VPN clients will be coming from. This might be the Internet, or it might be a secured perimeter network such as a DMZ. Click Next to continue.
8. On the IP Address Assignment page, select how VPN clients will get their IP addresses (typically Automatically). In addition, you can specify a manual range. Click Next to continue.
9. On the Managing Multiple Remote Access Servers page select whether to use RRAS to authenticate locally or to use a remote RADIUS server. Click Next to continue.
10. Review the wizard settings and click Finish when complete.
11. Click OK when prompted about the default connection request policy being created, and click OK again if prompted about the DHCP Relay Agent.
12. Click Finish when the wizard is complete.
The wizard will enable RRAS on the server and allow for administration of the VPN settings and client from the Routing and Remote Access dialog box. Review the settings within this tool to familiarize yourself with how the system is configured.
Modifying the Remote Access Network Policy
After installing and configuring Remote Access, the NPS system will deny access by default to the Remote Access server for clients, unless the network policy generated is modified. The network policy, which is labeled Connections to Microsoft Routing and Remote Access Server, can be found under the Network Policies node of the Network Policy Server.
The policy must be set to Grant Access in the Access Permission section of the dialog box, as shown in Figure 14.3. This dialog box can be invoked by right-clicking the policy and choosing Properties. After this is enabled, the NPS system will allow client connections.
VPN clients can be controlled and monitored using the NPS role just like the IPsec, 802.1X, and DHCP clients can. Use the NPS Admin tool and the techniques described earlier in this chapter to enable client health monitoring.
Configuring DirectAccess
DirectAccess is installed as a feature on the Remote Access Server. To configure the service, follow these steps.
1. Open the Remote Access Management console, as shown in Figure 14.4, from the Tools menu in Server Manager. Click the Run the Getting Started wizard.
2. At the Configure Remote Access page, click Deploy both DirectAccess and VPN (recommended). This is shown in Figure 14.5. This lets you configure DirectAccess as a VPN server. This task allows remote client computers not supported on DirectAccess to connect to a VPN. (The second option only deploys DirectAccess. The third option configures a standard VPN server with Routing and Remote Access as described earlier in this chapter.) Click Next after you have checked the first option.
3. At the Remote Access Server Setup page, check the option Behind an edge device (with a single network adapter)—the default is Edge; then type the IP addressed to be used by your clients to connect to the remote access server. This is shown in Figure 14.6. Click Next.
4. Click Finish to apply remote access settings. At this point, you can click the Click Here” link to Open the Remote Access Review Page link to affect the changes or to review the configuration settings such as GPO settings, Remote clients settings, Remote Access Server settings, and Infrastructure Server settings.
You can also open the Remote Access Management console to access more settings and fine-tune RRAS configuration. From RRAS, you can also view the ports to check active and inactive VPN connections.
You can test DirectAccess-VPN simply by trying to connect from a supported or non-supported client.
Summary
Windows Server 2016 has improved VPN capabilities, allowing administrators to control and encrypt the connections clients make to the internal network. Using a combination of these technologies can greatly improve the security in an environment.
Best Practices
The following are best practices from this chapter:
Install the Network Policy Server role service to limit client access according to networks and services.
Use a dedicated certificate authority server for generation of certificates for IPsec.
Ensure that the server certificate used for the Network Policy Server is issued from a certificate authority that is trusted by the clients that will be connecting.
Install at least two network cards in a server that will handle VPN client connections.
Although Windows Server 2016 VPN functionality is strong, consider the use of an advanced firewall/VPN solution.
Use L2TP over IPsec encryption for VPN connections when possible. Avoid using the less-secure PPTP VPN connection type.