Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Securing Traditional Remote Access Portals

Remote access portals are those created by using specific devices, protocols, and techniques to facilitate trusted access to internal resources from outside the network. Trusted access is defined as approved access by employees, contractors, partners, and customers. It is typically protected by authentication requirements and may be restricted by conditions and protected via encryption. Windows Server 2003 provides several types of remote access through its Routing and Remote Access Services (RRAS) and Internet Authentication Services (IAS). RRAS provides

Dial-up access via the public telephone network

Virtual Private Network (VPN) connections over the dial-up connection

VPN connections over private Wide Area Networks (WANs)

VPN connections over the Internet

Remote Access Policies to manage and control access

Selection of encryption protocols

Selection of authentication protocols

IAS, Microsoft's implementation of RADIUS, provides additional functionality. RADIUS, or Remote Authentication Dial-In User Service, is a remote authentication, authorization, and accounting service often implemented on a server to manage remote access to a network. It provides

Additional constraints
Authorization for connections is judged against more conditions than RRAS alone can provide, and authorized connections can be further constrained by additional profile attributes.

Centralized authentication, accounting, and authorization services
IAS can manage these services for many RRAS servers. The servers are established as RADIUS clients of the IAS server. When this is so, only Remote Access Policies on the IAS server will be in effect.

RADIUS proxy
The RADIUS server can proxy connection requests to the organization's ISP and forward them to an IAS server on the organization's network.

Network Access Quarantine Control
Each client connection can be quarantined until the client proves compliance with security policy.

802.1x authentication services
Wireless client authentication and key management is provided.

To manage and secure remote access, configure:

Authorization
Identify which users and computers can connect to the network remotely and what they can do once they are connected. This includes the configuration of Network Access Quarantine Control, a new service provided by Windows Server 2003 IAS.

Authentication
Specify how users and computers can prove they are the accounts authorized for remote access.

Accounting (auditing)
Configure what events and details will be recorded about the remote access connection.

Communication Protection
Set encryption for dial-up connections and/or configure VPN protocol choices.

Wireless Communication Security
Configure 802.1x authentication and security for wireless access.

The use of IAS to configure 802.1x authentication is discussed in the section "Securing Wireless Access Using IAS"; the rest of these topics are included here after brief instructions for the secure installation of Windows Server 2003 RRAS and IAS and the configuration of client-side remote access connections.

Secure Installation of Windows Server 2003 RRAS and IAS Preparation

The first step in providing secure remote access services is to plan a secure installation. No amount of hardening or secure procedures will matter if the machine is compromised before being used for remote access. Management should provide an organizational Remote Access Policy; however, you may be required to provide services without one. You should insist on management approval for

The plan

The groups of individuals allowed to remotely access the network

Provisions for the proper purchase of equipment and software

Time necessary to provide secure remote access

You cannot create a plan for remote access deployment until you know the remote access capabilities and the security provisions available. Use the information in this chapter, your knowledge of your networks, policies, and procedures, and your knowledge of the technologies to create that plan. The processes described next provide the details necessary for the second stepsecure installation of the services. Before installing them on a production network, you should create your plan; however, to examine the configuration information discussed in future selections, you may want to install them on a test network.

Before installing RRAS or IAS, install a secure Windows Server 2003 computer. To do so, provide the necessary hardware (modem or additional network interface cards) and use the usual precautions:

Install the operating system isolated from the network and the Internet.

Apply the most recent service pack and security hotfixes before connecting the system to a test network.

Follow your organization's security baseline for new servers. If the security baseline includes disabling RRAS and other related remote access services, enable them after using the security baseline during the installation. (By default, RRAS is installed but not started.)

Determine which type of remote access portal you will use.

Install RRAS or IAS as detailed in the following section. IAS and RRAS can be installed on the same computer, but IAS can also be installed on its own server.

Chapter 11, "Securing Infrastructure Roles," has recommendations for developing a security baseline and provides information on ways to manage this across multiple systems.

Install and Configure RRAS

