RD Gateway connection and resource policies

RD Gateway connection and resource policies allow you to specify under what conditions users can connect to an RD Gateway server. RD Connection Authorization Policies (CAPs) can be stored on the RD Gateway server or in a Central RD CAP Store. Some of the benefits of using a Central CAP Store are that the same CAPs can apply to multiple RD Gateway servers without having to reproduce them on each server and that they can also be centrally updated as needed. If your organization has only a single RD Gateway server however, there is no need to use a central RD CAP Store.

On an RD Gateway server that is not a member of a domain, you might have to create a separate local user group with local user accounts to allow users to authenticate against the RD Gateway server prior to authenticating against the session target.

To create an RD Gateway CAP, perform the following general steps:

1. In the RD Gateway Manager console, right-click Connection Authorization Policies, click Create New Policy, and then click Custom.

2. On the New RD CAP dialog box, enter a policy name on the General tab.

3. On the Requirements tab, select Password or, if your organization supports it, Smart Card. Next, click Add Group to specify the User Group to which you want to grant access to RD servers through the RD Gateway server. You should create a separate security group for users you want to grant access to, which makes granting and revoking access just a matter of removing the user’s account from this group.

4. On the Device Redirection tab, choose whether you want to enable device redirection for all client devices or disable it for specific types, such as volumes, clipboards, and plug-and-play devices. You also have the ability to restrict connections to only clients that enforce RD Gateway device redirection policies. You might do this if you want to block access to clients running non-Microsoft operating systems.

5. On the Timeouts tab, you can enable an idle timeout, which disconnects users who aren’t interacting with their session, and a session timeout, which limits all sessions including active sessions. Click OK to finish creating the policy.

After you have configured an RD CAP, you need to configure an RD Resource Authorization Policy (RAP). An incoming connection must meet the conditions specified in one RD CAP and one RD RAP before it can be successfully established. To create an RD RAP, perform the following steps:

1. In the RD Gateway Manager console, right-click Resource Authorization Policies, click Create New Policy, and then click Custom.

2. On the New RD RAP page, enter the policy name.

3. On the User Groups page, click Add to add the user groups that the policy applies to.

4. On the Network Resource page, choose between the following options:

   • Select an Active Directory Domain Services group

   • Select an existing RD Gateway managed group

   • Allow users to connect to any network resource

5. On the Allowed Ports page, choose to restrict connections from the RD Gateway server to port 3389, which is the default, to another specific port, or through any port. Unless the RD servers use alternate ports, the default is appropriate.

Configuring server settings

RD Gateway servers need a TLS certificate to encrypt and authenticate the RDP over an HTTPS connection. As is always the case with TLS certificates, obtaining a certificate from a trusted, third-party certification authority (CA) may cost money and time (at the time of writing, the most popular CA provides TLS certificates free of charge), but this investment means that any client can use the RD Gateway without problems. Using an internal certificate is cheaper because it is not necessary to purchase a certificate, but it does require you to configure RD Gateway clients to trust the issuing authority. Given the organizational cost to support the distribution of an internal or self-signed certificate, it is usually just easier to obtain a certificate from a trusted, third-party CA.

Configuring clients to use RD Gateway

You can configure clients to use an RD Gateway server either by manually configuring the server’s address by editing the advanced properties of Remote Desktop Connection, as shown in Figure 15-1, or by configuring the server’s address through Group Policy.

There are three RD Gateway-related Group Policy items that can be configured to simplify the process of ensuring that clients connect to the correct server. These policy items are located in the User ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRD Gateway node of a standard GPO. These policies can be used to configure the following:

• Set RD Gateway Authentication Method. This policy allows you to force a user to use a particular authentication method, but it also allows you to set a default authentication method that the user can override. The options are:

  • Ask For Credentials; Use NTLM Protocol

  • Ask For Credentials; Use Basic Protocol

  • Use Locally Logged-In Credentials

  • Use Smart Card

  • Negotiate Protocol

• Enable Connection Through RD Gateway. When this policy is enabled, the client attempts to connect through the configured RD Gateway server if it is unable to establish a connection to the specified target of the RD Connection. Set this policy and the RD Gateway Address Policy to ensure that domain clients connect through RD Gateway when they are not connected to the internal network.

