Am Mittwoch 21 Dezember 2011, 15:00:24 schrieb John Tobin:
Dear Ralf,
Hi, I hope you are still here before the holidays, I would appreciate your advice and counsel. I have Suse 12.1 up, mile stone 5. It works well.
The final 12.1 release is out since almost 6 weeks, you should really update to that.
I have installed and used ldap 2.4.26. It is also working with nss_ldap code. I am having some trouble on 2 counts. First I tried to get start_tls, and / or ldaps to work in that environment. I have not gotten tls to work. Was this tested at all in SUSE?
yes
TLS is critical to some success in the university lab I am running over here. I have posted the problem to the open ldap crew, and have heard nothing from anyone for solving the problem, or even assistance in how to debug it, or understand the failure I get.....[this is from nss_ldap]
Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls failed:stat=-1 Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept failure error=-1 id=1217, closing Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS negotiation failure) Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls failed:stat=-1
In the middle of this mess Chris wood mentioned this would be easier, and may well work under nslcd.
While nslcd certainly has some advantanges compared to nss_ldap, I can't imagine why switching to nscld would make the base SSL/TLS setup easier.
Does ldapsearch with TLS work for you? Please test as a non-root user. If it doesn't work adding the "-d -1" option might give you a hint why it is not able to connect.
Also check the permissions of the CA certificate, everybody needs read access to them. The server-cert and server-key as to be readable by the user as which slapd is running.
Are you running AppArmor, then make sure that your current profile doesn't block read access to the relevant files.
As you didn't give much details about your configuration I can only give you those general hints. If you think you hit a bug in openSUSE, feel free to open a bug report (with all your relevant configuration files and log files) at bugzilla.novell.com.
OK. I installed nslcd.... I have the lastest I believe: 0.7.13-7.3
I setup nslcd.conf to the best of my ability. With just a : Uri ldap://192.168.0.10/ Base dc=dark,dc=net Scope sub
It works fine. For user jtobin [is only in ldap server] I get a login
But in a similar fashion to nss_ldap, when I turn on ssl start_tls And add to the nslcd.conf above:
Ssl start_tls Tls_reqcert allow Tls_cacertfile /var/lib/ldap/cacert.pem Tls_cert /var/lib/ldap/server.crt Tls_key /var/lib/ldap/server.key
Hm, do you really want to do SSL/TLS client authentication? Otherwise those tls_cert and tls_key settings are unneeded for nss_ldap/nslcd.
It fails.... I get: user jtobin does not exist
But worse... I get nothing in the /var/log/localmessages file for debugging.
Certificates were created using www.opeldap.org/faq/data/cache/185.html Which to my knowledge is the referenced site for openldap The certificate is a self signed cert. Most of my testing at the moment is local.... Client and slapd server are on the same machine, so same certificate file for tls_cacertfile, tls_cert, tls_key, though I have tested on remote clients with the same results.
I see your name on a number of the nslcd doc and email. Help me out here.... How can I get this working / debugged? Who would have some of the information I need? Who would be interested in helping me to get this working.
So far all I have gotten is a number of messages from interested parties asking me if I have gotten to work yet... Drop me aline with some advice as to how to get this resolved, or if it is probably not a short term Priority for anyone, tell me that. I will find a different strategy for securing my lab ldap client and server machines.
[is getting this to work a priority at SUSE?
It works for me (and many others), so it is very likely a configuration issue on your side. If it wouldn't work in general this would certainly a priority for the openSUSE community to fix it.
regards, Ralf