Professional Windows Server 1002003 Security A Technical Reference [Electronic resources]

Roberta Bragg

نسخه متنی -صفحه : 194/ 122
نمايش فراداده

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.

Figure 14-1. The VPN connection simulates a PPP connection.

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.

Figure 14-2. The client/server VPN tunnels and encrypts data as it travels from the client to the VPN server.

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.

Figure 14-3. Provide alternative encryption to create an end-to-end solution.

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:

1.

John Doe is working at the branch office and needs to access a file on a file server on the Headquarters network. He uses the Windows Explorer, Tools, Map Network Drive tool to enter the IP address, 192.168.10.15, of the server and the share name.

2.

The branch office network is configured to route requests for resources on the 192.168.10.0/24 network (a headquarters network subnet) to the branch office VPN server.

3.

The branch office VPN server receives the data and recognizes the destination address as one on the network it is configured to connect to.

4.

The VPN server requests a connection to the remote VPN server. Configured connection parameters must be fulfilled for the connection to occur.

5.

The connection is made.

6.

The request for the drive mapping is evaluated at the remote server in the headquarters network. If authorized, John is connected to the server and can access its resources as if his computer were on the network at headquarters.

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

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

1.

Add the computer account to the RAS and IAS Server security group in Active Directory. (If you are a domain administrator, this is not necessary, because the account will be added automatically when you enable RRAS.)

2.

At the console of the server, open the Start, Administrative Tools, Routing And Remote Access Services console.

3.

Right-click the server icon in the console, select Configure and Enable Routing and Remote Access, and then click Next.

4.

Select Remote Access (Dial up and VPN) and click Next.

5.

Select VPN and click Next.

6.

Select the network interface that is connected to the Internet.

7.

Select Enable security on the selected interface by setting up static packet filters. Static packet filters allow only VPN traffic to gain access to this server through the selected interface and click Next.

8.

If network address assignment for clients will be via an established DHCP server, click Automatic or click From a specific range addresses, and then click Next.

9.

If the property From a specific range of address was selected, use the New button to enter the address range. Click OK, and then click Next.

10.

If Routing and Remote Access will be used for authentication, as shown in Figure 14-4, click Next, and then click Finish.

Figure 14-4. Configuring RRAS for authentication.

11.

If RADIUS will be used for authentication:

In the Managing Multiple Remote Access Servers page, click Yes, setup this server to work with RADIUS, and then click Next.

Enter the name of the primary and secondary RADIUS server and enter the shared secret. Click Next, and then click Finish.

12.

If prompted, click OK to start the RRAS service.

13.

Expand the server in the RRAS console and view the folder, as shown in Figure 14-5. If you selected RADIUS as the authentication provider, the Remote Access Policies container will not be present.

Figure 14-5. Viewing the RRAS console.

[View full size image]

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:

1.

Create a table and enter the configuration parameters for both servers. Table 14-1 is an example of such a table. The parameters entered in the table are examples used to illustrate these steps. They should be replaced with your own data. The parameters in the table will be referenced in these instructions to make them more understandable.

Table 14-1. Demand-Dial VPN Configuration

Parameter

Network One Atlanta

Network Two New York

Router Name

Motorin

Regalinn

IP Address of the opposite router external interface

207.209.66.50

208.147.68.50

Interface name

DD_NewYork

DD_Atlanta

User name for the account in the dial-out interface

DD_Atlanta

DD_NewYork

IP network of the internal interface

192.168.10.0/24

192.168.5.0/24

2.

Make the table available to both VPN server administrators.

3.

Configure the Motorin router by opening the Routing and Remote Access console and expanding the server.

4.

Select the Network Interface container and select the Internet interface in the detail pane.

5.

Right-click the Network Interface container, select New Demand-Dial Interface, and then click Next.

6.

Enter the interface name DD_NewYork, as shown in Figure 14-6, then click Next. The DD_NewYork interface name is the name of the interface on the motorin VPN server.

Figure 14-6. Enter an interface name.

[View full size image]

7.

Select Connect Using Virtual Private Networking (VPN) and click Next.

8.

Select the protocol to be used and click Next.

