Configuring Routing and Remote Access User Authentication

With remote access, you are basically opening the door for remote access clients to access the internal network. With remote access arises the topic of security. You must be able to allow certain "trusted" clients to have remote access while denying access to everyone else. You also want to ensure that the data that is being sent between a remote access client and a remote access server is secure. To meet these requirements, Windows Server 2003 supports a number of authentication and encryption protocols.

Configuring Remote Access Authentication Protocols

Windows Server 2003 supports a number of authentication protocols that can be used to authenticate dial-up clients. The supported protocols are as follows:

• Password Authentication Protocol (PAP) PAP is the least secure of all of the authentication protocols because it sends the username and password in clear text.

• Shiva Password Authentication Protocol (SPAP) SPAP can be used to authenticate against Shiva remote access servers and to authenticate against Windows 2003 Servers. This protocol is typically more secure than PAP but not as secure as CHAP or MS-CHAP.

• Challenge Handshake Authentication Protocol (CHAP) CHAP does not send the username and password across the network. Instead, it uses a challenge response with a one-way hash algorithm. It is an industrystandard protocol that can be used to authenticate non[nd]Windowsbased clients.

• Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) MS-CHAP is a Microsoft version of CHAP that uses mutual authentication and encryption for Windows-based clients. MS-CHAP version 2 provides strong encryption and separate encryption keys for sending and receiving data.

• Extensible Authentication Protocol (EAP) EAP is an extension of PPP that provides support for other authentication mechanisms, such as smart cards. This authentication protocol requires the presence of a PK infrastructure.

Exam Alert

Knowing the features and the differences among the following authentication protocols is important for achieving success on the exam. For example, if your remote access clients use smart card authentication, you need to enable EAP on the remote access server. Or, if smart cards are not deployed, and all remote access clients are running Windows XP, you should only enable MS-CHAPv2 because it provides the most security.

Using the Properties dialog box for the remote access server that is shown in Figure 5.5, you can configure which authentication protocol the remote access server can use to authenticate remote clients. Clicking the Authentication Methods button from the Security tab opens the Authentication Methods dialog box, from which you can select the authentication protocols that are available on the server.

Figure 5.5. You configure authentication methods by clicking the Authentication Methods button on the Security tab

When you have enabled the authentication protocols at the server level, you can use the Authentication tab in the policy's Properties dialog box (see Figure 5.6) to specify which of the authentication protocols are available for each remote access policy. To do so, click the Remote Access Policies container, right-click the appropriate policy within the Details pane, and click Properties. You can access the Authentication tab by clicking the Edit Profile button.

Figure 5.6. Configuring authentication methods in a remote access policy via the Authentication tab

Configuring Encryption Protocols

If you're sending sensitive data across the network, you might want to add another level of security by implementing some form of data encryption. The two types of encryption available are as follows:

• Microsoft Point-to-Point Encryption (MPPE) MPPE can use 40-bit, 56-bit, and 128-bit encryption keys. MPPE encryption can be used for PPP connections, including PPTP VPN connections. MPPE is used in conjunction with EAP-TLS and MS-CHAP authentication protocols.

• IP Security (IPSec) IPSec is used with L2TP connections. It supports the Data Encryption Standard (DES) and triple DES (3DES).

Note

Some older Microsoft operating systems do not support 56-bit encryption. To support these clients, you must use 40-bit encryption instead. Otherwise, you should use 56-bit encryption. Also keep in mind that 128-bit encryption is supported only in North America.

Encryption for a dial-up connection is configured at the policy level. Right-click the remote access policy within the Details pane for the Remote Access Policies container. Open the Properties dialog box for the remote access policy, click the Edit Profile button, and select the Encryption tab (see Figure 5.7). Select one or more of the following encryption levels:

• No Encryption Select this option to allow remote access clients to connect without requiring a form of encryption.

• Basic This specifies whether remote access clients can connect using MPPE 40-bit or IPSec 56-bit DES encryption.

