The Ultimate Windows Server 1002003 System Administrators Guide [Electronic resources] نسخه متنی

VIRTUAL PRIVATE NETWORKS

A virtual private network is a connection between two communication endpoints that ensures privacy and authentication. A tunnel coupled with encryption creates a "virtual private network" between an organization's central network and its branch offices or dial-in users. Thus, these offices and dial-in users may interconnect through the Internet's infrastructure without being subject to unauthorized snooping and impersonation. VPN technology establishes a wide area network (WAN) between sites that allows a user to log on to the network from one location and access company resources throughout the "virtual network." Connecting directly to the Internet through an ISP's point of presence (POP) is cheaper than leasing expensive dedicated circuits or making long-distance telephone calls, which is the reason for the VPN's increasing popularity.

The VPN connections discussed in this chapter are composed of three elements. A connection is considered a VPN when all three are correctly functioning.

Authentication

Encryption

Tunneling

Authentication

Let's first introduce some basic strategies for authenticating users and computers when establishing VPNs. Not all tunneling protocols support every authentication protocol, but a general awareness will allow you to compare technologies for the best VPN solution.

Authentication protocols are designed to guarantee the identity of users and servers, as discussed in Chapter 10, "Kerberos and the Public Key Infrastructure." The password is the basis for most implementations, but X.509 certificates are also used when establishing secure channels and IP Security. There is a difference between user authentication (both passwords and certificates) and machine authentication (usually certificates). Table 13.1 lists the authentication protocols supported by Windows Server 2003.

Role of Encryption

Encryption provides data confidentiality and forms the "black pipe" between tunnel endpoints. Once the tunnel has been formed, packets are encrypted and encapsulated in the tunnel protocol. Usually hidden in the encrypted portions of these packets is the original IP header information, which prevents eavesdroppers not only from reading the encrypted data but also from reading the packet's destination. The destination tunnel endpoint IP address and other IP header information are the only pieces of information required to route a packet from one end of the tunnel to the other. Although there are many implementations and levels of encryption, primarily IPSec and MPPE are used to encrypt tunnels with Windows Server 2003. (See Table 13.2.)

Tunnels

The tunnel is defined by two endpoints that communicate through a tunneling protocol. One end of the tunnel encapsulates incoming traffic and routes it to the other end. This encapsulation process can occur at either the second or third protocol layer as defined by the Open Systems Interconnections (OSI) model. Layer 2 protocols encapsulate at the data link layer and retain MAC-level addresses and frame information for different media types. Layer 3 protocols encapsulate packets from the network layer up. The Point-to-Point Tunneling Protocol (PPTP) and the Layer 2 Tunneling Protocol (L2TP) are layer 2 tunneling protocols, whereas IP Security implemented in tunnel mode is in layer 3. Windows Server 2003 supports all three, but L2TP is the preferred implementation for Microsoft products.

The following discussion outlines these mutually exclusive protocols in relationship to VPN.

POINT-TO-POINT TUNNELING PROTOCOL

The Point-to-Point Tunneling Protocol is one way to create a VPN. PPTP relies on the Point-to-Point Protocol (PPP) to initially encapsulate an IP packet coming from a source at one end of the tunnel (Figure 13.1). Microsoft Point-to-Point Encryption (MPPE) can be used to encrypt the PPP payload information. MPPE is set up with keys passed using the MS-CHAP or EAP-TLS authentication methods.

The PPP header and payload are encapsulated into a Generic Routing Encapsulation (GRE) header and an IP header. The source IP address in the IP header corresponds to the tunnel server at the start of the tunnel, and the destination IP address corresponds to the tunnel server at the end (Figure 13.2).

LAYER 2 TUNNELING PROTOCOL

The Layer 2 Tunneling Protocol is the preferred method of establishing a VPN in a Windows Server 2003 environment and also relies on the prepackaged PPP frame (Figure 13.3). L2TP encapsulates the PPP frame with an L2TP header and User Diagram Protocol (UDP) header.

