LDAP Authentication Delays - Decommissioned Trusted Domain

Modified on Tue, 2 Jun at 1:23 PM

SYMPTOMS

Netop connections time out or are denied after a 2–3 minute delay

The nhostw.log shows the same stall on every auth attempt:

Ap_LDAP_VP_TU=0x0

↓ ~46 seconds

Ap_LDAP_FOCDN=0x0

↓ ~31 seconds

Ap_LDAP_VP_ClassDNName resolved

↓ ~78 seconds

SQL: rqe0x0 (connection denied)

Delay is identical regardless of port (389 or 636) or whether DC is specified by hostname or IP

Password is validated successfully but connection is still denied

WHAT'S HAPPENING

Netop performs three LDAP bind operations for every connection attempt. During the third bind, it retrieves the authenticating user's full group membership list (memberOf).

If any group in that list belongs to a trusted domain that has been decommissioned or taken offline, Windows' LDAP client automatically tries to contact that domain's DC to resolve the group reference. When the DC is unreachable, it hangs until the referral timeout expires — 46 to 78 seconds per phase — before moving on.

This happens on every connection attempt, making authentication too slow to complete before the client times out.

Bind Phase	Typical Stall
Service acct bind	~46 sec
User DN lookup	~31 sec
Group membership	~78 sec

⚠ Common Misconception: NSS:LDAP_NEST_LEVELS=0 does not prevent this issue. That setting only controls recursive group-in-group expansion depth. It does not stop the LDAP client from chasing referrals to foreign domains found in a user's direct memberOf list.

RESOLUTION

Fix 1 — Clean up AD (Permanent)

Remove all users from groups whose DN belongs to the decommissioned domain. Delete those group objects from AD. Once no user's memberOf contains a reference to the offline domain, the referral chase cannot occur.

Fix 2 — Dead DNS zone (Fast-fail workaround)

Create an empty DNS zone for the decommissioned domain on your internal DNS servers. Referral lookups will return NXDOMAIN instantly instead of timing out, restoring normal auth performance while longer-term fixes are arranged.

ALSO CHECK

Missing Access Rules (rqe0x0)

Even after fixing the LDAP delay, connections will still be denied if no access rules exist in the Netop Security Server database for the user's groups. In the Security Manager console, create an access rule mapping the appropriate LDAP group to the target hosts.

LDAP Service Account Format

For LDAPS (port 636), the service account userdn must be specified as a full Distinguished Name:

CN=svc_netop,OU=Service Accounts,DC=corp,DC=example,DC=com

Using NetBIOS format (DOMAIN\svc_netop) can cause additional bind delays on some DC configurations.

ACECLNT Load Errors

If the log shows ACECLNT load failed at startup, the RSA SecurID ACE Agent client library is missing. This is harmless if RSA two-factor auth is not in use, but should be noted if any access rules require RSA authentication.

Port 636 vs 389

When using LDAPS (port 636), always specify the DC by hostname — not IP address. The DC's TLS certificate contains its hostname in the Subject/SAN fields. Connecting by IP causes certificate validation to fail. Use port 636 with hostname for encrypted LDAP.