• Strong This specifies whether remote access clients can connect using MPPE 56-bit or IPSec 56-bit DES encryption.

• Strongest This specifies whether remote access clients can connect using MPPE 128-bit or IPSec triple DES (3DES).

Figure 5.7. Configuring the encryption level for a profile

Exam Alert

For PPTP connections, 128-bit MPPE is the highest level of encryption supported by Windows 98/ME/2000/XP. For L2TP connections, 3DES is the highest level of encryption for Windows 2000/XP (Windows 2000 requires service pack 2 or later). Windows 98 requires DUN 1.4.

Configuring Internet Authentication Services (IAS) to Provide Authentication for Routing and Remote Access Clients

As your networks increase in size, you might need to implement multiple remote access servers. To ease the administrative overhead of managing multiple RAS servers, you can implement a RADIUS server to centralize the authentication of remote access clients and the storage of accounting information.

Windows Server 2003 can be configured for RADIUS by installing the Internet Authentication Service (IAS) through the Add or Remove programs applet in the Control Panel. With IAS, a server can be configured as a RADIUS server and a RADIUS proxy. When configured as a RADIUS server, RAS servers can forward authentication requests from RAS clients to the IAS server. IAS provides the benefit of centralizing user authentication and centralizing the storage of auditing and accounting information collected from the RAS servers. When RADIUS is implemented, the remote access server is configured as a RADIUS client. You can configure a RADIUS client when enabling routing and remote access. Any authentication requests to the remote access server are sent to the server running IAS. The server running IAS provides authentication, auditing, and accounting services for RADIUS clients.

When configured as a RADIUS proxy, an IAS server can forward authentication and accounting information to other RADIUS servers. The IAS server functions as a message router and forwards messages to another specified RADIUS server or client. Connection request[nd]processing rules are configured to tell the IAS server where to forward the authentication request messages. Keep in mind that an IAS server can function as a RADIUS server and a RADIUS proxy. Depending on the connection request[nd]processing rules configured, some connection requests can be authenticated and others can be forwarded.

Installing IAS

IAS can be installed using the Add or Remove Programs applet within the Control Panel by performing the following steps:

1.	Click Start, point to the Control Panel, and click Add or Remove Programs.
2.	Click Add/Remove Windows Components.
3.	From the list of Windows components, select Networking Services and click the Details button.
4.	From the list of subcomponents, select Internet Authentication Service. Click OK. Click Next.
5.	Click Finish.

When IAS has been installed, you can use the Internet Authentication Service MMC snap-in, which is located within the Administrative Tools menu, to configure IAS.

Configuring Routing and Remote Access Policies to Permit or Deny Access

A remote access policy enables you to control which users are permitted remote access to the network and specify the characteristics of the connection. In terms of remote access, Windows 2000 introduced some major changes from Windows NT 4.0. One of these changes is the use of remote access policies. Before Windows 2000, remote access was controlled through the Properties dialog box of a user account. Windows 2000 and Windows Server 2003 use both user account properties and remote access policies to control remote access.

With remote access policies, administrators can permit or deny connection attempts based on a number of criteria (such as the time of day or group membership), giving administrators much more flexibility and granular control. When a connection has been permitted, administrators can further control the session by defining the maximum session time and encryption settings.

A remote access policy consists of the following elements, which work together to provide secure access to remote access servers:

• Conditions

• Permissions

• Profile

When remote access is enabled, two default remote access policies are created automatically: connection to Microsoft Routing and Remote Access Server and connections to other access servers. You can use the Connection to Microsoft Routing and Remote Access Server policy to grant access to remote access clients. By default, this policy is configured to deny remote access.

You can create additional policies by right-clicking the Remote Access Policies icon within the Routing and Remote Access management console and selecting the New Remote Access Policy option. The wizard prompts with the option of creating a typical policy for a common scenario using the wizard or to create a custom policy. The elements of a policy are discussed in the following section.

