PPP Authentication

PPP requires that the user present a set of credentials that are then validated by the remote access server. Security of outside connections is supremely important, so it is worth taking a long look at the details of each authentication method. This information helps you to decide which protocol to use and how to troubleshoot if the protocol gets misconfigured.

PPP itself has no preferred authentication protocol. The authentication method is negotiated during the Link Control Protocol stage of the connection transaction. Windows Server 2003 supports a variety of authentication methods for use within PPP. Here is a short summary of each followed by a detailed analysis:

• Password Authentication Protocol (PAP). The client transmits a clear-text password to the server, where it is compared to the user's password stored in a database of some form. PAP is unsuitable for all but the most trivial dial-up transactions.

• Shiva PAP (SPAP). This proprietary form of PAP is used by Shiva LANRover and other products. It transmits a reversibly encrypted password to the server, which is better than PAP, but still unsuitable when there is potential for impersonation of the remote access server.

• Challenge Handshake Authentication Protocol (CHAP). This industry-standard authentication method is used by nearly all Internet Service Providers (ISPs). CHAP does not transmit passwords over the wire. Instead, it uses a challenge-response methodology where the user's password is used to hash a response to the server, which compares the result to a hash performed using the same password.

• Microsoft CHAP (MS-CHAP) . This is a proprietary version of CHAP that uses a hashed version of a user's password to respond to the challenge rather than the password itself. This method is used by Windows 3.1x and the original Windows 95.

• Microsoft CHAPv2 (MS-CHAPv2). This is an improved version of MS-CHAP that eliminates several weaknesses by including mutual authentication between the client and server, a longer challenge, and a more secure means of changing an expired password.

• Extensible Authentication Protocol (EAP). This is not an authentication protocol, as such, but rather a mechanism for using an alternate authentication protocol. The primary use of EAP in Windows is to support smart card authentication. Vendors can add more EAP methods.

Now let's take a close look each authentication protocol and examine its strengths and weaknesses.

Password Authentication Protocol (PAP)

PAP authenticates a user by collecting the user's logon credentials (name and password) and sending them to the server in clear text. Figure 20.4 shows how this looks in a packet capture.

A Windows remote access server obtains a copy of the user's password via a secure, encrypted channel to a domain controller. It uses this copy of the user's password to validate the authentication request.

Active Directory does not store clear-text versions of user passwords. You can, however, enable the storage of passwords that are encrypted with a reversible key. The domain controller can decrypt the password and send the result to the remote access server to support PAP authentication. See the sidebar, "Reversible Passwords," for details.

PAP is only acceptable when connecting a trusted client to a trusted server over a trusted phone line. Even then, the ability to view user passwords via packet captures is simply too much of a temptation. It's best to avoid PAP by disabling it at the server.

Shiva Password Authentication Protocol (SPAP)

SPAP is used by Shiva's LANRover products and Shiva-compatible remote access servers. SPAP is supported by RAS both to permit a Shiva client to dial into a Windows RAS server and to permit a Windows client to dial into a LANRover device.

Unlike PAP, SPAP transmits passwords in encrypted form, not clear text. This is a scant improvement because the passwords are reversible, simple to break, and not coupled with information to keep them from getting shanghaied and used for impersonation.

SPAP should never be enabled as a dial-up authentication protocol at an RRAS server. It should only be used by dial-up clients connecting to a LANRover remote access server.

Challenge Handshake Authentication Protocol (CHAP)

Standard CHAP is defined by RFC 1994, "PPP Challenge Handshake Authentication Protocol (CHAP)." Windows remote access servers use CHAP to support non-Windows clients. Windows clients use CHAP when connecting to non-Windows remote access servers, such as those at an ISP.

The advantage of CHAP compared to PAP or SPAP is that the password, or a derivation of the password, never travels along the wire. Procedure 20.1 shows an outline of a CHAP authentication transaction.

Procedure 20.1 CHAP Authentication Transaction

By default, CHAP is disabled at a Windows Server 2003 RRAS server. If you need to support third-party clients, you must enable it manually along with enabling reversible passwords.

Microsoft Challenge Handshake Authentication Protocol (MS-CHAPv1 and v2)

