The previous article in this series discussed improvements made to IPSec in Windows Server 2003. This article expands on this topic with an examination of the security-related enhancements made in Routing and Remote Access Service (RRAS) and Internet Authentication Service (IAS), specifically:
- Support for L2TP/IPSec over NAT
- Network Access Quarantine
- NetBIOS-related enhancements
- EAP-TLS improvements
- Improved remote access client support
- IAS Proxy
RRAS was introduced as a built-in component in Windows 2000 Server (but it is also available as an add-on for Windows NT 4.0 Server). As its name indicates, it combines routing and remote access functionality into a single administrative interface, allowing the server to be turned into a secure, software-based router or a remote access server, or both. IAS (which first appeared in Windows 2000 server) is Microsoft's implementation of Remote Authentication Dial-In User Service (RADIUS), and its primary purpose is to provide authentication, authorization, and accounting functionality for remote access. Because of its role, it closely interacts with RRAS. Hence, this article describes both.
Windows 2003 RRAS has a number of new, nonsecurity-related features. It supports Point-to-Point Protocol over Ethernet (PPPoE), reflecting the growing popularity of broadband communication. It can also function as a bridge, combining separate, mixed media segments into a single networking subnet. What might also be a bit of surprise is the dependency between RRAS and Internet Connection Firewall (ICF), since this component was not available in Windows 2000.
Like its Windows XP equivalent, the new version of ICF operates as a stateful firewall (intended for protecting Internet Connection Sharing), which means it tracks sessions initiated from the internal network and, by default, permits inbound traffic only if it constitutes part of these sessions. In addition, ICF selectively permits incoming traffic based on the targeted port and redirects it to any of internal IP addresses (on the same or a different port). Since the same functionality can be provided by RRAS (configurable from the NAT/Basic firewall tab of the interface properties dialog box in IP Routing node of the Routing and Remote Access MMC console snap-in), Microsoft decided to make them mutually exclusive. However, ICF must be disabled to activate RRAS to take full advantage of the security-related features detailed below.
Support for L2TP/IPSec Over NAT
In recent years, virtual private networks (VPNs) have become the primary choice for providing secure remote connectivity. VPN implementation in both Windows 2000 and 2003 is based on one of two protocols -- Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP). Although PPTP is inferior when it comes to security (although in Windows 2003 it can be configured to use certificates by employing Extensible Authentication Protocol), in the past it was the preferred solution because of its simplicity and compatibility with older Windows platforms. It was also the only way to provide direct secure remote access to RRAS residing behind the NAT firewall in Windows 2000 (since IPSec was not NAT-aware).
This changed in Windows Server 2003 with the introduction of NAT-T (Transparent), as described in the previous article of this series. In addition, you can use L2TP/IPSec in Windows NT 4.0, 98, and ME, thanks to the new L2TP/IPSec client, which makes it the preferred choice for remote access even for legacy clients.
Important to note, however, is that L2TP/IPSec is more complex to configure and troubleshoot, it requires more processing power from systems participating in secure communication (this can be mitigated by using network adapters supporting IPSec in hardware), and it relies on the availability of Public Key Infrastructure with Certificate Authority.
Both L2TP and PPTP enable secure communication with any of Windows 2003 servers, including Web edition. In this case, however, it is limited to a single connection only.
Network Access Quarantine
When a remote client authenticates against Windows Server 2003, an administrator now has the (previously not available) option of invoking the client's quarantine. Thus, access to the internal network is not automatically granted (as it was in the case of Windows 2000 RRAS). Instead, a client's configuration is first evaluated against custom policies. If the results of the evaluation are not satisfactory, the connection is automatically terminated. The configuration of policies is fully customizable but often includes such checks as system service pack or security patch level, presence (or absence) of security-sensitive components (such as routing), Internet Connection Firewall, password-protected screen savers, and up-to-date antivirus software. The system administrator must implement these checks in the form of custom actions, such as batch files, scripts, or executables.
The mechanism of Network Access Quarantine is based on interaction among a number of different components. On the client side, it requires Windows 98, Millenium, 2000, XP (both Home and Professional), or Windows 2003 servers, since these versions are capable of using connection manager profiles configured with the Connection Manager Administration Kit utility, which is part of Windows Server 2003 Administrative Tools.
The profiles contain, among other settings, a set of custom actions described above (which are specified as Post-connect actions on the Custom Actions page of Connection Manager Administration Kit Wizard). Client systems must also have a notifier component installed that will relay results obtained by the quarantine script to a listener component running on RRAS server. Microsoft provides such programs (RQC.EXE and RQS.EXE, respectively) as part of its Windows Server 2003 Resource Kit, which is downloadable from its Web site. It is also possible to use third-party equivalent software.
In addition, you must define the new Remote Access Policy specific for Network Access Quarantine on a Windows Server 2003. The location of the policy will depend on which authentication provider is used. Windows Authentication provider will activate the Remote Access Policy node in Routing and Remote Access MMC snap-in, and RADIUS Authentication provider requires the Remote Access Policy node in the Internet Authentication Service MMC snap-in. A new policy must be configured for VPN access method (specified on the Access Method page of the New Remote Access Policy Wizard). Once the policy is created, the two attributes on the Advanced tab of the policy Profile dialog box must be set and configured.
- MS-Quarantine-Session-Timeout specifies the amount of time, in seconds, during which the new connection can remain in a restricted state before it is disconnected or switched to a nonrestricted state. The time period specified should be long enough to allow the evaluation of custom actions to complete before the connection is terminated.
- MS-Quarantine-IPFilter specifies the IP filter to be used when the connection is in a restricted state. This filter is needed so notification of quarantine results can be sent from the remote access client to the remote access server. Assuming that standard Microsoft tools (RQC.EXE notifier on the client and RQS.EXE listener on the server) are used, you should allow inbound traffic on TCP port 7250. Depending on other configuration options of a client's connection manager profile, you might need to specify other ports, such as UDP port 67 (with source port 68) to allow a DHCP communication, UDP port 53 to allow DNS use, UDP port 137 for WINS related traffic, or TCP ports 139 and 445 for file sharing.
For security reasons, NetBIOS is automatically disabled for each external interface. You can verify this by checking the respective NetBIOS settings on the WINS tab of Advanced TCP/IP Settings dialog box. Note also that Windows 2003 RRAS can operate as NetBIOS over TCP/IP proxy, providing broadcast name resolution on behalf of remote clients. However, this feature causes NetBIOS name resolution broadcasts to be forwarded to internal network interfaces of a RRAS server. Before enabling it, ensure that you understand its bandwidth implications and keep in mind that its intended targets are small environments for which setting up a WINS or DNS server is not economical. The described functionality is controlled by a single checkbox (labeled "Enable broadcast name resolution") on the IP tab of RRAS server Properties dialog box in the Routing and Remote Access MMC snap-in.
Extensible Authentication Protocol (EAP) is not a specific authentication protocol, but instead it is a mechanism allowing negotiation of an authentication scheme between a remote access client and a server (either RRAS or IAS, depending on configuration). Windows Server 2003 includes two built-in authentication schemes: MD5-CHAP (Challenge Handshake Authentication Protocol) and EAP-TSL (Transport Layer Security). MD5-CHAP uses user names and passwords for authentication, just like PPP-based CHAP (the only difference is message formatting). EAP-TSL, which is considered much more secure than its counterpart, employs certificates for authentication and encryption and is the only option when securing remote access with smart cards (where certificates are stored). EAP-TSL was available in Windows 2000 RRAS, but its Windows Server 2003 implementation offers more functionality, such as support for multiple root certification authorities (configurable on per-interface basis, using Network Interfaces node of RRAS server in the RRAS MMC snap-in).
Improved Client Support
When a remote access client connects to a DHCP server, its IP address and subnet mask is typically assigned dynamically from a DHCP server residing on an internal network. However, other parameters, such as WINS- and DNS-related settings, are inherited from a manually configured internal network interface of the RRAS server, which might not always be what you intend to do. The ability to forward DHCP configuration settings to a remote client by a statically configured RRAS server became possible with Windows Server 2003, but is limited to only Windows XP and 2000 clients (on older clients you still need to resort to static assignments). This is because this new feature requires both the client and server be capable of recognizing DHCPINFORM packets. These packets are broadcast by clients and forwarded through the internal interface of the RRAS server configured with DHCP Relay Agent.
Windows 2003 IAS can be configured as a proxy, forwarding authentication, authorization, and accounting traffic between RADIUS clients (i.e., remote access servers) and other RADIUS servers. Such a solution might be required in environments where RRAS and RADIUS infrastructures are maintained by separate organizations or where the authentication database is not directly accessible to a local IAS server. The proxy functionality is configured using Connection Request Policies subnode located under Connection Request Processing node in the IAS MMC snap-in. Within this subnode, you can create multiple Connection Request policies and assign each a processing priority, conditions that must be satisfied for it to be processed, and a profile, which determines how the connection request will be handled.The Authentication and Accounting tabs of each Profile Properties dialog box enables the admin to specify whether to forward such requests to a RADIUS server group for authentication. RADIUS server groups are defined within the Remote RADIUS Server Groups folder under the Connection Request Processing node in the IAS MMC snap-in. They can contain any number of remote RADIUS servers to which connection requests would be forwarded.
This concludes our discussion on RRAS and IAS security-related improvements on Windows Server 2003 platform. The next article in this series will look into innovative ways to practice role-based management with Authorization Manager.