Share via

Password-Based Authentication Methods

  • Article

Applies To: Windows Server 2008

Password-based authentication methods

Each authentication method has advantages and disadvantages in terms of security, usability, and breadth of support. Password-based authentication methods, however, do not provide strong security and their use is not recommended. It is recommended that you use a certificate-based authentication method for all network access methods that support the use of certificates. This is especially true for wireless connections, for which the use of PEAP-MS-CHAP v2 or PEAP-TLS is recommended.

The authentication method to use is determined by the configuration of the network access server, the client computer, and network policy on the server running Network Policy Server (NPS). Consult your access server documentation to determine which authentication methods are supported.

You can configure NPS to accept multiple authentication methods. You can also configure your network access servers, also called RADIUS clients, to attempt to negotiate a connection with client computers by requesting the use of the most secure protocol first, and then the next most secure, and so on, down to the least secure. For example, the Routing and Remote Access service tries to negotiate a connection using EAP first, then MS-CHAP v2, then MS-CHAP, then CHAP, then SPAP, and then PAP. When EAP is chosen as the authentication method, the negotiation of the EAP type occurs between the access client and the NPS server.

MS-CHAP version 2

Version 2 of the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v2) provides stronger security for network access connections than its predecessor, MS-CHAP. MS-CHAP v2 solves some of the issues of MS-CHAP version 1, as described in the following table.

MS-CHAP version 1 issue MS-CHAP version 2 solution

LAN Manager encoding of the response used for backward compatibility with older Microsoft remote access clients is cryptographically weak.

MS-CHAP v2 no longer allows LAN Manager-encoded responses.

LAN Manager encoding of password changes is cryptographically weak.

MS-CHAP v2 no longer allows LAN Manager-encoded password changes.

Only one-way authentication is possible. The remote access client cannot verify that it is dialing in to its organization's remote access server or a masquerading remote access server.

MS-CHAP v2 provides two-way authentication, also known as mutual authentication. The remote access client receives verification that the remote access server that it is dialing in to has access to the user's password.

With 40-bit encryption, the cryptographic key is based on the user's password. Each time the user connects with the same password, the same cryptographic key is generated.

With MS-CHAP v2, the cryptographic key is always based on the user's password and an arbitrary challenge string. Each time the user connects with the same password, a different cryptographic key is used.

A single cryptographic key is used for data sent in both directions on the connection.

With MS-CHAP v2, separate cryptographic keys are generated for transmitted and received data.

MS-CHAP v2 is a one-way encrypted password, mutual authentication process that works as follows:

  1. The authenticator (the network access server or the NPS server) sends a challenge to the access client that consists of a session identifier and an arbitrary challenge string.

  2. The access client sends a response that contains:

    • The user name.

    • An arbitrary peer challenge string.

    • A one-way encryption of the received challenge string, the peer challenge string, the session identifier, and the user's password.

  3. The authenticator checks the response from the client and sends back a response containing:

    • An indication of the success or failure of the connection attempt.

    • An authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user's password.

  4. The access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the access client terminates the connection.

Enabling MS-CHAP v2

To enable MS-CHAP v2-based authentication, you must do the following:

  1. Enable MS-CHAP v2 as an authentication protocol on the network access server.

  2. Enable MS-CHAP v2 on the appropriate network policy.

  3. Enable MS-CHAP v2 on the access client.

Additional considerations

  • MS-CHAP (version 1 and version 2) is the only password-based authentication protocol that supports password change during the authentication process.

Note

Password change scenarios are supported only when NPS is able to communicate directly with a writable domain controller in your network for the password change transactions. Password change scenarios are not supported if NPS is configured to communicate with a Read-only domain controller (RODC) in your network.

  • Make sure your network access server supports MS-CHAP v2 before you enable it on a network policy on an NPS server. For more information, see your NAS documentation.

MS-CHAP

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), also known as MS-CHAP version 1, is a nonreversible, encrypted password authentication protocol. The challenge handshake process works as follows:

  1. The authenticator (the network access server or the NPS server) sends a challenge to the access client that consists of a session identifier and an arbitrary challenge string.

  2. The access client sends a response that contains the user name and a nonreversible encryption of the challenge string, the session identifier, and the password.

  3. The authenticator checks the response and, if valid, the user's credentials are authenticated.