L2TP over IPSec, as illustrated in Table 13.3, is the preferred method of encryption for the L2TP tunnel. An IPSec Encapsulating Security Payload (ESP) header and trailer encapsulate the L2TP payload for encryption and authentication (Figure 13.4). IPSec negotiates the transport level connection using computer certificates and the Internet Key Exchange (IKE) protocol; once this is complete, L2TP tunnel settings are used to establish the tunnel and authenticate the user. The IP header contains the tunnel endpoints for the source and destination IP addresses. The packet's true source and final destination are not visible to the Internet when encryption is enabled. L2TP over IPSec also offers data integrity and authentication without encryption through the use of digital signatures supported in Authentication Headers (AH).

NOTE The current Windows Server 2003 implementation of L2TP does not support connections over X.25, Frame Relay, or ATM networks.

NOTE Windows Server 2003 adds support for Network Address Translation (NAT) for both L2TP and IPSec VPN clients. TCP and UDP traffic may now flow through a NAT device without losing encryption protection. Additionally, IPSec can be used to secure L2TP tunneling in accordance with RFC 3193.

NOTE Windows Server 2003 IPSec has added the stronger 128-bit equivalency IKE key. This provides a 2048-bit Diffie-Hellman key generation. This is based on support of the IETF draft (draft-ietf-ipsec-ike-modp-groups-02.txt).

IPSEC TUNNELING

The IPSec tunnel operates at layer 3 and incorporates the IP packet and its contents. When L2TP and PPTP are not available on VPN servers or clients, it may be used for interoperability. IPSec provides two general modes of operation: tunnel and transport. Tunnel mode is discussed first; transport mode is discussed in the next section.

Tunnel mode involves two configurations: Encapsulating Security Payload (Figure 13.5) and Authentication Headers (Figure 13.6). ESP encapsulates IP packets for encryption and integrity. AH signs packets for integrity only. Both append an IP header to the packet that contains routing information between tunnel endpoints.

Comparison of Tunneling Methods

Some implementations of the three tunneling protocols might vary on different operating systems. As Table 13.3 shows, L2TP and IPSec offer the most favorable solution, thanks to features inherited from both PPP encapsulation and the IPSec transport.

VPN Configurations

When designing a virtual private network, it is important to understand that there are two general VPN configurations:

Router-to-router Example: A branch office router is connected to a corporate intranet.

Remote access
Example: One dial-in client establishes a connection at the time of the call.

These configurations are examined in the following sections.

ROUTER-TO-ROUTER

Branch office connections through a router-to-router VPN (Figure 13.7) can be configured to meet a wide range of organizational and physical requirements. For example, they may be persistent 24 hours a day or they may be established on demand. The nonpersistent router-to-router VPN may cut down on expensive long-distance phone or data connections, and establishing it is transparent to the user. Many users on both networks use a VPN connection concurrently.

REMOTE ACCESS

The remote access VPN configuration is established when a single client dials in to either an ISP or a corporate Remote Access Server. The connection is then established between the client and the tunnel server, but not before mutual authentication between them is established. Once the user is identified, remote access policies determine the conditions for the VPN connection setup. If the client dials in to an ISP, the VPN connection remains with the corporate tunnel server and is transparent to the ISP (Figure 13.8).

VOLUNTARY AND COMPULSORY TUNNELS

The two methods for establishing a tunnel between the client and the corporate intranet are voluntary and compulsory. Remote access policy for individual users determines which method will be used. The voluntary tunnel is initiated by the individual VPN client workstation when it accesses the corporate network. The compulsory tunnel is initiated by a VPN client server at the ISP when the user attempts to log on to the corporate network. Policies set on the corporate VPN server force users to set up this mandatory tunnel and may exist on the corporate VPN server or corporate Internet authentication server (IAS), to be discussed in a later section.

VPN Architecture and Configuration

With a conceptual understanding of VPN, we can now turn our attention to the details of implementations associated with the previously discussed VPN configurations. The three common VPN configurations are router-to-router persistent, router-to-router on demand, and remote access over the Internet. Here are the basic steps to implement them:

Internet/intranet connection interface configuration

Routing and remote access setup

Certificates supporting IPSec

Static routes

Tunnel port configuration

Tunnel filter configuration

Remote access policy

VPN client configuration

