Objective 5.2: Designing a Secure Remote Access Plan

When designing a network, most modern corporations will need to include some means of remote access for traveling and telecommuting members of their workforce. One could almost say that the prevalence of the Internet has destroyed the time-honored tradition of the snow day, where a blizzard left you free to sit on the couch and watch movies ”the increasing prevalence of laptops and broadband Internet connections has made it much simpler (and therefore expected) to be able to access corporate resources from remote locations. As a network administrator, you need to be concerned not only with providing this type of access, but also with ensuring that allowing remote access will not compromise the confidentiality, integrity, or availability of your company s data and resources. The design decisions that you make will need to strike a balance between creating convenience for your users and not sacrificing the security of your corporate network. In this section, we ll examine common remote access technologies and protocols, and look at the relative security merits of each. Having a firm grasp of this information will assist you in preparing for the 70-298 exam, and designing a secure remote access for a real-world network.

Choosing a Remote Access Method

There are two general options that you can choose from when designing a remote access solution for your network. The first option is to use a direct-dial remote access server that s running the Routing and Remote Access service with a modem, bank of modems, or dedicated WAN connection physically attached to the server. You should already be aware of the cost implications of this solution: using a direct-dial number can become prohibitively expensive if you re dealing with users who are dialing in from around the country or the world ”whether the expense is borne by the users themselves making long-distance connections, or by the company supporting a toll-free access number.

From a security standpoint, direct- dialed access can be quite attractive, since network access will be restricted to the corporate network itself and will not be traversing the Internet or other shared networks. However, keep in mind that dial-up remote access is not a panacea ”it will not absolutely safeguard you from attackers . For example, dial-up remote access is vulnerable to attack when end users store their passwords with their connection information ”if a traveling user s laptop is stolen and she has stored her password with her RAS connection, the person who stole her laptop will be able to access the corporate network using that saved password information. You might also encounter situations where malicious users will attempt to attack a toll-free 800 number itself, either running up phone charges for the sake of mischief, or attempting to use the toll-free access to make other unauthorized phone connections once the RAS connection has been established. (Some companies that have been victim to this type of attack only became aware of it when their telephone bill showed up in a box instead of an envelope!) While telephone and PBX security is beyond the scope of the 70-298 exam, it s a real-world consideration that you should definitely be aware of when designing a network.

If you want to avoid the cost considerations of supporting a dial-up RAS server, you can opt instead to allow VPN connections to your internal network. RAS and VPN were covered in detail in Chapter 7, Securing VPN and Extranet Communications, but as a refresher, you should recall that your VPN design should call for the most secure encryption that your RAS clients will be able to support. (We ll discuss RAS and VPN protocols in the next section.) Since VPN traffic is traversing the Internet, you need to mandate the strongest level of encryption possible to ensure the confidentiality and integrity of your data and your users account and password information.

Selecting a Remote Access Protocol

For each remote access method, there are a number of different protocols that you can select for your client workstations to connect with. While you obviously want to use the best encryption possible, you need to keep in mind any technical constraints created by your network clients, since not all operating systems can support all protocols.

• Dial-up remote access protocols

  • Password Authentication Protocol (PAP)/Shiva Password Authentication Protocol (SPAP) Both of these protocols are supported by Windows Server 2003 for backward compatibility only. PAP sends user credentials to the remote access server in cleartext , and SPAP uses a primitive encoding method that isn t much better. If possible, connections using these protocols should not be allowed by any secure remote access server.

  • Challenge Handshake Authentication Protocol (CHAP) This protocol encrypts a RAS user s credentials (username and password) using the MD5 encryption algorithm. While this is an improvement over PAP and SPAP, only the user s credentials are encrypted: any data transmitted during the RAS connection is sent in clear-text. Additionally, CHAP requires that user passwords in Active Directory be stored using reversible encryption, which makes Active Directory DCs subject to additional types of network attacks. CHAP should only be used if your network is supporting remote access users who are running the Macintosh or UNIX platform.

  • Microsoft Challenge Handshake Authentication Protocol(MS-CHAP) This is a Microsoft-specific implementation of CHAP that improves somewhat on the encryption used by CHAP. It does not require passwords to be stored using reversible encryption. You should only allow MS-CHAP connections if you are supporting legacy RAS clients that are running Windows 95 or older Microsoft operating systems.

  • MS-CHAP version 2 This improvement on MS-CHAP introduces mutual authentication , where both the client and the server verify their identity to one another. MS-CHAP uses a much stronger encryption algorithm, and uses separate encryption keys for sending and receiving data. MS-CHAPv2 is supported by Windows 98 and Windows NT 4.0, allowing you to use a stronger encryption method than MS-CHAP unless you are supporting very old RAS clients.

  • Extensible Authentication Protocol (EAP) As the name implies, EAP allows developers to extend remote access authentication to include a number of advanced features, including two-factor authentication using smart cards or biometric devices (such as retina scanners or thumbprint recorders ). EAP-TLS uses public key certificate-based authentication for remote access, and is the strongest RAS authentication method available under Windows Server 2003. However, EAP-TLS can only be used by clients that are running Windows 2000, Windows XP, or Windows Server 2003.

