Re: LDAP search fails with referral enabled

Xu, Qiang (FXSGSC) wrote:
> 
> If referral is disabled, our printer can do LDAP queries without any
> problem. However, if the referral option is enabled, and the server
> is pointed to some ADS, which at the same time is a domain server,
> the search will fail.

Why do you want to enable referral chasing?

> Looking at the network trace, I found the initial search is successful, and the result is bounced back from the server. However, in the result packet, there are three pieces of referral information:
> =================
> ldap://ForestDnsZones.otsg.crmt.801/DC=ForestDnsZones,DC=otsg,DC=crmt,DC=801
> ldap://DomainDnsZones.otsg.crmt.801/DC=DomainDnsZones,DC=otsg,DC=crmt,DC=801
> ldap://otsg.crmt.801/CN=Configuration,DC=otsg,DC=crmt,DC=801
> =================
> This will lead to 3 following anonymous searches, which will fail. The error is "000004DC: LdapErr: DSID-0C0906DD, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1771". However, the error code is 85 in the log, meaning LDAP_TIMEOUT.

Yes, that's the default behaviour of most LDAP client libs for automatic
referral chasing. Obviously it's wrong.

Letting the LDAP client chase referrals is a fundamentally broken
concept in LDAPv3 anyway because there is no clear definition at all
which credentials the client should use when chasing the referral.

Speaking of AD as a LDAPv3 implementation with a certain profile or
additional assumptions the client could use the same credentials he used
to bind to the originating server. I think that's the way the AD
developers thought about it in the light of domain trusts etc. But again
that's not a valid assumption in general for a LDAP client application.
In general the application has to be configured with a-priori knowledge
how to bind to the referral's target.

Ciao, Michael.