To use RRAS as a remote access portal, you must configure the type(s) of access it will provide. Your choice will depend on the type of remote access you need to provide. The choices are

Dial-up

Client/Server VPN

Demand-Dial (Router-to-Router) VPN

Dial-up access is provided via ordinary phone system connections and uses the point-to-point communications protocol (PPP). You can supplement authentication and communications protection by also configuring and requiring the use of a VPN. A Virtual Private Network (VPN) provides a simulated point-to-point connection between two networks across a third. When a VPN connection is used, the logical connection appears to be directly between the two networks. A dial-up connection may actually travel through many telephone system switches and even across multiple systems owned by different companies. A VPN connection across a private WAN or across the Internet may start with a connection to the ISP and travel over many networks to reach the VPN server. In both cases, it appears to the user and the computer that the connection is simply between the computer and the VPN server. The VPN logical connection and real network route is illustrated in Figure 14-1.

The previous VPN example is the one most commonly understood and is known as the client/server VPN. A client computer running client VPN software connects to a VPN server. If configured, data is both tunneled and encrypted as it travels from the client to the server. Note, as shown in Figure 14-2, that once the data leaves the VPN server, unless connections have been figured for encrypted communications, the data is not encrypted.

The demand-dial or router-to-router VPN, another type of VPN, can also be configured between two Window Server 2003 VPN servers. This type of VPN connection provides a tunneled and encrypted communications path between two networks over a third but does not require the client computers on either network to install a VPN client or participate in the VPN connection. Instead, if data leaving the local network for the remote network is routed through the VPN server on the local network, it will automatically use the tunnel and be encrypted.

Don't let the name "demand-dial" confuse you. The connection can be configured to occur on demand and can be used to connect two VPN servers over the telephone network. However, a demand-dial VPN can also be configured to use the Internet and to remain always connected (a persistent connection). Figure 14-3 illustrates a demand-dial VPN. In the figure, a client computer on the branch office network can communicate with the network at headquarters by using VPN server branch office. A demand-dial connection exists between the branch office VPN router and the headquarters VPN router. Note that data from the computers on the branch office network to the branch office VPN server will not be encrypted or tunneled. Likewise, data from the headquarters VPN server to any computers on the headquarters network will not be encrypted or tunneled. If protection for data between the computers on either network and the VPN server is required, IPSec policies or other encryption could be provided for these connections, as shown in Figure 14-3.

If the connection will not be available at all times, configure the connection as demand-dial. In this case, when data must be sent from one network to the other, the VPN server initiates the connection to the other VPN server. To illustrate this action, consider the following process:

Enabling RRAS and Configuring RRAS for Dial-Up and VPN Connections

To install RRAS on a prepared Windows Server 2003 server, follow these steps:

When Routing and Remote Access is selected for authentication, the RRAS server will use its local user database or, if it is joined in a domain, the Active Directory database to authenticate users. If the centralized services of an IAS server will be required, you have to configure IAS as the authentication and/or accounting source.

Each configuration made using the wizard can be modified later. The use of RADIUS or Windows for authentication and/or accounting and the client IP addressing selection are configured from the Property pages (right-click the server and select Properties). Additional PPTP and/or L2TP/IPSec ports, as well as network interface selection, are configured from the RRAS console Ports and Network Interface containers, respectively.

Configuring RRAS as Demand-Dial VPN

It is not difficult to configure a demand-dial VPN, but it can be confusing. Several pieces of information must be configured, and some of them must match their counterparts on the other server. To make it easier to do so, keep these two key pieces of information in mind. First, the name of the interface becomes the name of the user account necessary to access that interface. The account will be created for you if the option is selected during the configuration process. This account becomes the dial-in account name referenced in the setup wizard. Second, the user account, the dial-out account requested in the setup wizard, which will be used to make a connection to the opposite VPN server, is the dial-in account name of the opposite VPN server. To configure a demand-dial VPN, follow these steps:

After the wizard is complete, you can configure additional settings to meet specific needs and to secure the connection. Settings relate to callback, encryption, authentication, and other restrictions. For example, you may want to change the connection to Persistent (always connected), configure encryption, and set allowed authentication methods and secure the connection by requiring callback to use the phone number of the other VPN router.