If you will be using VPN technologies to enable remote access, you have two main choices of protocols that you can enable. Your choice of protocol will be largely dependent on the client operating systems and network hardware that you need to support.

• Virtual private networking protocols

  • Point-to-Point Tunneling Protocol (PPTP) PPTP is a VPN tunneling protocol that is supported by all Microsoft clients since Windows NT 4.0. PPTP can encrypt data using a 40-bit, 56-bit, or 128-bit encryption key. Unless you have a specific reason not to, you should mandate 128-bit encryption when using PPTP, since the 40-bit and 56-bit keys have been broken and are therefore vulnerable to decoding.

  • Layer Two Tunneling Protocol (L2TP) This is a stronger form of encryption that s supported natively by Windows 2000 and Windows XP, and by Windows 98, Me, and NT 4.0 with the installation of an add-on client. L2TP does not provide its own data encryption, but instead relies on IPSec to encrypt data using either a 56-bit DES key, or three 56-bit DES keys using 3DES encryption. Before the release of Windows Server 2003, PPTP was necessary if you were using Network Address Translation (NAT) devices, since L2TP and IPSec could not traverse NAT devices. However, Windows Server 2003 supports NAT traversal natively, and Microsoft has released an update for Windows XP and Windows 2000 that will allow their L2TP/IPSec clients to do so, as well.

No matter which authentication and encryption protocols you choose, you should mandate their use by your remote access clients by configuring remote access policies, which we ll discuss next.

Objective 5.2.1: Designing Remote Access Policies

You can use remote access policies to verify any number of settings both before and after a RAS client is allowed to connect to your corporate network. For example, you can use remote access policies to either allow or reject connection attempts based on group memberships, time of day, day of the week, and the like. You can further require a specific authentication method and encryption strength, and even limit the amount of time a RAS client can remain connected to your network. When planning your remote access policy strategy, you can use one of the following three approaches:

• Common policy You can create a single common policy that creates a universal connection template for anyone connecting using a particular access method ”you can create a policy to handle all VPN clients, one to configure all wireless clients, and so forth.

• Default policy If you re not concerned with restricting remote access usage based on connection methods , group membership, and the like, you can use one of the default policies that are installed with the Routing and Remote Access service. These default policies will grant remote access to any user with a valid Active Directory account.

• Custom policy This will allow you to specify a more detailed configuration for a particular access method. This will be necessary if you want to manage connection attempts at an extremely granular level. We ll look at each possible connection setting that you can control through a custom policy in the next section.

Understanding the Elements of a Remote Access Policy

Remote access policies consist of the following elements: conditions, permissions, and profiles. We ll discuss each of these elements in turn , and list how each can be used to control remote access attempts by your network clients.

Remote Access Conditions

Remote access conditions consist of one or more attributes that can be compared against a connection attempt by a remote user. A remote access policy can specify one or more of these attributes that should be checked before allowing access. If a policy specifies multiple conditions, then all of the conditions need to match in order for the policy to find a match. For example, let s say that a remote access policy will only allow VPN connections on Saturdays and Sundays, and only from members of the SalesVP group. If a member of the SalesVP group attempts to establish a VPN connection on a Friday, the connection attempt would be rejected, since both conditions were not met. Table 10.3 lists the various attributes that you can set as part of a remote access policy.

