MCSE/MCSA Implementing and Administering Security in a Windows 2000 Network: Study Guide and DVD Training System (Exam 70-214)

We have covered the dial-up modem features of the Windows 2000 RRAS in some detail. Now we need to take a look at the other side of the coin: the VPN capabilities of the Windows 2000 RRAS server.

Let's begin this discussion with a brief introduction to VPNs. A VPN creates a logical private network across an existing public network infrastructure such as the Internet. This connection is called virtual because the logical connection is built independently of the underlying physical network. In other words, the VPN connection is not aware of the physical route the packets take across the network; it is only aware of the endpoints of the virtual connection.

The purpose of a VPN is to securely extend your private internal network to users and external networks. When a VPN is configured correctly, a user should be unable to differentiate a VPN connection from a LAN connection. More important, the user's applications cannot differentiate between the two types of connections, providing a seamless method for integrating remote users or locations into the private network.

You will encounter two common types of VPN:

• Remote access VPN  A remote access VPN is typically used to allow remote users to securely connect to a private corporate network. This was one of the major drivers of the VPN technology—it allowed users to connect to the corporate network without requiring the extensive modem cards and lines needed for large RAS implementations.

• Site-to-site VPN  Also known as a network-to-network VPN, a site-to-site VPN is typically used to replace expensive WAN links with lower-cost VPN connections, utilizing the Internet as the underlying public network. Widespread adoption of this type of connection has been delayed by factors such as Internet reliability, VPN reliability, and the dramatic reductions in WAN technologies such as Frame Relay or asynchronous transfer mode (ATM), but they are becoming more common now that the Internet's reliability is more accepted and the VPN technology has become more stable. One other driver for site-to-site VPNs is the growing requirement for companies to interconnect with business partners, vendors, and customers. Not only do VPNs provide a secure mechanism for these interconnections—they can be created much more quickly than installing a WAN connection, which typically takes from 45 to 60 days.

One other type of VPN connection that is less common but growing in popularity is the VPN connection across the private network. This type of connection is typically used in environments in which different sections of the internal network require different levels of security. A VPN might be required to access the research and development network within a company, to ensure secure connections between corporate offices that exchange sensitive data, or within the government to secure top-secret data files traversing the internal network. All three of these VPN types are easily supported with Windows 2000 RRAS servers.

Now that we have seen what a VPN is, let's take a look at how you configure your Windows 2000 server to function as a VPN server.

Installing and Configuring the VPN Server

In Exercise 9.03 we install our VPN server to allow remote users to access the local network via a VPN connection. Not only is this the most common configuration you will encounter, it is also the easiest to perform in a lab environment.

Exercise 9.03: Configuring the Routing and Remote Access Service for Remote User VPN Access

1. Click Start | Programs | Administrative Tools | Routing and Remote Access to open the Routing and Remote Access console. To reset the Routing and Remote Access configuration. select Disable Routing and Remote Access from the Action menu (see Figure 9.22). This action resets the Routing and Remote Access to its initial condition and allows us to set up the VPN server as a clean installation. In Figure 9.23 you can see the warning message you receive when you reset the configuration. Resetting should only be done in a test or lab environment; resetting configured servers is discouraged.

   Figure 9.22: Resetting the Configuration

   Figure 9.23: The Reset Warning Message

2. To begin the VPN server setup process, select Configure and Enable Routing and Remote Access from the Action menu to start the Routing and Remote Access Server Setup wizard. Select Next to open the Common Configurations screen.

3. From the Common Configurations menu (see Figure 9.24), select Virtual private network (VPN) server and select Next to continue.

   Figure 9.24: Selecting VPN Server from the Common Configurations Menu

4. The Remote Client Protocols screen opens. Ensure that TCP/IP is one of the listed protocols (it is included by default), and select Next to continue. (We saw this screen and the next in Exercise 9.01; they do not change for the VPN setup.)

5. If the AppleTalk protocol is installed on your server, the Macintosh Guest Authentication screen opens. As in the dial-in RAS exercise, leave the Allow unauthenticated access for all remote clients unchecked and select Next to continue.