A Windows client authenticating against a Windows RRAS server has an advantage over a third-party client because both the client and the server have a copy of the same password hash used for network logons. This permits the two entities to substitute the user's password hash for the clear-text password during the challenge-response transaction. This avoids storing reversible passwords.

Microsoft terms this alternate authentication protocol MS-CHAP. There are two versions of MS-CHAP. The original version is documented in informational RFC 2488, "Microsoft PPP CHAP Extensions." This version exposed some fairly notorious security vulnerabilities, including the use of the very weak LanMan (LM) Data Encryption Standard (DES) password hash in the challenge-response, the potential for man-in-the-middle attacks, a password change procedure that exposes accounts to simple exploits, and an implementation of streaming encryption that made it fairly simple to extract the secret key.

These MS-CHAP vulnerabilities are documented in a white paper called "Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol," co-authored by Bruce Schneier at Counterpane Systems and Mudge from L0pht Heavy Industries (now @Stake). A copy of this white paper is available at www.counterpane.com.

In response to these vulnerabilities, Microsoft replaced MS-CHAP with a second version, MS-CHAPv2. This protocol is documented in informational RFC 2759, "Microsoft PPP CHAP Extensions, Version 2." This new version incorporates the following improvements:

• LanMan DES password hashes are no longer used in challenge-response transactions, only NT LanMan (NTLM) MD4 password hashes. MD stands for Message Digest.

• Longer challenges (16 bytes vice 8 bytes).

• Mutual authentication between client and server to eliminate man-in-the-middle vulnerabilities.

• A new change password transaction that avoids documented exploits.

• Changes to the way RC4 encryption keys are generated for streaming encryption to make it more difficult to extract the keys.

