Category: VPN

Windows 2000 implements a powerful centralized authentication, authorizations and accounting service (often referred to as AAA) in the form of IAS, its implementation of the Remote Access Dial-in Authentication Service (RADIUS). Used for both dial-in and VPN connections, IAS allows you to control in a more centralized manner the authentication of users, accounting of their connection start and stop times, as well as a way to centralize the application of remote access policies (authorization).

Not installed by default, IAS must be added via Add/Remove programs in Control Panel. Once installed, IAS is accessed using the associated Internet Authentication Services administrative tool.

Many people get confused about the purpose and configuration of IAS, so lets consider the basics. First of all, a big reason for using IAS is to centralize the authentication requests sent to remote access servers. For example, consider an environment that consists of a variety of remote access solutions (these are sometimes referred to as a NAS, or Network Access Server), such as Windows NT RAS, Windows 2000 RRAS, Cisco routers, various VPN and dial-in hardware solutions, and so forth. Maintaining accounts on those various platforms could be difficult, if not impossible. What RADIUS allows you to do is have all requests from the various remote access servers forwarded to the RADIUS server for authentication instead. As such, it is important to remember that a RADIUS client is actually a remote access server. The remote access server has client connections as well, but these are not RADIUS clients. I repeat, a RADIUS client is a remote access server. The remote access server does not authenticate client requests when RADIUS is used; instead it forwards them to the RADIUS server for processing.

This centralization provides a number of other benefits as well, including the ability to centralize the distribution of remote access policies. Remember that by default, remote access policies are local to the server on which they are created. In instances where you choose to set up a remote access server as a RADIUS client, all remote access policies on the server are ignored in favor of those configured on the RADIUS server. This presents a powerful way to control the application of remote access policy settings, especially in large distributed environments.

The actual configuration of IAS is quite simple, but there are a few things that you will need to be aware of. For starters, if you want a remote access server to act as a RADIUS client, it must be capable of authenticating to RADIUS. Most vendors add this functionality to their remote access servers, since RADIUS is an industry standard. Windows 2000 RRAS can act as a RADIUS client if correctly configured both in the RRAS settings and IAS setting. In RRAS, the setting are configured from the Security tab in the properties of the RRAS server.

By default, an RRAS-based server will authenticate to the Windows provide, either Active Directory or the local SAM database, depending on your setup. If RADIUS is chosen, further configuration is required, including the address of the server and a shared secret, which will be used between the RADIUS client and server for authentication purposes.

Simply configuring the RADIUS client is not enough. The settings for the RADIUS server must be configured via IAS.

Note the three sections that exist – Clients, Remote Access Logging, and Remote Access Policies. The Clients sections will allow you to add remote access server addresses and the corresponding shared secret that you originally set up. You will need to do this for each and every remote access server that you wish to act as a RADIUS client. The remote access logging pages allows you to configure what type information you wish log (and the associated format). Note that by default, nothing is logged, but recommendations are provided.

The last section allows you to configure the centralized remote access policies that I discussed earlier. These policies are configured and work in exactly the same manner as explained in the earlier remote access article.

You should understand that if you want IAS to be able to access a user’s dial-in properties in Active Directory, you must configure it to do so. This is accomplished choosing ‘Register Service in Active Directory’ from the Action menu of the snap-in (if the server is not a member of an AD domain, this option will be grayed out). Note that IAS will authenticate users against Active Directory or the local SAM database, as applicable. Note also that if you want redundant IAS servers, you should configure them similarly, being sure to copy the remote access policies to the second server, while configuring the RADIUS clients appropriately to account for the second server as well.

For the purpose of authentication protocols, IP address assignment, and so forth, the VPN ports use the exact same server properties as those used by dial-in clients, so I will not repeat them here. Because of this, I will only cover settings relating specifically to the configuration of VPN ports in this section.

You probably noticed that by default there were 10 VPN ports automatically configured when RRAS was started, providing 5 PPTP and 5 L2TP ports by default. Since a VPN connection will be coming in over a network card, in theory the number of possible incoming connections is only limited by the processing capabilities of the system, and not by physical ports. However, the maximum number of ports supported is 30,000 for a given type (such a PPTP WAN Miniports for example).

Note that you cannot change the number of ports to 0, even though the system suggests this is possible. At a minimum, you must have one of each port type available. The reason I mention this is because you will need to configure how many of each type of port you wish to have available for connections, as well as which protocol they will use. If you had chosen to use PPTP for VPN connections for example, it would make sense not to allow incoming connections via L2TP. This would be controlled not by setting the number of L2TP ports to 0, but instead by configuring the L2TP WAN Miniport properties to not allow incoming connection.

So why would you choose PPTP over L2TP or vice versa? The answer depends on the level of security you require, as well as the security mechanisms that your network supports. For example, PPTP supports only user-level authentication, meaning that any connection using PPTP that has the correct username/password combination will be allowed. In contrast, L2TP requires 2 levels of authentication – first the machine is authenticated (via a machine certificate that would need to be pre-installed either via group policy or using certificate services) and then the user is authenticated using PPP. This allows a higher degree of security, since both the user and machine must be validated. The downside is the extra effort involved with using L2TP, as well as the fact that only Windows 2000 has built-in L2TP and IPSec capabilities among Microsoft operating systems.

