Can I load balance LDAP / Active Directory queries?
Short answer
Yes, with an L7 TCP vService. The LDAP (389) and LDAPS (636) ports can be forwarded as they are with the TCP protocol on the frontend; in this method, StartTLS and LDAPS encryption stay on the domain controller, and since the two ports are published in a single vService, Use Frontend Port is turned on in the Backend Services. If LDAPS is to be terminated on TR7, port 636 is published in a separate L7 TCP vService with TCP + TLS and a certificate. Least Connection is used as the algorithm, and a health check of the LDAP or LDAPS type is used for the health check.
Problem: What Should Be Considered in LDAP Traffic?
Applications connect to the domain controllers (DCs) continuously for authentication and directory queries; when a DC goes down, all logins can stop. In LDAP, encryption is done in two ways: StartTLS on port 389 (TLS starts later within the connection) or LDAPS directly on port 636. Whether TR7 terminates the encryption or not also affects the security settings on the DC.
Solution: Two Methods
| Your situation | Suitable method |
|---|---|
| Encryption should stay on the DC; StartTLS and channel binding are used | Method 1: Forwarding as is with TCP |
| The LDAPS certificate should be managed on TR7 | Method 2: Terminating LDAPS on TR7 |
Method 1: Forwarding as Is with TCP Recommended
- How it works TR7 distributes the connections to the DCs and does not touch the encryption; the StartTLS and LDAPS handshake takes place directly between the client and the DC.
- Where it is opened vService → Type: L7 TCP → Frontend 389 and 636 → Protocol: TCP; Backend Service → Use Frontend Port
- Requirement The DCs' own certificates being trusted by the clients
- vService type L7 TCP
- Backend Service side No change is required on the DC. By default, the DC sees the connections as coming from TR7's IP; if the client IP is required in the audit records, SNAT → Use Client IP is selected on the Backend Service and the DC's return traffic is routed through TR7.
Step-by-Step Configuration
On the Load Balancer → Profiles → Health Checks screen, the Add button is clicked (how to add).
Name is entered and LDAP is selected as the Check Type; if logging in with a service account is also to be checked, LDAP Authentication is turned on and the username and password are entered.
The Add button at the bottom of the form is clicked.
On the Load Balancer → Backend Services screen, the Add button is clicked (How is a Backend Service added; which information is required?).
Backend Service Name and Address (e.g. 192.0.2.70:389) are entered; in the Health Check field, the profile created in steps 1–3 is selected.
In the Details section of the same form, Use Frontend Port is turned on; in this way, a connection arriving at 389 goes to the DC's 389, a connection arriving at 636 goes to its 636, and the port in Address is not used.
The Add button (Edit for an existing Backend Service) at the bottom of the form is clicked. Steps 4–7 are repeated for each DC.
The Load Balancer → Load Balancer vService List → Add steps are followed; Name is entered and L7 TCP is selected as the Type.
Two rows with the same IP are added to the Frontend table: 389 / TCP and 636 / TCP. If the IP is not in the list, it is first added with Network → Interfaces → Actions → Add IP (Why can't I type the Frontend IP manually; what should I do to use an IP that is not in the list (e.g. IPv6) on a vService?).
In the Default Backend Services table, the Backend Services added in steps 4–7 are selected.
The Details switch at the top right of the form is turned on; in the Algorithm field in the LB Algorithm box, Least Connection is selected.
The Save button is clicked. In a cluster setup, the change is also transferred to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.
Verification
ldapsearch -H ldap://203.0.113.60 -ZZ -x -D "user@corp.example" -W -b "dc=corp,dc=example" "(sAMAccountName=test)"The user record is returnedThe distribution of the connections to the DCs is seen on the vService Sessions screen of the vService.
The 389 and 636 connections are spread across the healthy DCsMethod 2: Terminating LDAPS on TR7
- How it works TR7 terminates TLS on port 636 with its own certificate and forwards the query to the DCs.
- Where it is opened A separate L7 TCP vService → Frontend 636 → Protocol: TCP + TLS → Certificate
- Requirement A valid certificate for the LDAPS name uploaded to TR7; channel binding not being mandatory on the DC
- vService type L7 TCP
- Backend Service side TR7 can connect to the DC with unencrypted LDAP (389); if the query must also go to the DC encrypted, the address of the Backend Service is set to the DC's port 636 and SSL Service is turned on.
Step-by-Step Configuration
If the certificate for the LDAPS name is not on TR7, it is uploaded with Certificates & PKI → SSL/TLS Certificates → Add (How do I upload my certificate to TR7; which formats are supported?).
On the Load Balancer → Backend Services screen, the Add button is clicked for a new Backend Service; an existing Backend Service can also be edited by selecting it and clicking the Edit button.
For unencrypted forwarding, the Address is the DC's port 389; if the connection to the DC is also to be encrypted, the Address is set to 636 and SSL Service is turned on. Since this vService listens on a single port, Use Frontend Port stays off.
The Add button (Edit for an existing Backend Service) at the bottom of the form is clicked. Steps 2–4 are repeated for each DC.
The Load Balancer → Load Balancer vService List → Add steps are followed; Name is entered and L7 TCP is selected as the Type. If the same IP as the vService in Method 1 is to be used, the 636 row is first removed from that vService; the same IP:port cannot be used in two vServices.
In the Frontend row, the IP is selected, the port is set to 636 and TCP + TLS in the Encrypted (TLS) group is selected as the Protocol.
In the Certificate field that appears, the certificate for the LDAPS name is selected. A TCP + TLS row saved without a certificate listens as unencrypted TCP.
In the Default Backend Services table, the Backend Services prepared in steps 2–4 are selected.
The Save button is clicked. In a cluster setup, the change is also transferred to the peer device with the default auto-sync.
Verification
openssl s_client -connect 203.0.113.60:636 -servername ldap.corp.exampleThe certificate uploaded to TR7 is seenCommon Mistakes
- Not turning on Use Frontend Port (Method 1). While 389 and 636 are in the same vService, the single port in the Address of the Backend Service is used; LDAPS connections go to the DC's LDAP port.
- Selecting TCP + TLS on 389. StartTLS starts TLS later within the connection; it cannot be terminated on TR7. 389 is always forwarded with TCP.
- Terminating LDAPS while channel binding is mandatory. If LDAP channel binding is mandatory on the DC, connections terminated on TR7 can be rejected; in this case, Method 1 is used.
- Not assigning a health check. A DC that has gone down continues to receive connections if there is no health check, and logins fail.
How it is done in the documentation