Table 10.3: Remote Access Conditions

Attribute Name	Description
Authentication Type	The type of authentication that is being used by the access client. Authentication types include CHAP, EAP, MS-CHAP, and MS-CHAP v2.
Called Station ID	The phone number that the client is dialing in to.
Calling Station ID	The phone number that the caller is dialing in from .
Client Friendly Name	The name of the RADIUS client that is requesting authentication. This name is configured in Friendly name on the Settings tab in the properties of a RADIUS client in IAS. This attribute is a character string. This attribute is used by IAS, which we ll discuss in a late section.
Client IP Address	The IP address of the client.
Client Vendor	The vendor of the network access server (NAS) that is requesting authentication ”this is most often used in a site-to-site VPN like the ones discussed in Chapter 7. You can use this attribute to configure separate policies for different NAS manufacturers who are connecting via IAS.
Day and Time Restrictions	The day of the week and the time of day of the connection attempt. The day and time is relative to the day and time of the server providing the authorization.
Framed Protocol	The type of framing for incoming packets, such as PPP, SLIP, Frame Relay, and X.25.
NAS Identifier	The name of the NAS. This attribute is a character string. You can use pattern-matching syntax to specify multiple NASs.
NAS IP Address	The IP address of the NAS (the RADIUS client) that sent the message.
NAS Port Type	The type of media that is used by the access client, such as a plain old telephone line, ISDN, wireless, or VPN connection.
Service Type	The type of service that is being requested . Examples include framed (such as PPP connections) and login (such as Telnet connections).
Tunnel Type	The type of tunnel that the client is requesting ”either PPTP or L2TP, as we discussed earlier.
Windows Groups	The names of the groups to which the user or computer account that is attempting the connection belongs. You don t need to have a separate remote access policy for each group. Instead, you can use multiple groups or nested groups to consolidate and delegate the administration of group membership.

Remote Access Permissions

If all of the conditions set by a remote access policy are met, then permission to access the network will be either granted or denied . The best way to set remote access permissions for your users is to configure your accounts to Control Access through Remote Access Policy , rather than granting or denying permissions to each individual account.

Exam Warning  

The remote access permission specified on a user s account Properties page overrides any permissions set through a remote access policy. Therefore, if a user account has been manually configured to Grant Remote Access, that user will be able to make a RAS connection no matter what remote access policies are in place. This is why using the Control Access through Remote Access Policy option is a best practice in a large enterprise environment.

Remote Access Profiles

A remote access profile is a set of conditions that are applied to a connection after it has been authorized, either through the user s account Properties, or through a remote access policy. Once a user has been granted a remote access connection, you can fine-tune the connection by setting any of the following profile conditions:

• Dial-in constraints can include any of the following:

  • # of minutes a client can remain idle before it is disconnected. By default, this property is not set.

  • # of minutes a client can remain connected. This specifies the maximum amount of time that a client can remain connected, after which the connection is disconnected by the access server after the maximum session length. By default, this property is not set, which means that there is no maximum session limit.

  • Allow access only on specific days and times. The days of the week and hours of each day that a connection is allowed. If the day and time do not match the configured profile, the connection will be disconnected. However, if a client makes a connection during an allowed time, the session will not be disconnected if the client remains connected past the allowed day/time restrictions.

  • Allow access to this number only. The specific phone number that a caller must call in order for a connection to be allowed. If the dial-in number of the connection attempt does not match the configured dial-in number, the connection attempt is rejected. By default, this property is not set so that all dial-in numbers are allowed.

  • Allow access only through these media. The specific types of media, such as modem, ISDN, VPN, or wireless that a caller must use for a connection to be allowed. If the dial-in medium of the connection attempt does not match the configured dial-in media, the connection attempt is rejected. By default, this property is not set and all media types are allowed.

• Possible IP profile constraints include the following:

  • The access server must supply an IP address.

  • The access client can request an IP address.

  • IP address assignment is determined by the access server (this is the default setting).

  • A static IP address is assigned. A static IP address assigned to the user account overrides this setting. The IP address assigned is typically used to accommodate vendor-specific attributes for IP addresses.

    Test Day Tip  

    You can also use the IP profile constraints to configure IP traffic filters that apply to remote access connections. You can configure either input or output filters on an exception basis . This means that all traffic is allowed except for the traffic specified in the filters, or all traffic is blocked except for traffic that is specifically allowed.

