What are the suggested timer configurations for LDAP during disaster recovery

Large companies can have a mirrored location in the event of a disaster, this is known as a disaster recovery site. This includes the domain controllers and the firewalls, and their RA VPN infrastructure. In case of issues on the primary side, users will be able to connect to the secondary side and perform their tasks, as intended.

This document provides some of the timer configurations for LDAP authentication in those situations.

• Palo Alto Firewalls.
• Supported PAN-OS.
• LDAP Configured.
• Disaster recovery settings for LDAP.

The LDAP authentication, in the Palo Alto Networks firewall implementation is performed directly from the firewall. Any user that tries to connect and authenticates using a GlobalProtect client, will be authorized from the firewall to the LDAP server that is configured in the authentication profile, and used in the GlobalProtect configuration. Usually, every Active Directory (AD) environment will have multiple data centers in the primary location (if one fails the other(s) are up to handle the requests) and one or more data centers in the disaster recovery location. This is necessary so that even if the whole primary location is down (in case of heavy outage) the requests will be handled by the disaster recovery data center(s).

In the Palo Alto Networks firewall(s), this can be achieved by adding multiple AD servers in the LDAP Profile.

In this case, as shown below, two data centers are being used in the main location and one in the disaster recovery location:
GUI:  Device > Server Profiles > LDAP 

The LDAP profile has 3 timer values that need to be defined as the following:

• Bind Time
• Bind Time Limit
• Retry Interval

If adding just the servers, and leaving the default values will not help much in a case of a outage.

Below are short explanations about the timers:

1. The Bind Time is the time the firewalls are waiting for an LDAP connection to be established (LDAP bindRequest to be sent and bindResponse to come back).

• The Bind Time Limit is the value the firewalls are waiting for on the information for the LDAP search to return a result.
• The Retry Interval specifies the interval after which the system will try to connect to the LDAP server after a previous failed attempt.

Using the default values in case of disaster recovery or LDAP outage, can result in failed authentication attempts for GlobalProtect users. This is true, because GlobalProtect authentication requests will time out after 20 seconds. Therefore, if the first LDAP server in the LDAP profile is down, by default, the firewall will wait 30 seconds before going to the next one. Additionally, because the Retry Interval (by default) is not defined, even if the firewall is not able to connect to authenticate one user, it will try to connect for every new request to the same LDAP and will cause all the authentication attempts, for all the users to fail.

Steps

To prevent this scenario, the timer parameters should be changed to appropriate values using the following steps:

1. Change the Bind Time to a lower value, depending on the network latency, bandwidth and server utilization. This connection is usually very fast, but in disaster recovery scenarios (where the disaster recovery location is more than 100 km away) it can take a couple of seconds, so a save value can be around 2-3 seconds.

2. Change the Bind Time Limit to a lower value. This is also usually very fast, but again the same considerations from before are valid, so a save value can also be around 2-3 seconds.

3. Change the Retry Interval to a high value. This way, during an outage, even if the request for the first user to the first server (or first two) fails, the firewall will not attempt to authenticate users to that/those LDAP servers for the configured interval.

4. This value should be configured depending on the usual response times that are defined in the company for the emergency response teams. Usually the save value is 900s. If all the servers are up and running, this timer will never kick in.

Note: Be sure to test the first two timers and change the values according to the tests. If binding and getting the result back takes longer than the defined values, then problems with authentication might be seen, so use values that are best suited for the network.

5. Create an Authentication Profile that uses the defined LDAP profile:
GUI: Device > Authentication Profile

6. As shown in the following screenshots, attach the created Authentication Profile to the GlobalProtect Portal and GlobalProtect Gateway: