Hide Forgot
The code below works perfectly on RHEL 6.2, and gives the expected results: import ldap, ldap.sasl auth = ldap.sasl.gssapi("") ldap_connection = ldap.initialize("ldap://<ldapserver>") ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,'<path/to/ca.crt>') ldap_connection.start_tls_s() ldap_connection.sasl_interactive_bind_s("",auth) ldap_connection.search("dc=redhat,dc=com", ldap.SCOPE_SUBTREE, "uid=mteixeir", ["uid", "cn"]) The same code above throws the following error on Fedora 16: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 505, in search_st return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 495, in search_ext_s msgid = self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 491, in search_ext timeout,sizelimit, File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"} This was working fine until a couple of weeks ago. I am not sure exactly what has been updated on the system (or when) that broke it. RHEL 6.2 packages: python-2.6.6-29.el6.x86_64 python-ldap-2.3.10-1.el6.x86_64 cyrus-sasl-gssapi-2.1.23-13.el6.x86_64 Fedora 16 packages: python-2.7.2-5.2.fc16.x86_64 python-ldap-2.3.12-2.fc15.x86_64 cyrus-sasl-gssapi-2.1.23-27.fc16.x86_64
Additional info: If you have this set of packages installed, it DOES work: cyrus-sasl-2.1.23-27.fc16.x86_64 cyrus-sasl-gssapi-2.1.23-27.fc16.x86_64 cyrus-sasl-lib-2.1.23-27.fc16.x86_64 cyrus-sasl-md5-2.1.23-27.fc16.x86_64 cyrus-sasl-plain-2.1.23-27.fc16.x86_64 nspr-4.8.8-4.fc16.x86_64 nss-3.12.10-7.fc16.x86_64 python-2.7.2-5.2.fc16.x86_64 python-ldap-2.3.12-2.fc15.x86_64 If you update nss to nss-3.13.1-9.fc16.x86_64, it will break.
https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c126
Kamil, I tested, and it works, but I'm still not convinced. If I run this: $ NSS_SSL_CBC_RANDOM_IV=0 python >> (copy/paste script) It works. However I notice that both /usr/lib64/python2.7/site-packages/_ldap.so and /usr/bin/ldapsearch, even though in different entry points, but still ldapsearch works just fine without the nss parameter. $ ldd /usr/lib64/python2.7/site-packages/_ldap.so | grep nss libnss3.so => /usr/lib64/libnss3.so (0x00007fb30a060000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007fb309e3a000) $ ldd /usr/bin/ldapsearch | grep nss libnss3.so => /usr/lib64/libnss3.so (0x00000033a3e00000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x00000033a2200000) The LDAP server is running openldap-2.3.43-12.el5_7.9 on RHEL 5.7 Please advise.
If you are able to repeat the failure using the openldap API directly, then it is probably a bug in the openldap package.
I have no idea how use the OpenLDAP API. C, maybe? I don't know how to code for LDAP using C.
What is the LDAP server you are trying to connect?
I switching the component to openldap as both server and client run openldap.
Kamil, Are you sure that's the best decision? The issue was caused by an nss update, not an openldap update.
The nss update broke many things. This is known issue: https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c124 https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c129
Created attachment 551160 [details] reproducer in C equivalent code in C, compile with: # gcc -g -lldap -o bz771421 bz771421.c
The C reproducer returns success. But I still think that /usr/lib64/python2.7/site-packages/_ldap.so is calling a different function, or using different parameters.
Comment on attachment 551160 [details] reproducer in C invalid
(In reply to comment #13) > The C reproducer returns success. Well, you are right. However I can confirm that the issue is present on F16 with: LDAPTLS_CACERT=cacert.pem ldapsearch -ZZ -Y GSSAPI -H ldap://ldap-server "(cn=foo)"
nss-3.13.1-10.fc16 from updates-testing sets NSS_SSL_CBC_RANDOM_IV=0 by default, but OpenLDAP should be fixed anyway
Is it really the client what needs to be fixed? In case of curl, the fix landed to an embedded testing server in the end. I am asking as the server used in this bug report does not run on Fedora according to the information I was given.
Actually, I didn't have time to investigate it much and I do not understand the NSS fix yet. If this is a problem on server side, OpenLDAP server will need to be fixed. If the problem is in the crypto backend on the server side, then we can probably do anything.
I confirm nss-3.13.1-10.fc16.x86_64 from updates-testing works. So far I have not verified anything else funny. Everything that was working before still works, and python-ldap works fine now.
FYI: perhaps the information in this bz might be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=800787
Hmm, seems to be fixed for OpenLDAP. NSS_SSL_CBC_RANDOM_IV=1 makes no difference in F17.