REMOTE ACCESS OVER THE INTERNET

To provide a better understanding of VPN implementation, the following example demonstrates how to configure a RAS server for VPN connections with individual clients. In this scenario, the client establishes a remote connection over an intranet or the Internet using a tunneling protocol and encryption mechanism, as in Figure 13.4. She dials in to her ISP and establishes Internet connectivity. Remote access policies prevent a client connection unless a tunnel is established. The tunnel is therefore mandatory before intranet connectivity is permitted. The RAS will be configured to authenticate clients using L2TP over IPSec encryption. Once a client has been authenticated, and a VPN connection has been established, the RAS will forward data between the client and the intranet behind the server. This is known as configuring a RAS server for VPN.

NOTE Windows Server 2003 has added a few features to accommodate small businesses with servers performing many network functions. These include:

The ability to install and run RAS, NAT, Active Directory, and Firewall functions on a single system connecting a small company with the Internet.

A server configured to handle dial-in access and NAT functions may now permit RAS clients access to the Internet.

Setting Up Internet and Intranet Interfaces on the VPN Server

The following provides a step-by-step review of VPN setup using sample IP addresses. (These should not be used in a real or test environment. Secure and use your own IP addresses when simulating this example.) For this example, assign 111.111.111.2 and subnet mask 255.255.255.0 to the intranet interface. Then, assign IP address 111.111.112.2 with 255.255.255.0 subnet mask to the Internet interface (Figure 13.9).

Select Start Settings Network Connections and double-click the intranet interface. Click Properties.

Select the Internet Protocol (TCP/IP) option and click Properties. Type the IP address and subnet mask for the intranet interface.

Repeat this process for the Internet interface.

Setting Up Routing and Remote Access

To route between the Internet and the intranet, the Routing and Remote Access Service must be installed.

Select Start Programs Administrative Tools Routing and Remote Access. Right-click the VPN server node and select Configure and Enable Routing and Remote Access. The Routing and Remote Access Server Setup Wizard starts. Click Next.

Select Virtual private network (VPN) access and NAT and click Next (Figure 13.10).

Select the interface that is attached to the Internet. This is the network from which the client is communicating (Figure 13.11). In this case that interface is 111.111.112.2. Click Next.

DHCP can be used to assign IP addresses to VPN clients by selecting Automatically. For this example, configure a pool of addresses for the RAS server to assign to clients by selecting From a specified range of addresses (Figure 13.12). Click Next.

Create a range of IP addresses to assign VPN clients by clicking New (Figure 13.13). Type the Start IP address and End IP address to designate the new IP address range. Click OK. Click Next.

The next dialog box involves the RADIUS service, which is discussed in another example. Here select No, I don't want to set up this server to use RADIUS now (Figure 13.14). Click Next.

Click Finish. The wizard may bring up some suggestions for your RAS installation.

Once the Routing and Remote Access server is up and running, a green dot should be visible on the new server from the Routing and Remote Access snap-in. If you plan to dial directly in to the RAS (as well as access the server over the Internet through a LAN interface), make sure that the following options are enabled.

Right-click the new server and select Properties. From the General tab, ensure that the Remote access server option is checked and that LAN and demand-dial routing is selected.

Applying Certificates for IPSec

IP Security requires an X.509 version 3 certificate to be installed on all participating systems. Install an IPSec machine certificate from a trusted certificate authority. (See Chapter 11 for additional information.) We recommend using the Certificate snap-in to request an IPSec certificate. Right-click the Personal store node and select All Tasks Request New Certificate. Follow the Certificate Request Wizard's instructions. If the client is offsite, use the Web server Certificate Request Web pages to request a certificate from the certificate authority. (Again, see Chapter 11.)

Configuring Static Routes

The RAS/VPN server may be configured with either routing protocolssuch as the Routing Information Protocol (RIP) and Open Shortest Path First protocol (OSPF)or static routes to direct traffic between the VPN client and the destination internal networks. For the sake of simplicity, we will examine how to configure RAS/VPN using static routes. All networks the VPN client wishes to communicate with must have a configured route in the table.

From the Routing and Remote Access snap-in, right-click the Routing and Remote Access node servername node IP Routing Static Routes and select New Static Route.

