Question

Why can we only use PAP (with unencrypted passwords) when authenticating with LDAP and L2TP/IPsec, PPTP or SSL VPN towards an Microsoft Active Directory server? We want to be able to use Chap, MS-CHAP or MS-CHAPv2 as those are encrypted.

Answer

With the introduction of LDAP as an authentication method in cOS Core version 9.10.00, it has been possible to setup a user authentication rule in the firewall that connects to an LDAP server for user credential authentication.

A problem can arise when using a PPTP tunnel towards a firewall that is in turn linked to an MS AD server using LDAP. The only authentication method that works in this scenario is PAP (unencrypted passwords).

Important: PPTP is no longer considered secure and should not be used unless absolutely necessary. The reference to PPTP is kept in the article as a reference example. Also, instead of the SSL VPN client/server in cOS Core it is recommended to use the new OneConnect client/server as it is the replacement for the old SSL VPN client/server solution. The old SSL VPN solution will not be actively updated going forward.

This is particularly bad for PPTP as the username/password is sent as a part of the PPP negotiation, before MPPE encryption is enabled. When using other VPN tunnels such as SSL VPN or L2TP/IPsec the username/password are sent inside an encrypted tunnel. In that case, it does not really matter if the passwords are unencrypted (PAP) on the inside, as they are transported as encrypted data anyway.

The reason why only PAP works is related to how the LDAP protocol is defined, together with the way passwords are stored by Microsoft Active directory.

The main reason is that the LDAP protocol only supports a limited number of ways of authenticating access to the “database”. The only method that is compatible with the authentication methods supported by PPP is a method called “simple”, that is using plaintext password in the authentication request (bindRequest). This maps as well to the PAP authentication method.

To be able to support any other PPP authentication method on a PPP server connected to LDAP, the password would need to be retrieved from the LDAP server. In cOS core, this is implemented by letting cOS Core authenticate to the LDAP server using an administrator account, and ask for information about the specific user trying to gain PPP access.

There is however no legitimate way to retrieve the userPassword from Microsoft Active Directory through LDAP. The LDAP protocol itself supports this, but Microsoft has intentionally implemented this as a write only attribute in Active Directory. The password can be changed but not retrieved. (additionally, the AD stores a password hash, not the password itself).

Alternative 1 – Description field

As described in the manual and also in some other older Clavister forum articles, an alternative to using the password attribute field is to use the “Description” field for the user on the AD. By using that field, you will be able to use CHAP, MS-CHAP and MS-CHAPv2 when authenticating the PPP client towards cOS Core connected to an AD server.

The drawback of using the description field is that you will most likely end up having two different passwords for users in the AD. Most administrators require their users to change their password from time to time, and since the description field is not part of this process it means that whenever the user changes their password, the description field will be left unchanged unless the administrator changes this manually.

This is counter-productive, as the whole point of using an AD server is most likely to avoid the hassle of having a separate user database for VPN users.

Note: The password between cOS Core and the AD server will still be sent using PAP (unencrypted password).

Alternative 2 – RADIUS

It is possible to setup a RADIUS server on the AD server and link it towards the user database. RADIUS has the advantage that it actually supports all authentication methods supported by PPP. cOS Core will thus be able to forward the whole authentication exchange, without even having any way to know the password. This is described in the following older Clavister forum entry:

https://forums.clavister.com/viewtopic.php?f=8&t=3423 

The above article uses WebAuth as an example. In the case of, for example PPTP, the client will use whatever authentication method is defined on the client, and that will also be used towards the RADIUS server. So if the client decides to use MS-CHAPv2, the firewall will also use MS-CHAPv2 in the communication with the RADIUS server.

Why use LDAP then?

The issue described in this article is related to how Microsoft have implemented their LDAP database. Other LDAP implementations, such as OpenLDAP, may not have this limitation and it will be possible to use CHAP, MS-CHAP and MS-CHAPv2.

If MS AD is used, connecting the AD server to a RADIUS server and then RADIUS to cOS Core would be a good way to solve the unencrypted password issue.

Related articles