In a multi-domain Active Directory forest with bidirectional trust, we're observing unexpected LDAP referral behavior where domain controllers return referrals pointing to non-AD controlled domains. The specific case involves:

Domain: ad.company.com.au
Referral: company.com.au (not AD-controlled)

This occurs when querying standard LDAP ports (389) but works correctly via Global Catalog (3268). The key observations:

• Both domains in same forest: company.local and ad.company.com.au
• DNS delegation exists from company.com.au to ad.company.com.au
• Standard LDAP queries return referral to parent domain
• GC queries return expected results

The issue stems from how the domain naming context is registered in Active Directory. When a domain controller receives an LDAP query for a partition it doesn't host, it will return a referral. In this case, the DC seems to be misidentifying its own domain as requiring a referral.

Common causes include:

1. Incorrect DNS configuration for the AD domain
2. Missing or incorrect service principal names (SPNs)
3. Forest-wide naming context misconfiguration
4. Cross-domain trust configuration issues

First, verify the domain naming contexts with:

nltest /dsgetdc:ad.company.com.au
repadmin /showrepl

Then check DNS registration:

nslookup -type=SRV _ldap._tcp.ad.company.com.au

Here's the step-by-step resolution:

# 1. Verify and correct DNS delegation
dnscmd /zoneadd ad.company.com.au /DsPrimary

# 2. Ensure proper SPN registration
setspn -L DC01.ad.company.com.au

# 3. Force replication of naming contexts
repadmin /syncall /A /e /q

# 4. Modify LDAP query to use GC port
ldapsearch -x -h 172.xx.xx.11:3268 -b DC=company,DC=com,DC=au -D my.username@ad.company.com.au -W

For applications that can't use GC port:

# Use chase referrals option in LDAP queries
ldapsearch -x -h 172.xx.xx.11 -b DC=company,DC=com,DC=au -D my.username@ad.company.com.au -W -R -M

# Or specify the full domain DN
ldapsearch -x -h 172.xx.xx.11 -b DC=ad,DC=company,DC=com,DC=au -D my.username@ad.company.com.au -W

To avoid similar issues during domain migration:

• Complete DNS configuration before creating trust relationships
• Use ADSI Edit to verify naming contexts
• Test LDAP queries from multiple domain controllers
• Monitor replication health during migration

---

During our Active Directory migration from company.local to ad.company.com.au, we encountered a peculiar LDAP referral issue. When querying any Domain Controller in the new domain, we received referrals pointing to company.com.au instead of resolving locally.

# Example of the problematic referral
$ ldapsearch -x -h 172.xx.xx.11 -b DC=company,DC=com,DC=au -D "my.username@ad.company.com.au" -W
# Returns:
# search result
search: 2
result: 10 Referral
text: 0000202B: RefErr: DSID-031007EF, data 0, 1 access points
    ref 1: 'company.com.au'
ref: ldap://company.com.au/DC=company,DC=com,DC=au

The issue stems from DNS delegation and Active Directory partition configuration:

• The ad.company.com.au domain is properly delegated in DNS to our DCs
• However, the Domain Naming Master (forest-wide FSMO role) still contains references to the parent domain
• The Global Catalog works because it contains partial attribute sets from all domains

First, let's check our DNS configuration:

nslookup -type=ns company.com.au
nslookup -type=ns ad.company.com.au

Then verify the domain partitions:

repadmin /showrepl
repadmin /showreps * /v

We implemented these steps to resolve the issue:

1. Update DNS Delegation:

   dnscmd /recordadd company.com.au ad NS dc1.ad.company.com.au
   dnscmd /recordadd company.com.au ad NS dc2.ad.company.com.au

2. Modify Referral Settings:

   # PowerShell script to disable cross-domain referrals
   Import-Module ActiveDirectory
   $rootDSE = [ADSI]"LDAP://RootDSE"
   $rootDSE.Put("msDS-Other-Settings", "DoNotIncludeReferralInResults=TRUE")
   $rootDSE.SetInfo()

3. Force Replication:

   repadmin /syncall /AdeP

For applications that can't wait for the full fix:

# Using LDAP controls to ignore referrals
ldapsearch -x -h 172.xx.xx.11 -b DC=company,DC=com,DC=au \
           -D "my.username@ad.company.com.au" -W \
           -o nettimeout=30 \
           -o ldif-wrap=no \
           -E !::ldap://company.com.au

Or in code (Python example):

import ldap3
server = ldap3.Server('dc1.ad.company.com.au', get_info=ldap3.ALL)
conn = ldap3.Connection(server, user='my.username@ad.company.com.au', password='password', auto_bind=True)
conn.search('dc=company,dc=com,dc=au', '(objectclass=*)', 
            search_scope=ldap3.SUBTREE,
            controls=[ldap3.protocol.microsoft.LDAP_SERVER_REFERRALS_OID(False)])

After implementing the fixes, verify with:

ldapsearch -x -h 172.xx.xx.11 -b DC=company,DC=com,DC=au -D "my.username@ad.company.com.au" -W -LLL dn

Should now return proper entries without referrals.