Managing Remote Access Conditions

Conditions define the parameters that must match those configured on the remote access client before the server will grant remote access. These can include parameters such as the time of day and Windows group membership. Before the permissions of a remote access policy are evaluated, the connection attempt must match the conditions within a remote access policy. For example, the conditions of the policy might specify that you must be a member of the Sales group. If the user account is a member of the Sales group, the conditions have been met and the policy evaluation continues by checking the permissions of the user account. If multiple policies are configured, the first policy that matches the conditions of the connection attempt is then further evaluated for permissions and profile settings. Table 5.2 summarizes some of the commonly used conditions that can be configured for a remote access policy.

Table 5.2. Conditions That Can Be Configured in a Remote Access Policy

Condition	Description
Called station ID	The number dialed by the remote access client
Calling station ID	The number from which the remote access client called
Day and time restrictions	The days of the week and time of day users are allowed remote access
Windows groups	The Windows groups to which the user must belong

To configure the conditions of a remote access policy, follow these steps:

1.	Open the Routing and Remote Access management console and click the Remote Access Policies container.
2.	Right-click the remote access policy and click Properties.
3.	From the Properties dialog box for the policy, click the Add button.
4.	In the Select Attribute dialog box, select the attributes that you want to configure and click Add (see Figure 5.8).

Figure 5.8. You can configure remote access conditions to further control how remote access is handled

Controlling Remote Access Permissions

If the connection attempt matches the conditions of a remote access policy, the permissions of that policy are then evaluated. The remote access permissions determine whether a specific user is granted or denied remote access. Windows Server 2003 uses a combination of the dial-in properties of a user account and the permissions in the remote access policy to determine whether the connection attempt is allowed. Remote access permissions can be explicitly allowed or denied through user account properties. When configuring remote access permissions using the Dial-In tab in the Properties dialog box for a user account, you have the following three options (see Figure 5.9):

Figure 5.9. Configuring remote access permissions through the user account properties

• Allow Access

• Deny Access

• Control Access Through Remote Access Policy

Exam Alert

If the Control Access Through Remote Access Policy option is unavailable, switch the domain from Windows 2000 native mode to Windows Server 2003 mode. This option is not available when operating in Windows 2000 native mode.

If you explicitly allow remote access by selecting the Allow Access option, the connection attempt can still be denied if the properties configured for the user account do not match the remote access policy or if the profile settings are not met.

If you choose to have the policy control remote access permissions, you can grant or deny permission through the policy's Properties window (see Figure 5.10). If you are using the default policy, remote access permission is denied by default. You must change this setting to allow access.

Figure 5.10. Controlling access through the remote access policy

From the Dial-In tab, several other settings can be configured, including caller ID, callback options, and static IP routes. Again, if you configure the settings for the user account, they must match the settings configured on the client or the connection attempt will be denied.

Exam Alert

Using the callback feature, a RAS server can be configured to call a remote access client back at a preconfigured number or at a number set by the caller. This provides an added level of security because users are permitted to dial in to the remote access server only from the number specified.

Configuring a Remote Access Profile

The final element of the remote access policy is the remote access profile. When the remote access client has been granted permission, the profile determines the settings of the connection. Again, the settings in the profile must match those of the connection attempt or it will be denied.

To configure the profile settings, click the Edit Profile button in the policy's Properties window. This opens the Edit Dial-In Profile dialog box, shown in Figure 5.11. Several tabs are available, as summarized in Table 5.3.

Figure 5.11. You can configure a remote access profile via a remote access policy

Table 5.3. Remote Access Profile Settings

Property Tab	Description
Dial-In Constraints	Configure the disconnect if idle time, maximum session time, day and time restrictions, and media and number restrictions.
IP	Define how IP addresses are assigned to clients, and configure packet filtering for inbound and outbound connections.
Multilink	Enable and configure multilink and the Bandwidth Allocation Protocol.
Authentication	Configure the authentication methods that are available for the connections in the remote access policy.
Encryption	Configure the different levels of encryption for the policy.
Advanced	Specify additional connection parameters.

