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. _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