To forward external traffic destined for an internal network other than the 111.111.111.0 network (or your intranet network):

Select the intranet interface from the Interface drop-down list box (Figure 13.15).

Type the destination network and subnet mask. All IP packets destined for this network will now follow this new route.

Type the router interface address responsible for forwarding the packet to the destination network in the Gateway box. In this example, a router has an interface on the 111.111.111.0 internal network. It is also capable of routing to the 111.111.113.0 network.

A low metric number gives high preference to this route when multiple options for a destination network exist.

For instance, to route incoming packets from the 111.111.112.2 interface onto the 111.111.113.0 network, the entries shown in Figure 13.15 would be made. The Intranet interface address is 111.111.111.2.

To verify the newly created route, display the routes for the VPN server using the route print command from the command prompt (Figure 13.16).

NOTE If there is only one network at the corporate intranet or branch office, no static routes are required. RAS will forward packets between the two interfaces if all packets are destined for addresses on the local VPN network.

The routing table can also be displayed from the Routing and Remote Access snap-in by right-clicking the Routing and Remote Access node servername node IP Routing node Static Routes node and selecting Show IP Routing Table. The full table is displayed for the routing and remote access server (Figure 13.17).

Tunnel Ports

By default there are 128 PPTP and 128 L2TP ports defined for the RAS server. If you expect more than this number of concurrent VPN connections using L2TP, take the following steps to increase the number of L2TP ports.

Right-click the Routing and Remote Access node servername node Ports node, then select Properties. Select WAN Miniport (L2TP) and click Configure.

Increase the Maximum ports by typing or selecting a number in the combo box, and click OK (Figure 13.18).

NOTE Microsoft's Windows Server 2003 Connection Manager Administration Kit permits administrators to configure VPN servers to redirect client requests for external sites directly to the Internet. When the external VPN client connects to a VPN server, only requests bound for internal servers are forwarded over the company's network. This limits network traffic on the company's network to requests for internal resources.

L2TP over IPSEC Filters

Tunnel filtering can be used to disable all other connection types. Filtering UDP port numbers and source and destination IP addresses is an effective way to eliminate connections for other services. Some protection is afforded the VPN server through inbound and outbound packet filtering. To configure L2TP input filters:

Open the Routing and Remote Access node servername node IP Routing node General node, right-click the Internet interface in the details pane and select Properties. The General tab displays properties for the external adapter.

Click Inbound Filters. Click New.

Check the Destination network box and type the IP address of the internal interface. Type 255.255.255.255 for the Subnet mask (Figure 13.19).

Select the UDP protocol from the Protocol drop-down list.

Type 500 for the Source port and 500 for the Destination port (Figure 13.19). Port 500 is used by the Internet Security Association and Key Management Protocol (ISAKMP) to authenticate keys and negotiate IPSec connections. (ISAKMP is also known as the Internet Key Exchange protocol.)

Repeat steps 2 through 5, but make the Source port and Destination port 1701. Click OK. Port 1701 is reserved for L2TP communications.

In the Inbound Filters dialog box, select Drop all packets except those that meet the criteria below. Click OK.

At this stage, it is necessary to add appropriate L2TP input and output filtering, as here:

In the Internet adapter's Properties dialog box, select Output Filters.

Click Add and check the Source network box.

Type the IP address of the external interface in the IP address box.

Type 255.255.255.255 for the Subnet mask.

Type 500 for the Source port and Destination port. Click OK.

Repeat steps 8 through 12, but make the Source and Destination ports 1701.

Select Drop all packets except those that meet the criteria below. Click OK.

All four filters (two input and two output) should have been applied to the Internet adapter IP address, thereby preventing all other connections from passing through the adapter. The intranet adapter (on the corporate network) will be unaffected by these filter settings, and thus internal systems will still be able to establish any type of connection with the VPN server.

Remote Access Policy

Remote access permissions are granted on a user-by-user basis through the Dial-in tab associated with each user account's properties. Right-click a user from the Active Directory Users and Computers snap-in and select the Dial-in tab. Select Allow access or Deny access as appropriate to assign VPN or Dial-in permissions (Figure 13.20).