If L2TP is selected, IPSec certificates can be used for VPN computer authentication in addition to the user account. However, each computer must be able to validate the certificate presented by the other. If a different CA issues the certificate for each computer, a copy of the root CA certificate for each CA must be placed in the computer certificate store.

9.

Enter the IP address for the external interface from the table, 207.209.66.50. Click Next. (This IP address is the external interface of regalinn, the other VPN server.)

10.

Select Add a user account so a remote router can dial in, as shown in Figure 14-7, and click Next. (The account will be added for you.)

Figure 14-7. Add a User Account so the other VPN can authenticate its connection.

11.

Add static routes, in this case, for the 192.168.10.0/24 network, the internal network for regalinn. Then, click Next.

12.

Complete the dial-in credentials in adding and confirming a password for the account created in step 10. These will be the credentials used by the regalinn router to connect to this router. The name of the interface entered in step 6 is shown as the user name, as shown in Figure 14-8, and cannot be changed. Click Next.

Figure 14-8. The name of the interface is used to name the user account.

13.

Enter the dial-out credentials, the user name domain, the password for the user account at regalinn, and then click Next. Click Finish.

14.

Repeat the process on the regalinn computer, using the information from Table 14-1. (The interface name for regalinn must match the user name entered in step 13, and the dial-out credentials must match the information entered for the motorin computer.)

15.

When the configuration is complete, test the connection by right-clicking the interface and selecting Connect.

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.

Figure 14-9. Configure persistence from the Options Property page.

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:

1.

Double-click the interface in the Network Interface node of the Routing and Remote Access console.

2.

Select the Options page.

3.

Click the Callback button.

4.

Use the Add the phone button to identify the modem to use and the phone numbers approved for callback. These are the numbers answered by the peer router.

5.

Click OK to close.

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:

1.

Open the demand-dial Property pages.

2.

Select the Security page.

3.

Click to select the Advanced (custom settings) radio button and click the Settings… button, as shown in Figure 14-10.

Figure 14-10. Customize authentication and encryption from the Security page.

4.

Configure encryption using the Data encryption drop-down list, as shown in Figure 14-11. The choices are as follows:

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)

Figure 14-11. Select the strongest possible encryption and authentication.

5.

Configure authentication in the Logon security box.

6.

If certificates will be used, click to select Use Extensible Authentication Protocol (EAP) and select Smart Card or other certificate (encryption enabled).

7.

If certificates or MD5 challenge are not used, always select the strongest possible authentication choices from the Allow these protocols area. By default, MS-CHAP and MS-CHAPv2 are selected. Click to deselect MS-CHAP; demand-dial connections between any combination of Windows 2000 servers and Windows Server 2003 servers are capable of using MS-CHAPv2.

8.

Click OK to complete.

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.

Figure 14-12. The L2TP/IPSec pre-shared key is clearly visible in the 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:

1.

Open the Start, Setting, Control Panel, Add or Remove Programs applet and double-click the Add/Remove Windows Components option.

2.

Click Networking Services and click Details.

3.

Select Internet Authentication Service, click OK, and then click Next.

4.

If prompted, insert the Windows Server 2003 installation disc.

5.

When the installation is done, click Finish and click Close.

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

1.

Open the Start, Administrative Tools, Internet Authentication Service console, as shown in Figure 14-13.

Figure 14-13. The IAS console provides access for configuring RADIUS clients.

[View full size image]

2.

Right-click the RADIUS Client container and select New RADIUS Client.

3.

Enter a friendly name for the client, as shown in Figure 14-14.

Figure 14-14. Add the RRAS server as a RADIUS client.

4.

Enter the client computer (the RRAS computer) name or IP address.

5.

If a name was entered, click the Verify button and the Resolve button to resolve the name into an IP address.

6.

Click OK, and then click Next to continue.

7.

Enter and confirm the shared secret for this RADIUS client, as shown in Figure 14-15.

Figure 14-15. The shared secret for the RADIUS client should match the one entered when configuring the RRAS server to use RADIUS for authentication.

8.

Click Request must contain the Message Authenticator attribute. (See the sidebar "Best Practices for IAS and RRAS Security" for an explanation of this attribute.)

9.

Click Finish.

10.

Repeat steps 2 to 9 for each RADIUS client.

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:

1.

Expand the Connection Request Processing folder in the Internet Authentication Service console.