Persistence and Restrictions

Demand-dial connections can be configured to provide connection over IP networks and telephone networks. When configuring connections over IP networks, you may want the connection to stay up at all times. In this case, configure the connection to be persistent by double-clicking the demand-dial interface in the Network Interfaces node of the RRAS server to open the Property pages, selecting the Options page, as shown in Figure 14-9, and then clicking to select the Persistent connection radio button.

Use the other options on this page to restrict idle time and set the dial policy for redial attempts and redial intervals.

Callback

Requiring callback for a demand-dial connection can prevent connections from non-authorized computers. Callback can be configured in a Remote Access Policy, or on a standalone router, it may be configured in the Property pages of the demand-dial interface. To configure callback in the Property pages, follow these steps:

Encryption and Authentication

Encryption and authentication are set by default to use a secure password and to require encryption. The strongest encryption should always be used, although you may need to reduce the encryption strength if you must connect to a down-level version of the operating system. To change these settings, follow these steps:

No encryption allowed (server will disconnect if it
requires encryption)
Options encryption (connect even if no encryption)
Require encryption (disconnect if server declines)
Maximum strength encryption (disconnect if server declines)

If L2TP/IPSec is configured for the demand-dial connection, configure the pre-shared key password for this connection by clicking the IPSec Settings button from the Security Property page. The entered password is in clear text, as shown in Figure 14-12, and hence is visible to anyone with the ability to review the Property pages of the demand-dial connection. Don't forget to enter the same password on the other router's configuration pages.

Installing and Configuring IAS

Installing and configuring IAS requires several steps, including installation, configuring a connection request policy, and configuring RRAS servers to act as RADIUS clients.

To install IAS on a prepared Windows Server 2003 server, follow these steps:

To configure the connection for each RADIUS client, follow these steps:

A connection request policy is a policy that IAS uses to manage the requests from RRAS servers or a RADIUS proxy or to configure the IAS server to forward requests to another RADIUS server for authentication (be a RADIUS proxy). A default connection request policy is configured to authenticate connection requests from a RRAS server-based VPN connection or from a direct dial to the IAS server. You can customize this connection request by making selections from its Property pages, or you can create your own customized connection request using the wizard. To use the wizard, follow these steps:

To configure a RRAS server to use RADIUS for authentication follow these steps:

RADIUS Ports for Firewall and IPSec Policy Configuration

The typical placement of the RADIUS server that will be used by Internet connections and the VPN server is behind the firewall on the Perimeter network. To allow access, you may need to configure VPN protocol ports and/or RADIUS ports on the firewall. In addition, if IPSec policies are configured between RADIUS clients, proxies, and servers, the filters must be configured for RADIUS traffic. Table 14-2 lists the RADIUS ports and indicates how they are used.

Configure Clients to Use Remote Access

Clients can be individually configured to use remote access connections. However, this makes managing clients difficult. To manage clients, use the Connection Manager Administration Kit (CMAK) to create client profiles. The Connection Manager (CM) profile is a self-executing file that installs a preconfigured dialer and any provided scripts on the client computer. Creating profiles ensures consistency in configuration for each Windows OS. In addition, custom actions, such as the running of a Network Access Quarantine Control script, can be configured for each phase of the connection.

In addition to a dialer, a Phone Book can be created, which will provide traveling users with a listing of the phone numbers for every location. The Phone Book can be updated online from an FTP server configured as a Phone Book server.

TIP: CMAK on Installation CD

The CMAK is provided on the Windows Server 2003 installation CD-ROM but is not installed by default. You can install this tool by running the adminpak.msi program from the I386 folder on the installation CD-ROM. To create a profile, run the Connection Manager Administration Kit program from Start, Administrative Tools. A tutorial on setting up a Connection Manager profile can be downloaded at http://www.microsoft.com/downloads/details.aspx?FamilyID=93fd20e7-e73a-43f6-96ec-7bcc7527709b&DisplayLang=en Authorization.

