Enable ldap_raise_on_search_error by default

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Collaborate/take over this issue

Summary

The ops feature flag ldap_raise_on_search_error has been default_enabled: false since it was introduced in GitLab 18.10 by !226913 (merged). This issue tracks enabling it by default.

The flag guards the fix from #6054 (closed) ("Introduce additional connection logic to LDAP so groups don't lose membership unnecessarily"). With the flag off, that fix is inert, so every self-managed instance still runs the original behavior unless an administrator knows to turn the flag on.

Behavior being enabled

Gitlab::Auth::Ldap::Adapter#check_empty_response_code inspects the LDAP result code when a search returns no entries.

With the flag disabled (today's default), a result code outside NON_ERROR_LDAP_RESPONSE_CODES (10 referral, 32 no-such-object) logs a warning and ldap_search returns []. An empty result is indistinguishable from a failed search, which leads to:

• Gitlab::Auth::Ldap::Access#find_ldap_user returning nil, so access.rb:60 runs block_user(user, 'does not exist anymore').
• Group sync treating the group as having no members and removing them.

With the flag enabled, the same condition raises Net::LDAP::Error, which ldap_search retries and then converts to LdapConnectionError. That error is rescued by every consumer:

Consumer	Behavior on error
lib/gitlab/auth/ldap/access.rb:63	allowed? returns false, denying the request without blocking the user
ee/lib/ee/gitlab/auth/ldap/sync/group.rb:45,70	Aborts the sync, calls fail_ldap_sync, emits an audit event, leaves memberships intact
ee/lib/ee/gitlab/auth/ldap/sync/users.rb:41	Aborts the sync

Why this was not already enabled

The flag was introduced disabled, as required for new flags. The author has since left the project, and because ops flags have no rollout issue and no cleanup deadline, nothing in the feature flag lifecycle surfaced it. The rollout_issue_url field in the definition is empty, and the milestone field was never refreshed, so the 12-month ops flag re-evaluation never happened.

Proposal

1. Set default_enabled: true and refresh milestone to the current release.
2. Keep the flag as an ops kill-switch so an administrator whose directory legitimately returns a non-success result code can restore the old behavior.
3. Document the behavior and the kill-switch in the LDAP administration docs, which currently do not mention the flag at all.

Rollback

Disable the flag:

Feature.disable(:ldap_raise_on_search_error)

Verification

No GitLab.com rollout applies: LDAP is GitLab Self-Managed only. Validation is the existing spec coverage in spec/lib/gitlab/auth/ldap/adapter_spec.rb, which exercises both flag states, plus the consumer specs for Gitlab::Auth::Ldap::Access and the LDAP sync services.