2.

Right-click the Connection Request Policies container, select New Connection Request Policy, as shown in Figure 14-16, and then click Next.

Figure 14-16. Configure a custom connection request policy.

3.

Select A custom policy.

4.

Add a name for the policy and click Next.

5.

Click the Add button to add policy conditions.

6.

Select attributes such as Day-and-Time Restrictions, Tunnel Type, and so forth. Attributes are described in the section "Configure Clients to Use Remote Access," later in this chapter.

7.

Click Add to add the attribute, select the constraints for the condition, and click OK.

8.

Add additional policy conditions if required. When you are done, click Next.

9.

Use the Edit Profile button to add additional attributes (conditions and constraints) to this request, such as changing the RADIUS server for Accounting.

10.

Click Next and click Finish.

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

1.

Open the Routing and Remote Access console.

2.

Right-click the server and select Properties.

3.

Select the Security tab.

4.

Use the Authentication provider: drop-down box, as shown in Figure 14-17, to change to RADIUS authentication.

Figure 14-17. Change to RADIUS authentication.

5.

Click the Configure… button.

6.

Click Add to add the RADIUS server name.

7.

Click the Change button to add the shared secret, as shown in Figure 14-18. The shared secret must match that configured at the RADIUS server for this client.

Figure 14-18. Set the shared secret.

8.

Select the Always use message authenticator check box.

9.

If multiple RADIUS servers will be used, indicate the score, as shown in Figure 14-18. The RADIUS servers will be queried in order from highest to lowest.

10.

Click OK.

11.

Add additional RADIUS servers in the same manner.

12.

Click OK twice when you are done.

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.

Table 14-2. RADIUS Ports

RADIUS Messages

Standard Port

Optional Port

Authentication

UDP 1812

UDP 1645

Accounting

UDP 1813

UDP 1646

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.

Figure 14-19. RRAS servers in a Windows Server 2003 functional mode domain refer remote access permissions to Remote Access Policies.

Figure 14-20. The default Remote Access Policy denies remote access.

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.

Table 14-3. Dial-In Account Configuration

Setting

Description

Verify Caller-ID

Before using this feature, verify the following:

All parts of the dial-up connection, including the caller, the phone system between the caller and the remote access server, and the phone system between the remote access server and the call answering equipment, provide Caller-ID services.

The call answering equipment can provide the remote access server with the number called from, and the phone number from which the user may call may be entered here.

If your systems meet these conditions, and this feature is desired, enter the number the user will use to dial-in. The user will be denied access if he places a call from another number.

No Callback

RRAS will not disconnect a connection and attempt to dial the user's computer.

Set by Caller (Routing and Remote Access Service only)

At connection, an authorized user can request dial back to a phone number he enters. This offers no real security benefit. It is not available if IAS is used to manage RRAS connection requests.

Always Callback to

Enter a phone number in the user's dial-in Property page. RRAS will dial the number entered after the user's connection is authorized. This feature may prevent unauthorized use of the user's credentials, if the person using them does not also have access to the phone line represented here. This can be an effective security measure, but it restricts the user to one location and one phone line.

Assign a Static IP Address

In the typical configuration, RRAS assigns an internal network address to the connection, either by using a network accessible DHCP server or from an address pool configured on the server. Using an assigned IP address may provide greater accountability because the user's network access can be tracked by IP address and by user account. If auditing is configured, it is also possible to link IP addresses to user accounts by reviewing the records.

Apply Static Routes

It may be necessary to identify static routes, routes that are needed for this specific account. When an account configured with static routes makes a connection, the routes are added to the RRAS server.

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).

Table 14-4. Remote Access Policy Restrictions RRAS and IAS

Attribute

Description

Authentication Type

Identification of the authentication type that is used. Authentication types are CHAP, EAP, MS-CHAP or MS_CHAPv2, and so forth.

Called Station ID

The phone number of the network access server (NAS) or RRAS server that is acting as the RADIUS client. The server must support passing the called ID.

Calling Station ID

The phone number used by the client accessing the NAS or RRAS server.

Day and Time Restrictions

The day of the week and the time of day of the connection attempt. The RRAS server day and time are used.

Tunnel Type