Remote access policies provide conditions and a profile that clients must meet in order to access the server. To use one, select Allow access for each user account. (Native-mode Windows Server 2003 systems have the Control Access through Remote Access Policy option instead of Allow access.) Once all user accounts have been given remote access capability, additional policies are used to restrict which users and connection types are permitted to access the server. Table 13.4 describes remote access policy attributes. A few examples will be discussed in the next procedural steps.

Setting remote policies is the next step to take to support client use of RAS. To create a remote policy, follow these steps:

From the Routing and Remote Access snap-in, select the Routing and Remote Access node servername node Remote Access Policies. Right-click the Remote Access Policies node and select New Remote Access Policy.

Select Set up a custom policy. Type something like VPN Policy for the policy name. Click Next.

Select several conditions in the following steps:

Click Add. Select the Windows-Groups attribute and click Add (Figure 13.21). The Windows-Groups condition identifies security group membership required to meet the policy.

Click Add and select security groups to govern remote access privileges. Click OK. Click OK. Click Next.

Select Grant remote access permission to allow users who meet this policy's requirements to have remote access privileges. Click Next.

Click Edit Profile to modify profile settings for VPN Policy. Select the Authentication tab. Smart card authentication is configurable from here. Both MS-CHAP v2 and MS-CHAP should be enabled (Figure 13.22).

The Encryption tab offers the following selections:

Basic
40-bit DES encryption

Strong
56-bit DES encryption

Strongest
3DES encryption (encrypts each data block using from one to three different keys with the DES algorithmthis is only for North American VPN clients)

Click OK. Click Next. Click Finish. If other default policies exist, remove them. This will eliminate conflicts with previously established RAS policies.

Remote Access Client Configuration

For the client to dial in to a VPN, specific steps must be taken to configure its remote access. From the client computer, create a local dial-in connection:

Start the Network Connection Wizard by selecting Start Settings Network Connections. Double-click the New Connection Wizard icon to start the wizard. Click Next.

Select Connect to the network at my workplace and click Next. Select Dial-up connection and click Next. This will provide the client Internet connectivity via its local ISP Point of Presence.

The next step involves connecting to the VPN. Create a second connection using the Network Connection Wizard. Make it a VPN connection to be invoked after the dial-in connection is established:

Start the Network Connection Wizard by double-clicking the New Connection Wizard icon. Click Next. Select Connect to the Network at my workplace. Click Next.

Select Virtual Private Network connection (Figure 13.23). Click Next.

Type a name for the VPN connection and click Next.

Select Automatically dial this initial connection and select the previously created dial-in connection to invoke the dial-up when this new VPN connection is established. If you plan to access the Internet through a LAN interface, select Do not dial the initial connection. You may also select this option and dial up to the Internet manually. Click Next.

Type the IP address of the VPN server's external interface. Click Next.

Select whether all users on the system will be able to use the VPN connection. Click Next.

Click Finish.

Once the VPN client's dial-in and VPN network connections are created, the client system is ready to establish a VPN tunnel. The user need only start the dial-in connection first and then the VPN connection. If the VPN connection has been selected to automatically dial the dial-in connection, it alone need be invoked. The same is true if the VPN server is available through a LAN interface (Figure 13.24).

Routing and Remote Access Server Management

The Routing and Remote Access snap-in can perform several functions. To control the server's behavior, right-click the RAS server and select Start, Stop, Pause, Resume, or Restart.

VIEWING REMOTE ACCESS CLIENTS

To manage this environment well, a facility for easy viewing of remote access clients is important. Right-click servername Remote Access Clients, select the desired client from the details pane, and choose

Status to see statistics, errors, and network information (Figure 13.25).

Disconnect to disconnect a client from the VPN server.

Send Message to send a text message to a single client.

Send to All to send text message to all remote clients.

Internet Authentication Service and RADIUS

