Windows Server 2008 Remote Access and Network Access Protection

Lesson 1: Managing Remote Access

If your organization is going to allow workers to telecommute, you need to provide those workers with some way to access resources on your organization’s internal network. In this lesson, you will learn how to plan the deployment of VPN servers to allow remote access to your internal network from locations that are external to your organization’s network. You will also learn about DirectAccess, a technology available with Windows 7 and Windows Server 2008 R2 that dramatically simplifies the remote access process from the user perspective. The lesson will also cover traditional remote access protocols, including Point to Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol/Internet Protocol Security (L2TP/IPsec), Secure Socket Tunneling Protocol (SSTP), and another technology new to Windows Server 2008 R2 called IKEv2.

The Routing and Remote Access Service (RRAS) role service is available as part of the Network Policy And Access Services server role. You should deploy the Remote Access Service (RAS) component of the RRAS role service when you want to provide either of the following resources to your network environment:

• VPN remote access server

• Dial-up remote access server

In this lesson, you will learn how to configure and monitor a VPN remote access server running Windows Server 2008 and Windows Server 2008 R2. To install the RRAS role service, use the Add Roles Wizard and then select Network Policy And Access Services. RRAS is a role service within this role. As an alternative, open an elevated Windows PowerShell prompt on a computer running Windows Server 2008 R2 and issue the following commands:

Import-Module ServerManager
Add-WindowsFeature NPAS-RRAS-Services

To remove RRAS completely from a server running Windows Server 2008 R2, issue the command:

Remove-WindowsFeature NPAS

Once installed, you must configure RAS manually. Only members of the local Administrators group are able to configure the RAS. In domain environments, you should perform this action using a user account that is a member of the Domain Admins group. If your user account is not a member of the Domain Admins security group, organize a domain admin to add the RAS server account manually to the RAS And IAS Servers domain security group. It is not necessary to add the RAS server to this group if the RAS server will be using local authentication or authenticating against a Remote Authentication Dial-In User Service (RADIUS) server.

To enable Remote Access, open the Routing and Remote Access console from the Administrative Tools menu, right-click the computer running Windows Server 2008 R2 that you want to host this role, and then click Configure And Enable Routing And Remote Access. Performing this action starts the Routing And Remote Access Server Setup Wizard. The configuration page of this wizard, shown in Figure 9-1, allows you to select the combination of services that this particular server will provide. The Remote Access (Dial-Up Or VPN) option is selected when you want to provide either remote access option or both options to clients outside your organization.

If you have chosen to install a VPN server, you will need to specify which network interface connects to the Internet on the VPN Connection page shown in Figure 9-2. This will be the interface that has the public IP address, rather than the interface that has the private IP address. If additional network adapters are installed on the server that hosts the RAS role after the RAS server is deployed, they can be configured for use with RAS using the RRAS console. If the computer running Windows Server 2008 R2 has fewer than two network adapters, you will not be able to perform a standard VPN server setup and will need to perform a custom configuration instead.

When you configure a remote access server, the process applies packet filters that allow only VPN protocols to the Internet interface. This means that the server is limited to providing VPN access. If you have deployed other services on the server that will host the RAS role, you will need to configure new packet filters to allow this traffic to the server. As a deployment strategy, you should seriously consider keeping the RAS server separate from other services.

After you identify the external interface, the next step in configuring the RAS role is specifying how to assign IP addresses to clients. You can do this in several ways:

• Client addresses can be leased from a DHCP server within the organization.

• The RAS server can generate the addresses itself.

• You can specify a range of addresses to assign to connecting clients.

When using your organization’s DHCP infrastructure, the RAS server will lease blocks of 10 addresses, requesting new blocks if previously requested blocks are all currently in use.

DHCP servers running Windows Server 2008 and Windows Server 2008 R2 have a predefined user class, known as the Default Routing And Remote Access Class. This class allows administrators to assign specific options only to Routing And Remote Access clients. This class is configured through the Advanced tab of DHCP Server Options, as shown in Figure 9-3.

The next step in configuring an RAS server is determining how authentication will occur. You can configure the RAS server to perform authentication against Active Directory Domain Services (AD DS) or the local account database, or you can configure the RAS server as a RADIUS client and allow the RADIUS server to perform the authentication and authorization of client connection requests. You will learn more about RADIUS options later in this lesson. After you have performed these steps, the RAS server will be functional.