• You can use Multilink profile settings to configure the maximum number of ports that can be taken up by a Multilink connection. You can also configure the Bandwidth Allocation Protocol so that extra multilink ports can be freed up if they are not being actively used.

• Authentication profiles will mandate what type of authentication a client must use to connect. By default, MS-CHAP and MS-CHAPv2 are enabled. You can add or remove other authentication methods as needed, including EAP, or lower forms of authentication if required.

• Encryption properties will specify one of the following encryption strengths:

  • No encryption will allow a client to connect to your RAS server using no encryption at all. To require encryption, it s important to clear this option.

  • Basic encryption requires a 40-bit key for PPTP connections, or a 56-bit DES connection with L2TP connections. Since both of these encryption levels are fairly weak, do not allow this option unless it s absolutely necessary.

  • Strong encryption enables a 56-bit connection for PPTP, or a 56-bit DES connection for L2TP.

  • Strongest encryption mandates a 128-bit connection for PPTP or a 3DES connection for L2TP. This is the best encryption method possible, and should be mandated by your remote access configuration if possible.

Your goal as an administrator is to create remote access policies that reflect the usage needs of your company or clients. If your remote access capabilities are limited to three dial-up modem connections, for example, you might want to restrict the use of these modems during the day to those users who have a specific need for it. You might have a small number of regional sales directors who work from various locations and need to access reporting data during the day, and you do not want to have their connection attempts refused because non-mission-critical RAS connections are tying up the available connections. In the following exercise, we ll create a remote access policy that limits remote access connections on your network to members of the SalesVP group between the hours of 8 a.m. and 5 p.m ., Monday through Friday. Creating this policy will allow your company s sales vice presidents to access the information they need rather than allowing extraneous remote access connections to tie up your limited resources.

Exercise 10.02: Creating a Remote Access Policy

1. Open the Routing and Remote Access MMC by clicking on Start Programs Administrative Tools Routing and Remote Access .

2. Right-click on Remote Access Policies and select New Remote Access Policy . Click Next to bypass the initial screen in the wizard. You ll see the screen shown in Figure 10.7. Click Use the wizard to set up a typical policy for a common scenario , enter a name to describe the policy, and then click Next .

   
   Figure 10.7: Creating a Remote Access Policy

3. From the Access method screen, select the access method that this policy will apply to. You can select one of the following methods:

   • VPN access

   • Dial-up access

   • Wireless access

   • Ethernet

4. For the purpose of this example, select Dial-Up Access , and then click Next .

5. Decide whether to grant remote access permission on a user or group level. Using groups will provide easier and more efficient administration since you can group users with common remote access needs and add or remove users from the group as needed. Select Group , and add the SalesVP group. Click Next to continue.

6. In the screen shown in Figure 10.8, select the authentication method that this remote access policy will use. If your clients are using software that can handle the higher encryption levels, you can disable weaker encryption schemes like CHAP to prevent users from connecting with a lower level of encryption.

   
   Figure 10.8: Remote Access Authentication Methods

7. Click Next to continue. On the next screen, select the levels of encryption that your users can employ to connect to the IAS server. You can select an encryption level of 40-, 56-, or 128-bit encryption, or choose not to mandate encryption at all. Click Next and then click Finish to set these standard policy settings.

8. Next, you ll want to further modify the remote policy so that users can only connect to your dial-up modems between 8 a.m. and 5 p.m. , Monday through Friday. Right-click on the Remote Access Policy that you just created, and select Properties .

9. Click Add to include another condition to this policy, adding new conditions one at a time. Figure 10.9 illustrates the various conditions that you can use to grant or deny remote access to your clients.

   
   Figure 10.9: Remote Access Policy Conditions

   The final step in enabling remote access is to configure your Active Directory Users or Groups to use the remote access policy that you just created. To configure the SalesVP group to use the remote access policy, follow these steps:

10. In Active Directory Users and Computers, right-click on the SalesVP group and select Properties .

11. Click on the Remote Access tab, and select Click on Control Access through Remote Access Policy . Click OK , repeating this step for any other users or groups who require the remote access policy.

 