The requesting client tunnel type. Types include Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). This attribute can also specify profile settings, such as authentication method or encryption strength.

Windows Groups

The name of the Windows group to which the user or computer account belongs.

Table 14-5. Remote Access Policy Restrictions (IAS Only)

Attribute

Description

Client Friendly Name (IAS only)

The name of the RADIUS client that is requesting authentication. Configure this in the Friendly Name on the Setting tab of the RADIUS client properties in IAS (IAS only).

Client IP Address

The IP address of the RADIUS client (the RRAS or NAS) or the RADIUS proxy.

Client Vendor

The NAS vendor (the NAS requesting authentication).

Framed Protocol

The framing type of the incoming packetsfor example: PPP, SLIP, Frame Relay, and x.25 ( IAS server only).

NAS Identifier

The name of the NAS (IAS only).

NAS IP Address

The IP address of the NAS (the RADIUS client) that sent the message (IAS only).

NAS Port Type

The access client media type used, such as analog phone line (async), ISDN, tunnels, VPNs, (virtual), IEEE 802.11 wireless, and Ethernet switches.

Service Type

The type of service requestedfor example; framed (a PPP connection) or login (Telnet connection).

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.

Table 14-6. Profile Properties

Property Page

Description

Dial-in constraints

Sets idle time, connection limit, days and times, specified number, and specific media (async, ISDN, virtual, or 802.11).

IP

Specifies client IP address assignment and, optionally, IP packet filters. IP address assignment choices are as follows:

Access server supplies the address.

Client requests an IP address.

Address assignment is specified by the access server.

Profile lists a static IP address.

An IP address in the user account Dial-in Property page will override the profile setting unless the dial-in properties are ignored.

IP packet filters defined on this page apply to remote connection traffic.

Multilink

Sets the number of ports a multilink connection can use and specifies Bandwidth Allocation Protocol (BAP) policies. (The RRAS server must have multilink and BAP enabled for these to work.)

Authentication

Enables authentication types. Authentication types are configured in the Property pages of the RRAS and IAS server, but settings on the authentication page overrides those settings when this Remote Access Policy is used. This page also determines if users are allowed to change their passwords by using MS-CHAP. (This setting must match the settings for RRAS.)

Encryption

Defines encryption choices. The client and the server negotiate the encryption that will be used; this specification indicates the choices the server may accept. The choices are as follows:

No encryption

Basic (dial-up and PPTP connections use 40-bit key MPPE. L2TP/IPSec connections use 56-bit DES)

Strong (PPTP connections use 56-bit MPPE, L2TP/IPSec connections use 56-DES)

Strongest (PPTP connections use 128-bit MPPE, L2TP/IPSec connections use 3DES)

Advanced

Provides the ability to define RADIUS attributes. The IAS server will use these attributes to constrain an authorized connection between the RADIUS server (IAS) and the RADIUS client (RRAS). Configure the Ignore User Dial-in Properties attribute here.

Configuring Remote Access Policies

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

1.

Open the Routing and Remote Access console if Windows authentication is used or the Internet Authentication Service if RADIUS authentication is used.

2.

Right-click the Remote Access Policies container, select New Remote Access Policy, and then click Next.

3.

Enter a name for the policy, as shown in Figure 14-21, and click Next.

Figure 14-21. Enter a name for the policy.

4.

Select the access method, as shown in Figure 14-22, such as VPN, and then click Next.

Figure 14-22. Select the access method that will trigger this policy.

5.

Use the Add button and the object picker to select the Windows groups that will be affected by this policy. Add as many groups as you require and click Next.

6.

Choose the authentication methods that will be allowed by selecting or deselecting check boxes, as shown in Figure 14-23. If smart cards or EAP is selected, the server certificate must be available for selection.

Figure 14-23. Select authentication methods.

7.

If Extensible Authentication Protocol (EAP) is selected, choose Protected EAP (PEAP) or Smart Card or other certificate in the Type drop-down box. After selection, use the Configure button to select the server certificate, as shown in Figures 14-24 (for smart cards) and 14-25 (for PEAP).

Figure 14-24. Select the server certificate.

Figure 14-25. Select the server certificate for PEAP.

8.

Click Next.

9.

Select the encryption level desired, and then click Next and Finish.

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

1.