• Set RD Gateway Server Address. This policy allows you to configure the RD Gateway server address, either on the basis of IP address or fully qualified domain name (FQDN). This policy should be set in conjunction with the Enable Connection Through RD Gateway policy to ensure that remote domain clients transparently connect through the RD Gateway server without having to configure anything themselves.

IKEv2 Always On VPN protocol

The IPsec Tunnel Mode with Internet Key Exchange version 2 (IKEv2) VPN protocol was introduced with the release of the Windows Server 2008 R2 and Windows 7 operating systems. From Windows Server 2012 R2 onward, this protocol also went by the name Always On VPN. The main benefit of Always On VPN is its capability to allow automatic reconnection without requiring reauthentication when the connection is disrupted. Automatic reconnection can occur even if the client’s connection address changes and reconnection is possible for up to eight hours. For example, imagine that a user is connected to the internal network using an Always On connection through a laptop computer’s cellular modem and then boards an airplane and connects to the airplane’s Wi-Fi. Under an Always On scenario, the connection is automatically reestablished without requiring the user to manually reauthenticate, even though the connection method, from cellular network to airplane Wi-Fi, has changed. Connections only have to be reestablished when a user puts the computer into hibernation mode.

Always On/IKEv2 has the following features:

• Supports IPv6

• Enables VPN reconnect

• Supports EAP and Computer certificates for client authentication

• Does not support PAP or CHAP

• Only supports MS-CHAPv2 with EAP

• Supports data origin authentication, data integrity, replay protection, and data confidentiality

• Uses UDP port 500

To configure Always On VPN server running Windows Server 2019, do the following:

1. Deploy an enterprise CA.

2. Create a new certificate template based on the IPsec template. You need to modify the application policies of this template to ensure that it supports the IP security IKE intermediate policy and Server Authentication certificate.

3. Install a certificate generated from this template on the VPN server.

4. Ensure that at least one Certificate Revocation List Distribution Point is accessible to clients on the Internet. You can place this CRL DP on the perimeter network or host it in the cloud.

5. Ensure that all clients trust the enterprise CA that issued the VPN server’s certificate.

Windows clients running the Windows 8 operating system or later attempt to establish an Always On VPN session before they try SSTP or L2TP/IPsec. If those options are unsuccessful, the client falls back to PPTP.

SSTP VPN protocol

Some locations block the ports that some VPN protocols use. The advantage of the SSTP VPN protocol is that it allows computers that might not normally be able to establish a remote access connection to do so through TCP port 443, which is usually used for TLS connections to websites. While it doesn’t have the performance of other protocols, SSTP almost always works, even if it has to traverse NAT, firewalls, and proxy servers. SSTP doesn’t work, however, if there is a web proxy in place that requires manual authentication. For example, if you are in a hotel and you have to sign on to the Wi-Fi network through a browser, you need to perform this action before you attempt to establish an SSTP connection.

SSTP has the following requirements:

• You need to install a TLS certificate on the VPN server.

• All clients need to trust the CA that issued the TLS certificate.

• You need to configure the TLS certificate with a name that matches the FQDN that maps to an IP address associated with the external network interface of the VPN server.

• The Certificate Revocation List Distribution Point of the CA that issued the TLS certificate needs to be accessible to clients on the Internet.

L2TP/IPsec protocols

Layer Two Tunneling Protocol with IPsec (L2TP/IPsec) is a VPN protocol that has been used with Windows Server operating systems and clients since the release of Windows 2000. It works with almost every Windows and third-party operating system.

When configuring L2TP/IPsec you need to ensure that you have configured a CA that is able to automatically issue certificates to connecting clients. As is the case with other VPN protocols, the CA needs to be trusted by the client, and the CDP must be accessible to clients making connections from the Internet. You would primarily deploy L2TP/IPsec as a way of providing secure access to clients that are not able to leverage the simpler to implement Secure Socket Tunneling Protocol (SSTP) VPN protocol. Although L2TP/IPsec usually requires you to deploy digital certificates, it is possible, with special configuration, to get L2TP/IPsec to work with pre-shared keys.

