Search

(Re)configuring F5 to use LDAPS instead of LDAP

In March 2020, Microsoft updated a security update regarding LDAP channel binding and LDAP signing hardening changes:

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

When a set of unsafe default configurations for LDAP channel binding and LDAP singing exist on Active Directory, an elevation of privilege vulnerability exists in Microsoft Windows that could allow man-in-the-middle attackers to successfully forward an authentication request to a Windows LDAP server.

This document will focus on (re)configuring F5 to use LDAPS instead of LDAP and it is divided into two sections:

  • Remote authentication to the management interface
  • Authentication via Access Policy Manager (APM)

Remote Authentication to Management Interface

Existing LDAP Configuration

To check the current LDAP configuration, go to System > Users > Authentication

When the SSL setting is set to Disabled, the LDAP connection is unencrypted. These types of connections are vulnerable for man-in-the-middle attacks, as the connections is readable in plain text. A malicious user who can intercept this traffic, can read the username, structure of your AD and password in plain text.

 

Corrective Actions

The F5 will communicate to the AD server over port 636, so we must make sure that the AD can accept the traffic on 636 and that there is no firewall in between that can block this traffic. The F5 also needs a valid CA certificate to check against.

When the connection on port 636 fails, you will not be able to login again with your AD credentials. Make sure you have the credentials for have a local account. The admin user will always be able to login, any other user requires the setting ‘Fallback to Local’ to be enabled.

Check the Root CA Certificate

The configuration requires the root CA certificate where the F5 can check against. Before changing the LDAP configuration, check if the certificate is listed in the certificate list under System > Certificate Management > Traffic Certificate Management > SSL Certificate List

 

If the root CA certificate is not listed, upload the certificate via the import button.

 

Change the LDAP configuration

Extra configuration settings become visible when changing the SSL setting from Disabled to Enabled. The port changes automatically from 389 to 636.

 

Change the SSL CA Certificate to a valid CA certificate where the F5 can check against. The SSL Check Peer option specifies that the system verifies the LDAP server's certificate with the trusted certificates defined with the SSL CA Certificate option.

 

Results

The configuration is now using LDAPS. Try to login with your AD credentials. Capturing this traffic shows that the connection is being encrypted.

 

What if the authentication fails?

  1. Check the root CA certificate
    2. Verify if intermediate devices, like a firewall, are blocking the connection
    3. Check the logs: /var/log/audit and /var/log/secure
    4. Take a packet capture, make sure you can decrypt this traffic.
    5. Use ldapsearch and/or adtest

New LDAP Configuration

Check the Root CA Certificate

The configuration requires the root CA certificate where the F5 can check against. Before changing the LDAP configuration, check if the certificate is listed in the certificate list under System > Certificate Management > Traffic Certificate Management > SSL Certificate List

 

If the root CA certificate is not listed, upload the certificate via the import button.

Configure Remote Authentication using LDAPS

By default, the F5 is using local authentication. To enable Remote Authentication, go to System > Users > Authentication

 

There are a number of options to enable LDAPS authentication.

  1. Host: the LDAP database that the F5 will use for remote authentication.
  2. Port: For LDAPS, port 636 should be used. This is set by default when enabling SSL.
  3. Remote Directory Tree: the file location of the user authentication database in the remote directory tree of the LDAP server.
  4. Scope: the level of the remote LDAP directory that the system should search for the user authentication. When the scope is set to Sub, the system searches all subdirectories of the LDAP.
  5. Bind: the distinguished name for binding to the LDAP server.
  6. SSL: whether the system uses an SSL port to communicate with the LDAP server. If you enable this setting, the port number changes automatically to 636, and the page presents additional options for specifying SSL certificate-related values.
  7. SSL CA Certificate: the name of an SSL certificate from a certificate authority (CA).
  8. SSL Check Peer: that the system verifies the LDAP server's certificate with the trusted certificates defined with the SSL CA Certificate option. An SSL session is established only if a valid server certificate from a trusted CA is presented by the LDAP server.

Results

The configuration is now using LDAPS. Try to login with your AD credentials. Capturing this traffic shows that the connection is being encrypted.

 

What if the authentication fails?

  1. Check the root CA certificate
  2. Verify if intermediate devices, like a firewall, are blocking the connection
  3. Check the logs: /var/log/audit and /var/log/secure
  4. Take a packet capture, make sure you can decrypt this traffic.
  5. Use ldapsearch and/or adtest

Authentication via Access Policy Manager (APM)

Existing LDAP Configuration

To see which policy is still using LDAP, go to Access > Authentication > LDAP.

This list does not show you which object is using which type of LDAP. This can only be seen when you open the object itself:

 

When using LDAP, the information is visible in plain text.

The following APM policy is a quite simple example:

Corrective Actions

Change the LDAP configuration

Create an extra LDAP object with the same configuration, but change the LDAP mode from LDAP to LDAPS. In this scenario, we use the default server SSL profile. Another profile can be used, this has to be created first under Local Traffic > Profiles > SSL > Server.

Once this object is created, you must change the APM policy to use the correct LDAP server. In a simple policy or a policy where macros are used, you can create an extra branch. In this way, you can test the LDAPS connection first, before deleting the old LDAP configuration.

Another possibility would be to create a test virtual server which references a copy of your current APM policy. In this test policy, you can test everything before changing a production environment.

Results

The configuration is now using LDAPS. Try to login with your AD credentials. Capturing this traffic shows that the connection is being encrypted.

What if the authentication fails?

  1. Verify if intermediate devices, like a firewall, are blocking the connection
  2. Check the logs: /var/log/apm
  3. Take a packet capture, make sure you can decrypt this traffic.
  4. Use ldapsearch

New LDAP Configuration

Configure Remote Authentication using LDAPS

Create an extra LDAP object with the mode setting configured to LDAPS. In this scenario, we use the default server SSL profile. Another profile can be used, but has to be created first under Local Traffic > Profiles > SSL > Server.

There are a number of options to configure for LDAPS authentication.

  1. Server Connection: select Use Pool even if you have only one LDAP server.
  2. Server Pool Name: type a name for the AAA server pool.
  3. Server Addresses: the IP address(es) of the LDAP server(s).
  4. Mode: select LDAPS. This will automatically change the port to 636.
  5. Admin DN: type the distinguished name (DN) of the user with administrator rights.
  6. SSL Profile (Server): select an SSL server profile. You can select the default profile, serverssl, if you do not need a custom SSL profile.

 

Create or modify an APM policy referencing the LDAP object in LDAP Auth or LDAP Query.

In the LDAP Auth object, you specify which LDAP server you want to use.

Results

The configuration is now using LDAPS. Try to login with your AD credentials. Capturing this traffic shows that the connection is being encrypted.

What if the authentication fails?

  1. Verify if intermediate devices, like a firewall, are blocking the connection
    2. Check the logs: /var/log/apm
    3. Take a packet capture, make sure you can decrypt this traffic.
    4. Use ldapsearch

References:

https://support.f5.com/csp/article/K11072

https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-access-policy-manager-authentication-methods-14-1-0/ldap-and-ldaps-authentication.html#GUID-4A8CA973-9AFC-421C-8C39-988EE589DA04

 

Incident Response Hotline

Facing cyber incidents right now?

Contact our 24/7/365 world wide service incident response hotline.