Regardless of technology, you must grant authorization for remote access before any remote access can occur. You may need to configure both account dial-in permissions and Remote Access Policy.

Configure User Account Properties for Remote Access

By default, remote access authorization is not granted to any account. Access is set on the user's dial-in Property page to deny access. However, if the RRAS server is a standalone remote access server, or when a Windows Server 2003 domain is raised to Windows Server 2003 functional mode, the dial-in page of new accounts will indicate that access depends on Remote Access Policies, as shown in Figure 14-19. This option will still deny the user remote access by default because the default Remote Access Policy is set to deny access, as shown in Figure 14-20. To manage user accounts in an efficient manner, use Remote Access Policies.

TIP: Servers as Clients to Switches

Windows Server 2003 computers can also be configured as remote access clients. One of the computer account Properties pages is a dial-in page. This feature might be used so that an 802.1x Ethernet client could use EAP-TLS and a computer certificate to authenticate to an authenticating Ethernet switch.

The dial-in Property page selections Deny, Allow, and Control Access Through Remote Access Policy have the following impact on remote access:

If an account is configured to Deny remote access, a connection attempt will be denied. However, if the IAS profile constraint that ignores user dial-in properties is set, access might still be granted.

If an account is configured to Allow remote access, Remote Access Policies can still terminate the connection.

If RRAS is installed on a Windows Server 2003 standalone computer or after you raise a Windows Server 2003 domain to Windows 2000 or Windows Server 2003 functional level, new account default dial-in permissions become dependent on Remote Access Policy by default.

If access is managed via Remote Access Policies, the connection is controlled by a combination of account dial-in properties and Remote Access Policy constraints unless the Remote Access Policy settings are configured to ignore user dial-in properties.

NOTE: Control Access Permissions

By default, no account has authorization to remotely dial-up or VPN to the network. The first step in securing remote access is to carefully control this permission. Require management approval before granting any user remote access capability.

In a simple remote access scenario, accounts are granted remote access permissions by individually configuring each account approved for access. Once the selection Allow Access is made, the choices, as displayed previously in Figure 14-19 and as described in Table 14-3, can be configured. Some of these choices add no additional security.

It is important to provide dial-in Property page configuration to manage specific accounts; however, if the user will use multiple remote access methods, such as dial-in and wireless, a conflict may occur. For example, wireless access does not use a phone number; therefore, setting the callback feature on the user's dial-in Property page may prevent a wireless connection. Wireless and dial-up connections can be made from the same user account if IAS Remote Access Policies are used. If correctly configured, an additional constraint can block the use of dial-in page settings when wireless access is requested.

Remote Access Policies

Remote Access Policies are used both to make management of remote access simpler and to provide additional access restrictions based on Windows groups, the type of connection, time of day, and by profile constraints that apply to the authorized connection. If the authentication choice for a RRAS server is set to Windows Authentication, the Remote Access Policies configured on the RRAS server are used to manage the connection. However, if authentication is configured to use RADIUS, and a Windows IAS server is designated as the RADIUS server, remote access policies on the IAS server are used to manage the connection. Table 14-4 lists the items that can be configured via Remote Access Policies. You can only configure some Remote Access Policy constraints if you are using IAS, and they are marked in Table 14-5 as (IAS only).

If the connection request meets the conditions set by an RRAS or IAS Remote Access Policy, RRAS or IAS evaluates the Allow or Deny authorization property of the Remote Access Policy or the dial-in Property page. RRAS or IAS will evaluate the Remote Access Policy profile properties if the setting is Allow. The Remote Access Policy profile properties can further constrain or deny the connection. The constraints configured in the profile will only affect connections that meet the conditions set by the Remote Access Policy. Table 14-6 lists and describes these items.

Configuring Remote Access Policies

To configure a simple Remote Access Policy, follow these steps:

To configure a custom policy and edit the profile, follow these steps:

The Remote Access Connection Process