Open the Routing and Remote Access console if Windows authentication is used or the Internet Authentication Service if RADIUS authentication is used.

2.

Right-click the Remote Access Policies container, select New Remote Access Policy, and then click Next.

3.

Select Set up a custom policy and click Next.

4.

Use the Add button and select a condition from the Select Attribute page, as shown in Figure 14-26.

Figure 14-26. Select a condition that this policy relates to.

5.

When you have configured the conditions, close the Select Attribute page by clicking OK, and then click Next.

6.

Chose Deny Remote Access Permission or Grant Remote Access Permission. Click Next.

7.

Click the Edit Profile button to edit the Remote Access Policy profile.

8.

Select the Dial-in Constraints page to configure session settings, as shown in Figure 14-27.

Figure 14-27. Set dial-in constraints.

9.

Select the IP tab, as shown in Figure 14-28, and configure how IP address assignment will occur. This page is also used to add input and output protocol filters.

Figure 14-28. Set IP address assignment and configure protocol filters.

10.

Select the Advanced tab and use its Add button to configure additional attributes. This is where the Ignore User dial-in constraints attribute is configured.

11.

Click OK to close the profile, then click Next, followed by Finish.

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:

1.

If the account is not configured to use Remote Access Policies, the Deny or Allow setting determines if remote access can be attempted.

2.

If the account setting is Deny, remote access is denied.

3.

If the account setting is Allow, the remote access is allowed subject to the constraints set in the properties and, of course, additional constraints on network resources.

4.

If the account is configured to use Remote Access Policies and no Remote Access Policy exists, access is denied.

5.

If the account is configured to use Remote Access Policies and Remote Access Policies exist, the connection attempt is evaluated against the first Remote Access Policy conditions. (A default Remote Access Policy denies connection any time of the day, any day of the week.)

6.

If all the conditions of the Remote Access Policy are met, the value of the Ignore-User-Dial-in-Properties attribute (configured in the Remote Access Policy profile) is checked. If it is set to true, any dial-in page constraints are ignored. If it is not set or is set to false, any dial-in Property page settings are evaluated.

7.

If all the conditions of the Remote Access Policy are not met, the next Remote Access Policy is evaluated. (Remote Access Policies are evaluated in the order listed in the Remote Access Policies node. The order can be changed.)

8.

If no Remote Access Policy matches the connection attempt, the connection attempt is rejected.

9.

If the connection is allowed, it is constrained by the profile settings of the Remote Access Policy.

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

1.

The dial-in Property page of the user account is checked.

2.

If the account setting is Allow, the process continues. Remote Access Policy conditions are checked, and Remote Access Policy profile constraints may be applied. If all conditions are met, the connection is accepted. If they are not, any remaining Remote Access Policies are checked.

3.

If the account setting is Deny, the connection attempt is rejected.

4.

If the user account setting is Control Access Through Remote Access Policy, the remote access permissions setting of the policy is checked. If it is Deny, the connection is rejected. If it is Allow, processing will continue.

5.

The account dial-in Property page constraints and the Remote Access Policy profile constraints are evaluated.

6.

If all connection settings in the policy and the user dial-in page are met, the connection is accepted.

7.

If some connection setting is not met, the connection is rejected.

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.

Table 14-7. Remote Access Authentication Protocols

Protocol

Description

Password Authentication Protocol (PAP)

A plaintext password is sent across the network. PAP is rarely used, but might be required to accommodate some legacy clients.

Shiva Password Authentication Protocol (SPAP)

Employs a proprietary reversible encryption mechanism supported by Shiva remote access servers. This is more secure than PAP but less secure than CHAP. Microsoft Point-to-Point Encryption cannot be used with SPAP.

CHAP

The MD5 hashing protocol encrypts challenge strings. The user name, but not the password, is transported across the network in plain text. The server, however, must store a plaintext copy of the password, or store the password using a reversible encryption algorithm. CHAP may be required to accommodate some UNIX clients.

MS-CHAP

The MD4 hash is used, and the server can store a hashed version of the password. The protocol can provide more sophisticated error messages than CHAP, including a password expired error code that allows the user the ability to change the password during the authentication phase of the connection. The client and server independently create the encryption key based on the user's password. MS-CHAP may be required if Windows 95 clients must connect to the remote access server.

