Frequently Asked Questions

Q: Is python-ldap yet another abandon-ware project on SourceForge?

A1: "Jump on in."
A2: "Jump into the C ;-)"
A3: CHANGES
Q: Can I use LDAPv2 via python-ldap?

A: Yes, by explicitly setting the class attribute protocol_version.
Q: Can python-ldap be built against OpenLDAP 2.2 libs or older?

A: No, OpenLDAP 2.3 or newer is required. Patched builds of python-ldap linked to older libs are not supported by the python-ldap project.
Q: Can python-ldap 2.x be built against Netscape, Mozilla or Novell libs?

A: Nope.
Q: During build there are warning messages displayed telling Lib/ldap.py and Lib/ldap/schema.py are not found:
```
warning: build_py: file Lib/ldap.py (for module ldap) not found
warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) not found
```
A: ldap and ldap.schema are both module packages (directories containing various sub-modules). The messages above are falsely produced by DistUtils. Don't worry about it.
Q: My binary version of python-ldap was build with LDAP libs 3.3. But the python-ldap docs say LDAP libs 2.x are needed. I'm confused!

A: This is a rather long story:
E.g. some Win32 DLLs floating around for download are based on the old Umich LDAP code which is not maintained anymore for a couple of years. Last Umich 3.3 release was 1997 if I remember correctly.
The OpenLDAP project took over the Umich code and started releasing OpenLDAP 1.x series mainly fixing bugs and doing some improvements to the database backend. Still only LDAPv2 was supported at server and client side. (Many commercial vendors also derived their products from the Umich code.)
OpenLDAP 2.x is a full-fledged LDAPv3 implementation. Still it has its roots in Umich code but has many more features/improvements.
You cannot compile recent python-ldap 2.x against old Umich 3.3 or OpenLDAP 1.x libs.
Q: Does it work with Python (1.5|2.0|2.1|2.2)?

A: The basic modules ldap and ldif should still work with Python 1.5 but python-ldap is not tested thoroughly with this version anymore. Any other version since 2.0 should not be a problem at all.
Q: Does it work with Windows 32?

A: You can find links to pre-compiled packages for Win32 on the download page.
Q: While importing module ldap there are undefined references reported. Error message looks similar to this:
```
Traceback (most recent call last):
  File "./ldap_connect", line 7, in ?
    import _ldap
ImportError: /usr/local/lib/libldap.so.2: undefined symbol: res_query
```
A: Especially on Linux systems you might have to explicitly link against libresolv. Tweak setup.cfg to contain this line:
```
libs = lber ldap resolv
```
Q: While importing module ldap some shared lib files are not found. Error message looks similar to this:
```
    import ldap
  File "/usr/local/lib/python2.1/site-packages/ldap/__init__.py", line
5, in ?
    from _ldap import *
ImportError: ld.so.1: /usr/local/bin/python: fatal: liblber.so.2: open
failed: No such file or directory
```
A1: You need to make sure that the path to liblber.so.2 and libldap.so.2 is in your LD_LIBRARY_PATH environment variable.

A2: Alternatively if you're on Linux you can add the path to liblber.so.2 and libldap.so.2 to /etc/ld.so.conf and invoke ldconfig afterwards.
Q: My code imports module _ldap. That used to work but with recent version 2.0.0pre that does not work anymore?

A: Despite some outdated programming examples the extension module _ldap SHOULD NOT be imported directly. Import ldap instead which is a Python wrapper around _ldap providing the full functionality.
Q: python-ldap build with OpenLDAP libs prior to 2.1.3 and the following error happens during import:
```
ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined symbol:
ldap_first_reference
```
A: In older OpenLDAP versions libldap_r was not complete. Either try to build against (not re-entrant) libldap or use a newer OpenLDAP version (see also OpenLDAP ITS#1922).
Q: My script bound to MS Active Directory but a a search operation results in an exception ldap.OPERATIONS_ERROR with the diagnostic messages text "In order to perform this operation a successful bind must be completed on the connection.".
What's happening here?

A: When searching from the domain level MS AD returns referrals (search continuations) for some objects to indicate to the client where to look for these objects. Client-chasing of referrals is a broken concept since LDAPv3 does not specify which credentials to use when chasing the referral. Windows clients are supposed to simply use their Windows credentials but this does not work in general when chasing referrals received from and pointing to arbitrary LDAP servers.
Therefore per default libldap automatically chases the referrals internally with an anonymous access which fails with MS AD.
So best thing is to switch this behaviour off:
l = ldap.initialize('ldap://foobar') l.set_option(ldap.OPT_REFERRALS,0)