The Internet Authentication Service (IAS) enables centralized authentication, authorization, and auditing for remote clients. Once the client has been authorized with the centralized account manager, a VPN connection may be established according to the user's account policies. This is accomplished through the Remote Authentication Dial-In User Service (RADIUS), which enables the ISP's points of presence (POPs) to authenticate dial-in and VPN clients on one IAS server for the corporation. User account profiles are maintained in one location, not on every VPN server the local network supports. Once the IAS server on the local corporate network has verified the user's credentials, the POP can establish a VPN connection with a local VPN server.

NOTE Windows Server 2003 provides authentication improvements for wireless, remote access, and VPN users in other forests, nontrusted domains, or other RADIUS user databases. A member IAS/RADIUS server provides authentication and authorization for user accounts that are members of the domain or forest. It can authenticate the user account in the other forest where Active Directory forests are in cross-forest mode with two-way trusts. Most of the enhancements to IAS and RADIUS with Windows Server 2003 are:

IAS Proxy can authenticate users with a RADIUS server outside of a company's network and then authorize the user for local access by assigning the user a locally recognized Active Directory user account.

IAS can directly map certificates issued by trusted certificate authorities to Active Directory user accounts.

Systems that reboot while participating in the local Active Directory network using IAS can be reauthorized for network access using their computer account. The system cannot access resources in the local AD framework. Unless the user logs on manually to the AD network with a user account, a subsection of IAS configuration may be replicated between servers using NetShell commands.

IAS may authenticate users in other forests if a two-way trust has been established between the local and remote forests.

Access for visiting users and other network devices without authorization can be assigned to local Active Directory using Extensible Authentication ProtocolTransport Layer Security (EAP-TLS).

Multiple Extensible Authentication Protocol types can be assigned based on network connection type or security group membership. This allows the administrator to assign different EAP types to each access policy.

Roaming wireless clients can be reauthenticated quickly when moving geographically between wireless access points using the Protect-EAP.

IAS can negotiate the EAP authentication method with clients.

In conjunction with Remote Access Server, IAS can quarantine until the client's system configuration has been analyzed and accepted. In this way, administrators can ensure that clients have installed correct antivirus and software patches.

IAS can require object identifiers (OIDs) on client certificates to enforce the type of certificate required to log on. A user may be forced to log on with a "User" certificate rather than a "Web Server" certificate.

IAS can be configured to interoperate with Network Access Servers that do not conform to RFCs.

Wireless devices can be authenticated with user name and passwords in addition to certificate based authentication.

EAP-TLS authentication event logging has been enhanced to assist troubleshooting.

RADIUS configuration can be assigned to a range of IP addresses to ease administration.

A RADIUS Proxy can forward authentication to another RADIUS server. An organization may need this capability for load-balancing reasons or simply to authenticate users from partner sites on its local network.

Logon hours as assigned in Active Directory user accounts are enforced for RADIUS clients.

The general architecture of IAS has the following components (Figure 13.26):

The mobile remote client connects to a nearby ISP's POP using a modem connection and any of the supported authentication methods discussed at the beginning of the "Virtual Private Networks" section. The user's realm name is either provided at the connection logon in the form username@realm or provided by the Connection Manager automatically. This name is easier to handle if it corresponds to the corporation's Active Directory user account realm name (discussed later in an example).