PPTP VPN protocol

PPTP is the oldest VPN protocol supported by Windows Server 2019 and is also the least secure. It is most often used when organizations need to support clients running unsupported operating systems, such as Windows XP, or in situations where it isn’t possible to deploy the certificate infrastructure required to implement L2TP/IPsec. PPTP connections provide data confidentiality but do not provide data integrity or data origin protection. This means that captured data can’t be read, but you also can’t be sure that the transmitted data was the same data sent by the client.

VPN authentication

Although Windows Server 2019 supports many protocols that have been in use for some time, these protocols are often less secure than more recently developed protocols. Windows Server 2019 supports the following protocols, listed from most secure to least secure:

• Extensible Authentication Protocol-Transport Level Security (EAP-TLS). Use this protocol with Smart Cards or digital certificates. You can only use this protocol if you are using RADIUS authentication or if the remote access server performing authentication is domain-joined.

• Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2). Provides mutual authentication, which means that not only is the user authenticated, but the service that the user is connecting to is also authenticated. Allows for the encryption of the authentication process and the session.

• Challenge Handshake Authentication Protocol (CHAP). Authentication data is encrypted through MD5 hashing. The data is not encrypted.

• Password Authentication Protocol (PAP). This protocol does not encrypt authentication data, meaning that if the authentication is captured, then attackers will have access to credentials.

Deploying a VPN server

To configure a Windows Server 2019 server that has one network card connected to the perimeter network, which is accessible to clients on the Internet, and a second network card that is connected to the internal network to support VPNs, perform the following general steps:

1. Ensure that the prospective VPN server is connected to the Active Directory domain and log in with an account that is a Domain Admins group member.

2. Open an elevated PowerShell prompt and enter the following commands:

   Click here to view code image

   Install-WindowsFeature -IncludeAllSubfeature RemoteAccess

3. Open the Routing And Remote Access console, right-click the server name, and click Configure And Enable Routing and Remote Access. This opens the Routing And Remote Access Server Setup Wizard. Click Next.

4. On the Configuration page, select Remote Access (Dial-Up Or VPN) and then click Next.

5. On the Remote Access page, select VPN and then click Next.

6. On the VPN Connection page, select the network connection that is connected to the Internet and then click Next.

7. On the IP Address Assignment page, choose between assigning IP addresses automatically from an existing scope or from a specified range of addresses.

8. On the Manage Multiple Remote Access Servers page, select No, Use Routing And Remote Access To Authenticate Connection Requests, click Next, and then click Finish.

Disable VPN protocols

By default, Windows Server 2019 server supports SSTP, PPTP, L2TP, and IKEv2 remote access connections. If you want to limit incoming connections to a specific protocol or disable an existing protocol, you need to edit the port properties related to that protocol. If you don’t disable a specific protocol, clients might use that protocol to connect to the VPN server. For instance, if you’ve gone to the effort of configuring IKEv2, you don’t want to find out a few weeks later that all your clients are still falling back to using PPTP! To configure which VPN protocols are available, perform the following general steps:

1. Open the Routing and Remote Access console, right-click the Ports node under the VPN server, and then click Properties.

2. On the Ports Properties dialog box, select the VPN protocol for which you want to limit connections, and then click Configure.

3. On the Configure Device dialog box, set the Maximum Ports to 1 and ensure that the Remote Access Connections (Inbound Only) item is not selected. Click OK.

Granting access to a VPN server

If you have only a small number of users, you can grant access to those users on an individual basis by editing their user account properties in Active Directory Users And Computers. To grant access to an individual user, choose Allow access under Network Access Permission on the Dial-In tab of the user’s Account Properties.

The default setting for network access for access to a Windows Server 2019 VPN server is for it to be controlled through a Network Policy Server (NPS) network policy. To be granted access, a user must meet the conditions of a connection request policy and a network policy. A connection request policy includes type of access, time of access, and which authentication protocols are available. A network policy can be as simple as specifying that a particular user group has access.

When you install a VPN server, a default connection request policy called Microsoft Routing And Remote Access Service Policy is created. You can view the policy’s properties under the PoliciesConnection Request Policies node of the Network Policy Server console on the VPN server. To configure this policy, perform the following steps:

1. Open the Network Policy Server console on the VPN server.

2. Expand the PoliciesConnection Request Policies node. Right-click Microsoft Routing And Remote Access Service Policy and then click Properties.

3. On the Conditions tab, verify that the day and time restrictions match those that you want to enforce for the remote access policy. You can also use this tab to add conditions to the policy. Clients must meet all specified conditions, so keep in mind that the more conditions you add, the fewer clients the policy applies to. Conditions that you can add include the following:

   • User Name. Specifies a specific HCAP user name.

   • Access Client IPv4 Address. Specifies the RADIUS client IPv4 address.

   • Access Client IPv6 Address. Specifies the RADIUS client IPv6 address.

   • Framed Protocol. Specifies the protocol used for framing incoming packets, such as Point-to-Point Protocol (PPP) or Serial Line Internet Protocol (SLIP).

   • Service Type. Limits clients to a specific service, such as Point-to-Point protocols.

   • Tunnel Type. Restricts clients to a specific tunnel type, such as PPTP, L2TP, and SSTP.

   • Day and Time Restrictions. Specifies when connections can be active.

   • Calling Station ID. Specifies the Network Access Server telephone number.

   • Client Friendly Name. Specifies the RADIUS client name.

   • Client IPv4 Address. Specifies the RADIUS client IPv4 address.

   • Client IPv6 Address. Specifies the RADIUS client IPv6 address.

   • Client Vendor. Specifies the RADIUS client vendor.

   • Called Station ID. Specifies the NAS identification string or telephone number.

   • NAS Identifier. Specifies the NAS identification string.

   • NAS IPv4 Address. Specifies the IPv4 address of NAS.

   • NAS IPv6 Address. Specifies the IPv6 address of NAS.

   • NAS Port Type. Specifies the RADIUS client access type, such as ISDN, VPN, IEEE 802.11 wireless, and so on.

4. Settings are a set of categories that are required. You can select from the following:

   • Authentication Methods. This setting enables you to specify which protocols clients can use to connect to the VPN server. The VPN server attempts to use the most secure protocol first and then, in order of most to least secure, attempts less secure protocols until it reaches the least secure protocol supported by the policy.

   • Authentication. This setting determines whether the VPN server performs authentication or whether authentication credentials are passed to another server.

   • Accounting. This setting enables you to record authentication information to a log file or SQL server database. Recording this information gives you a record of which people have gained access through VPN connections.

   • Attribute, RADIUS Attributes Standard & Vendor Specific. These settings are necessary only if you are placing the VPN server into an existing RADIUS infrastructure.

After you ensure that the details of the connection request policies meet your needs, you can configure a network policy. Network policies are useful when you want to give remote access to a large number of users, but you do not want to configure access on a per-account basis. To create a new network policy that allows this access, perform the following general steps:

1. Open the Network Policy Server console. Right-click the PoliciesNetwork Policies node and then click New. The Specify Network Policy Name And Connection Type dialog box opens.

2. Enter a name for the policy and set the Type of Network Access Server drop-down menu to Remote Access Server (VPN-Dial Up) and then click Next.

3. On the Conditions page, click Add and then Add Conditions. The conditions that you can add are as follows:

   • Windows Groups. Limits access to user or computer groups.

   • Machine Groups. Limits access to members of the specified computer group.

   • User Groups. Limits access to members of the specified user group.

   • Day and Time Restrictions. Restricts when the policy can be used for access.

   • Access Client IPv4 Address. Specifies the IPv4 network address of the client.

   • Access Client IPv6 Address. Specifies the IPv6 network address of the client.

   • Authentication Type. Defines acceptable authentication protocols.

   • Allowed EAP Types. Defines allowed EAP authentication protocols.

   • Framed Protocol. Specifies the protocol used for framing incoming packets, such as Point-to-Point Protocol (PPP) or Serial Line Internet Protocol (SLIP).

   • Service Type. Limits clients to a specific service, such as Point-to-Point protocols.

   • Tunnel Type. Restricts clients to a specific tunnel type, such as PPTP, L2TP, and SSTP.

   • Calling Station ID. Specifies the Network Access Server telephone number.

   • Client Friendly Name. Specifies the RADIUS client name.

   • Client IPv4 Address. Specifies the RADIUS client IPv4 address.

   • Client IPv6 Address. Specifies the RADIUS client IPv6 address.

   • Client Vendor. Specifies the RADIUS client vendor.

   • MS-RAS Vendor. Specifies the Network Access Server (NAS) vendor.

   • Called Station ID. Specifies the NAS identification string or telephone number.

   • NAS Identifier. Specifies the NAS identification string.

   • NAS IPv4 Address. Specifies the IPv4 address of NAS.

   • NAS IPv6 Address. Specifies the IPv6 address of NAS.

   • NAS Port Type. Specifies RADIUS client access type, such as ISDN, VPN, IEEE 802.11 wireless, and so on.

After you have configured the network policy, it should be possible to establish a VPN connection.

DirectAccess topologies

DirectAccess supports multiple deployment topologies. You don’t have to deploy the DirectAccess server with a network adapter directly connected to the Internet. Instead, you can integrate the DirectAccess server with your organization’s existing edge topology. During your DirectAccess server deployment, the Remote Access Server Wizard asks you which of the topologies reflects your server configuration. The difference between them is as follows:

• Edge. This is the traditional DirectAccess deployment method. The computer hosting the server has two network adapters. The first network adapter is connected directly to the Internet and has been assigned one or more public IPv4 addresses. The second network adapter connects directly to the internal trusted network.

• Behind An Edge Device (With Two Network Adapters). In this type of deployment, the DirectAccess server is located behind a dedicated edge firewall. This configuration includes two network adapters. One of the network adapters on the DirectAccess server is connected to the perimeter network behind the edge firewall. The second network adapter connects directly to the internal trusted network.

• Behind An Edge Device (With A Single Network Adapter). In this type of deployment, the DirectAccess server has a single network adapter connected to the internal network. The edge firewall passes traffic to the DirectAccess server.

DirectAccess server

The DirectAccess server is a domain-joined computer running Windows Server 2012 or later that accepts connections from DirectAccess clients on untrusted networks, such as the Internet, and provides access to resources on trusted networks. The DirectAccess server performs the following roles:

• Authenticates DirectAccess clients connecting from untrusted networks

• Functions as an IPsec tunnel mode endpoint for DirectAccess traffic from untrusted networks

Before you can configure a computer running Windows Server 2012 or later to function as a DirectAccess server, you must ensure that it meets the following requirements:

• The server must be a member of an Active Directory Directory Services domain.

• If the server is connected directly to the Internet, it must have two network adapters: one that has a public IP address and one that is connected to the trusted internal network.

• The DirectAccess server can be deployed behind a NAT device, which limits DirectAccess to use IP over HTTPS (IP-HTTPS).

• A server connected to the Internet requires only a single public IPv4 address. Two-Factor Authentication, using either Smart Card or One-Time Password (OTP), however, requires two consecutive public IPv4 addresses.

• The DirectAccess server can also host a VPN server. This functionality was not present in the Windows Server 2008 R2 version of DirectAccess.

• You can configure DirectAccess in a network load-balanced configuration of up to eight nodes.

• The TLS certificate installed on the DirectAccess server must contain an FQDN that resolves through DNS servers on the Internet to the public IP address assigned to the DirectAccess server or to the gateway through which the DirectAccess server is published.

• The TLS certificate installed on the DirectAccess server must have a Certificate Revocation List (CRL) distribution point that is accessible to clients on the Internet.

A DirectAccess implementation also relies on the following infrastructure being present:

• Active Directory domain controller. DirectAccess clients and servers must be members of an Active Directory domain. By necessity, when you deploy a domain controller, you also deploy a DNS server. Active Directory, due to its basic nature, also makes Group Policy available.