Objective 5.2.2: Providing Access to Internal Network Resources

Once you ve granted access to your network through any of the remote access methods we ve discussed, you ll need to provide your users the ability to connect to the actual resources and data contained within your network. (Otherwise, the entire exercise of planning and deploying remote access technology wouldn t be very useful, now, would it?) It is not enough to simply grant remote access permissions via a policy or a user s account properties in Active Directory Users & Computers; you ll need to create the appropriate NTFS permissions to actual file and application shares within your internal network.

Perhaps the most convenient feature of remote access in Windows Server 2003 is that your clients, once granted access, will use standard tools and interfaces to connect to internal network resources. Any services that are available to a user connected via the LAN will be made available to RAS clients by way of the RAS authentication and logon process. From Windows 2000 or XP Professional workstations, remote access users can create network drive mappings or access files and printers using the familiar Windows Explorer or My Network Places interface. Windows Server 2003 fully supports the use of drive letter mappings and Universal Naming Convention (UNC) connections from remote access clients. Because of this, most Microsoft and third-party applications will function over a RAS connection just as though the user were connected locally.

Objective 5.2.3: Using Internet Authentication Service

Beginning as early as the Option Pack add-on for NT 4.0, Microsoft has offered IAS as a RADIUS server. The release of IAS included in Windows Server 2003 expands and improves the existing IAS functionality, and includes connection options for wireless clients, as well as authenticating network switches and the ability to relay requests to remote RADIUS servers. IAS is available in the Standard, Enterprise, and Datacenter Editions of Windows Server 2003, but not the Web Edition. Since it functions with a wide range of wireless, remote access, and VPN equipment, IAS can be used for everything from the smallest corporate remote access solution to managing the user base of a major Internet service provider (ISP). IAS is capable of managing the entire user login process: managing the user authentication process, then verifying that a user is authorized to access various network resources, and finally creating an audit trail to provide accountability for each user s activities.

Exam Warning  

Windows Server 2003, Standard Edition, can only support a maximum of 50 RADIUS clients and 2 RADIUS server groupings. The Enterprise and Datacenter Editions of Windows Server 2003 will allow you to configure an unlimited number of RADIUS clients and server groups.

Authentication Protocols Supported by IAS

IAS supports a variety of authentication methods that can meet the needs of most client platforms. In addition, you can create custom authentication methods to meet any specialized requirements of your network security policy. The default authentication methods supported by IAS are password-based PPP and EAP, which we ve already discussed. By default, IAS supports two EAP protocols: EAP-MD5 and EAP-TLS. Other supported PPP protocols include:

• Password Authentication Protocol (PAP)

• Challenge Handshake Authentication Protocol (CHAP)

• Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)

• MS-CHAP version 2

Once a user has been authenticated using one of these protocols, IAS is able to use a number of methods to verify the authenticated user s authorization to access various services or resources. Just as with authentication methods, you can either use a default authorization scheme or use the Software Development Kit (SDK) to create custom methods to meet your company s needs. IAS supports the following authorization methods out of the box, with no need for custom codes or scripting:

• Dialed Number Identification Service (DNIS) bases its authorization decision on the phone number that the caller is using. As a cost-saving measure, for example, you can authorize only users within a local calling area to use a particular number.

• Automatic Number Identification/Calling Line Identification (ANI/CLI) is the opposite of DNIS; it authorizes access based on the number that a user is calling from .

• Guest Authorization allows access to an access point or dial-up number without a username and password. This is becoming more common in airplane terminals, coffee shops , and the like, where businesses provide a wireless access point as a convenience for their clientele. To protect the access point in question, users connecting with Guest Authorization will typically have a severely curtailed set of actions that they can perform: they might be limited to Web browsing only without access to the My Network Places browser, for example.

• Remote access policies are the most effective way to determine authorization for Active Directory user accounts. As we ve already discussed, remote access policies can authorize network access based on any number of conditions such as group membership, time of day, the telephone access number being used, and so forth. Once a user has been authorized, you can also use remote access policies to mandate the level of encryption that remote access clients need to be using in order to connect to your network resources, and set any maximum time limits for a remote connection or inactivity timeout values. Packet filters can also control exactly which IP addresses, hosts , and/or port numbers a remote user is permitted to access while connected to your network.