The ISP dial-in server (soon to be a VPN client with the user's corporate network) forwards the RADIUS request to the RADIUS server configured as a proxy.

The proxy sends a RADIUS request to the RADIUS server at the corporate site.

The RADIUS server verifies the user's credentials in the Active Directory and checks the user's applicable remote access policies.

The RADIUS proxy relays the user's connection request to the VPN client at the ISP. The VPN client at the ISP then initiates a tunnel with the VPN server at the corporate site.

NOTE The VPN connection is entirely separate from the RADIUS authentication process. The RADIUS server at the corporate site is configured with the Internet Authentication Service snap-in tool. RADIUS clients are added to the RADIUS server's client list, where logging and accounting properties can be configured. Remote access policies and profiles are modified in the same fashion as they are for VPNs. The main difference between the VPN scenarios and the IAS architecture is the method of authentication chosen from the Routing and Remote Access snap-in tool.

Firewalls must be configured to forward RADIUS UDP communications and permit remote connections with the IAS server. This is usually accomplished by putting the IAS server in a demilitarized zone (DMZ) to provide both Internet access and limited intranet exposure.

The RADIUS architecture permits all user requests throughout the Internet to be forwarded to one or more IAS servers maintained and administered from the corporate intranet. In this way, remote access policies can be managed in a central location. ISPs forward requests to the local intranet, which verifies a user's remote access policy. Remote user accounts can be managed from the corporate intranet without the need to constantly update accounts with different ISPs.

IAS INSTALLATION

The IAS installation is not automatic during standard installation. The following steps should be followed to install IAS on a Windows Server 2003:

From Control Panel, click Add/Remove Programs and select Add/Remove Windows Components.

From Windows Components, select Networking Services and click Details. Choose Internet Authentication Service and click OK. Click Next. Click Finish.

From the Internet Authentication Service snap-in, right-click the Internet Authentication Service node and select Properties. The following tabs are available (Figure 13.27):

The General tab configures the logging of accepted or rejected authentication requests.

The Ports tab identifies UDP ports required for IA to provide authentication and accounting services through a firewall.

IAS Remote Access Policy

Remote access policies for IAS must be established. To do so, follow these steps:

Right-click the Remote Access Policy node and select New Remote Access Policy. Click Next. Type a name for the new policy, such as IAS VPN Client Policy. Click Next.

Select the VPN option. Click Next. Grant access to a particular user or group. Click Next.

Select Authentication Methods. Click Next.

Select Encryption Levels. Click Next. Click Finish.

If any other default policies exist, remove them. This will eliminate conflicts with previously established RAS policies.

Registering the IAS Server with the Active Directory

To make IAS available throughout the enterprise, it is necessary to register it with the Active Directory. The following step will do this:

Right click the Internet Authentication Service snap-in node and select Register Server in Active Directory.

Radius Client Configuration

The Network Access Server (NAS) handling the client's dial-in connection also supports the RADIUS client software and configuration. The following example demonstrates configuration of a RADIUS client/RAS server running Windows Server 2003 Routing and Remote Access.

From the Routing and Remote Access snap-in, right-click the Routing and Remote Access node and select servername node. Select Properties and proceed to the Security tab.

Select RADIUS Authentication from the drop-down list under Authentication provider (Figure 13.28), then click Authentication Methods. Ensure that the MS-CHAP v2 and MS-CHAP authentication protocols are selected (Figure 13.29). Click OK. Click Configure and type the RADIUS server name or IP address and enter the shared secret by clicking Change.

Select RADIUS Accounting under Accounting provider and click Configure. Repeat step 2 for RADIUS accounting.

Stop and restart the Routing and Remote Access service to make sure the new settings take effect.

Set up a remote access client by following the steps in the "Remote Access Client Configuration" section and verify client connectivity and RADIUS configuration settings.

RADIUS ACCOUNT LOGGING

RADIUS records authentication and accounting requests made from the RADIUS client. This information can be used to track billing and account activity. To select the types of requests to be logged on to the RADIUS log file:

From the Internet Authentication Service snap-in tool, select the Remote Access Logging node. Right-click the Local File and select Properties.

From the Settings tab, three logging characteristics are available (Figure 13.30).

NOTE IAS can be configured to send logging information for accounting requests, authentication requests, and periodic status to a Structured Query Language (SQL) server. This allows IT administrators to use SQL queries to obtain historical and real-time information about connection attempts that use RADIUS for authentication. To configure, obtain properties of the SQL Server™ logging method in the Remote Access Logging folder of the Internet.

RADIUS PROXY SERVERS

Radius proxy servers are configured at ISPs to forward communications with the desired IAS server. An ISP can configure a proxy server with all necessary IAS server information and can point RAS servers to it. This eliminates the need to configure every RAS server with current RADIUS server information.

RADIUS LOAD BALANCING

Windows Server 2003 provides IAS/RADIUS Proxy load balancing between RADIUS servers. The feature enables greater scalability and geographic failover. The objective is to balance the load of a large volume of authentication traffic. There is little need for administrative intervention since IAS RADIUS proxy dynamically balances the load of connection and accounting requests. Specific RADIUS proxy servers can be designated with higher preference.