User-Level Authentication

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2

All site-to-site connection technologies require user-level authentication. The "user" to be authenticated in a site-to-site connection is the calling router. To prevent a non-authorized router from making a connection, RRAS requires that the calling router be authenticated by the answering router.

RRAS can use any of several PPP authentication methods to provide user-level authentication. For better security, choose one of the two strongest recommended PPP user authentication methods — Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) or Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2).

For more information about other PPP authentication protocols (in addition to EAP-TLS and MS-CHAP v2) supported by Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003, see Remote Access Authentication Methods in the RRAS Deployment Guide.

Certificate-based EAP-TLS

EAP-TLS is a more secure protocol than MS-CHAP v2 for user-level authentication of a dial-up, PPTP VPN, or L2TP/IPsec VPN connection. EAP-TLS requires a certificate infrastructure, because it uses a user certificate for the calling router and a computer certificate for the authenticating server of the answering router. The identity of the authenticating server depends on the authentication provider:

  • If Windows provides authentication, the computer certificate is installed on the answering router. The answering router must be a member of the Active Directory domain.

  • If RADIUS provides authentication, the computer certificate is installed on the RADIUS server. If the RADIUS server is an NPS server, it must be a member of the Active Directory domain. In this case, the answering router does not need to be a member of the domain.

We recommend EAP-TLS for all connection types both because it is the strongest method for user authentication and because it provides mutual user authentication between calling and answering routers. The calling router submits a user certificate for authentication, and the answering router (or RADIUS server) submits a computer certificate for authentication. With EAP-TLS, the user account that the answering router uses to authenticate and authorize the calling router must be an Active Directory user account.

If you plan to use certificate-based EAP-TLS, you can use a third-party CA if the conditions in the following two lists are met.

Requirements for certificates installed on authenticating server (answering router or RADIUS server)

  • Computer certificates must be installed in the Local Computer certificate store.

  • Computer certificates must have a corresponding private key.

  • The cryptographic service provider for the certificates must support secure channel (Schannel). (If not, the authenticating server cannot use the certificate and the certificate cannot be selected in the properties of a remote access network policy.

  • Computer certificates must contain the Server Authentication certificate purpose (also known as an enhanced key usage [EKU]). An EKU is identified by using an object identifier (OID). The OID 1.3.6.1.5.5.7.3.1 represents Server Authentication.

  • Computer certificates must contain the fully qualified domain name (FQDN) of the computer account of the authenticating server computer in the Subject Alternative Name property.

  • The root CA certificates of the CAs that issued the calling router user certificates must be installed in the Trusted Root Certification Authorities certificate store.

Requirements for certificates installed on calling router

  • User certificates must have a corresponding private key.

  • User certificates must contain the Client Authentication EKU, represented by the OID 1.3.6.1.5.5.7.3.2.

  • User certificates must be installed in the Current User certificate store.

  • User certificates must contain the universal principal name (UPN) of the user account in the Subject Alternative Name property.

  • The root CA certificates of the CAs that issued the authenticating server computer certificates must be installed in the Trusted Root Certification Authorities store.

Password-based MS-CHAP v2

Like EAP-TLS, MS-CHAP v2 also provides mutual authentication between the calling router and the answering router. MS-CHAP v2 is a password-based authentication method in which the answering router uses either an Active Directory user account or a local user account to authenticate the calling router. MS-CHAP v2 is the recommended method for user authentication if a certificate infrastructure is not available.

If you use a local user account for MS-CHAP v2 authentication, the demand-dial routers do not need to be members of the Active Directory domain. Be sure to use strong passwords with MS-CHAP v2. In an Active Directory domain, you can use Group Policy settings to enforce the use of strong passwords.

Advantages of EAP-TLS and MS-CHAP v2

Although several weaker PPP authentication protocols are also available for user authentication, EAP-TLS and MS-CHAP v2 are the preferred methods because both provide the following benefits:

  • Mutual authentication. With mutual authentication, the calling router is authenticated by the answering router, and the answering router is then authenticated by the calling router. This mutual authentication prevents an attacker from masquerading as the answering router, whereas other types of authentication verify only the identity of the calling router.

  • Encryption features. For a dial-up or PPTP connection, EAP-TLS and MS-CHAP v2 provide the following encryption features:

    • Stronger initial encryption keys. MS-CHAP v2 uses both a unique session identifier and user credentials to generate encryption keys. EAP-TLS uses user certificates to verify user identity. (In contrast, MS-CHAP uses only the user name and password to create these keys, making it easier for attackers to determine the keys in use.)

    • Different keys for encrypting data. The calling router and answering router use separate keys to encrypt and send data. Using different keys makes it more difficult for attackers to determine which key is used for encryption.

    • MPPE for encryption. MPPE uses Rivest-Shamir-Adleman (RSA) RC4 stream ciphering with 40-bit, 56-bit, and 128-bit encryption keys. Encryption key strength is negotiated during connection establishment (as is authentication method). The client (calling router) and server (answering router) negotiate the strongest mutually allowable key size. If the answering router requires a larger key than that supported on the calling router, the answering router rejects the connection.

Note

L2TP/IPsec generates its encryption keys by using IPsec and therefore does not need EAP-TLS or MS-CHAP v2 for encryption keys. 

For more information about encryption for site-to-site connections, see [Choose MPPE or IPsec Encryption](ff687780\(v=ws.10\).md).