MS-CHAPv2

Mutual authentication, a process in this case where both the client and server prove that they have knowledge of the client password, and other improvements over the MS-CHAP protocol are provided. Still, because the encryption key is based on the user's password, the protection is only as strong as the user's password.

Extensible Authentication

An extension to PPP that provides Protocol (EAP) for a choice of authentication protocols, known as EAP types. EAP types are dynamically negotiated during the authentication phase of PPP. Because EAP is modularly designed, it provides for the introduction of new authentication types without requiring that the EAP protocol be rewritten. The currently available EAP types in for Windows Server 2003 are as follows:

EAP-TLSEnables mutual authentication between clients and severs. The dial-in server validates the client certificate, and the client validates the server's certificate.

EAP-TLS can be used with PPTP and L2TP/IPSec. When EAP-TLS is used, client computer certificates are not required. (This will always be the case when PPTP is used.) A server certificate is required, however. User certificates may be either installed on client computers or smart cards.

EAP-MD5Can only be used with L2TP/IPSec. VPNs and dial-up access usage is allowed but not PPTP or wireless VPNs. A password is used by the user, and no certificates are required. This is less secure than EAP-TLS. A reversibly encrypted password must be stored in the account database, which weakens password security as well.

To configure authentication protocols, follow these steps:

1.

Open the Routing and Remote Access console.

2.

Right-click the server and select Properties.

3.

Select the Security tab and click the Authentication Methods button. Figure 14-29 displays the initial authentication configuration screen for remote access services.

Figure 14-29. Selecting remote access authentication protocols.

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.

Figure 14-30. Use the Security Property page of the RRAS server to select the Accounting method.

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.

Figure 14-31. Configure event logging on the Logging Property page.

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.

Figure 14-32. RRAS Access attempts are logged in a special log file or SQL server if configured.

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.

Figure 14-33. Log file location and frequency are configured on the Log File tab.

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.

Figure 14-34. Only the data portion of the PPTP packet is encrypted.

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.

Figure 14-35. A large portion of the L2TP/Ipsec packet is encrypted.

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.

Table 14-8. PPTP Input Filters: Packets That Should Not Be Dropped

Interface IP

Subnet Mask

Destination Port

Purpose

Internet interface VPN router

255.255.255.255

TCP 1723

PPTP tunnel maintenance

Internet interface of router

255.255.255.255

Protocol ID 47

PPTP tunneled data to router

VPN router Internet interface

255.255.255.255

TCP source port 1723

Only for the calling router

Table 14-9. PPTP Destination Output Filters: Packets That Should Not Be Dropped

Source Interface IP

Subnet Mask

Source Port

Purpose

Internet interface VPN router

255.255.255.255

TCP 1723

PPTP tunnel maintenance

Internet interface of router

255.255.255.255

Protocol ID 47

PPTP tunneled datato router

VPN router Internet interface

255.255.255.255

TCP source port 1723

Only for the calling router

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

Table 14-10. L2TP/IPSec Input Filters: Packets That Should Not Be Dropped

Destination Interface IP

Subnet Mask

Destination Port

Purpose

Internet interface VPN router

255.255.255.255

UDP 500

Internet Key Exchange (IKE)

Internet interface of router

255.255.255.255

UDP 4500

IPSec NAT-T (if necessary)

VPN router Internet interface

255.255.255.255

UPD 1701

L2TP traffic

Table 14-11. L2TP/IPSec Destination Output Filters: Packets That Should Not Be Dropped

Source Interface IP

Subnet Mask

Source Port

Purpose

Internet interface VPN router

255.255.255.255

UDP 500

IKE traffic

Internet interface of router

255.255.255.255

UDP 4500

IPSec NAT-T(if required)

VPN router Internet interface

255.255.255.255

UDP 1701

L2TP traffic

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:

1.

An authorized connection attempt is received by the remote access server. If the client is authenticated and authorized to make a remote access connection, the connection is made, but the client is subject to the quarantine restrictions.

2.

The client runs a network policy requirements script (the script is included in the CM profile).

3.

The script evaluates the client computer according to specified controls such as anti-virus product, security patch level, and so forth. (The script can be a simple batch file of commands or a custom executable file.)