If you use MS-CHAP as the authentication protocol, then you can use Microsoft Point-to-Point Encryption (MPPE) to encrypt the data sent on the PPP or PPTP connection.

MS-CHAP version 2 provides stronger security for network access connections than MS-CHAP. You should consider using MS-CHAP version 2 instead of MS-CHAP.

Enabling MS-CHAP

To enable MS-CHAP-based authentication, you must do the following:

  1. Enable MS-CHAP as an authentication protocol on the network access server.

  2. Enable MS-CHAP on the appropriate network policy in NPS.

  3. Enable MS-CHAP on the access client.

Additional considerations

  • By default, this implementation of MS-CHAP v1 does not support LAN Manager authentication. If you want to allow the use of LAN Manager authentication with MS-CHAP v1 for older operating systems such as Windows NT 3.5x and Windows 95, you must set the following registry value to 1 on the NPS server:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Allow LM Authentication

  • If MS-CHAP v1 is used as the authentication protocol, a 40-bit encrypted connection cannot be established if the user's password is larger than 14 characters. This behavior affects both dial-up and VPN-based remote access and demand-dial connections.

Warning

Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

CHAP

The Challenge Handshake Authentication Protocol (CHAP) is a challenge-response authentication protocol that uses the industry-standard Message Digest 5 (MD5) hashing scheme to encrypt the response. CHAP is used by various vendors of network access servers and clients. A server running Routing and Remote Access supports CHAP so that access clients that require CHAP are authenticated. Because CHAP requires the use of a reversibly encrypted password, you should consider using another authentication protocol, such as MS-CHAP version 2.

To enable CHAP-based authentication, you must do the following:

  1. Enable CHAP as an authentication protocol on the network access server.

  2. Enable CHAP on the appropriate network policy in NPS.

  3. Enable storage of a reversibly encrypted form of the user's password.

    You can enable its storage per user account or for all accounts in a domain.

  4. Force a reset of the user's password so that the new password is in a reversibly encrypted form.

    When you enable passwords to be stored in a reversibly encrypted form, the current passwords are not in a reversibly encrypted form and are not automatically changed. You must either manually change user passwords or set user passwords to be changed the next time each user logs on.

    If you set user passwords to be changed the next time a user logs on, the user must log on by using a LAN connection and change the password before the user attempts to log on with a remote access connection by using CHAP. You cannot change passwords during the authentication process by using CHAP; the logon attempt fails. One workaround for the remote access user is to temporarily log on by using MS-CHAP to change the password.

  5. Enable CHAP on the access client.

Additional considerations

  • When users' passwords expire, CHAP does not provide the ability for them to change passwords during the authentication process.

  • Verify that your network access server supports CHAP before you enable it on a network policy on a server running NPS. For more information, see your NAS documentation.

  • You cannot use Microsoft Point-to-Point Encryption (MPPE) with CHAP.

PAP

Password Authentication Protocol (PAP) uses plaintext passwords and is the least secure authentication protocol. It is typically negotiated if the access client and network access server cannot negotiate a more secure authentication method.

To enable PAP-based authentication, you must do the following:

  1. Enable PAP as an authentication protocol on the network access server.

  2. Enable PAP on the appropriate network policy in NPS.

  3. Enable PAP on the access client.

Important

When you enable PAP as an authentication protocol, user passwords are sent in plaintext form. Anyone capturing the packets of the authentication process can easily read the password and use it to gain unauthorized access to your intranet. The use of PAP is highly discouraged, especially for VPN connections.

Additional considerations

  • If you deploy a dial-up server, by disabling the support for PAP on the network access server you ensure that plaintext passwords are never sent by dial-up clients. Disabling support for PAP increases authentication security, but remote access clients who only support PAP cannot connect.

  • When users' passwords expire, PAP does not provide the ability for them to change passwords during the authentication process.

  • Make sure your network access server supports PAP before you enable it on a network policy on an NPS server. For more information, see your NAS documentation.

  • You cannot use Microsoft Point-to-Point Encryption (MPPE) with PAP.

Unauthenticated access