VPN Authentication

A VPN is an extension of a private network that encompasses encapsulated, encrypted, and authenticated links across shared or public networks. A client connects to a public network, such as the Internet, and initiates a VPN connection to a remote server. This remote server is usually located on the perimeter network of the organization that the client wants to connect to. After the connection is made, an encrypted tunnel forms between the client and the VPN server. This encrypted tunnel carries local area network (LAN) traffic between the client and the remote network that the client is connected to. Clients are connected to the network in the same way that they would be if they were in the office. Instead of a network cable connecting them to a switch somewhere in the office, a virtual cable in the form of a VPN tunnel connects them to their organization’s network infrastructure.

The following authentication protocols can be used by a computer running Windows Server 2008 or Windows Server 2008 R2 to authenticate incoming VPN connections. These protocols are listed in order from most secure to least secure:

• Extensible Authentication Protocol-Transport Level Security (EAP-TLS) This is the protocol that you deploy when your VPN clients are able to authenticate using smart cards or digital certificates. EAP-TLS is not supported on stand-alone servers and can be implemented only when the server hosting the RAS role service is a member of an AD DS domain.

• Microsoft Challenge Handshake Authentication Protocol (MS-CHAPv2) This protocol provides mutual authentication and allows for the encryption of both authentication data and connection data. MS-CHAPv2 is enabled by default in Windows Server 2008 and Windows Server 2008 R2.

• Challenge Handshake Authentication Protocol (CHAP) An older authentication method that encrypts authentication data using MD5 hashing. CHAP does not support the encryption of data and is used most often to provide compatibility with older, non-Microsoft clients.

• Extensible Authentication Protocol-Message Digest 5 Challenge Handshake Authentication Protocol (EAP-MD5 CHAP) A version of CHAP that has been ported to the EAP framework. This authentication protocol supports encryption of authentication data through MD5 hashing and is generally used to provide compatibility with non-Microsoft clients.

• Shiva Password Authentication Protocol (SPAP) A weakly encrypted authentication protocol that does not support the encryption of connection data.

• Password Authentication Protocol (PAP) When this protocol is used, authentication data is not encrypted, but is passed across the network in plain text. Does not support the encryption of protection data.

The authentication process always attempts to negotiate the use of the most secure authentication protocol. The default authentication protocol used for VPN clients connecting to a Windows Server 2008 and Windows Server 2008 R2 VPN is MS-CHAPv2.

VPN Protocols

Windows Server 2008 R2 supports four different VPN protocols: Point to Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol over IPsec (L2TP/IPsec), Secure Socket Tunneling Protocol (SSTP), and IKEv2. The factors that will influence the protocol you choose to deploy in your own network environment include client operating system, certificate infrastructure, and how your organization’s firewall is deployed.

PPTP

PPTP connections can only be authenticated using MS-CHAP, MS-CHAPv2, EAP, and PEAP. PPTP connections use MPPE to encrypt PPTP data. PPTP connections provide data confidentiality but do not provide data integrity or data origin authentication. It is possible to use PPTP with certificates if EAP-TLS is selected as the authentication protocol, although the advantage of PPTP over the other VPN protocols supported by Windows Server 2008 and Windows Server 2008 R2 is that it does not require certificates be installed on the client making the connection. With PPTP, you do not need to be concerned about shared secrets or computer certificates or ensuring that the appropriate Certificate Authority (CA) is trusted. PPTP is often used with non-Microsoft operating systems.

L2TP/IPsec

L2TP connections use encryption provided by IPsec. L2TP/IPsec is the protocol that you need to deploy if you are supporting remote access clients running Microsoft Windows XP because such clients cannot use SSTP. L2TP/IPsec provides per-packet data origin authentication, data integrity, replay protection, and data confidentiality.

L2TP/IPsec connections use two levels of authentication. Computer-level authentication occurs either using digital certificates issued by a CA trusted by the client and VPN server or through the deployment of preshared keys. PPP authentication protocols are then used for user-level authentication. L2TP/IPsec supports all the VPN authentication protocols available on Windows Server 2008 and Windows Server 2008 R2.

SSTP

