From: Jens V. <je...@da...> - 2005-05-22 12:16:50
|
On May 21, 2005, at 23:26, Michael Str=F6der wrote: >> I was getting the exact same error. I fixed the problem by explicitly >> disabling referral chasing in the OpenLDAP client libraries (for my >> purposes, I didn't care about referrals). >> >> Before you call ldap.initialize, try: >> >> ldap.set_option(ldap.OPT_REFERRALS, 0) >> > > This is good advice since IIRC the OpenLDAP libs chase referrals doing > an anonymous bind. Therefore it's definitely better to get the search > references (check the result type). Sort them out or chase the =20 > referrals > in your Python application. For what it's worth, a long time ago I had the same problems with the =20= LDAPUserFolder Zope product against AD. Among the resultset returned =20 by a query there would always be one record that made everything =20 barf. The (not very clean) workaround has been to special-case that =20 record and discard it. It is a AD-specific referral. Another solution has been to connect to the "Global Catalog" port or =20 somesuch thing. This port apparently gives you a view on the data =20 contained in a forest of AD server instances as one single entity, as =20= opposed to single AD instances handing back references to other AD =20 instances where a record may be found. jens |