Mr. Schneier and Mudge along with David Wagner from UC Berkeley have documented vulnerabilities peculiar to MS-CHAPv2 in an update to their original PPTP white paper. (The updated white paper is also available at the Counterpane web site.) Paul Leach from Microsoft has disputed several of the assertions in the white paper in a message posted on Bugtraq. (Search for Mr. Leach's name and MS-CHAPv2.)

At the end of the day, we as system administrators need to come to a conclusion about what technology to implement. It is fair to say that MS-CHAPv2 is the most secure of the password-based authentication protocols natively supported on Windows Server 2003. (RADIUS does not replace MS-CHAPv2, it merely designates a different location to go for credentials.) If security is a high priority—and when shouldn't it be?—you should consider using smart cards for remote access authentication. See the "Deploying Smart Cards for Remote Access" section for details.

Extensible Authentication Protocol (EAP)

EAP is not an authentication protocol in and of itself. It provides a way to use alternate authentication methods not directly supported by PPP. Windows Server 2003 comes with two EAP packages:

• MD5-CHAP. This method uses the same transactions as standard CHAP but initiates them as part of EAP for testing purposes.

• Certificate or Smart card. This method uses an X.509 certificate issued to a user and stored in a smart card to affect the authentication.

The MD5-CHAP package is included in EAP purely as a diagnostic tool. If you are having trouble getting a smart card deployment to work and you want to see if there is a problem in EAP itself, you can enable reversible passwords, change a test user's password to get a reversible copy, then use MD5-CHAP to validate the EAP mechanism. Do not use MD5-CHAP for production authentication.

Using smart cards for authentication requires a PKI in which an administrator enrolls a smart card user and obtains an X.509 certificate from a trusted Certification Authority (CA) that is stored in the memory of the smart card. The user inserts the smart card in a reader when initiating the dial-in connection. See "Deploying Smart Cards for Remote Access" for details about generating certificates and saving them to smart cards.

The dial-in client software must be configured to use smart card authentication. For Windows clients, this configuration is done in the Security tab of the Properties window of the dial-in connection. Figure 20.8 shows an example.

Procedure 20.2 shows a rundown of a smart card authentication transaction.

Procedure 20.2 EAP Smart Card Authentication Transaction

Just as with a standard PPP CHAP transaction, smart card authentication is only used to create the data connection. The user still needs to authenticate on the network. You can elect to also use a smart card for the network logon or you can fall back on a password. The best route is to use the smart card for network access, as well. This is done using the Logon Using Dial-Up Connection option in Winlogon.

If you use a smart card for network logons, the users do not know their passwords. If they choose to log on to their machines without doing a dial-up connection, they can insert the card and get local access. The system caches their smart card-based credentials just as it would their password-based credentials. (The public-private key pair and PIN are not cached, just the user's UPN and a data structure that includes the user's SID.)

If you decide to use smart cards for LAN authentication as well as remote logon, you might be interested in a few new features in Windows Server 2003/XP that make life easier for administrators in a smart card environment:

• You can use the RUNAS command with a smart card. The syntax is runas /u:user@domain.root /smartcard. The same is not true for the GUI RunAs window. There, you must select alternate credentials by password.

• You can use a smart card with the NET USE command. The syntax is net use * \\server\share /smartcard. The same is not true for the GUI Map Network Drive window. There you must select alternate credentials by password.

• You can use a smart card to authenticate in a Terminal Server session. This simplifies management via Remote Desktop.

RADIUS Authentication

If you have a remote access server that is not a member of a domain but you want to authenticate users based on their domain credentials, you can make use of the same authentication method used by most ISPs: Remote Authentication Dial-In User Services, or RADIUS.

RADIUS originated with Livingston Systems and is now an open standard described in RFC 2138, "Remote Authentication Dial-In User Service (RADIUS)," and RFC 2139, "RADIUS Accounting." Microsoft has published extensions to the standard RADIUS attributes in informational RFC 2548, "Microsoft Vendor-specific RADIUS Attributes," and Nortel has done the same in informational RFC 2882, "Network Access Servers Requirements: Extended RADIUS Practices."

RADIUS is both an authentication mechanism and a way to implement policies based on the user's identity, platform, connection method, and other attributes. ISPs use RADIUS policies to do tricks such as, "This is user X. She is calling from the 623 area code into the Albuquerque network access server. Grant user X the IP address 24.3.28.201 and route her to the least privileged router."

Internet Authentication Service

The Windows service that implements RADIUS goes by the name Internet Authentication Service, or IAS. The primary advantage of using IAS service, compared to a third-party RADIUS service, is that IAS can obtain user credentials directly from Active Directory. This eliminates the need for dual databases and dual passwords that must be kept in sync. It also means you can set up an IAS server in any convenient location as long as a domain controller is available. You can even run the IAS service directly on a domain controller for maximum throughput.

Figure 20.9 shows a simple Windows Server 2003 RADIUS configuration. The dial-up clients make connection to a remote access server that has been configured to use RADIUS as an authentication mechanism. The IAS server has been configured to accept authentication requests coming from the remote access server. The IAS server accepts the RADIUS packets from the remote access server then collects the user's credentials using a secure channel to a Windows Server 2003 or Windows 2000 domain controller.

An IAS server can handle RADIUS requests from any RFC-compliant RADIUS device, not just Windows Server 2003 RRAS servers. This includes most remote access concentrators, terminal servers, and boundary routers sold by major vendors. Multiple IAS servers can be used for fault tolerance. See "Configuring Internet Authentication Services (IAS)" for details on setting up an IAS server and configuring a Windows Server 2003 remote access server to use IAS for RADIUS authentication.

Configuring Remote Access Profiles

If you do not use IAS, the RADIUS policies assigned to a particular set of dial-in users are configured using the RRAS console under the Remote Access Policies icon. The default policy is configured to permit 24 x 7 access after it has been set to Grant from Deny.

Each RADIUS policy has an underlying profile. The terminology is a little confusing because the two terms are used in several other contexts. Think of a RADIUS policy as defining who will get a particular setting, whereas the profile determines what the setting will do.

For instance, the default RADIUS policy defines a logon time range of Monday through Sunday from midnight to midnight. This policy will apply to anyone who makes a dial-in connection to the server. The profile underlying this policy stipulates the authentication and IP address settings that will apply to dial-in users who fall under the policy, which in this case would be everyone.

The authentication settings in a RADIUS profile essentially mirror the settings in the RRAS server properties, but the two are not automatically kept in sync. Keep this in mind, because you can spend a lot of diagnostic time poking around in the RRAS configuration when your problem lies in RADIUS.

The profile options under the Encryption tab determine how data will be encrypted between dial-in clients and the remote access server. Figure 20.10 shows an example.

There are four encryption options:

• Basic uses either 40-bit MPPE RC4 streaming encryption or DES block encryption, depending on the connection type.

• Stronger uses 56-bit MPPE RC4 or DES.

• Strongest uses 128-bit MPPE RC4 or 3DES.

Selecting No Encryption with no other options prevents all forms of encryption. Selecting No Encryption in conjunction with one or more other options permits a client to negotiate that setting.

The remaining tabs define policies that refine and control the configuration of the dial-in clients that are permitted to access the system. Many of these options are redundant to options that can be configured at the Windows clients and in the server properties in RRAS. This is because IAS can be used by any RADIUS server, not just Windows Server 2003 RRAS servers.

Dial-Up Authentication and Domain Authentication

Two authentication transactions occur when a user makes a connection to a remote access server. One authentication takes place during the PPP transaction and the other takes place when the user touches a shared resource on a member server after the PPP connection has been made. The mechanism for obtaining credentials in the remote domain varies depending on the user's operating system.

When users on Win9x-based machines are not connected to the network, they typically escape past the first domain logon window to get to their desktop. They then use Dial-Up Networking to make connection to the remote access server. When the connection completes, a domain logon window appears and the user enters credentials to get authenticated. If the user does not authenticate at this point, no network permissions are granted. Because the user has been authenticated on the domain, each time the user touches a member server through the dial up connection, the server is able to authenticate the user via classic pass-through authentication.

Users on NT-based machines have two alternatives. The first is that they make the PPP connection prior to logging on to the desktop. The Graphical Identification and Authentication (GINA) window used by Winlogon has an option Log On Using Dial-up Connection to use for this purpose. If the user selects this option, the system makes PPP connection to the remote access server then Winlogon takes over to perform a domain logon, just as if the user were on the local network. Modern Windows clients use Kerberos for this transaction. Post-SP3 NT4 uses NTLMv2.

As an alternative, the user could log on to the local machine using cached credentials then make PPP connection to the remote access server. In this circumstance, the user is not immediately given domain access. When the user touches a member server for the first time, she is prompted for credentials. If the server is running Windows Server 2003 or Windows 2000, the Local Security Authority at the client takes over and obtains a Kerberos ticket-granting ticket (TGT) for the user's domain followed by Kerberos session tickets for each server that the user touches. (This succeeds only if the client is able to find a DNS server through the dial-up connection.)

The client caches the TGT and session tickets from the same domain as the user. Session tickets for servers in remote domains are not cached unless the user's domain and the remote access server's domain are both running in Native. You can see the contents of the ticket cache using Kerbtray or Klist from the Resource Kit. From this point forward, the user has been authenticated in the domain and is no longer prompted for credentials.

If the member server hosting the resource touched by the user is running NT4, the user is prompted for credentials and the server performs classic NTLM pass-through authentication to validate the user's identity. The user does not get Kerberos tickets and will be prompted for credentials again when touching another server.

This is an important point to remember for troubleshooting. XP and Windows 2000 clients participate in Kerberos transactions in an Active Directory domain even if the user does not initially log on to the domain. This minimizes hassle for the user and speeds up access to servers, especially in a WAN where classic pass-through authentication works very slowly.

The only real difference between this situation and logging on to the domain right away using the Log On Using Dial-up Connection option is the effect on group policies. When the user logs on to the domain from the main Winlogon window, group policies are downloaded. That actual set of policies obtained by the client depends on the Slow Link setting in group policy. The default for this setting is 500 Kbps. Administrative templates and security settings are downloaded regardless of the link speed.

Multidomain Authentication

If you have a multidomain forest, you will probably want users from any domain to use remote access servers in any other domain. This includes access by direct dial-up and VPN. After all, if a user from Brussels stays overnight in Tokyo, why would she need to dial long distance to Europe if there is a perfectly good remote access server in Japan?

When a user from one domain makes a PPP connection to a dial-in server that belongs to another domain, the dial-in server must obtain the user's credentials from a domain controller in the user's domain. That's because only a domain controller in the user's domain has a full copy of the naming context for that domain. The Global Catalog (GC) does not contain sufficient information to authenticate a PPP user.

This presents a problem. The RRAS service runs in the Local System security context. When it touches Active Directory, it uses Kerberos tickets obtained by the local machine. The machine account in one domain does not have privileges to read user information from Active Directory in another domain. You can encounter a similar problem if the dial-in user belongs to a domain in one forest in a federation and the RRAS or IAS server is a member of a domain in another forest.

For RRAS server in different domains in the same forest, this problem is resolved by making the RRAS server a member of the RAS and IAS Servers group in each domain in the forest. This group has the following access permissions for User-class objects in its local domain:

• Logon Information

• Group Membership

• Account Restrictions

• Remote Access Information

The net effect of these permissions permits servers in the RAS and IAS Servers group to obtain the critical Active Directory user information needed to complete PPP authentication transactions.

[View full width]
Key:    HKLM\SOFTWARE\Microsoft\Windows Windows Server 2003\
CurrentVersion\Winlogon
Value:  KeepRASConnections
Data:   REG_SZ (This is not a misprint. This value uses a String 
data type.)
Data:   1

In addition, the RAS and IAS Servers group has Read/Write permissions on the RAS and IAS Servers Access Check object under cn=System,dc=<domain>,dc=<root>. This object serves as a touchstone. If a server cannot read the contents of this object, it knows it doesn't have access to the rest of the naming context and immediately returns an error to the client.

When you first initialize the remote access service, the wizard automatically adds the server to the RAS and IAS Servers group in the local domain. You must add the server manually to the RAS and IAS Servers group in the other domains. If you forget to do this, users will get an error when they attempt a PPP connection stating that the authentication server did not respond in a timely fashion. This is the same error you will get if the IPSec portion of L2TP is not configured correctly; so don't go down a long diagnostic path for what is otherwise a simple problem to fix.

For RRAS servers in different forests, you can take advantage of the new proxy feature in IAS. This feature permits an IAS server to forward authentication requests to an IAS server in another forest.

Standard PPP Authentication Transaction

Before we dive into the various authentication methods used by PPP, it is instructive to follow through the details of a relatively straightforward sample transaction. Figure 20.11 shows a dial-up configuration with an XP client and a Windows Server 2003 remote access server. The server is a member of one domain and the user is a member of another domain. Procedure 20.3 shows the sequence of events that occurs when the client uses a modem to connect directly to the server.

Procedure 20.3 Standard PPP Transaction Details

This completes the PPP transaction. Traffic from the client is now routed through the RRAS server onto the main network, where the client is authenticated if the Logon Using Dial-Up Connection option was selected.

Comparison of Dial-Up Authentication for Various Clients

This section examines PPP and domain authentication used by various client platforms. This helps you to categorize connection problems based on whether they are PPP-related or they are related to domain authentication.

The examples in this section use the network configuration shown in Figure 20.12. In this figure, the remote access server is running Windows Server 2003. There are two domains in the forest. The remote access server is a member of the parent domain, although the results would not differ if it were a member of the other domain. As far as dial-in permissions are concerned, there is nothing special about the root domain of a forest.

The forest and the two domains in it have been set to full Windows Server 2003 functionality, although the results would be the same if the functionality level were left at Windows 2000 Native. A Mixed functionality level would affect the outcome only if NT4 Emulation is enabled at the domain controllers. See Chapter 9, "Deploying Windows Server 2003 Domains," for details.

Scenario 1: Dial-In User on a Standalone XP/Windows 2000 Pro Machine

The client makes a PPP connection and is authenticated via MS-CHAPv2, the highest default security level. For this authentication to succeed, the user must have credentials in one of the domains in the forest. The name of the domain must be stipulated at the client. This is true even for XP Home Edition clients, even though they cannot join the domain. At this point, it is the user being authenticated, not the desktop.

If the user is a member of a domain other than the home domain of the remote access server, the server must be a member of the RAS and IAS Servers group in the user's domain. This permits the server to obtain user credentials.

After the PPP connection is made, when the user touches a shared resource on a server in one of the domains, the server prompts for credentials. Recall that the user's machine is not a member of a domain (standalone workstation) and therefore cannot participate in a Kerberos transaction. The target server performs an NTLM pass-through authentication to its logon server to validate the challenge-response performed by the user.

The end result is that the user can access resources in any domain in the forest. This is true even if the domains are running in Mixed. The user is prompted for credentials each time a server is touched.

Scenario 2: Dial-Up User on a Non-Windows Platform

The initial PPP connection is authenticated via CHAP unless the machine is configured with a PPP package that supports MS-CHAPv2. CHAP authentication requires reversible passwords in Active Directory, so this option must be enabled in group policy.

After the PPP connection has completed, the subsequent transactions are the same as for Windows clients. For example, if the third-party machine is running Linux with the most current version of Samba, the client will present NTLMv2 credentials when challenged by member servers and the server will validate the challenge via classic pass-through.

Scenario 3: Dial-In User at a Windows 9x Machine

The initial PPP connection is authenticated via MS-CHAPv2. (Only original Windows 95 uses MS-CHAPv1.) The user is prompted to perform a Windows domain logon after the dial-up connection has completed. This transaction uses classic LanMan Challenge-Response (DES password hash).

When the user touches a shared resource on a member server, the server authenticates the user via LanMan pass-through to its logon server. The user is not prompted for credentials because domain logon has already been completed. The user has access to resources in any domain as long as the intervening domains are running in Native or higher.

A group policy called Do Not Store LAN Manager Hash Value On Next Password Change affects this transaction. This policy prevents storing the highly vulnerable LanMan DES password hash in Active Directory. This prevents utilities such as L0phtcrack from using the weak password to gain access to the system.

Enabling this policy prevents Windows 9x clients from logging on to an Active Directory domain unless they have been configured with the Dsclient patch from the Windows Server 2003 or Windows 2000 Server CD. This patch upgrades the client to NTLMv2 authentication. See Chapter 11, "Understanding Network Access Security and Kerberos," for details.

If you set this group policy then attempt a dial-up connection from a Windows 9x client that has not been patched with Dsclient, here is the result: The initial PPP connection succeeds but the subsequent logon to the domain fails. The failure of the domain logon is something you should expect with no LanMan password hash in Active Directory, but the success of the initial PPP connection might be a surprise. It reveals how the RRAS server obtains user credentials from its logon server.

The reason the initial PPP connection succeeds is that RRAS always uses NTLM pass-through to obtain user credentials for MS-CHAP authentication transactions. The use of NTLM results in the return of the user's NT password hash regardless of the platform used by the dial-in user. See the sidebar, "NTLM and RRAS" for more information.

If you attempt a PPP connection from a classic Windows 95 client using MS-CHAPv1, the PPP connection will appear to fail during the authentication phase, but it actually fails during the IPCP phase when the client attempts to negotiate encryption and there is no LanMan password available at the server. The encryption used by MS-CHAPv2 relies on the NT password hash so the encryption negotiation succeeds.

The end result is that users at Windows 9x machines can make dial-in connection to any remote access server and access resources in any domain in the forest. If LanMan passwords have been disabled in group policy, the clients must be running the Dsclient patch.

Authentication Limitations in NT4 and Mixed Domains

The presence of classic NT BDCs inhibits full remote access authentication functionality in Windows Server 2003 and Windows 2000. As long as there is a possibility that a remote access server could try to validate a dial-in user via pass-through to a classic BDC, the following features cannot be implemented:

• Connection control with remote access policies

• Caller ID verification

• Assignment of static IP addresses and static routes

These options are available in the Properties window of a user account in AD Users and Computers on the Dial-In tab (see Figure 20.13). The options remain dimmed until you shift to Native. At that point, all classic BDCs should be off the network.

The shift to Native might catch your support staff off-guard because of the change in the default dial-in permission setting for users. In Mixed, a new user is denied dial-in permissions by default. In Native, the permissions are controlled by remote access policy, which is set to Grant Access by default.