SSTP is a VPN technology that made its debut with Windows Server 2008 and is available in Windows Server 2008 R2. SSTP VPN tunnels allow traffic to pass across firewalls that block traditional PPTP or L2TP/IPsec VPN traffic. SSTP works by encapsulating PPP traffic over the Secure Sockets Layer (SSL) channel of the Secure Hypertext Transfer Protocol (HTTPS). Expressed more directly, SSTP piggybacks PPP over HTTPS. This means that SSTP traffic passes across TCP port 443, which is almost certain to be open on any firewall between the Internet and a public-facing web server on an organization’s perimeter network.

The PPP of SSTP allows for the deployment of advanced authentication methods such as EAP-TLS, which is used most commonly with smart cards. The SSL component of SSTP provides the VPN tunnel with encryption, enhanced key negotiation, and integrity checking. This means data transferred using this method is encoded and that it is possible to detect whether someone has attempted to intercept the contents of the tunnel between the source and destination points.

When planning for the deployment of SSTP, you need to take into account the following considerations:

• SSTP is supported only with Windows Server 2008, Windows Server 2008 R2, Windows 7, and Windows Vista with SP1.

• SSTP requires that the client trust the CA that issues the VPN server’s SSL certificate.

• The SSL certificate must be installed on the server that will function as the VPN server prior to the installation of RRAS; otherwise, SSTP will not be available.

• The SSL certificate subject name and the host name that external clients use to connect to the VPN server must match, and the client running Windows 7 or Windows Vista SP1 must trust the issuing CA.

• SSTP does not support tunneling through web proxies that require authentication.

• SSTP does not support site-to-site tunnels. (PPTP and L2TP, however, do.)

IKEv2

IKEv2 is a VPN protocol that is new to Windows 7 and Windows Server 2008 R2. This protocol is not present in previous versions of Windows, and clients running Windows 7 will be able to use this protocol only if the remote access server is running Windows Server 2008 R2. IKEv2 has the following properties:

• Supports IPv6.

• Has a VPN Reconnect feature.

• Supports EAP and computer certificates for client-side authentication. This includes the Microsoft: Protected EAP (PEAP), Microsoft: Secured Password (EAP-MSCHAP v2), and Microsoft Smart Card Or Other Certificate options in the user interface.

• IKEv2 does not support PAP, CHAP, or MS-CHAPv2 (without EAP) as authentication protocols. IKEv2 supports data origin authentication, data integrity, replay protection, and data confidentiality.

• IKEv2 uses UDP port 500.

• When you configure a new Windows 7 VPN connection with the default settings, the client will attempt to make an IKEv2 connection first.

• IKEv2 requires a client running Windows 7 and an RRAS server running Windows Server 2008 R2.

The benefit of using IKEv2 over other protocols is that it supports VPN Reconnect. When you connect to a VPN server using the PPTP, L2TP/IPsec, or SSTP protocol and you suffer a network disruption, you can lose your VPN connection and need to restart it. This often involves reentering your authentication credentials. If you are transferring a file, downloading email, or sending a print job, and something interrupts your connection, you need to start over from the beginning. VPN Reconnect allows clients running Windows 7 to reconnect automatically to a disrupted VPN session even if the disruption has lasted for up to 8 hours.

VPN Reconnect uses the IKEv2 tunneling protocol with the .mobike extension. The .mobike extension allows VPN clients to change their Internet addresses without having to renegotiate authentication with the VPN server. For example, a user might be using a VPN connection to his corporate network while connected to a wireless network at an airport coffee shop. As the time of his flight’s departure approaches, he moves from the coffee shop to the airport lounge, which has its own Wi-Fi network. With VPN Reconnect, the user’s VPN connection is reestablished automatically when he achieves Internet connectivity with the new network. With a traditional VPN solution, this user would have to reconnect manually once he connected to the new wireless network in the airport lounge, and any existing operations occurring across the VPN would be lost. Unlike DirectAccess, which only some editions of Windows 7 support, all editions of Windows 7 support IKEv2 with VPN Reconnect.

DirectAccess

DirectAccess is an always-on, IPv6, IPsec VPN connection. If a properly configured computer is able to connect to the Internet, DirectAccess automatically connects that computer to a properly configured corporate network. DirectAccess differs from the VPN solutions outlined earlier in the following ways:

• The connection process is automatic and does not require user intervention or logon. The DirectAccess connection process starts from the moment the computer connects to an active network. From the user’s perspective, the computer always has access to the corporate intranet, whether she is sitting at her desk or when she has just connected to a Wi-Fi hotspot at a beachside cafe. Traditionally, users must initiate VPN connections to the corporate intranet manually.

• DirectAccess is bidirectional, with servers on the intranet being able to interact with the client running Windows 7 in the same way that they would if the client was connected to the LAN. In many traditional VPN solutions, the client can access the intranet, but servers on the intranet cannot initiate communication with the client.

• DirectAccess provides administrators with greater flexibility in controlling which intranet resources are available to remote users and computers. Administrators can integrate DirectAccess with NAP to ensure that remote clients remain up to date with virus definitions and software updates. Administrators can also apply connection security policies to isolate servers and hosts.

The DirectAccess process is automatic. It requires no intervention on the part of the person who is logging on to the computer running Windows 7. A portable computer that is taken home and connected to a home Internet network can still receive software and Group Policy updates from servers on the corporate network even if the user has not logged on. Clients running Windows 7 use the following process to establish a DirectAccess connection:

1. The client running Windows 7 configured with DirectAccess connects a network. This occurs prior to user logon when the client running Windows 7 first connects to the network.

2. During the network identification phase, whenever a computer running Windows 7 detects that it is connecting to a new network or resuming a connection to an existing network, the client attempts to connect to a specially configured intranet website. An administrator specifies this website address when configuring DirectAccess on the DirectAccess server. If the client can contact the website, Windows 7 concludes that it has connected to the corporate network and no further action is necessary.

3. If the client running Windows 7 is unable to contact the specially configured intranet website, the client attempts to determine whether a native IPv6 network is present. If a native IPv6 network is present and the client has been assigned a public IPv6 address, DirectAccess makes a direct connection to the DirectAccess server across the Internet.

4. If a native IPv6 network is not present, Windows 7 attempts to establish an IPv6 over IPv4 tunnel using first the 6to4 and then the Teredo transition technologies.

5. If the client running Windows 7 cannot establish a Teredo or 6to4 connection due to an intervening firewall or proxy server, the client running Windows 7 attempts to connect using IP-HTTPS. IP-HTTPS encapsulates IPv6 traffic over an HTTPS connection. IP-HTTPS is likely to work because few firewalls that allow connections to the Internet block traffic on TCP port 443.

6. The DirectAccess IPsec session is established when the client running Windows 7 and the DirectAccess server authenticate with each other using computer certificates. DirectAccess supports only certificate-based authentication.

7. The DirectAccess server checks the appropriate AD DS group to verify that the computer and user have authorization to connect using DirectAccess.

8. The DirectAccess client now has access to appropriately configured resources on the corporate network.

Table 9-1 summarizes DirectAccess client configurations and the corresponding method of communicating using IPv6 with the DirectAccess server. When you configure the DirectAccess server, you configure it to support all these different connection methods. You do this because you cannot be certain of what conditions exist on the remote network from which the DirectAccess client is attempting to connect. IP-HTTPS is tried last because it provides a poorer performance compared to the other connection methods.

Table 9-1 DirectAccess Connection Methods

CLIENT NETWORK CONNECTION	DIRECTACCESS CONNECTION METHOD
Public IPv6 Address	Public IPv6 Address
Public IPv4 Address	6to4
Private (NAT) IPv4 Address	Teredo
Client unable to connect through firewall, but is connected to the Internet	IP-HTTPS

Only domain-joined clients running Windows 7 Enterprise and Ultimate editions support DirectAccess. You cannot use DirectAccess with other editions of Windows 7 or earlier versions of Windows, such as Windows Vista or Windows XP. When configuring a client for DirectAccess, you must add the client’s domain computer account to a special security group. You specify this security group when running the DirectAccess wizard on the DirectAccess server.

Clients receive their DirectAccess configuration through Group Policy. This differs from traditional VPN configuration, where connections are configured manually or distributed through the Connection Manager Administration Kit (CMAK). Once you have added the computer’s client account to the designated security group, you need to install a computer certificate on the client for the purpose of DirectAccess authentication. An organization needs to deploy Active Directory Certificate Services (AD CS) so that clients can enroll automatically with the appropriate certificates.

You configure DirectAccess primarily by configuring the DirectAccess server. When you configure the DirectAccess server, you also end up configuring the necessary Group Policy objects (GPOs) that support DirectAccess. Prior to installing DirectAccess, you should ensure that the DirectAccess server meets the following requirements:

• The computer needs to have Windows Server 2008 R2 installed and be a member of a domain.

• This server must have two network adapters.

• One of these network adapters needs to have a direct connection to the Internet. You must assign this adapter two consecutive public IPv4 addresses.

• The second network adapter needs a direct connection to the corporate intranet.

• The computer needs digital certificates to support server authentication. This includes having a computer certificate that matches the fully qualified domain name (FQDN) that is assigned to the IP addresses on the DirectAccess server’s external network interface.

You should also create at least one global security group in AD DS that you use with DirectAccess. You can give this group any name that you like, although it is easier to keep track of it if you give it a DirectAccess-related name. It is possible to create and specify multiple DirectAccess-related security groups if necessary. You create multiple groups when you need to differentiate access to segments of the corporate intranet.

To install DirectAccess on a server running Windows Server 2008 R2, add the DirectAccess Management Console feature using the Add Features Wizard or the following PowerShell command:

Add-WindowsFeature DAMC

Installing the DirectAccess Management console allows you to configure and manage DirectAccess features. Installing the DirectAccess Management console also requires that you add the Group Policy Management feature. The Group Policy Management feature is necessary because the DirectAccess setup wizard creates DirectAccess-related GPOs that configure DirectAccess clients. You need to run the DirectAccess Setup wizard with a user account that has permission to create and apply GPOs in the domain.

After you have installed the DirectAccess Management console, you can configure the DirectAccess server. To do this, perform the following steps:

1. Open the DirectAccess Management console from the Administrative Tools menu on the computer running Windows Server 2008 R2. This console is shown in Figure 9-4.

   

   Figure 9-4 DirectAccess Management console

2. Select the Setup node. In the details pane, in the Remote Clients area, click Configure. This opens the DirectAccess Client Setup dialog box. Click Add and then specify the name of the security groups to which you add computer accounts when you want to grant access to DirectAccess to specific clients running Windows 7. These groups can have any names.

3. Use the DirectAccess Server Setup item to specify which interface is connected to the Internet and which interface is connected to the internal network. Performing this step will enable IPv6 transition technologies on the DirectAccess server, as shown in Figure 9-5. You use this item to specify the CA that client certificates must ultimately come from, either directly or through a subordinate CA. You also must specify the server certificate used to secure IP-HTTPS traffic.

   

   Figure 9-5 DirectAccess Server Setup

4. On the Infrastructure Server Setup page, you specify the location of the internal website (known as the Network Location Server) that DirectAccess clients attempt to contact to determine whether they are connected to the corporate intranet or a remote location. You must ensure that you secure this website with a web server certificate. You also use this dialog box to specify which DNS servers and domain controllers the DirectAccess clients are able to contact for authentication purposes.

5. The final step involves specifying which resources on the corporate intranet are accessible to DirectAccess clients. The default setting is to allow access to all resources. In more secure environments, it is possible to use isolation policies to limit the contact to the membership of specific security groups. For example, you might create a security group and add the computer accounts of some file servers and mail servers, but not others.

6. When you click Finish, DirectAccess interfaces with a domain controller and creates two new GPOs in the domain. The first of these is targeted at the security groups that contain the computer accounts of DirectAccess clients. The second GPO is targeted at the DirectAccess server itself.

DirectAccess relies upon several other components in a Windows Server 2008 R2 network infrastructure. The domain in which you install the DirectAccess server must also have the following:

• At least one domain controller running Windows Server 2008 R2 and a DNS server on the internal network

• A server running Windows Server 2008 or later with AD CS installed, either as an Enterprise Root CA or an Enterprise Subordinate CA

To make internal network resources available to remote DirectAccess clients, you need to do one of the following:

• Ensure that all internal resources that will be accessed by DirectAccess support IPv6.