When an RRAS server receives a request, authentication is evaluated according to the RRAS server settings, which is discussed in the section "Authentication." However, regardless of the authentication setting, the remote access connection request is evaluated by the RRAS or IAS server by considering the account dial-in Property pages and Remote Access Policies.

A default Remote Access Policy specifies that unless individual access permissions are specified in the user profile, this policy controls access to the network. The default policy also specifies Deny remote access permission. This means that setting individual user dial-in properties can control user access. The RRAS and IAS default connection process follows these steps:

If a Remote Access Policy is evaluated, these steps are followed:

Configure Authentication and Auditing for RRAS and IAS

Authentication and Auditing (often called accounting in RADIUS discussions) is a very important part of your RRAS and/or IAS configuration. Standalone RRAS servers are each configured separately. In the typical Windows Server 2003 IAS implementation, Authentication and Auditing are configured on the IAS server. This provides centralized management of these features. Configuring one server manages Authentication and Auditing for all the remote access servers that act as RADIUS clients for the IAS servers.

Authentication

The first authentication consideration when configuration RRAS is the selection of Windows authentication or RADIUS authentication. By default, both use the local Windows Server 2003 account database of a standalone RRAS server or the domain account database if the RRAS server is a member server. However, Windows authentication provides a local selection of PPP remote access authentication protocols and the use of local Remote Access Policies. Multiple RRAS servers can exist independently on the network. Synchronization of their configuration and Remote Access policies can only be manually done if Windows authentication is selected. If RADIUS is selected as the authentication mechanism, the RRAS server acts as a RADIUS client and forwards authentication, accounting, and auditing requests to the IAS server. In this case, only the Remote Access Policies configured at the IAS server are used.

The second authentication consideration is the selection of authentication protocols. Table 14-7 lists and describes the possible remote access authentication protocols.

To configure authentication protocols, follow these steps:

Accounting (Auditing)

Logging for both RRAS and IAS consists of entries in the Windows event logs as well as RRAS- and IAS-specific logs. By default, connection requests are not logged, and only service start and stop events are recorded in the event logs. You should configure additional logging in order to record information for troubleshooting and security events. Logging connection attempts and successes is useful for troubleshooting but also can assist in tracing remote access as well as attempted and successful attacks. The service-specific logs, if configured, include information about each connection request. Logging can also be redirected to a Microsoft SQL server or to a named pipe. A named pipe is a pipe that has been given a name. Pipes are a form of interprocess communication (sharing of information between processes). Pipes are a one-way or duplex connection point to a running process, and they might be used to send information to another computer. When RADIUS accounting is selected, and IAS is used as the RADIUS server, the logging from all RRAS servers can be collected on the IAS server. To configure the location for accounting, select the accounting provider from the Security page of the RRAS properties, as shown in Figure 14-30. If RADIUS Accounting is selected, the Configure… button can be used to enter the name of the RADIUS servers that are available.

Configure additional event logging on the Logging tab of the RRAS server properties. (Right-click the server in the Routing and Remote Access console, select Properties, and then click the Logging tab.) Log all events to capture information related to access events, as shown in Figure 14-31.

To configure request logging, select the Remote Access Logging folder in the Routing and Remote Access console, double-click the log file type in the detail pane, and select boxes for accounting and authentication requests, as shown in Figure 14-32. If RADIUS accounting has been configured for the RRAS server, use the Remote Access Logging folder in the IAS server console. The Property pages will look the same.

The Log File tab, as shown in Figure 14-33, can be used to change the location for the log file, the log file format, or the frequency of new log file creation.

When additional log file recording is configured, the following information is recorded:

The name of the Remote Access Policy that accepted or rejected the connection attempt

The RRAS server IP address

User name

Record date

Record time

Service name

Computer name

Attribute value pairs, which specify items such as routing information, IP address configured for the user, tunnel information, and reason codes (such as success or a reason for the rejection)

TIP: Find More Attribute Definitions

A full list of attributes is provided in the product documentation and can be located online in the article "Interpreting IAS-Formatted Log Files" at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/sag_ias_log1a.asp.

VPN Protocol Consideration