Evaluating Remote Access Policies

Given the many options and the complexity of remote access policy elements, it is important to have a good understanding of how policies are applied when a remote access client attempts a connection. Assuming that your domain functional level is Windows Server 2003, the following points outline the connection process:

• When a user attempts to establish a remote access connection, the RAS server determines whether a policy exists. The first policy in the ordered list of remote access policies is checked. If there is no policy configured (and the default policy has been deleted), the connection attempt is rejected. If a policy does exist, the evaluation process continues.

• The conditions of the first policy in the list are evaluated. If the connection attempt matches all the conditions, the evaluation process continues. If all conditions do not match the connection attempt, the next policy in the list is evaluated. If no more policies exist, the connection attempt is rejected.

• If the connection attempt matches the conditions in one of the policies, the permissions for the user are evaluated. If the user's account property is set to Deny Access, or if the permission within the policy is set to Deny Access, the connection attempt is rejected. If the policy or the account property is set to Allow Access, the process continues.

• The settings of the remote access profile and the properties of the user account are evaluated against the connection attempt. If the connection attempt matches both the profile and account settings, the user is granted remote access. If not, the connection attempt is rejected.

Exam Alert

Remote access policies are a popular topic on the exam. Be sure you are familiar with how remote access policies and the policy elements are evaluated. Also keep in mind that remote access policies are not stored within Active Directory; they are stored on each server.

Tip

If you are running in Windows 2000 native functional level, keep in mind that, unless they are set to Deny Access, the permission settings configured using the Dial-In tab for a user account override those in the policy. For example, if the account property is set to Allow Access but the profile denies it, the user is granted access and the process of evaluation continues. On the other hand, if the account property is set to Deny Access and the profile permits access, the connection attempt is rejected. By default, the Administrator and Guest accounts on a standalone remote access server or in a Windows Server 2003 functional-level domain are set to control access through the remote access policy; for a Windows 2000 native functional-level domain, they are set to Deny Access.

Configuring Routing and Remote Access for DHCP

As you saw when enabling RRAS, you can configure the remote access server with a range of IP addresses to assign to remote access clients. (If you do, make sure the range does not conflict with the range of IP addresses configured on the DHCP server, to avoid duplicate addresses.) You can also configure the RAS server to obtain IP addresses from the DHCP server to lease to clients.

When you choose to use a DHCP server, the remote access server obtains, by default, 10 IP addresses to lease to clients. If all 10 IP addresses are in use, the remote access server obtains 10 more from the DHCP server. (Ten is the default number but can be changed through the Registry.) The benefit of using DHCP with RAS is that IP address assignment remains centralized.

For DHCP to be used with RAS, the DHCP Relay Agent must be configured on the RAS server. When you configure the DHCP Relay Agent, clients still receive IP addresses from the RAS server, but they can use DHCPInform messages to obtain optional parameters, such as the IP addresses of WINS and DNS servers, directly from the DHCP server. The relay agent component allows the RAS server to relay the DHCPInform messages between the remote access clients and the DHCP server.

To configure DHCP to work with remote access, follow these steps:

1.	Within the Routing and Remote Access management console, right-click General under the IP Routing icon and select New Routing Protocol.
2.	In the Select Routing Protocol window, select the DHCP Relay Agent and click OK.
3.	Right-click the DHCP Relay Agent icon, listed under IP Routing, and select New Interface. Select the network connection over which DHCP messages will be routed and click OK.
4.	Right-click the DHCP Relay Agent and select Properties. Type the IP addresses of the DHCP server or servers to which the RAS server should forward the DHCPInform requests (see Figure 5.12). Figure 5.12. You must configure the RAS server with the IP address of the DHCP server
5.	Right-click the interface to open the Properties window. From the Properties window, you can disable or enable the relaying of DHCP packets, and configure the hop count and the boot threshold.