• Deploy ISATAP on the intranet, which allows intranet servers and applications to be reached by tunneling IPv6 traffic over an IPv4 intranet.

• Deploy a NAT-PT device, which allows hosts that support only IPv4 addresses to be accessible to DirectAccess clients using IPv6.

All application servers that DirectAccess clients access need to allow ICMPv6 traffic in Windows Firewall with Advanced Security (WFAS). You can accomplish this by enabling the following firewall rules using Group Policy:

• Echo Request – ICMPv6-in

• Echo Request – ICMPv6-out

The following ports on an organization’s external firewall must be open to support DirectAccess:

• UDP port 3544 Enables Teredo traffic

• IPv4 protocol 41 Enables 6to4 traffic

• TCP port 443 Allows IP-HTTPS traffic

• ICMPv6 and IPv4 protocol 50 Required when remote clients have IPv6 addresses

NPS RADIUS Servers

In addition to its ability to provide RRAS gateways, Network Policy Server (NPS) can function as a RADIUS server and as a RADIUS client, which also is known as a RADIUS proxy. When an organization has more than one remote access server, an administrator can configure a server that has NPS installed as a RADIUS server and then configure all remote access servers as RADIUS clients. The benefit of doing this is that network policy management is centralized rather than requiring management on a per-remote-access-server basis.

When RADIUS is used as an authentication provider for RAS servers, the connection request is sent in a RADIUS request message format to a RADIUS server. The RADIUS server performs the authentication and authorization and then passes this information back to the RAS server. The RADIUS server must be a member of an AD DS domain, but the RAS VPN server passing authentication requests to the RADIUS server can be a stand-alone computer.

NPS and RADIUS clients

RADIUS clients are network access servers such as VPN servers, wireless access points, and 802.1x authenticating switches. Although the computers that access these network access servers are called remote access clients, they are not considered RADIUS clients. RADIUS clients provide network access to other hosts.

To configure a RADIUS client using NPS, open the Network Policy Server console from the Administrative Tools menu. Right-click RADIUS Clients and then click New RADIUS Client. This will open the dialog box shown in Figure 9-6.

Configuration involves providing the following information:

• Friendly Name

• Address (IP or DNS)

• Vendor Name (with more than 20 separate vendors available in this drop-down menu)

• Shared Secret (configured using the NPS snap-in on the RADIUS client)

NPS as a RADIUS Proxy

RADIUS proxies route RADIUS messages between remote access servers configured as RADIUS clients and the RADIUS servers that perform authentication, authorization, and accounting. When configured as a RADIUS proxy, an NPS will record information in the accounting log about the messages that it passes on from RAS clients to the RADIUS servers. NPS functions as a RADIUS client when it is configured as a RADIUS proxy.

You should deploy NPS as a RADIUS proxy when you need to provide authentication and authorization for accounts from other AD DS forests. The NPS RADIUS proxy uses the realm name (which identifies the location of the user account) portion of a user name to forward the request to a RADIUS server in the target forest. This allows connection attempts for user accounts in one forest to be authenticated for the network access server in another forest. Using a RADIUS proxy for inter-forest authentication is not necessary when both forests are running at the Windows Server 2003 functional level or higher and a forest trust exists.

You should also deploy NPS as a RADIUS proxy when you need authentication and authorization to occur against a database other than the Windows account database. Connection requests that match a specific realm name are forwarded to a RADIUS server, often running on a platform other than Windows, that accesses a separate database of user accounts and authorization data. Hence, you would deploy NPS as a RADIUS proxy when authentication and authorization have to occur against a RADIUS server that uses Novell Directory Services or one that runs on UNIX.

A final reason to consider the deployment of NPS as a RADIUS proxy server is when you need to process a large number of connection requests between RAS RADIUS clients and RADIUS servers. An NPS RADIUS proxy can load balance traffic across multiple RADIUS servers—something that is difficult to configure when dealing with just RADIUS clients and RADIUS servers.

Remote Access Accounting

You can configure NPS to perform RADIUS accounting. RADIUS accounting allows you to keep track of who is connecting and who has failed to connect to your RADIUS infrastructure. You can use NPS accounting to monitor the following information:

• User authentication requests

• Access-Accept messages

• Access-Reject messages

• Accounting requests and responses

• Periodic status updates