• Group Policy. When you configure DirectAccess, the setup wizard creates a set of Group Policy Objects (GPOs) that are configured with settings you choose in the wizard. They apply to DirectAccess clients, DirectAccess servers, and servers that you use to manage DirectAccess.

Prepare DNS servers by removing the ISATAP name from the global query block list. You must take this step on all DNS servers that are hosted on computers running Windows Server operating systems. To complete this step, remove ISATAP from the GlobalQueryBlockList value on the ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters hive of the registry, so that it contains only the wpad entry, as shown in Figure 15-3. After making this configuration change, you must restart the DNS server.

As an alternative to editing the registry, you can also remove ISATAP from the DNS global query block list by issuing the following command on each DNS server and restarting the DNS Server service:

Click here to view code image

Dnscmd /config /globalqueryblocklist wpad

Network Location Server

The Network Location Server (NLS) is a specially configured server that enables clients to determine whether they are on a trusted network or an untrusted network. The NLS server’s only function is to respond to specially crafted HTTPS requests. When the client determines that it has a connection to any network, it sends this specially crafted HTTPS request. If there is a response to this request, the client determines that it is on a trusted network and disables the DirectAccess components. If there is no response to this request, the client assumes that it is connected to an untrusted network and initiates a DirectAccess connection.

DirectAccess clients are informed of the NLS’s location through Group Policy. You don’t have to configure these policies manually because they are created automatically when you use the DirectAccess Setup Wizard. Any server that hosts a website and has an SSL certificate installed can function as the NLS. You should ensure that the NLS is highly available because if this server fails, it causes all clients that are configured for DirectAccess on the trusted network to assume that they are on an untrusted network.

Configuring DirectAccess

After you understand the infrastructure requirements, configuring DirectAccess is straightforward. To configure DirectAccess, perform the following steps:

1. Create a security group in Active Directory and add all the computer accounts for computers that are DirectAccess clients. This security group can have any name, but a name such as DirectAccess_Clients makes it easy to remember why you created it.

2. Ensure that you configure DNS with the following information:

   • The externally resolvable DNS zone needs to have a record mapping the FQDN of the DirectAccess server’s external interface to the public IPv4 address of the DirectAccess server.

   • If you use a certificate issued by your organization’s CA, ensure that a DNS record exists for the CRL location.

   • The internal DNS zone needs a record mapping the name of the NLS to an IP address.

   • Remove ISATAP from the global query block list on all DNS servers in the organization.

3. If you use your organization’s CA, you must configure an appropriate certificate template, as well as deploy a CRL distribution point in a location that can be accessed by clients on the Internet. The certificate template can be a duplicate of the Web Server Certificate Template. You can use this certificate for both the NLS’s TLS certificate and the IP-HTTPS certificate for the DirectAccess server. If you don’t use your organization’s CA to issue certificates, you can use certificates from a public CA for the NLS and the DirectAccess server.

4. Configure firewall rules for all hosts on the trusted network that should be accessible to DirectAccess clients, so they enable inbound and outbound ICMPv6 echo requests. You can configure these rules in a GPO that applies to hosts that DirectAccess clients can access. The rules should have the following properties:

   • Rule Type: Custom

   • Protocol Type: ICMPv6

   • Specific ICMP Types: Echo Request

5. Install the Remote Access role on the computer that functions as the DirectAccess server.

6. Open the Remote Access console and then choose between running the Getting Started Wizard and the Remote Access Setup Wizard. The Getting Started Wizard enables administrators to quickly deploy DirectAccess by only requiring a minimal amount of information. The Remote Access Setup Wizard requires more detailed responses but enables administrators to customize their deployment. The rest of this procedure deals with the Remote Access Setup Wizard.

7. The Configure Remote Access page of the Configure Remote Access Wizard enables you to choose between deploying DirectAccess and VPN, deploying DirectAccess only, or deploying VPN only.

8. If you select Deploy DirectAccess Only, you are provided with the Remote Access Setup diagram. This diagram involves a series of steps that enable you to configure the DirectAccess server, clients, and infrastructure. There are four steps, including:

   • Step 1: Remote Clients

   • Step 2: Remote Access Server

   • Step 3: Infrastructure Servers

   • Step 4: Application Servers