Communication protection is provided both by the selection of protocol and by its configuration. Dial-up connections can be protected by encryption if configured to do so; however, using a VPN provides more control and protection. Three protocols may be defined for use in a Windows Server 2003 VPN:

Point-to-Point Tunneling Protocol (PPTP)

Layer 2 Tunneling Protocol over IP Security (L2TP/IPSec)

IPSec tunnel mode

Each provides sound protection for data traveling across a VPN. However, some protocols are more suitable in some circumstances than others, and some cannot be used in certain situations. The following PPTP and L2TP/IPSec considerations should be reviewed before selection and configuring a specific VPN communications protocol.

PPTP Considerations

PPTP was developed by Microsoft but is an IETF standard. It can tunnel and encrypt multiprotocol traffic across an IP network. Additionally:

PPTP provides the tunnel and Microsoft Point-to-Point Encryption (MPPE) provides encryption. MPPE uses the RSA/RC4 algorithm and 40-bit, 56-bit, or 128-bit encryption keys.

To use encryption with PPTP, you must use one of the following authentication protocols:

Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP).

MS-CHAPv2.

Extensible Authentication Protocol-Transport Level Security (EAP-TLS).

The PPTP tunnel negotiates authentication, compression, and encryption.

The initial encryption key is generated during user authentication and is periodically refreshed.

PPTP encrypts only the data payload. Figure 14-34 shows the PPTP packet and identifies the encrypted area.

PPTP and L2TP/IPSec support dynamic assignment of client addresses.

L2TP/IPSec Considerations

L2TP is a combination of Cisco Layer 2 Forwarding Protocol (L2F) and Microsoft PPTP. In addition:

L2TP can tunnel data across any network that transports PPP traffic, such as IP, Frame Relay, and Asynchronous Transfer Mode (ATM) networks.

L2TP uses User Data Protocol (UDP) over IP messages for tunnel management.

L2TP sends encapsulated PPP packets over UDP, and payloads can be encrypted and compressed.

IPSec Encapsulating Security Payload (ESP) encrypts L2TP VPNs by using an automatically generated IPSec policy that uses IPSec in transport mode.

IPSec ESP encryption encrypts more than the data payload portion of the packet. Figure 14-35 illustrates the packet and identifies the encrypted portion.

L2TP/IPSec VPNs require user and mutual computer authentication. Computer authentication for VPNs requires computer certificates.

L2TP/IPSec is generally considered more secure and does offer additional security beyond what PPTP offers.

L2TP/IPSec may not work behind a Network Address Translation (NAT) server.

IPSec in Tunnel Mode Considerations

IPSec tunnel mode has limited use as a VPN on a Windows Server 2003 network. Consider the following:

IPSec in tunnel mode is usually used to connect a Windows Server VPN server with a device, such as a router, that does not use L2TP.

In IPSec tunnel mode, IP packets are encrypted using IPSec and tunneled across an IP network.

IPSec in tunnel mode can be used for a demand-dial or client/server VPN.

However, its use for user remote access VPN is not supported.

The use of IPSec filters to allow or block communications using specific protocols or ports is not supported in IPSec tunnel mode.

L2TP/IPSec, NAT, and NAT-T

The original L2TP/IPSec standard is incompatible with a NAT server. During processing, a NAT server replaces the IP address of the source computer in outbound packets. This does not cause a problem for most traffic because any responses are delivered to the NAT server, and the NAT server can match the response with the original source and deliver the packets. It does cause a problem for IPSec encrypted packets, however. The standard includes a requirement that the encrypted IPSec protected packets include a checksum calculated over much of the packet and including the IP address of the original source computer. This checksum is used when the packet is received to determine if the packet has been changed during transport. Guaranteeing the integrity of the packet is one of the strengths of IPSec. Because the IPSec encryption occurs before the NAT processing, and NAT cannot decrypt and then re-encrypt the packet with a new checksum, the packet is dropped on receipt because it fails the checksum test. The IPSec decryption process cannot tell the difference between a modification made by a NAT server and an attack.Chapter 15, "Protecting Data in Flight." Windows clients must also be NAT-T compliant. The following updates and clients are available:

Windows XP and the L2TP/IPSec update

Windows 2000 and the L2TP/IPSec update

Windows NT 4.0 and the L2TP/IPSec VPN client

Windows 98 and the L2TP/IPsec VPN client

NOTE: NAT-T Issue

A Windows 2000 server can be a NAT-T client, but a Windows 2000 VPN server cannot utilize NAT-T.

Firewall Ports for VPN Protocols

The following tables list the ports used by VPN protocols. The firewall must be configured to allow these ports if these protocols must traverse the firewall.

Tables 14-8 and 14-9 provide input and output port information for PPTP.

Tables 14-10 and 14-11 provide configuration specifications for L2TP/IPSec.

Network Access Quarantine Control

Network Access Quarantine Control is a new process that can be configured on a Windows Server 2003 computer running RRAS or IAS. When configured, Quarantine Control encourages secure practices by the users of the client computers attempting to remotely access the network. If client computers do not meet the conditions defined by policy and tested by a script, they are prevented from making full, authorized remote access. Instead, they may be directed to a site that describes what they must do to meet policy conditions. Conditions might require the computer to be up-to-date with security patches, running updated and approved anti-virus software, and so forth.

Network Access Quarantine Control may help prevent some forms of attack by providing the support that Remote Access Policies do not. Remote Access Policies set conditions and constraints on remote access connections. Remote Access Policies can require some client connection and communication configuration specifics such as authentication, encryption, and communications protocols. However, the security status of the client system is not checked. VPNs and encryption do not inspect the traffic that they protect. Indeed, an encrypted, authenticated, and authorized connection can transport a virus, Trojan horse, or other malicious code. In addition, a compromised client computer might be used to attack the network over the protected remote access connection. If a determined attacker has access to authorized credentials, Network Access Quarantine Control will not prevent his directed attacks from being successful. However, Network Access Quarantine Control can require that a client connecting remotely has security configuration in place, which may prevent the spread of virus infection and automated Trojan horse attacks. Clients that are up-to-date with security patches will also be less likely to be compromised.

For Network Access Quarantine Control to be used, both a quarantine-compatible remote access client and a compatible remote access server must be available. Clients can be configured by developing a Connection Manager (CM) profile using the Connection Manager Administration Kit (CMAK), which is provided with Windows Server 2003. Compatible clients are as follows:

Windows Server 2003

Windows XP Professional

Windows XP Home Edition

Windows 2000

Windows Millennium Edition

Windows 98 Second Edition

A compatible remote access server is a Windows Server 2003 Routing and Remote Access Service and a listener component (rqs.exe). The listener component listens for messages from the clients. If Windows authentication is configured, a RADIUS server is not required. If RADIUS authentication is configured, a Quarantine Controlcompatible RADIUS server, such as IAS, is required.

When a connection is made and the client is placed in quarantine, Network Access Quarantine Control has the following restrictions:

Quarantine packet filters
Restricts the traffic that can be sent to and from a quarantined remote access client.

Quarantine session timer
Restricts the amount of time a client can be connected in quarantine mode.

When a Network Access Quarantine Control Remote Access Policy is added to an RRAS server, the process works like this:

If a client is not configured with the CM profile and therefore cannot run the script, and the Remote Access Policy that specifies the use of the process is the only Remote Access Policy, the client is placed in quarantine and cannot complete its remote access connection.

TIP: Some Clients Are Not Compatible With Network Access Quarantine Control

Network Access Quarantine Control cannot be used with wireless clients and authenticated switch clients. However, these clients must have a domain account for computer authentication; therefore, configure a network policy compliance script to run as part of the computer's startup and logon sequence.

Configuring Network Access Quarantine Control

Network Access Quarantine Control is configured after the IAS server is installed and configured for normal usage. Then, the following steps are taken:

To install the Remote Access Quarantine Agent Service, use other Network Access Quarantine Control items and install the Windows Server 2003 Resource Kit tools on the remote access server:

To configure the Quarantine Remote Access Policy, follow these steps: