Unencrypted LDAP authentication problem towards Microsoft AD

Frequently Asked Questions
Post Reply
Posts: 697
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

Unencrypted LDAP authentication problem towards Microsoft AD

Post by Peter » 07 Oct 2013, 09:30

This FAQ applies to:
  • Clavister CorePlus / cOS Core version 9.10.00 and up.

Why can i only use PAP (unencrypted passwords) when authenticating with LDAP using an L2TP/IPSec, PPTP or SSL VPN towards Microsoft Active Directory? I want to be able to use Chap, MS-CHAP or MS-CHAPv2.


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

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

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.
SetupExample_1.png (109.29 KiB) Viewed 8394 times
The reason why only PAP works is related to how the LDAP protocol is defined, together with the way passwords are stored by the 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 trough 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 How-To 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.

    The drawback of using the description field is that you will most likely end up having two different passwords for the 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 his 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 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 will still be sent using PAP (unencrypted password).
Alternative 2 – RADIUS
  • It is possible to setup a RADIUS server on the MS AD 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 How-To:


    The above article uses WebAuth as example. In the case of e.g. PPTP, the client will use whatever authentication method defined on the client, and that will also be used towards the Radius server. So if the client decides to use MS-CHAPv2, the SGW will also use MS-CHAPv2 in the communication with the RADIUS server.
Why use LDAP then?
  • The issue described in this FAQ is related to how Microsoft have implemented their LDAP database. Other LDAP implementations such as OpenLDAP does 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 to a Radius then the Radius to cOS Core would be a good way to solve the unencrypted password issue.

Post Reply