| The first step in understanding how to set up a Windows Server 2003-based remote access server is to understand how Windows Server 2003 RRAS user authentication works, beginning with the remote access authentication protocols. Configuring Remote Access Authentication Protocols Objective: Configure Routing and Remote Access user authentication. Before we discuss the remote access authentication methods available within Windows Server 2003 RRAS, we should briefly discuss the underlying access protocols: Serial Line Interface Protocol (SLIP) The granddaddy of serial line protocols, SLIP is supported for legacy applications and is almost never used. Windows Server 2003 supports SLIP as a client-only protocol; it does not support it as a server protocol. A Windows Server 2003 server can dial into another server by using SLIP, but it cannot receive SLIP-based connections. Point-to-Point Protocol (PPP) PPP provides a standard transport method for point-to-point links, commonly called dial-up connections. Dial-up connections usually refer to either asynchronous modem connections or Integrated Services Digital Network (ISDN) connections. In addition to a transport method, PPP also defines the authentication protocols that can be used to negotiate a connection before allowing network-layer protocols such as TCP/IP or IPX to be transmitted over the connection.
The authentication protocols used in conjunction with Windows Server 2003 RRAS include the following: Password Authentication Protocol (PAP) PAP uses unencrypted (plain text) passwords for authenticating users on a PPP link. PAP is generally considered to be an obsolete protocol due to the password encryption issues, rendering it the least secure PPP authentication protocol available. Although PAP does provide a simple method for establishing a PPP connection, the only time you might encounter it would be if you needed to connect a legacy, non-Windows host to your RRAS server. Challenge Handshake Authentication Protocol (CHAP) CHAP provides a more secure PPP authentication mechanism than PAP by negotiating encrypted authentication with Message Digest 5 (MD5). MD5 is an industry-standard hashing scheme that allows connection authentication without actually transmitting the password over the network. You generally see CHAP used to allow Windows Server 2003 to securely connect to third-party PPP servers, leveraging the fact that CHAP is an industry-standard protocol. Note: Introduction to Hashes Hashes, when discussed in the context of authentication and encryption, are, in their simplest form, numbers generated from a string of text. In the context of authentication, a user's password is stored on the system as a hash value, created by applying a specific hashing algorithm to derive the value. When the user attempts to authenticate to the system, he or she enters his or her password, and the system applies the same specific hashing algorithm to the password. That value is then passed across the connection, and it is compared to the stored hash on the host system. If the hashes agree, the password is valid, and the connection is established. For example, let's say Alice has a password of Dogface. The hashing algorithm states that each letter of the password is supposed to be converted to a number by doubling the numeric value of each letter in the alphabet. After the number is converted, all 0s are removed, and the result is the hash. In our example, the initial conversion for Dogface would be 830142610. Remove the 0s, and the hash becomes 8314261. There is no easy way to retrieve the password from that hash, and by comparing that number to the stored value, you can verify the user's password without ever transmitting it across the network.
Shiva PAP (SPAP) SPAP is used specifically to allow Shiva client computers to connect to a Windows Server 2003 server and to allow Windows 2000 client computers to connect to Shiva servers. Microsoft CHAP (MS-CHAP) MS-CHAP is an extension of CHAP that increases CHAP's capabilities by integrating the encryption and hashing algorithms used on Windows networks. MS-CHAP supports LAN Manager authentication, as well as the ability to change passwords as part of the authentication process. Like CHAP, MS-CHAP uses a challenge-response mechanism. In this case, the mechanism is called password hashing, and it keeps the password from being sent across the connection. Although Microsoft has kept MS-CHAP as consistent with standard CHAP as possible, the MS-CHAP protocol is designed specifically for use by Windows computers. MS-CHAP version 2 (MS-CHAPv2) MS-CHAPv2 corrects several problems with the original version of MS-CHAP, including removing the support for the notoriously weak LAN Manager authentication, adding the ability for two-way authentication (which allows the client to authenticate the PPP host to which it is connecting), and adding support for much stronger cryptographic keys for the authentication process. MS-CHAP uses the Message Digest 4 (MD4) hashing algorithm and the Data Encryption Standard (DES) encryption algorithm to generate the challenge and the response. It also allows for mutual authentication, the generation of stronger initial data encryption keys for Microsoft Point-to-Point Encryption (MPPE), and different encryption keys for sent and received data. Note: Which Protocol Should You Use? In a purely Microsoft environment, MS-CHAPv2 is the most secure PPP authentication protocol that uses a user ID and password to authenticate a user.
Extensible Authentication Protocol (EAP) EAP was developed in response to an increasing need for stronger authentication mechanisms for remote user access services such as remote access servers and VPNs. The number of mobile users has increased and the technical sophistication of attackers has also increased, and today user ID/ password authentication is not secure enough for many organizations. EAP provides a standard mechanism for support of additional authentication methods within PPP, such as token cards, one-time passwords, and public key authentication using smart cards or certificates. Unlike the user ID/password capabilities of the other PPP authentication protocols, EAP, in conjunction with external authenticators such as a smart card or token card, is not vulnerable to brute-force or dictionary password attacks. Windows Server 2003 leverages the EAP-MD5 CHAP and EAP-Transport-Level Security (EAP-TLS) authentication methods as part of its remote access and VPN services, as follows: EAP-MD5 CHAP EAP-MD5 CHAP is an EAP type that uses the same challenge handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. In other words, EAP-MD5 allows for the use of external authentication that utilizes external hosts while still allowing the use of a user ID and password. An example of this is using EAP in conjunction with an external Remote Authentication Dial-in User Service (RADIUS) server for storing the database of user accounts and passwords that could authenticate to a RAS server. Windows Server 2003 includes RADIUS authentication capabilities as part of IAS. It is important to note that although this form of EAP does add additional capabilities for PPP authentication, because the underlying authentication is still based on a user ID/password combination, this type of EAP is still vulnerable to brute-force and dictionary password attacks. EAP-TLS EAP-TLS is a mutual authentication method that is similar to MSCHAPv2. With EAP-TLS, not only can the server authenticate the client as part of the authentication process, but also the client can verify the identity of the server. EAP-TLS is also the EAP type that is used in certificate-based or token-based security environments. As a result, EAP-TLS provides the most secure authentication method.
RADIUS RADIUS is an authentication and accounting system that is used by many Internet service providers and is available in Windows Server 2003. When you connect to a Windows Server 2003 remote access server, you need to enter your username and password. This information is passed to a RADIUS server, which checks that the information is correct and then authorizes access. When used in conjunction with Windows Server 2003 RRAS, RADIUS allows centralized storage of remote access authentication, allowing multiple Windows Server 2003 remote access servers to authenticate to the same credentials.
Table 6.1 lists the RFCs related to the Windows Server 2003 authentication protocols. Table 6.1. RFCs Related to Windows Communication and Authentication ProtocolsProtocol | RFC Number | Title and Date |
|---|
PPP | 2484 | "PPP LCP Internationalization Configuration Option," January 1999 | PAP | 1334 | "PPP Authentication Protocols," August 1996 | CHAP | 1994 | "PPP Challenge Handshake Authentication Protocol (CHAP)," August 1996 | MS-CHAP | 2433 | "Microsoft PPP CHAP Extensions," October 1998 | MS-CHAPv2 | 2759 | "Microsoft PPP CHAP Extensions, Version 2," January 2000 | EAP | 2284 | "PPP Extensible Authentication Protocol (EAP)," March 1998 | RADIUS support for EAP | 2869 | "RADIUS Extensions," June 2000 | EAP-TLS | 2716 | "PPP EAP TLS Authentication Protocol," October 1999 | RADIUS | 2865 | "Remote Authentication Dial In User Service (RADIUS)," June 2000 |
Before you can configure authentication with Windows Server 2003, you need to enable Windows Server 2003 to accept connections. Step by Step 6.1 demonstrates how to configure Windows Server 2003 RRAS to accept dial-in and VPN connections. You need two network interface cards (NICs) installed in your server to support VPN remote access connections properly. Step By Step 6.1. Setting Up Windows Server 2003 RRAS for Dial-in and VPN Access 1. | Log on to Windows Server 2003 by using the Administrator account or another account that has administrator privileges.
| | | 2. | Open the Routing and Remote Access console by selecting Start, Control Panel, Administrative Tools, Routing and Remote Access. By default, the local computer is listed as a server as seen in Figure 6.1. Notice the red arrow. It indicates that RRAS is not presently enabled.
Figure 6.1. The Routing and Remote Access console is used to configure RRAS for a variety of functions, including enabling dial-in and VPN access. 
| 3. | Right-click the server you want to configure and select Configure and Enable Routing and Remote Access. The Routing and Remote Access Server Setup Wizard starts.
| | | 4. | Click Next to start configuring RRAS. The Configuration dialog box of the wizard appears, as seen in Figure 6.2.
Figure 6.2. The Routing and Remote Access Server Setup Wizard includes the most common configuration options to make the configuration process as easy as possible. 
| | | 5. | Select the Remote access (dial-up or VPN) option and click Next to continue. The Remote Access dialog box of the wizard appears, as seen in Figure 6.3.
Figure 6.3. The Remote Access dialog box allows you to set up dial-in connections, VPN connections, or both types of connections. 
| | | 6. | In the Remote Access dialog box, select VPN and Dial-up and click Next to continue. The VPN Connection dialog box of the wizard appears, as seen in Figure 6.4.
Figure 6.4. The VPN Connection dialog box allows you to select the external network interface to be used for VPN connections. 
| | | 7. | Select the network connection you plan on using as the external server NIC for the VPN. This is the connection that is used by remote access VPN clients to connect to the server. Leave the Enable Security on the Selected Network Interface by Setting Up Static Packet Filters check box checked. This provides additional security on that network adapter. Click Next to continue. The IP Address Assignment dialog box of the wizard appears, as seen in Figure 6.5.
Figure 6.5. The IP Address Assignment dialog box allows you to select how IP addresses will be assigned to remote access clients. 
| 8. | Select Automatically to allow the server to use a network DHCP server for issuing addresses or to automatically assign addresses by using the server default addresses. Click Next to continue. The Managing Multiple Remote Access Servers dialog box of the wizard appears, as seen in Figure 6.6.
Figure 6.6. The Managing Multiple Remote Access Servers dialog box is used to determine whether the server will authenticate users locally or use a central RADIUS server for authentication. 
| | | 9. | Select No, Use Routing and Remote Access to Authenticate Connection Requests and click Next. The Completing the Routing and Remote Access Server Setup Wizard dialog box appears, as seen in Figure 6.7. Click Next to complete the installation.
Figure 6.7. The Completing the Routing and Remote Access Server Setup Wizard allows you to double check your settings before you commit the changes permanently. 
|
Configuring IAS to Provide Authentication for RRAS Clients Objective: Configure Routing and Remote Access user authentication. IAS is included as part of the Microsoft Windows Server 2003, Standard Edition, Enterprise Edition, and Datacenter Edition. IAS is not included with the Web Edition of Windows Server 2003. IAS is the Microsoft implementation of the RADIUS server and proxy. Acting as a RADIUS server, IAS is commonly used to provide centralized authentication, authorization, and accounting for remote access and VPN connections. IAS can also provide authentication and accounting for additional network services, including authenticated DHCP (in which case a user cannot get an IP address without authenticating successfully), network and wireless connectivity, and switch, router, and firewall management authentication, to name a few. When acting as a RADIUS proxy, IAS can be used to forward authentication and accounting messages to other RADIUS servers, such as a central RADIUS server. Step by Step 6.2 guides you through the process of installing IAS on a Windows Server 2003 server. Step By Step 6.2. Installing Windows Server 2003 IAS 1. | Log on to Windows Server 2003 by using the Administrator account or another account that has administrator privileges.
| 2. | Open the Add or Remove Programs applet by selecting Start, Control Panel, Add or Remove Programs.
| 3. | Click the Add/Remove Windows Components icon on the left side of the applet, and when the Windows Components dialog box seen in Figure 6.8 appears, select Networking Services.
Figure 6.8. The Add or Remove Programs applet can be used to add or remove system components such as IAS. 
| 4. | Click Details to open the Networking Services dialog box, as seen in Figure 6.9, and select Internet Authentication Service. Click OK to return to the Windows Components dialog box.
Figure 6.9. The Networking Services dialog box allows you to add or remove any of the available Windows Server 2003 networking services. 
| | | 5. | Click Next to continue the installation. When the installation progress is complete, the Completing the Windows Components Wizard dialog box appears. Click Finish to complete the installation.
|
Now that IAS is installed, you need to look at how to enable RRAS so that you can use the service for authentication and accounting. Step by Step 6.3 details this process. Step By Step 6.3. Configuring RRAS to Use RADIUS Authentication and Accounting 1. | Log on to Windows Server 2003 by using the Administrator account or another account that has administrator privileges.
| 2. | Open the Routing and Remote Access console by selecting Start, Administrative Tools, Routing and Remote Access.
| 3. | Right-click the server located in the left pane of the Routing and Remote Access console and select Properties. The server Properties dialog box appears. Select the Security tab, as seen in Figure 6.10.
Figure 6.10. The Security tab is used to configure the authentication and accounting providers and the authentication method used to authenticate client systems. 
| | | 4. | On the Security tab, under the Authentication provider drop-down menu, select RADIUS Authentication (the default is Windows Authentication). Then click Configure to the right of this drop-down menu to configure the authentication provider. The RADIUS Authentication dialog box, as seen in Figure 6.11, appears.
Figure 6.11. If there are RADIUS servers available on your network for authentication, they appear in the RADIUS Authentication dialog box. 
| 5. | Click Add to add a RADIUS server for authentication. The Add RADIUS Server dialog box, as seen in Figure 6.12, appears. You need to enter the name or IP address of the server and a secret to authenticate the server (optional but recommended). Then, if needed, you can also set a timeout value (the length of time to wait for a response from the RADIUS server) and an initial score. (The initial score determines the initial responsiveness score of the RADIUS server. This score increases or decreases based on the ongoing responsiveness of the RADIUS server and can be used to rank RADIUS servers in a multiserver environment. The default is 30.) You also need to set the port, which is the TCP port used to communicate with the RADIUS server. (The default is 1812, which is the RFC port for RADIUS communications.) You can also require the use of the message authenticator, which uses a shared secret to provide an additional level of security through the use of digital signatures.
Figure 6.12. The Add RADIUS Server dialog box allows you to configure the RADIUS server(s) to be used for remote access authentication. 
| | | 6. | Click Change to set the shared secret for RADIUS authentication. The Change Secret dialog box, as seen in Figure 6.13, appears. Enter the same secret (the longer, the better) in both fields and click OK to save the secret.
Figure 6.13. The shared secret is used to authenticate the RADIUS client (the RRAS server) and the RADIUS server (the server running IAS). 
| 7. | Click OK to add the RADIUS server. Figure 6.14 shows the server successfully added. Click OK again to return to the Security tab.
Figure 6.14. A new RADIUS server entry shows up in the RADIUS Authentication dialog box. 
| | | 8. | On the Security tab, under the Accounting Provider drop-down menu, select RADIUS Accounting to allow accounting information to be stored on a central RADIUS server. (The default is Windows Accounting, which stores accounting information locally.) Then click Configure to the right of this drop-down menu to configure the authentication provider. The RADIUS Accounting dialog box, as seen in Figure 6.15, appears.
Figure 6.15. If there are RADIUS servers available on your network for accounting, they appear in the RADIUS Accounting dialog box. 
| | | 9. | Click Add to add a RADIUS server for accounting. The Add RADIUS Server dialog box, as seen in Figure 6.16, appears. You need to enter the name or IP address of the server and a secret to authenticate the server. Then, if needed, you can also set a timeout value and an initial score. You also need to set the port, which is the TCP port used to communicate with the RADIUS server. (The default is 1813, which is the RFC port for RADIUS accounting communications.)
Figure 6.16. The Add RADIUS Server dialog box allows you to configure the RADIUS server(s) to be used for remote access accounting. 
| 10. | Click Change to set the shared secret for RADIUS authentication. The Change Secret dialog box appears. Enter the same secret (the longer, the better) in both fields and click OK to save the secret. The secret you enter here needs to be the same secret used for RADIUS authentication.
| 11. | Click OK to add the RADIUS server. You should see the server successfully added to the RADIUS Accounting dialog box, similar to Figure 6.14. Click OK again to return to the Security tab, and click OK to close the server Properties dialog box.
|
Exam Alert: RADIUS Ports For the exam, you should remember the default RADIUS ports and their purpose. Port 1812 is used for authentication, and port 1813 is used for accounting.
Exam Alert: Shared Secret If you are going to use the same RADIUS server for authentication and for accounting, you need to be sure that you set the same shared secret for both options in the RRAS server Properties dialog box. There can be only one relationship between a RADIUS server and a RADIUS client, and it can have only one shared secret.
You have now installed IAS and configured Windows Server 2003 RRAS to use IAS for authentication and accounting. The final configuration for this architecture is to configure IAS to permit your Windows Server 2003 server to use IAS for authentication and accounting. Step by Step 6.4 details how to complete this process. Step By Step 6.4. Configuring IAS to support a RADIUS Authentication and Accounting Client 1. | Log on to Windows Server 2003 by using the Administrator account or another account that has administrator privileges.
| 2. | Open the Internet Authentication Service console by selecting Start, Administrative Tools, Internet Authentication Service, as seen in Figure 6.17.
Figure 6.17. The Internet Authentication Service console is used to configure RADIUS clients. 
| | | 3. | Right-click the RADIUS Clients folder in the left pane and select New RADIUS Client. The New RADIUS Client dialog box appears, as seen in Figure 6.18.
Figure 6.18. To start configuring a RADIUS client, you need a friendly name and the IP address of the client. 
| 4. | Enter a friendly name for the RADIUS client and an IP address or DNS name and click Next to continue. The Additional Information dialog box appears, as seen in Figure 6.19.
Figure 6.19. The Additional Information dialog box is used to collect the remaining information needed to complete the RADIUS client setup. 
| | | 5. | Select a type from the Client-Vendor pull-down menu (for this Step by Step, use the default, RADIUS Standard). If you don't know what the RADIUS client is, use RADIUS Standard, which will work in many cases. Next type the same shared secret used in the configuration of the RADIUS client setup in Step by Step 6.3. Do not select the Request Must Contain the Message Authenticator attribute check box. Click Next to continue. You are returned to the Internet Authentication Service console, and your new RADIUS client should appear under the RADIUS Clients folder, as seen in Figure 6.20.
Figure 6.20. When a RADIUS client has been added, it should appear in the RADIUS Clients folder. 
|
Configuring RRAS Policies to Permit or Deny Access Objective: Configure Routing and Remote Access user authentication. Remote access policies are a set of conditions and connection settings that give network administrators flexibility in authorizing connection attempts. They provide both granular and flexible configuration settings for both dial-in and VPN connections. This granularity and flexibility unfortunately comes at the expense of ease of use; remote access policies can be very complex, and you need an in-depth understanding of them to successfully provide secure remote access to users. With remote access policies, you can grant remote access by individual user account or through the configuration of specific remote access policies. Windows Server 2003 uses three types of remote access policies to control access: Group Access can be controlled by group policies created on each Windows Server 2003 RRAS server. This is the simplest method for authenticating users, as long as you use a single server for remote access. Local IAS These local policies are derived from RADIUS and can be used to define access permissions based on a number of client attributes. This mechanism requires that IAS be installed on the Windows Server 2003 remote access server. This is typically the best solution if you are planning on adding additional Windows Server 2003 remote access servers and don't want to have to replicate the policies to each new server.
Issues to Consider in Configuring Systems for Mobile Users If you deploy Windows Server 2003 as your dial-in remote access solution for mobile users, you need to keep a couple things in mind. First, because any server has only a limited number of communication ports, you will probably need a multiport modem card. Various manufacturers offer these types of products, but you should be sure to check the Microsoft Hardware Compatibility List before you make any purchases. You should also avoid installing this capability on any Domain Controllers or application servers. Although the overhead associated with supporting dial-in users is fairly low, the security ramifications of connecting a modem or modems to a production application server, or even worse, to a DC, are significant. You should try to avoid that architecture if at all possible. Windows Server 2003 supports two methods for creating a remote access policy: utilizing a wizard to create commonly used remote access policies and using a custom method that allows you to create less common remote access policies. However, before we look at creating a policy, we need to discuss how Windows Server 2003 determines whether to accept a remote access connection. The first step in establishing a remote access connection is for the client to successfully authenticate to the server. Authentication is the verification of user credentials used in the connection attempt. This is typically a user ID and password (unless EAP is used in conjunction with a token or smart card). The client sends its credentials to the server, where they are validated. After the client has been successfully authenticated, it needs to be authorized to connect. A client that can authenticate, but that is not authorized, will have its connection attempt denied. Three mechanisms are used by the Windows Server 2003 RRAS to authorize a connection, depending on the server's authentication configuration: Windows authentication If the server uses Windows authentication, the connection is authenticated using the local server's security configuration, and then the dial-in properties of the user account and locally stored remote access policies are used to authorize the connection. Non-IAS RADIUS authentication If the server uses non-IAS RADIUS authentication, the credentials of the connection attempt are passed to the RADIUS server for both authentication and authorization. If the connection attempt is both authenticated and authorized, the RADIUS server sends an accept message to the server, and the connection attempt is accepted. If the connection attempt fails to be authenticated or authorized, the RADIUS server sends a reject message to the server, and the connection attempt is rejected. IAS authentication If the server is configured to use an IAS server, the IAS server performs authentication through the selected Windows authentication mechanisms and then performs the authorization through the dial-in properties of the user account and remote access policies stored on the IAS server.
In versions of Windows before Windows 2000 Server, remote access authorization was based on individual configurations made in the User Manager or the Remote Access utility. In Windows Server 2003 (and Windows 2000 Server), remote access policies can also be used in addition to the per-user configuration of grant or deny access to grant or deny access to the network. A remote access policy is a collection of one or more ordered rule sets (conditions) that define whether or not a connection can be authorized or rejected. Each rule set contains one or more conditions that a remote access connection is evaluated against, a group of profile settings, and also a remote access permission (grant or deny access) setting. When a remote access connection is authorized, the remote access policy profile then specifies a set of conditions on the connection. Dial-in properties, if any, that have been configured on the user's account also provide a set of restrictions. The net result is that any properties configured on a user's account directly override those configured in the remote access policythus the sum is the total of the most restrictive conditions with NTFS file and folder permissions. By default, a new implemention of RRAS on a Windows Server 2003 computer contains two remote access policies: Connections to Microsoft Routing and Remote Access Server and Connections to Other Access Servers. The first policy has a single condition specified, MSRAD-Vendor Matches "^311$", which signifies Microsoft RRAS implementations. This policy is set to deny access if this condition is met, which only Microsoft RRAS server would meetall other devices accessing the RRAS server would fail to meet this condition and thus would move onto the second policy for evaluation. The second policy also has only one condition, a date and time window that covers all 24-hour periods in all seven days of the weekthus any remote access connection that is evaluated against this remote access policy will meet the condition and the connection will be denied since this policy also denies all connections that meet its policy condition. The net result of these default remote access policies is that no clients will be able to connect to your remote access server by default. You, can, however delete or modify either or both of these remote access policies to allow the RRAS server to grant access to users who meet the policy conditions that you specify. It's also worth noting that you do not have to have any remote access policies in place. In that case, you'll have to control remote access via the configuration on the Dial-in tab of the user's account Properties dialog box, as seen in Figure 6.21. In a Windows 2000 mixed or Windows Server 2003 interim domain functional level domain, you will only have the option to Allow Access or Deny Access, with the default selection being Allow Access. In a Windows 2000 native or Windows Server 2003 domain functional level, the Control Access Through Remote Access Policy option becomes available for selection and is the default option for newly created user objects. Figure 6.21. The Dial-in tab of the user account Properties dialog box. 
Exam Alert: The Default RRAS Remote Access Policies Be sure that you understand that the default remote access policies will deny all connection attempts made to a RRAS server, thus preventing the RRAS server from functioning in its intended role. You must modify or delete the first default remote access policy, "Connections to Microsoft Routing and Remote Access Server" to enable RRAS to allow remote access connections to be made.
Step by Step 6.5 walks you through the creation of a new remote access policy to allow VPN access to anyone in the Domain Users group by using the wizard. What about the user settings of Allow Access or Deny Access in the user properties? Do you need a policy? What if you don't have one? What are the three components that make up a policy? What are the default policies that already exist? Can I modify them? Can I delete them? And what happens?
Note: Using Local Authentication for the Rest of the Step by Steps To ensure the success of the following Step by Steps, make sure that the authentication method set on the server Properties dialog box Security tab is set to Windows Authentication. Setting up a remote access policy under IAS for centralized policy management works in exactly the same way as setting up the policy locally, but it complicates any testing you might want to do.
Step By Step 6.5. Using the New Remote Access Policy Wizard to Create a VPN Access Policy 1. | Log on to Windows Server 2003 by using the Administrator account or another account that has administrator privileges.
| 2. | Open the Routing and Remote Access console by selecting Start, Administrative Tools, Routing and Remote Access.
| 3. | Right-click the Remote Access Policies node in the left pane of the Routing and Remote Access console and select New Remote Access Policy from the menu. The New Remote Access Policy Wizard appears.
| 4. | Click Next to continue. The Policy Configuration Method dialog box of the wizard, as seen in Figure 6.22, appears. Select the Use the Wizard to Set Up a Typical Policy for a Common Scenario option. In the Policy name field, type Allow Remote Access to Remote Users. If you are in a complex environment where there are many remote access policies, you might even need a naming convention for these policies to keep them straight.
Figure 6.22. The Policy Configuration Method dialog box allows you to decide whether to use the wizard or manual configuration to create a remote access policy. 
| | | 5. | Click Next to continue. The Access Method dialog box of the wizard appears, as seen in Figure 6.23. In this case, select VPN. Be aware of the additional options for your informationit is good to know what can be done with this wizard.
Figure 6.23. The Access Method dialog box allows you to select how users will be connecting to the Windows Server 2003 remote access server. 
| 6. | Click Next to continue to the User or Group Access dialog box of the wizard. Select the Group option and Click Add to open the Select Groups dialog box, as seen in Figure 6.24. Type Domain Users in the Enter the Object Names to Select field. If you click Check Names, the console confirms that the object exists in Active Directory.
Figure 6.24. The Select Groups dialog box allows you to populate the list of groups that will be affected by this policy. 
| | | 7. | Click OK to return to the User or Group Access dialog box, as seen in Figure 6.25. Notice that the group you entered in Step 6 now appears in the list of groups.
Figure 6.25. Any groups added appear in the Group name field of the User or Group Access dialog box. 
| 8. | Click Next to continue. The Authentication Methods dialog box of the wizard appears, as seen in Figure 6.26. Notice that the only authentication types allowed are EAP, MS-CHAPv2, and MS-CHAP. To use other authentication types, you need to use a custom remote access policy. Make sure MS-CHAPv2 is selected.
Figure 6.26. The Authentication Methods dialog box is used to select which authentication methods will be permitted for accessing the Windows Server 2003 RRAS server by using this remote access policy. 
| | | 9. | Click OK to continue. The Policy Encryption Level dialog box of the wizard appears, as seen in Figure 6.27. Because you are dealing with a VPN connection, select Strongest Encryption. If this were a dial-up connection, you would have an additional optionno encryption.
Figure 6.27. Windows Server 2003 RRAS supports three different encryption strengths for VPN connections. 
| 10. | Click Next to continue. The Completing the New Remote Access Policy Wizard dialog box appears, as seen in Figure 6.28.
Figure 6.28. The Completing the New Remote Access Policy Wizard dialog box summarizes the configuration of the policy. 
| | | 11. | Click Finish to complete the policy creation. Figure 6.29 shows the newly created remote access policy.
Figure 6.29. The Remote Access Policies folder shows all the policies that are in effect on the local server. 
|
Step by Step 6.6 takes you through the process of creating a custom remote access policy that restricts access based on the day of the week and the time of day. Step By Step 6.6. Using the Routing and Remote Access Console to Create a Custom RRAS Policy to Restrict the Times When Users Are Able to Connect Remotely 1. | Log on to Windows Server 2003 by using the Administrator account or another account that has administrator privileges.
| 2. | Open the Routing and Remote Access console by selecting Start, Administrative Tools, Routing and Remote Access.
| 3. | Right-click Remote Access Policies in the left pane and select New Remote Access Policy from the menu. The New Remote Access Policy Wizard appears.
| | | 4. | Click Next to continue. The Policy Configuration Method dialog box appears. Select the Set Up a Custom Policy option, as seen in Figure 6.30. In the Policy name field, type Deny Access Based on Time of Day.
Figure 6.30. Selecting the Set Up a Custom Policy option in the Policy Configuration Method dialog box allows you to perform advanced policy creation. 
| | | 5. | Click Next to continue. The Policy Conditions dialog box of the wizard appears, as seen in Figure 6.31. You can use this dialog box to add the conditions that need to be matched for the policy to take effect. You have the option to configure multiple conditions, but in this case, select a single condition.
Figure 6.31. The Policy Conditions dialog box allows you to select conditions from an extensive list of options. 
| | | 6. | Click the Add button to open the Select Attribute dialog box, as seen in Figure 6.32.
Figure 6.32. Windows Server 2003 offers an extensive list of options for setting conditions on a remote access policy. 
| | | 7. | Because you are working on setting time restrictions for remote users, select Day-and-Time Restrictions from the list of conditions. (Later on, you should explore the rest of these conditions so that you are familiar with them.) Click the Add button to select this attribute. The Time of Day Constraints screen appears. It is initially blank because the default setting is Denied. Changing the setting to Permitted changes the screen to entirely blue, which indicates Permit Access. Select the times from 5:00 a.m. until 8:00 p.m. for all days of the week and click the Permit Access radio button. The selected region should turn blue to indicate that access is permitted during that time. The result should look like Figure 6.33.
Figure 6.33. The time-of-day constraints are some of the most common conditions to be set in a remote access policy. 
| | | 8. | Click OK to continue. The time-of-day restriction appears in the Policy conditions field of the Policy Conditions dialog box, as seen in Figure 6.34. Note that a connection attempt must meet all policy conditions in order for the policy to be enforced. That is to say that a connection attempt must meet all policy conditions in order for that policy to allow or deny the connection attempt depending on how the policy has been configured.
Figure 6.34. Any conditions that you set appear in the Policy Conditions field. 
| | | 9. | Click Next to continue. The Permissions dialog box of the wizard appears, as seen in Figure 6.35. Select Grant Remote Access Permission. This allows users to connect to the Windows Server 2003 RRAS server during the permitted times.
Figure 6.35. The Permissions dialog box allows you to configure a policy to accept connections that meet the conditions of the policy or deny them if needed. 
| | | 10. | Click Next to continue. The Profile dialog box of the wizard appears, as seen in Figure 6.36.
Figure 6.36. The Profile dialog box gives you access to the remote access profile, which allows you to further refine the configuration of the remote access policy. 
| | | 11. | Click Edit Profile. The Edit Dial-in Profile dialog box appears, as seen in Figure 6.37. Dial-in profiles are discussed in detail in the next section of this chapter. Note that profile settings are cumulative and all will be enforced on clients.
Figure 6.37. The Edit Dial-in Profile dialog box allows you to configure a number of parameters that are used to authenticate users. 
| 12. | Click OK to return to the Profile dialog box and click Next to continue. The Completing the New Remote Access Policy Wizard dialog box appears.
| 13. | Click Finish to complete the creation of the new remote access policy.
|
Exam Alert: Order Matters Remote access policies are applied in the order in which they appear in the remote access policy list. This can sometimes lead to conflicting policies or unintended results, so it is important to understand not only how remote access policies work, but also how the order in which they are applied can affect their results. Keep this in mind when dealing with remote access policies on your 70-291 exam.
Remote Access Profiles In conjunction with the remote access policy, there is also a component known as the remote access profile. This profile contains a number of variables that allow you to further refine the parameters of the remote access policy. You can modify a remote access profile during the creation of a remote access policy, as is done in Step by Step 6.6, or you can review or modify a profile for an existing remote access policy by right-clicking the policy in either the Routing and Remote Access console or the Internet Authentication Service console, selecting Properties, and then clicking the Edit Profile button. The Settings tab of the Properties dialog box appears, as seen in Figure 6.38, and you can use it to add additional conditions to the policy, edit the profile, or review or change the grant and deny access settings on the policy. There are six tabs available in the Edit Dial-in Profile dialog box; the following sections look at them one at a time. Figure 6.38. The Settings tab of the Properties dialog box allows you to refine the configuration of a remote access policy. 
The Dial-in Constraints Tab You'll configure the parameters on the Dial-in Constraints tab when you want to control idle and session timeout setting, certain day and time windows, a specific dial-in number, or port type. The parameters that can be configured on the Dial-in Constraints tab of the Edit Dial-in Profile dialog box, as seen in Figure 6.39, include the following: Figure 6.39. The Dial-in Constraints tab can be used to restrict how dial-in access can be used. 
Minutes server can remain idle before it is disconnected (Idle-Timeout) This setting allows you to set the number of minutes of inactivity a user has before the system disconnects the user. This setting can be used to limit toll charges being incurred by an idle system or to protect a network from the vulnerability a connected but idle system presents. This setting can also be used to maximize the availability of ports if the server has a limited number of ports. This prevents idle users from tying up ports that might be needed by other users. Minutes client can be connected (Session-Timeout) This setting allows you to set the total number of minutes a session can last. This can be used to limit toll charges for users who may leave themselves connected for extended periods of time. Allow access only on these days and at these times This setting allows you to place day and time limits on any remote access policy, without needing to make that a condition of the policy. Allow access only to this number (Called-Station-ID) This setting is typically used in conjunction with a branch office connection to ensure that the connection is originating from the appropriate number. This field can contain a phone number or an IP address, so it can be used in conjunction with a site-to-site VPN as well as a branch demand-dial connection. Allow access only through these media (NAS-Port-Type) This parameter allows you to control the types of network media that can be used to connect by using this profile. You might use this to ensure that a VPN connection can be established only by using LAN media and not dial-in lines.
Exam Alert: Changing Parameters: New Wording in Windows Server 2003 Don't get confused with Windows 2000 parametersthe parameters in the Edit Dial-in Profile dialog box have changed subtly in Windows Server 2003. Microsoft has changed the language from "Restrict to" to "Allow Only" terminology. For example, in Windows 2000, the parameter Restrict Dial-in to This Number Only is now Allow Access Only to This Number (Called-Station-ID) in Windows Server 2003. The Called-Station-ID field is the remote access policy condition used to set this parameter.
The IP Tab You'll configure the parameters on IP tab when you want to control how IP addresses are assigned or what types of IP filters should be used. The parameters that can be configured on the IP tab of the Edit Dial-in Profile dialog box, as seen in Figure 6.40, include the following: Figure 6.40. The IP tab can be used to configure the characteristics of IP for a remote access policy. 
IP address assignment (Framed-IP-Address) The options in this section define how users being authorized by this policy will get their IP addresses. This is typically left at the default setting, but you can change the setting to restrict how IP addresses are assigned. IP filters This section allows you to set IP packet filters on the connection. For example, if this connection were being used only for getting Web access to your intranet server, you might set an inbound filter for port 80 (HTTP) to access only the intranet server. IP packet filters are discussed in detail later in this chapter in the section "Managing Packet Filters."
The Multilink Tab You'll configure the parameters on the Multilink tab when you want to control how multilink connections are handled. A multilink connection is one that makes use of more than one port at a time, such as more than one modem or VPN port at a time. The parameters that can be configured on the Multilink tab of the Edit Dial-in Profile dialog box, as seen in Figure 6.41, include the following: Figure 6.41. The Multilink tab can be used to configure the Multilink capabilities (aggregation of multiple physical connections into a single logical connection) of Windows Server 2003 RRAS. 
Multilink settings The settings in this section control how the Multilink protocol can be used with the remote access policy: Server settings determine Multilink usage When this option is selected, the RRAS server settings are used to determine whether Multilink is permitted. Do not allow Multilink connections This setting disables the use of Multilink. Allow Multilink connections This setting allows a client computer to connect by using multiple ports and can also be used to set the maximum number of ports that can be used.
Although it can improve performance, Multilink can be a very resource-intensive solution. Not only does it tie up multiple ports per user at the server end of the connection, but it also requires multiple modems and phone lines on the user's end. This has largely been phased out as multiple modem lines are replaced by high-speed Internet connections such as cable modem lines and Digital Subscriber Line (DSL). Bandwidth Allocation Protocol (BAP) settings BAP monitors the utilization on a Multilink connection and dynamically reduces the number of connected lines if the user's utilization drops below a certain amount. You use this section to set the utilization percentage and time before dropping one line of the Multilink connection. You can (and should) require the use of BAP with any Multilink connection. BAP can also be configured to request additional bandwidth when utilization reaches a threshold.
The Authentication Tab The parameters that can be configured on the Authentication tab of the Edit Dial-in Profile dialog box allow you to configure what authentication methods will be used, as seen in Figure 6.42, and include the following: Figure 6.42. The Authentication tab allows you to configure the authentication protocols that can be used with this profile. 
Authentication methods You can select what protocols can be used to authenticate a user connecting via this remote access policy. Whenever possible, you should use MS-CHAPv2 or EAP, each of which provides the most secure authentication. Unauthenticated access You should never enable unauthenticated access. It essentially allows clients to connect without authenticating first and should never be used as a production option because it bypasses all authentication security. Allowing unauthenticated access can be very useful when you're troubleshooting problems because it allows the elimination of authentication as a source of the problems. You just need to be sure to reenable authentication when the problem is resolved.
The Encryption Tab The Encryption tab of the Edit Dial-in Profile dialog box, as seen in Figure 6.43, enables you to select how strong the encryption used by this connection must be. If you are running an entirely Windows 2000 or greater client population, you should permit only the strongest level of encryption. If you have older clients, you might need to permit less strong encryption levels. Figure 6.43. The Encryption tab is used to specify the permitted encryption strengths for a connection. 
The Advanced Tab The Advanced tab of the Edit Dial-in Profile dialog box, as seen in Figure 6.44, allows you to specify additional connection attributes, typically related to RADIUS requirements for a connection. This tab is generally used only for very complex implementations involving centralized RADIUS servers for remote access policy storage. Figure 6.44. The Advanced tab is used to specify additional connection attributes to be returned to the remote access server. 
|