Designing & Planning
New Features in Internet Authentication Service

While IAS has been around in one form or another since Windows NT 4.0, several new features have been introduced with Windows Server 2003 that make IAS an ideal solution for securing enterprise environments. Some of these new features include:

1. RADIUS proxy In addition to providing its own RADIUS authentication services, you can configure an IAS server to forward authentication requests to one or more external RADIUS servers. The external RADIUS server does not need to be another Microsoft IAS server; as long as it is running an RFC-compliant RADIUS installation, the external server can be running any type of platform and operating system. IAS can forward these requests according to username, IP address of the target RADIUS server, as well as other conditions. In a large, heterogeneous environment, IAS can be configured to differentiate between the RADIUS requests that it should handle by itself, and those that should be forwarded to external servers for processing.

   • Remote RADIUS-to-Windows-User Mapping Allows you to further segregate the authentication and authorization processes between two separate servers. For example, a user from another company can be authenticated on the RADIUS server belonging to his or her separate company, while receiving authorization to access your network through this policy setting on your IAS server.

   • Support for Wireless Access Points to allow authentication and authorization for users with IEEE 802.1x-compliant wireless network hardware. IAS can authenticate wireless users through the Protected Extensible Authentication Protocol (PEAP), which offers security improvements over EAP.

   • IAS can log auditing information to a SQL database for better collection and reporting of security information.

 

Using IAS for Dial-Up and VPN

The RADIUS support provided by the IAS service is a popular way to administer remote user access to an enterprise network. For example, you can instruct your users to dial a local telephone number for a regional ISP, and then authenticate against your IAS server using a VPN client. Or, if the remote user is in the same local calling area as your corporate network, you can integrate IAS with the familiar Routing & Remote Access feature to allow them to dial directly in to a modem attached to the IAS server. IAS will then use RADIUS to forward the authentication and authorization request to the appropriate Active Directory domain, thus providing the same level of security regardless of where the user is connecting from. In Exercise 10.03, we ll cover the necessary steps to install and configure IAS on a DC in your Windows Server 2003 domain.

Exam Warning  

Microsoft recommends that you configure at least two IAS servers within your Active Directory environment. If you have only one server configured and the machine hosting IAS becomes unavailable, dial-up and VPN clients will be denied access to network resources until you bring the IAS server back online. By using two servers, you can configure your remote access clients with the information for both, allowing them to automatically fail over to the secondary IAS server if the primary one fails. This way, your remote users will be able to have continuous access to your internal resources without sacrificing the security provided by IAS.

Exercise 10.03: Configuring IAS on a Domain Controller

1. From the Windows Server 2003 desktop, open the Control Panel by clicking on Start Programs Control Panel . Double-click on Add/Remove Programs .

2. Click Add/Remove Windows Components . When the Windows Components Wizard appears, click Networking Services , and then Details . You ll see the screen shown in Figure 10.10.

   
   Figure 10.10: Installing the Internet Authorization Service

3. Place a check mark next to Internet Authentication Service and then click OK .

4. Click Next to begin the installation. Insert the Windows Server 2003 CD if prompted. Click Finish and Close when the installation is complete.

   Now that you ve installed IAS, you need to register the IAS server within Active Directory. (This is similar to authorizing a newly created DHCP server.) Registering the IAS server will allow it to access the user accounts within the Active Directory domain.

5. Click on Start Programs Administrative Tools Internet Authentication Service . You ll see the screen shown in Figure 10.11.

   
   Figure 10.11: The IAS Administrative Console

6. Right-click on the Internet Authentication Service icon and click on Register Server in Active Directory .

7. Click OK at the next screen, shown in Figure 10.12. This will allow IAS to read the dial-in properties for the users in your domain, thus allowing the IAS server to authenticate users within Active Directory.

   
   Figure 10.12: Configuring Permissions for IAS

 

Test Day Tip  

You can also register an IAS server by using the netsh command-line utility. To add an IAS server with the DNS name of dc1.airplanes.com, use the following syntax:

netsh ras add registeredserver dc1.airplanes.com