With unauthenticated access, user credentials (a user name and password) are not required. Although there are some situations in which unauthenticated access is useful, in most cases it is not recommended on your organization network.

When you enable unauthenticated access, users are allowed access to your network without sending user credentials. In addition, unauthenticated access clients do not negotiate the use of a common authentication protocol during the connection establishment process and do not send a user name or password to NPS.

When you must use unauthenticated access, you can use one of the following solutions:

  • DNIS authorization

  • ANI/CLI authentication

  • Guest authentication

DNIS authorization

Dialed Number Identification Service (DNIS) enables the authorization of a connection attempt by NPS based on the number that the client computer called to initialize the connection. DNIS identifies the number that was called to the receiver of the call and is provided by most telephone companies. For example, you can allow all connections that connect through a specified toll-free number. To identify DNIS-based connections and apply the appropriate connection settings, you must do the following:

  1. Enable unauthenticated access on the network access server.

  2. Create a network policy on the NPS server for DNIS-based authorization with the Called-Station-Id condition set to the phone number that client computers must call to initiate the connection.

  3. Enable unauthenticated access on the network policy in NPS for DNIS-based authorization.

Additional considerations

  • If your phone service or hardware does not support DNIS, you can manually set the phone number of the port.

  • NPS does not support proxied DNIS access requests.

ANI/CLI authentication

Automatic Number Identification/Calling Line Identification (ANI/CLI) authentication is the authentication of a connection attempt based on the phone number of the caller. ANI/CLI service returns the number of the caller to the receiver of the call and is provided by most telephone companies.

ANI/CLI authentication is different from caller ID authorization. In caller ID authorization, the caller sends a valid user name and password. The caller ID that is configured for the dial-in property on the user account must match the connection attempt; otherwise, the connection attempt is rejected. With ANI/CLI authentication, a user name and password are not sent.

To identify ANI/CLI-based connections and apply the appropriate connection settings, you must do the following:

  1. Enable unauthenticated access on the network access server.

  2. Enable unauthenticated access on the appropriate network policy in NPS for ANI/CLI-based authentication.

  3. Create a user account in Active Directory® Domain Services (AD DS) or the local Security Accounts Manager (SAM) database on the NPS server for each number that will be calling and for which you want to provide ANI/CLI authentication. The name of the user account must match the number that the user is dialing from. For example, if a user is dialing in from 555-0100, create a "5550100" user account. In addition, the password for the user account must be null.

  4. Set the following registry value to 31 on the NPS server:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\User Identity Attribute

    This registry setting tells the authenticating server to use the calling number (RADIUS attribute 31, Calling-Station-ID) as the identity of the calling user. The user identity is set to the calling number only when there is no user name being supplied in the connection attempt.

    To always use the calling number as the user identity, set the following registry value to 1 on the authenticating server:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Override User-Name

    However, if you set Override User-Name to 1 and the User Identity Attribute to 31, the authenticating server can only perform ANI/CLI-based authentication. Normal authentication by using authentication protocols such as MS-CHAP, CHAP, and EAP is disabled.

Note

Changes to the registry settings will not take effect until the Routing and Remote Access service or the Network Policy Server service are restarted.

Warning

Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Guest authentication

AD DS includes a user account called Guest, which is disabled by default. If you want to provide unauthenticated access, you can enable the Guest account. With guest authentication, during the authentication process, the user does not provide a user name or password. If unauthenticated access is enabled, by default the Guest account is used as the identity of the caller.

To enable Guest account access, you must do the following:

  1. Enable unauthenticated access on the network access server.

  2. Enable unauthenticated access on the appropriate network policy in NPS.

  3. Enable the Guest account in Active Directory Users and Computers.

  4. Set the network access permission on the Guest account to either Allow access or Control access through NPS Network Policy, depending on your network policy administrative model.

If you want to enable a Guest account that is not named Guest, create a user account and set the remote access permission to either Allow access or Control access through NPS Network Policy. Then, set the following registry value on the authenticating server (either the remote access server or the NPS server) to the name of the account:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Default User Identity

Note

Changes to the registry settings will not take effect until the Routing and Remote Access service or the Network Policy Server service are restarted.

Warning

Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.