Remote access connections in Windows 2000 Professional are configured using the Make New Connection Wizard in the Network and Dial-Up Connections program window. The wizard provides 5 choices.

The first two choices involve creating dial-up connections. You should note that if you choose Dial-up to the Internet, the Internet Connection Wizard would start. The third option allows you to create a VPN connection over the Internet, by providing the fully qualified domain name or IP address of the server you wish to connect to. If your system is not directly connected to the Internet and uses a dial-up connection, you can specify the existing dial-up connection to be connected prior to establishing the VPN connection. This avoids having to initiate the two connections individually.

The fourth option in the wizard allows a Windows 2000 Professional machine to accept incoming dial-in, VPN, and direct cable connections. The last option creates a connection to another machine using a direct connection. This function works off the Guest/Host principal.

After the wizard defines the connection, a corresponding connection object will appear in Network and Dial-up Connections. Note that the wizard itself only handles the input of the most basic properties of the connection. However, you can get at the advanced settings of the connection by accessing its properties.

The security option of the connection can also be configured via the security tab. This includes settings such as which authentication mechanism is used, whether encryption is required, and so forth.

Finally, note the options tab. This allows you to control a number of elements including dialing options and associated parameters.

Note that the Make New Connection wizard only allows you to create and configure remote access connections. Local area connections are set up automatically based on the number of network adapters installed.

Windows 2000 Professional supports the ability to create both outgoing and incoming remote access connections. Types of connections supported include dialup, VPN, and direct cable connection (including infrared). The list below outlines the protocols supported and their associated features and limitations under Windows 2000.

Point-to-Point protocol – PPP is the de facto standard for dialup connections, and supports numerous transport protocols including TCP/IP, NetBEUI, IPX/SPX, AppleTalk and a range of others. PPP also support the assignment of client IP addresses via DHCP. Windows 2000 can act as both a PPP client and server.

Serial Line Internet Protocol – SLIP is an older dialup standard that can only be used with IP and does not allow for dynamic allocation of IP addresses. Windows 2000 can only function as a SLIP client and not as a SLIP server.

Point-to-Point Tunneling Protocol – PPTP is a virtual private networking (VPN) protocol used to create a secure connection over an untrusted network (such as the Internet) by encrypting all data sent between a PPTP client and PPTP server. PPTP is supported by a variety of operating systems, including Windows NT 4.0, Window 95, 98, etc.

Layer 2 Tunneling Protocol – L2TP is another VPN protocol that provides a similar function to PPTP. However, L2TP’s responsibility is tunnel creation and tunnel management. L2TP does not actually encrypt data. Instead, it works in conjunction with the IPSec protocol, which is actually responsible for the encryption. L2TP in an open standard developed jointly by Microsoft and Cisco to ultimately replace PPTP and Cisco’s Layer 2 Forwarding (L2F) protocol.

IPSec – In a VPN environment, IPSec is responsible for encrypted data sent between the VPN client and server, as well as negotiating encryption related parameters such as encryption level (56-bit, 128-bit, etc) and so forth.

Note that so far, the only Microsoft OS to natively support L2TP / IPSec is Windows 2000. As such, protocol choice is often based on client systems making the connection.

Windows 2000 Professional also supports a few new authentication protocols for the purposes of remote access connections. These include EAP and BAP, which are looked at below.

EAP – The Extensible Authentication Protocol is an extension to PPP that allows for a greater degree of choice in terms of the authentication mechanism used. Support is built into Windows 2000 for the use of generic token cards, the MD5-CHAP protocol, and Transport Layer Security (TLS), which is used for authentication via smart card. EAP also allows vendors to create additional authentication modules that can be used in Windows 2000, such a biometric hardware such as a thumbprint reader or retinal scanner, for example.

BAP – The Bandwidth Allocation Protocol is a protocol that enhances the capabilities of multilink in Windows 2000. Multilink is the ability to aggregate the bandwidth from multiple dialup connections (modem or ISDN) for a single user. BAP works to manage bandwidth usage more efficiently. For example, you can use BAP to automatically drop one line of a multilink connection should utilization fall below a certain level.

Windows 2000 also continues to support a variety of authentication protocols that included in NT 4.0. These include:

PAP – Password Authentication Protocol. Uses plaintext passwords.

SPAP – Shiva Password Authentication Protocol. Authentication protocol that allows Windows 2000 clients to be authenticated by Shiva servers, or Shiva clients to be authenticated by Windows 2000 Servers.

CHAP – Challenge Handshake Authentication Protocol. An MD-5 based authentication protocol that is supported in a variety of OSes.

MS-CHAP – Microsoft’s version of CHAP. When this option is chosen, you can choose to encrypt all data using MPPE (Microsoft point-to-point encryption).

MS-CHAP version 2 – supports many of the same features as MS-CHAP, but is a stronger version. For example, while MS-CHAP uses a single cryptographic key for all data sent and received, MS-CHAP v2 uses separate keys for each function. Also supports password changes during the authentication process.