Once you ve installed and authorized an IAS server, you can use the IAS icon in the Administrative Tools folder to configure diagnostic logging and specify which UDP port IAS will use to transmit logging information. To administer the IAS server, click on Start Programs Administrative Tools Internet Authentication Service . Once you ve configured IAS, you ll need to create remote access policies to enable your Active Directory users to access your network through the IAS server, similar to the policies we ve already discussed in this chapter and elsewhere in this guide. You can use IAS in many different situations to provide various types of remote access for your network users. Besides the uses we ve already covered, you can also configure IAS to handle the following:

• Authenticating switches You can use remote access policies to allow IAS to act as a RADIUS server for Ethernet switches that have the ability to authenticate to a central server. You can enforce this type of authentication to ensure that no rogue or unauthorized switches are brought online within your network infrastructure, or to ensure that only authorized personnel can plug in to a switch that supports authentication.

• Outsourcing remote access connections IAS allows an organization to outsource its remote access infrastructure to a third-party ISP. In this situation, users connect to an ISP s dial-up, but their login credentials are forwarded to your corporate IAS server for processing. Therefore, your end users will be able to dial in to the corporate network using local ISP dial-up numbers, but your internal IAS server will also handle all logging and usage tracking for your remote users. This can provide a great deal of cost savings for your organization, allowing you to use an ISP s existing network infrastructure rather than creating its own network of routers, access points, and WAN links. IAS can also provide a similar service for outsourcing wireless access, where a third-party vendor s Wireless Access Point (WAP) forwards the user s authentication information to your IAS server for processing.

Using IAS for Wireless Access

As we discussed earlier, Windows Server 2003 has made it a relatively straightforward matter to enable a WAP to interact with the wired LAN. Furthermore, wireless clients can authenticate against an IAS server using a smart card, a digital certificate, or a username and password. The actual sequence of events when a wireless device requests access to your wired network occurs as follows :

1. When a wireless client comes within range of a WAP, the WAP will request authentication information from the client.

2. The client sends its authentication information to the WAP, which forwards the login request to the RADIUS server (in this case, IAS).

3. If the login information is valid, IAS will transmit an encrypted authentication key to the WAP.

4. The WAP will use this encrypted key to establish an authenticated session with the wireless client.

To allow wireless clients to access your network, you ll need to perform two steps: create a remote access policy that allows wireless connectivity, and add your WAPs as RADIUS clients on the IAS server so that they can forward login information to IAS for processing. (You ll configure your WAP as a RADIUS client according to the instructions provided by the WAP manufacturer.) A remote access policy for wireless users should contain the following information:

• Access method Wireless access

• User or Group Group, specifying the WirelessUsers group, for example

• Authentication methods Smart card or other certificate

• Policy encryption level Strongest Encryption, disable all other possible encryption levels

• Permission Grant remote access permission

Using Network Access Quarantine Control

One of the most exciting new features in Windows Server 2003 is Network Access Quarantine Control, which allows you to delay remote access clients from accessing your network resources until you ve examined and validated their computer configuration, including making sure that they are running anti-virus software and are not vulnerable to any known security vulnerabilities. This prevents situations that were quite common in the past where a legitimate user s remote workstation was virus-infected; when the user was permitted access to the remote access server, the virus infection spread to machines on the internal network via the remote user s connection. Network Access Quarantine Control helps to eliminate this risk to your corporate network.

When a remote computer attempts to make a connection with a RAS server, the user is authenticated and the remote access computer is assigned an IP address. However, the connection is initially placed into quarantine mode , where network access is severely curtailed. While the machine is in this quarantined state, a script created by the network administrator is launched on the remote computer. This script is the component that checks for specific configuration details like anti-virus definitions, service pack level, and so forth. If the script completes successfully, it notifies the RAS server that the quarantined computer complies with network security standards. Only at this point is the remote user is granted normal access to the corporate network.

Remote Access Account Lockout

Another new feature in Windows Server 2003 is the ability to specify how many times a remote access connection can provide an incorrect password or other logon credential before the connection attempt is denied remote access. This is especially critical for VPN connections, since malicious users on the Internet can try to access your network s resources by perpetrating a password attack against a remote user account. With remote access account lockout enabled, such an attack would be stopped after a certain number of failed logon attempts.

Exam Warning  

Be sure not to confuse this feature with the Account lockout settings in the Default Domain Group Policy Object. This setting applies only to remote access connection attempts.