Configuring or reconfiguring PulseSecure to use LDAPS instead of LDAP
LDAP authentication for the Pulse Secure appliances relies on a connection between the Pulse Secure Connect and the LDAP server. It is desirable that this connection is secured as it would otherwise be vulnerable e.g. to man-in-the-middle attacks.
The LDAP server connection can be secured using two commonly available protocols “LDAP over TLS” (STARTTLS) and “LDAP over SSL” (LDAPS).
This article will detail how we will always configure the protocol LDAPS in the future because Orange Cyber Defense considers security a top priority.
The existence of this article is also partly due to the following security advisory of Microsoft: ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
LDAPS and STARTTLS
Overview
To ensure the confidentiality of the user credentials you should make use of an encrypted LDAP connection between the Pulse Secure Connect appliance and the LDAP service (e.g. running on a Microsoft active directory domain controller)
There are two ways you can enable encryption
All of these ports (389, 636, and 3269) are by default opened on a Windows Server 2016 installation. From a configuration point of view, there is not so much difference between using LDAPS or STARTTLS. Only the encryption type and port differ.
STARTTLS
StarTTLS for LDAP is slightly different from LDAPS, the main difference being, that first the client needs to establish an unencrypted connection with the directory server. At any point in time after establishing the connection (as long as there are no outstanding LDAP operations on the connection), the StartTLS extended operation shall be sent across to the server. Once a successful extended operation response has been received, the client can initiate the TLS handshake over the existing connection. Once the handshake is done, all future LDAP operations will be transmitted on the now secure, encrypted channel.
My concerns with StartTLS are:
You must have a plain LDAP port open on the network. Even after a client connects to the directory there is absolutely nothing preventing the user from sending BIND or any other kind of requests on the unencrypted channel before actually performing the StartTLS extended operation.
LDAPS
LDAPS is the non-standardized “LDAP over SSL” protocol that in contrast with StartTLS only allows communication over a secure port such as 636. It establishes the secure connection before there is any communication with the LDAP server. However, as LDAPS is not part of the LDAP standard, there is no guarantee that LDAPS client libraries actually verify the hostname against the name provided with the security certificate.
Notice StartTLS doesn’t mean it will use by default TLS v1.x. It allows the usage of unsecured SSL (V2/V3) protocols as well.
The same story for LDAPS. Both protocols support unsafe protocols ( SSL V2/V3 | TLS 1.0/1.2 ) but also both the safe protocol TLS 1.2
Since it’s clear that StartTLS doesn’t guarantee the connection is secured ( it depends on what the LDAP server allows ), we will focus further on the LDAPS protocol.
Pulse Secure – LDAPS configuration
Configuring Authentication with an LDAPS Server
To configure authentication with an LDAPS server:
- Select Authentication> Servers.
- Select LDAP Server and click New Server to display the configuration page.
- Complete the configuration as described in the table below.
- Save the configuration.
LDAP Server Settings. (I have put the important configurations parts for LDAPS in bold orange) . Notice many parameters are optional as well.
The (LDAP) user attribute field ‘samaccountname’ is used to identify the user.Below some screenshots of a working lab setup where LDAPS was configured.
The LDAP server in the LAB is a Microsoft Server Active Directory Domain Controller 2016. This is a very common setup in my experience.
The configuration for ‘Determining group membership’ was also done.
Notice LDAP admin credentials were entered ( = optional ) in order to support password manager with the Pulse Secure Connect appliance. In this way, it’s possible to change the end user’s password with the appliance.
Import the trusted CAs.
It’s recommended to activate the option ‘Validate Server Certificate’ . This requires you to import the trusted root CA and the intermedia root CAs as Trusted CAs. These are the CAs that signed the server certificate installed on the LDAP server.
In case there is a self-signed certificate installed on the LDAP server, you only need to import this certificate as ‘Trusted Server CA’
Modify an existing configuration
I would never modify an existing (native) LDAP configuration. I would rather add a new LDAPS authentication server as described in point 3.1
It’s safer to quickly create another user realm with the new LDAPS authentication server.
You can duplicate an existing user realm and edit the authentication server to the new LDAPS authentication server.
Users -> User Realms -> <select_user_realm>
You then add the new user realm to an existing URL :
Authentication -> Signing-In -> Sign-in Policies.
After you have done a number of tests with the new user realm, you can remove the old user realm from the url. If the old user realm is no longer in use for all urls, you can also remove the object under User -> User Realms.
Finally, you will be able to remove the old LDAP authentication server as well.
Troubleshooting
You test the connectivity for the configured LDAP port by clicking on the button ‘Test Connection’. (Authentication -> Auth Servers -> <LDAPS_Auth_Server>)
Notice this will only verify if the TCP connection can be initiated. In case there are issues, check any firewalls that are between the Pulse Secure appliance and the LDAP server.
Remember the appliance will use by default the node IP on the Internal Port. See System -> Traffic Segregation
The TCP Dump utility can help you to verify the TCP and TLS handshake.
(Maintenance -> Troubleshooting -> Tools -> TCP Dump ).