4.

If the client script successfully runs (the client has met the conditions of the script), a notifier component (rqc.exe from the Windows Server 2003 resource kit or a custom notifier) runs to notify the remote access server.

A listener component on the server (rqs.exe from the resource kit or a custom listener component) receives the message and removes the quarantine restrictions from the remote access connection. Appropriate access is granted to the user.

5.

If the script does not execute successfully, it directs the remote access client to a quarantine resource that describes how to install the components required for network policy compliance.

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:

1.

Designate quarantine resources. Quarantine resources are those that a quarantined client can access, such as DNS servers, DHCP servers, file servers, and web servers. These services will be used by the quarantined client to view instructions for policy compliance and to download programs required for compliance. Existing resources can be utilized by setting packet filters for each resource in the MS-Quarantine-IPFilter attribute of the Remote Access Policy, such as setting a packet filter allowing port 53 traffic to the IP address of a specific DNS server. Alternatively, you might deploy quarantine resources and only quarantine resources on a single subnet just for this purpose. A single input/output packet filter can then be configured. Figure 14-36 illustrates this arrangement and shows the location of the quarantine resources, the quarantine-compatible servers and clients, and other network elements.

Figure 14-36. If special quarantine resources are set up, you can limit client access to a single subnet.

[View full size image]

2.

Create a script to validate client configuration. This script can be a simple batch file (*.cmd or *.bat) or a custom program. The script performs tests and must complete with a call to the notifier or, in the case of failed compliance, to a web page that includes instructions on how to comply.

NOTE: For More Info

An example script is provided in the article "Network Access Quarantine Control in Windows Server 2003" and can be downloaded at http://www.microsoft.com/windowsserver2003/techinfo/overview/quarantine.mspx.

3.

Install the Remote Access Quarantine Agent service (rqs.exe) on all Windows Server 2003 remote access servers.

4.

Create a Quarantine CM profile with the Windows Server 2003 CMAK. This is a normal profile with a couple of additions. You need to use the Custom Actions page of the CMAK wizard to add a post-connect action to run the script and add the notification agent to the profile using the Additional Files page of the CMAK wizard.

5.

Distribute the CM profile to Remote Access Client computers.

6.

Configure a Quarantine Remote Access Policy. If Windows authentication is used, configure the policy on the RRAS server. If RADIUS authentication is used, configure the policy on the IAS server.

7.

Start the Remote Access Quarantine Agent Service.

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:

1.

Open the Program Files\Resource Kit\rqs_setup.bat file in Notepad.

2.

Use Edit\Find to search on Version1\0 and replace the string with the information from the script created in step 2 of the previous list.

3.

Close and save the file.

4.

From a command prompt, run the setup file using the following command:

rqs_setup/install

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

1.

Follow steps 1 to 6 of the custom Remote Access Policy procedure to configure a custom Remote Access Policy and name it Quarantine VPN remote access connections or something similar. Specify Windows groups to indicate the group of users authorized to make remote access connections.

2.

Click the Edit Profile button to edit the Remote Access Policy profile.

3.

Select the Advanced tab and click the Add button.

4.

In the Attribute list, click MS-Quarantine-Session-Timeout and click Add.

5.

In the Attribute information dialog box, enter the quarantine session time, as shown in Figure 14-37, and then click OK. The MS-Quarantine-Session-Timeout setting is the time, in seconds, that the session can remain in the restricted state before being disconnected.

Figure 14-37. Configure session timeout in the profile attribute.

6.

Click Add, and in the Attribute list, click MS-Quarantine-IP Filter. Then, click Add.

7.

Click Input Filters.

8.

In the Inbound Filter box, click New to add a filter.

9.

Click Destination Network and add the IP address and subnet mask of the server where the notification message should be received.

10.

For Protocol, click TCP. For Destination port, enter 7250 (this port is used to receive the notification message from the quarantined remote access clients), and then click OK.

11.

Click to select Permit only the packets listed below.

12.

Repeat steps 8 to 11 for each packet filter that you need in order to allow access to quarantine resources.

13.

When you finish adding filters, click OK to save the filter list.

14.

Click OK to save the attributes and click OK to close the profile.

15.

Click OK twice to complete the Quarantine Remote Access Policy.