6. The Internet Connection screen opens (see Figure 9.25). In this screen you need to identify the Internet connection for your VPN server. Doing so allows the wizard to configure the public and private interfaces of the server correctly. Click Next to continue.

   Figure 9.25: Selecting the Server's Internet Connection

7. The IP Address Assignment screen (see Figure 9.26) is used to determine how IP addresses will be assigned to remote users. For this exercise, select Automatically, and then select Next to continue.

   Figure 9.26: Selecting the Server's Internet Connection

8. The Managing Multiple Remote Access Servers screen opens. Select No, I don't want to set up this server to use RADIUS now and select Next to continue.

9. You are now at the last screen (see Figure 9.27) for configuring your VPN server. To complete the process, select Finish. Note that the message in this screen states, "You have successfully configured a VPN server."

   Figure 9.27: Completing the Installation

10. Before we end this exercise, we need to check some of the changes this installation has made to the server. From the main Routing and Remote Access Console screen (see Figure 9.28), expand the IP Routing section, and select General. In the right pane you will see the various network interfaces.

    Figure 9.28: Checking the Changes Made to the Interfaces

11. Right-click the interface you selected as your Internet interface and select Properties (see Figure 9.29). This action opens the Local Area Connection Properties screen (see Figure 9.30).

    Figure 9.29: Selecting the Interface Properties

    Figure 9.30: The General Tab of the Local Area Connection Properties Screen

12. From the General tab of the Local Area Network Properties screen, select Input Filters (see Figure 9.31). These filters are applied by default during the VPN configuration process, and they are there to protect your Internet interface from unwanted traffic. Repeat this process for your other LAN interface(s) and note the lack of any filters. They are not installed by default on any interface that the wizard considers an internal (private) network interface.

    Figure 9.31: Input Filters

13. Click OK to return to the General tab and select Output Filters (see Figure 9.32). These filters are also applied by default during the VPN configuration process. Repeat this process for your other LAN interface(s) and note the lack of any filters. As with the input filters, the output filters are not installed by default on any interface that the wizard considers an internal (private) network interface.

    Figure 9.32: Output Filters

14. The final portion of this exercise involves looking at configuring the server properties. Click OK to return to the General tab, and click OK again to return to the Routing and Remote Access console. Select your server (in this exercise, the server name in the figures is Abyssia) and select Properties. The <server name> (local) Properties screen opens (see Figure 9.33).

    Figure 9.33: The Server Properties General Tab

15. On the General tab of the Server Properties screen, you can enable your server to act as a router and/or as a remote access server. For this exercise, make sure the Remote access server is enabled.

16. On the Security tab of the Server Properties screen (see Figure 9.34), you can select the authentication provider (Windows authentication or RADIUS server) as well as the accounting provider (Windows accounting or RADIUS accounting.). Select the Authentication Methods… button to open the Authentication Methods screen (see Figure 9.35).

    Figure 9.34: The Server Properties Security Tab

    Figure 9.35: The Authentication Methods Screen

17. From the Authentication Methods screen shown in Figure 9.35, deselect any authentication methods except Microsoft encrypted authentication version 2 (MS-CHAP v2). As we discussed earlier in the chapter, this is the most secure of the user ID/password authentication protocols. If you are running older Windows clients (pre-Windows 2000), you might need to leave the MS-CHAP protocol enabled until you have time to update your clients.

18. Select the EAP Methods… button to open the EAP Methods screen (see Figure 9.36). You can see that by default you have the MD5-Challenge and Smart Card or other Certificate options. Select OK, then select OK again to return to the Server Properties screen.

    Figure 9.36: The Extensible Authentication Protocol Methods Dialog Box

19. On the IP tab of the Server Properties screen (see Figure 9.37), make sure that the Enable IP routing and Allow IP-based remote access and demand-dial connections boxes are selected. From this tab you can also set the IP address distribution method (DHCP or Static Pool) and set which interface should be getting DHCP, DNS, and WINS addresses for remote clients. This will almost always be the port on the internal network, since the remote users will be trying to access systems and services on that network.

    Figure 9.37: The Server Properties IP Tab

20. The AppleTalk tab allows you to enable or disable AppleTalk. Ensure that AppleTalk is enabled.

21. The PPP tab (see Figure 9.38) allows you to configure specific PPP settings, which we discuss later in the chapter.

    Figure 9.38: The Server Properties PPP Tab

22. The Event Logging tab (see Figure 9.39) allows you to set the level of Event Logging your server maintains. For this exercise, leave Log errors and warnings selected. You will generally only use the Log the maximum amount of information setting if you are troubleshooting an issue or if you work in a very high-security environment. Generally the amount of data logged under that setting provides too much data; you never have time to review it, and you could lose important information related to events due to the amount of information you have to work through.

    Figure 9.39: The Server Properties Event Logging Tab

23. Click OK to return to the General tab, and click OK again to return to the Routing and Remote Access console. Close the console to complete this exercise.

Working with VPN Ports

We have discussed in some detail what a VPN is, and how to set one up. Now we need to look into the underlying architecture that Windows 2000 uses to support these VPN connections. As we saw in Exercise 9.03, configuring the Windows 2000 RRAS service installs two types of ports, L2TP and PPTP. PPTP and L2TP are two of the protocols that the Windows 2000 supports for creating VPN connections.

Point-to-Point Tunneling Protocol

Point-to-Point Tunneling Protocol (PPTP) is a proprietary VPN protocol originally developed by the PPTP Forum, a group of vendors that included Ascend Communications, Microsoft Corporation, 3Com, ECI Telematics, and U.S. Robotics. PPTP was designed as an extension of PPP to allow PPP to be tunneled through an IP network. One of the main differentiators between PPTP and IPSec is that PPTP supports the encapsulation of not only IP but IPX or NetBEUI as well. This feature is particularly useful in Windows or Novell environments that have not migrated to TCP/IP.

PPTP used Microsoft Point-to-Point Encryption (MPPE) to encrypt the link between the VPN client and the server and uses the Generic Routing Encapsulation (GRE) protocol to encapsulate the encrypted PPTP data in the PPP frame. This can be an IP datagram, an IPX datagram, or a NetBEUI frame.

One of the key benefits of PPTP is that because Microsoft helped develop it, it has been bundled with all current versions of Microsoft's operating systems. One of the issues with PPTP when it was introduced was whether the protocol was in fact secure enough for use as a VPN. Fortunately, the Windows 2000 implementation of PPTP includes the security updates needed to address issues related to earlier protocol versions. Another early issue with PPTP until it was more widely deployed was support for PPTP on Internet routers. To connect to your PPTP server, every router you traversed needed to be able to route PPTP. This is not an issue now, but in the late 1990s not all Internet service providers (ISPs) supported PPTP on their routers.

At one time PPTP was the most widely used VPN protocol, but the release of IPSec has had a significant impact on PPTP's use. Very popular with Microsoft shops and when Windows 2000 is being used as the VPN server, IPSec is enjoying increasing popularity.

For more details on PPTP, see RFC2637, Point-to-Point Tunneling Protocol, July 1999. It is important to note that this is an informational RFC and was never adopted as a standard. This is a key difference between PPTP and IPSec.

Layer 2 Tunneling Protocol

Layer 2 Tunneling Protocol (L2TP) is a combination of the best features of PPTP and the Layer 2 Forwarding (L2F) protocol, which was an early competing protocol for PPTP, developed by Cisco Systems. Like PPTP, L2TP was designed as an extension of PPP to allow PPP to be tunneled through an IP network. However, L2TP defines its own tunneling protocol, based on L2F. L2TP support was first included in a Microsoft server product with the release of Windows 2000 Server. Prior to Windows 2000, PPTP was the only supported protocol.

L2TP uses one of the IPSec protocols, Encapsulating Security Payload (ESP), for encryption. For this reason, L2TP under Windows 2000 is also known as L2TP/IPSec. The use of IPSec as the encryption mechanism allows L2TP/IPSec to utilize third-party encryption hardware to offload the encryption functions of the VPN connections from the VPN server. In addition, the standard implementation of L2TP/IPSec requires the use of machine PKI certificates. This ensures a more secure connection but at the cost of a more complex implementation; you must have access to a certificate authority (CA) in order to implement an L2TP/IPSec VPN connection.

