Problem

Trino Gateway uses the Apache Directory LDAP client for form/basic LDAP authentication. When the LDAP user search base is narrow, for example an OU-specific base such as OU=Users,DC=example,DC=com, authentication works as expected.

However, in Active Directory deployments it is common to search from a broader base such as DC=example,DC=com so users can be found across multiple OUs or naming contexts. In that case, AD can return LDAP referrals. Gateway currently uses the LdapConnectionTemplate convenience search/authenticate overloads, which create a SearchRequest with the default referral behavior. When referrals are returned, authentication or authorization lookup can fail with errors like:

CursorLdapReferralException
ERR_13100_FAILURE_ON_UNDERLYING_CURSOR

Use case

Gateway should support LDAP deployments where users may exist in different OUs or naming contexts without failing just because the LDAP server returns referrals during user search.

Proposed solution

Add a Gateway LDAP configuration option for referral handling, for example:

ldapReferralPolicy: THROW

Supported values:

THROW
FOLLOW
IGNORE

THROW should remain the default to preserve the existing behavior for users who do not configure the new setting.

Implementation-wise, Gateway can build an explicit Apache Directory SearchRequest for LDAP user searches, apply the configured referral policy with followReferrals() or ignoreReferrals(), and then execute the request through the request-based LdapConnectionTemplate overloads for both authentication and group membership lookup.

Benefits

• Preserves backward compatibility by defaulting to the current behavior.
• Allows Active Directory users to opt into following referrals when using broader search bases.
• Keeps referral behavior centralized in Gateway's LDAP client wrapper instead of spreading it across call sites.
• Provides an explicit configuration surface for deployments that prefer to ignore referrals rather than chase them.