As Figure 9-7 shows, you have two separate ways of recording log data. Logs can be stored locally or written to a database in Microsoft SQL Server 2005 SP1, SQL Server 2008, or SQL Server 2008 R2. Locally written logs are suitable if you have a small number of remote access clients. If you have a significant number of remote access clients, writing data to a SQL Server database will provide you with a much better way of managing what is likely to be a mountain of information.

Local File Logging

NPS log files can be written in two formats: IAS and database-compatible. The default format is database-compatible. The frequency at which new log files are created should be adjusted to suit your organization’s needs. The benefit of having a single file of unlimited size is that locating a specific event is simpler, because you have to search for only one log file. The drawback of larger log files is that on systems where a log of NPS accounting data is logged, the log files can become huge, making the process of opening them and searching them difficult.

Although logs are written by default to the %Systemroot%/System32/LogFiles folder, Microsoft recommends that you keep log files on a partition separate from the operating system and application or file share data. Log files, unless strictly monitored, have a way of filling all available disk space. If this happens on a critical partition, the server could become unavailable. It is very important to note that NPS accounting data logs are not deleted automatically. You can configure the log retention policy to ensure that older log files are deleted automatically when the disk is full. This works best when log files are written to an isolated partition, so that the only impact of a disk that is full of NPS log files is on the storage of existing NPS log files. If NPS log files must be stored on a partition with other data or on the same volume as the operating system, you should consider writing a script that automatically removes logs when they reach a certain age.

Log files can be written to remote shares. This is done by specifying the UNC path of the share. If you configure this option, it will be necessary to ensure that the share permissions are configured to allow the account that writes the logs to write data to the shared folder. The Log File tab of the Local File Logging properties dialog box is shown in Figure 9-8.

Configure SQL Server Logging

The alternative to logging NPS accounting data locally is to have it written to a computer running SQL Server that is installed either locally or on the local network. NPS sends data to the report_event stored procedure on the target computer running SQL Server. This stored procedure is available on SQL Server 2000, SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2.

You can configure which NPS accounting data is sent to the computer running SQL Server by selecting options in the SQL Server Logging properties dialog box shown in Figure 9-9. Clicking Configure in this dialog box allows you to specify the properties of the data link to the computer running SQL Server. When configuring the data link properties for the SQL Server connection, you must provide the server name, the method of authentication that will be used with the computer running SQL Server, and the database on the computer running SQL Server that you will use to store the accounting data. Just as it is a good idea to have a separate partition on a computer to store NPS accounting data, it is a good idea to have a separate database that stores NPS accounting data.

Remote Desktop Gateway Servers

Remote Desktop Gateway (RD Gateway) servers allow Remote Desktop Protocol (RDP) over HTTPS connections to RDP servers located on protected internal networks to clients on the Internet. This functionality allows clients on the Internet to access RemoteApp applications, standard Remote Desktop Server sessions, and remote desktop sessions to appropriately configured clients.

An advantage of RD Gateway is that you do not need to set up RAS VPNs to grant access to resources. Instead of having to deploy client connection kits to everyone in the organization that needs to be able to access resources from the Internet side of the firewall, you can email them an RDP shortcut file and allow them to connect with their clients running Windows XP SP2, Windows Vista, or Windows 7. RD Gateway is essentially an SSL VPN that is restricted to RDP. With a regular VPN connection, you can access all resources directly once connected (in theory, anyway). For example, a VPN can be used to connect to internal file shares and shared printers. With RD Gateway, you can access an RDS server or remote desktop session and, through that, access resources such as shared drives and printers.

Follow these steps to configure an RD Gateway server:

1. Install the RD Gateway Role Service on a computer running Windows Server 2008 R2 that is located on a screened subnet. The perimeter firewall should be configured so that the RD Gateway server is accessible on port 443.

2. Obtain an SSL certificate. The certificate name must match the name that clients use to connect to the server. Install the certificate on the server and then use the RD Gateway Manager console to map the server certificate. It is important that you only use RD Gateway Manager to map the SSL certificate. If you use another method, the RD Gateway server will not function properly.

3. Configure Remote Desktop Connection Authorization Policies (RD-CAPs) and Remote Desktop Resource Authorization Policies (RD-RAPs). (These are covered in the next section.)