Despite offering a more secure form of connection for remote access clients, L2TP carries the expense of additional overheads in terms of configuration, maintenance, and processing. In addition, it is not widely supported by all clients. For example, Windows 2000 is the first Windows remote access client that can natively support L2TP/IPSec, so you might have to offer PPTP ports as well on your VPN server to ensure connectivity. However, if you are sure that only L2TP/IPSec clients will be using your VPN server, configuring only L2TP ports for remote access is a good security measure.

Internet Protocol Security

Internet Protocol Security (IPSec) is actually a set of protocols developed by the Internet Engineering Task Force (IETPF) to allow for the secure exchange of data via the Internet Protocol (IP). This was seen as a critical success factor for the next version of IP, known as IPv6, but it is also usable with IPv4, the version of IP used on the Internet today. As a result, IPSec is used by many vendors to deliver VPN services. One of the major limitations of IPSec is that the IETF guidelines do not allow IPSec to support the traversal of networks using Network Address Translation (NAT). Although many VPN manufacturers have implemented proprietary solutions to work around this limitation in the protocol, Microsoft has not. The Windows 2000 implementation of L2TP/IPSec does not support NAT.

Two encryption modes are supported by standard IPSec: Transport and Tunnel. Transport mode IPSec only encrypts the data portion of a packet. The packet's header information is left intact. For a more secure connection, using Tunnel mode IPSec encrypts not only the data portion of a packet but also the header.

The protocols used by IPSec include:

• Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley)  This protocol is used to share a public key between sender and receiver of a secure connection. The ISAKMP/Oakley protocol allows the receiving system to retrieve a public key and then authenticate the sender using digital certificates.

• Internet Key Exchange (IKE)  This protocol is used to authenticate the endpoints of an IPSec connection, negotiate the exchange of IPSec keys, and negotiate IPSec Security Associations (SAs). An SA is used by the IPSec endpoints to define how data will be encrypted and decrypted. IKE also uses the Diffie-Hellman public-key cryptography protocol to exchange the session keys used to create the initial secure connection.

• Authentication Header (AH)  Authenticates the data packet and ensures the integrity of the data being sent. In order to ensure packet and data integrity, AH uses hashing algorithms to "sign" the packets. The algorithms AH uses include MD5 and Secure Hash Algorithm (SHA).

• Encapsulating Security Payload (ESP)  This protocol encrypts the data contents of the packet.

• IPSec  Can use a number of encryption algorithms, including Data Encryption Standard (DES), Triple DES (3DES), or 40-bit DES, a version that is almost never used due to the poor key strength.

There are a couple of important features of IPSec in the Windows 2000 operating system. First, a pure IPSec connection (in other words, not L2TP/IPSec) will not appear in the list of ports shown in the RRAS console. If you need to install and support a pure IPSec connection, you need to use the ipsecmon.exe tool.

Now that we have discussed the types of VPN connections your Windows 2000 VPN server setup uses, let's take a look at how we can configure the VPN ports in Exercise 9.04.

Exercise 9.04: Configuring the PPTP and L2TP Ports for Inbound Access Only

1. Click Start | Programs | Administrative Tools | Routing and Remote Access to open the Routing and Remote Access console.

2. In the left pane of the Routing and Remote Access console, right-click Ports and select Properties. The Ports Properties screen (see Figure 9.40) opens.

   Figure 9.40: Ports Properties: Configuring the WAN Miniport (PPTP) Ports

3. Select WAN Miniport (PPTP) and click the Configure button to open the Configure Device screen (see Figure 9.41).

   Figure 9.41: The Configure Device – WAN Miniport PPTP Dialog Box

4. From this screen, make sure that the only option selected is Remote access connections (inbound only). This will make your VPN server an inbound VPN server only and will prevent this server from making site-to-site VPN connections. On this screen, you can also modify the number of PPTP ports supported by this server. Click OK to close this screen and return to the Ports Properties screen.

5. Repeat the same steps for the WAN Miniport (L2TP) port. When you have completed the steps for the L2TP ports, click Apply to update the configuration, and click OK to close the Ports Properties screen.

Now that you know how to work with the configuration of your VPN ports, let's look at checking the status of one of those ports in Exercise 9.05.

Exercise 9.05: Checking the Status of a Connected VPN Port

1. From the Routing and Remote Access Console, select Ports in the left pane. The list of all configured ports appears.

2. Select a port to check, right-click it, and select Status from the menu. (Later in the chapter, you will learn how to check an active port. Once you've completed that exercise, you can review this exercise to see what an active port status looks like.)

3. Review the statistics. In the Figure 9.42, you can see that the user is logged on as Administrator and has been logged in for a little over 27 minutes. You can also review the packet statistics, errors, and network information. In this example, the only protocol in use is TCP/IP, so the only information available is the IP address. From this window you can also disconnect the user by selecting the Disconnect button.

   Figure 9.42: The Port Status – WAN Miniport PPTP VPN Port Dialog Box

Configuring L2TP Ports

L2TP ports are new in Windows 2000, and together with IPSec and computer certificates they offer a more secure form of VPN connection than the legacy PPTP protocol. Because it is used with IPSec, L2TP can also offer end-to-end security from remote access client to the internal network resource if that system is also using IPSec. In comparison, PPTP offers only client to RAS server secure communication. Once the traffic passes the RAS server with PPTP, it is passed as unencrypted data.

In most instances, this level of security is not a requirement, especially since the overhead of setting up and maintaining this sort of configuration can be substantial. In addition, you need to be very IPSec-savvy in order to successfully integrate the Windows 2000 L2TP/IPSec connection with an internal server. The one bright spot in using L2TP/IPSec is that there is no need to configure specific IPSec policies to support this connection, because a default policy is created for you automatically on both the Windows 2000 server and the Windows 2000 remote access client. The real challenge in the configuration, as we have discussed before, is that by default, the L2TP/IPSec policy uses certificates rather than a preshared key or Kerberos for authentication. Therefore, your VPN server and remote access client must have a computer certificate for authentication that is issued by the same CA. In addition, IPSec requires computer certificates, not user certificates, for authentication.

Configuring Remote Access Policies

Now that we have discussed in detail all the components needed to access your Windows 2000 RRAS server via dial-up and VPN connections, we need to discuss the concept of remote access policies.

In the pre-Windows 2000 RAS service, dial-in permissions were either Grant or Deny. This made it very easy to configure permissions, but it lacked any flexibility of configuration. To make matters worse, you also needed to do configuration on a per-user basis. With the release of Windows 2000, Microsoft has given administrators a great deal of flexibility when it comes to granting remote access permissions. Under Windows 2000, authorization is granted based on the dial-in properties of a user account and the server's remote access policies.

But what is a remote access policy? Remote access policies are sets of conditions and connection settings that determine connection permissions. With a remote access policy, you can configure Grant or Deny permissions based on the time of day or day of the week (as illustrated in the next exercise) by Windows 2000 group, by protocol or VPN protocol, by connection type, and a number of other factors. You can also use the remote access profile portion of the policy to set idle timeouts, maximum session times, authentication protocols, encryption strengths, and several other connection parameters, which we discuss in detail later in the chapter.

The best way to get an understanding of remote access policies is to set one up. Let's do this in Exercise 9.06.

Exercise 9.06: Creating a New Remote Access Policy to Restrict Remote User Access Times

1. Open the Routing and Remote Access Service console and select Remote Access Policies from the left pane.

2. Right-click Remote Access Policies and select New Remote Access Policy from the menu. The Add Remote Access Policy screen opens (see Figure 9.43).

   Figure 9.43: The Add Remote Access Policy Screen: Policy Name

3. Enter a descriptive name in the Policy friendly name box, and select Next to continue. If you are in a complex environment in which there are lots of remote access policies, you might even need a naming convention for these policies to keep them straight.

4. The Add Conditions screen opens (see Figure 9.44). From this screen you will add the conditions that need to be matched in order for this policy to take effect.

   Figure 9.44: Add Remote Access Policy Conditions

5. Click the Add… button to open the Select Attribute screen (see Figure 9.45). Since we are working on setting time restrictions for remote users, select Day-and-Time Restrictions from the list of conditions. On your own time, you should explore the rest of these conditions so you are familiar with them. Select the Add… button to add this attribute.

   Figure 9.45: Selecting the Attribute(s)

6. Because we are setting day and time restrictions, the Time of day constraints screen opens. It will initially be blank. Select the times from 6:00 a.m. until 8:00 p.m. for all days of the week. The result should look like Figure 9.46. Since this is one of the more common constraints you will implement, try setting other days and times to be sure you are comfortable with the results. Select OK to continue.

   Figure 9.46: Time of Day Constraints

7. In Figure 9.47, the condition you configured should show up in the Conditions window. At this point you can add more conditions, but for this exercise, simply select Next to continue.

   Figure 9.47: The New Access Policy Condition

8. On the Permissions screen (see Figure 9.48), you can select whether to grant or deny access based on the condition(s) you just set. As you might guess, creating a policy can be a very intricate process. Be sure you understand exactly the results you need before you create a new policy. In this case, select Grant remote access permission, and then click Next to continue.

   Figure 9.48: Add Access Policy Conditions

9. The User Profile screen (see Figure 9.49) is used to modify the profile associated with the policy. We discuss this topic later in the chapter. Pay attention to the Microsoft note on this screen; a profile can be used if the policy conditions are overridden at the user level. This feature adds additional complexity to troubleshooting in the event of remote access issues that are policy related. Select Finish to complete the creation of your new remote access policy.

   Figure 9.49: Add Access Policy Conditions

10. You should now see your new policy. (In Figure 9.50 it is called the IT Department Access Policy.) Note the Order column of this screen. Remote access policies are processed in the order in which they appear in this screen. If you want to make your new policy the first on the list, right-click it and select Move Up from the menu.

    Figure 9.50: The New Remote Access Policy Has Been Entered

You have successfully created a new remote access policy. These policies can be used to configure the permissions for remote access connections. Now let's look at what you can do with the remote access profile that we passed over in this exercise. It is the final component you need to complete the configuration of your remote access policy.

Configuring Remote Access Profiles

Let's take a look at the various portions of the remote access profile. You can modify a remote access profile during the creation of a remote access policy, as we did in the last exercise, or you can review or modify a profile for an existing remote access policy by right-clicking the policy, selecting Properties, and then clicking the Edit Profile button. Five tabs are available in the configuration screen. Let's look at them one at a time.

Dial-in Constraints

The parameters that can be configured on the Dial-in Constraints screen (see Figure 9.51) include:

Figure 9.51: Remote Access Profile Dial-in Constraints

• Disconnect if idle for  This setting allows you to set the number of minutes of inactivity a user has before the system disconnects the user. The more stringent your security requirements, the shorter this time should be, to prevent an attacker using an idle system to access your network.

• Restrict maximum session to  This setting allows you to set the total number of minutes a session can last. From a security perspective, setting this option as short as possible is a good idea because it limits the amount of time a successful attacker can stay connected to your system. This risk needs to be balanced against the usability requirements of your end users; they might get annoyed if they keep getting bumped offline after 15 minutes while trying to synchronize their mail.

• Restrict access to the following days and times  This setting allows you another place where you can limit the time during which the system will accept connections.

• Restrict Dial-in to this number only  This setting is useful only if all your users connect from the same number or if you only have one user connecting using this remote access policy for authorization to this server (an administrator, for example) and you want that user to only connect from his or her home number.

• Restrict Dial-in media  This is not a commonly used parameter, but you can use it to limit the media that can be used to connect to this system.

IP

The parameters that can be configured on the IP screen (Figure 9.52) include:

Figure 9.52: Remote Access Profile IP

• IP Address Assignment Policy  This setting defines how users being authorized by this policy will get their IP addresses. This is typically left at the default setting, but can be used to restrict how IP addresses are assigned.

• IP Packet Filters  This setting allows you to set IP packet filters on the connection. For example, if this 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.

Multilink

The parameters that can be configured on the Multilink screen (see Figure 9.53) include:

Figure 9.53: Remote Access Profile Multilink

• Multilink  This setting allows you to permit or restrict the number of ports via which a single client can connect. Windows 2000 and later support the use of multiple connections to a single server, which are aggregated to provide additional bandwidth. Although this greatly improves performance, it can be a very resource-intensive solution for larger environments. Not only does it require multiple ports per user at the server end, it requires multiple modems and phone lines on the user's end.

• Bandwidth Allocation Protocol (BAP)  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.

Authentication

The parameters that can be configured on the Authentication screen (see Figure 9.54) include:

Figure 9.54: Remote Access Profile Authentication

• Authentication methods  This section allows you to select the protocols that can be used to authenticate a user connecting via this remote access policy. Whenever possible, use MS-CHAPv2 or EAP; they provide the most secure authentication.

• Unauthenticated access  Never enable this setting. It essentially allows clients to connect without authenticating first, and so it should never be used, since it bypasses all authentication security.

Encryption

The entire purpose of the Encryption screen (see Figure 9.55) is to select how strong the encryption used by this connection must be. If you are running an entirely Windows 2000 or later client population, you should only permit the strongest level of encryption. If you have older clients, you might need to permit weaker encryption levels.

Figure 9.55: Remote Access Profile Encryption

Advanced

The purpose of the Advanced screen (see Figure 9.56) is to specify additional connection attributes, typically related to RADIUS requirements for a connection. This screen is generally only used for very complex implementations involving centralized RADIUS servers for remote access policy storage.

Figure 9.56: Remote Access Profile Advanced

Remote Access Policy Administrative Models

The final remote access policy topic we need to cover is how remote access permissions are administered. Under the new Windows 2000 model, you might encounter three remote access and connection settings administration models:

• Access by user  In this model, remote access permissions are determined by the remote access permission on the Dial-in tab of the user account, much as they were in the pre-Windows 2000 RAS environment. Remote access permissions are set on a per-user basis by setting the remote access permission to either Allow access or Deny access. The key to this model is the fact that the remote access permission setting on the remote access policy is effectively overridden by the user account permissions. The good news under this model is that you can still enforce the connection settings by modifying the remote access policy conditions and profile properties. The major drawback of this solution is that you are managing your remote access security on a user-by-user basis, which is not very efficient or effective. This model is typically used if you have Windows NT 4.0 RAS servers. It works on a standalone Windows 2000 RAS server, a Windows 2000 RAS server in either a native mode or mixed domain, or even a Windows 2000 RAS server that authenticates from a Windows NT 4.0 domain.

• Access by policy in a Windows 2000 native-mode domain  In this model, the remote access permission on every user account is set to Control access through Remote Access Policy. This means that the remote access permissions are determined by the remote access permission setting on the remote access policy, which we just looked at configuring. This would be the other end of the spectrum from the access-by-user model, which ignores most of the profile settings. This is the most efficient model for managing your remote access security, but it is also the most complex, due to the overhead associated with creating and maintaining the remote access policies and profiles. This model can also be used with a standalone Windows 2000 RAS server, but it is not supported by either a Windows 2000 RAS server in a mixed mode (one or more Windows NT 4 domain controllers in a Windows 2000 domain) or a Windows NT 4 domain. For more information on mixed-mode versus native-mode domains, see Knowledgebase Article 186153 at support.microsoft.com/default.aspx?scid=KB;en-us;186153&.

• Access by policy in a Windows 2000 mixed-mode domain  In this model, every user account's remote access permission is set to Allow access, the default remote access policy is deleted, and separate remote access policies are created for each type of connection that is allowed. As a result, you are still managing remote access through remote access policies, but it is not as efficient nor as simple as the previous two modes. In some ways, this model combines the worst of both models: there is the user dial-in access settings to contend with as well as the complexity of setting up your remote access policies and profiles. Furthermore, in this model you cannot combine policies, so you need a policy for each connection medium, further complicating things. One benefit to this model is that it supports both a Windows 2000 RAS server in a mixed-mode domain or an NT 4 domain.