Connection Authorization Policies

Remote Desktop Connection Authorization Policies (RD-CAPs) specify which users are allowed to connect through the RD Gateway server to resources located on your organization’s internal network. This is usually done by specifying a local group on the RD Gateway server or a group within AD DS. Groups can include user or computer accounts. You can also use RD-CAPs to specify whether remote clients use password or smart-card authentication to access internal network resources through the RD Gateway server. You can use RD-CAPs in conjunction with NAP; this scenario is covered in more detail in Lesson 2, “Firewalls and Network Access Protection”.

Resource Authorization Policies

Remote Desktop Resource Authorization Policies (RD-RAPs) are used to determine the specific resources on an organization’s network that an incoming RD Gateway client can connect to. When you create an RD-RAP, you specify a group of computers that you want to grant access to and the group of users that you will allow this access to. For example, you could create a group of computers called AccountsComputers that will be accessible to members of the Accountants user group. To be granted access to internal resources, a remote user must meet the conditions of at least one RD-CAP and at least one RD-RAP.

Lesson Summary

• SSTP piggybacks PPP over HTTPS. The SSL certificate installed on the RAS server must match the host name that the SSTP client is connecting to. SSTP can be used only by clients running Windows 7 and Windows Vista SP1. SSTP cannot be used for site-to-site tunnels.

• IKEv2 VPNs can be used only by clients running Windows 7 that are connected to VPN servers running Windows Server 2008 R2. IKEv2 VPNs support the VPN Reconnect feature.

• DirectAccess is an always-on IPv6 remote access technology. DirectAccess is supported only on Windows 7 Enterprise and Ultimate editions and requires a DirectAccess server running Windows Server 2008 R2.

• NPS servers can be configured to write accounting data to local log files or to computers running SQL Server that have the report_event stored procedure available.

• RADIUS proxies are a useful way of load balancing requests from RAS servers to RADIUS servers.

• RD Gateway servers provide another method of remote access, allowing clients running Windows Vista to connect to RDP servers using port 443.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 1, “Managing Remote Access.” The questions are also available on the companion CD if you prefer to review them in electronic form.

1. Which of the following VPN protocols would you deploy if your firewall blocked all traffic from the Internet except traffic on TCP ports 25, 80, and 443?

   1. L2TP/IPsec

   2. SSTP

   3. PPTP

   4. IKEv2

2. Users at your organization have all been issued laptops running Windows 7 Enterprise edition. These users often need to place their computers into hibernation and do not want to have to reauthenticate to access their VPN connection when they resume using them. Which of the following VPN protocols allows users to reconnect to a VPN session that they initiated in the last few hours when they resume from hibernation?

   1. L2TP/IPsec

   2. SSTP

   3. PPTP

   4. IKEv2

3. Which of the following clients can connect to your organization’s VPN server running Windows Server 2008 R2 if the only ports that are available for VPN connections are ports 25, 80, and 443? (Each answer is a complete solution. Choose all that apply.)

   1. Windows Vista with SP1

   2. Windows 7

   3. Windows XP Professional with SP3

   4. Microsoft Windows 2000 Professional with SP2

4. Servers VPN1, VPN2, and VPN3 host the RAS server role and accept incoming VPN connections from clients on the Internet. Server NPS1 is configured as a RADIUS server using the NPS server role. Servers VPN1, VPN2, and VPN3 use NPS1 to authenticate incoming connections. Server SQL1 is a computer running Windows Server 2008 R2 that has SQL Server 2008 R2 installed. You want to improve your ability to search through RADIUS accounting data. Which of the following strategies should you pursue?

   1. Configure VPN1, VPN2, and VPN3 so that NPS accounting data is forwarded to SQL1.

   2. Configure VPN1, VPN2, and VPN3 so that NPS accounting data is forwarded to NPS1.

   3. Configure SQL1 so that NPS accounting data is forwarded to server NPS1.

   4. Configure NPS1 so that NPS accounting data is forwarded to server SQL1.

5. Computers running which of the following operating systems are able to use DirectAccess to access your organization’s internal network from locations on the Internet?

   1. Windows XP Professional with SP3

   2. Windows Vista Enterprise edition

   3. Windows 7 Enterprise edition

   4. Windows 7 Home Premium edition