Ok, I now have time to work on this. Please find ldap.conf, /etc/openldap/slapd/cn=config.ldif, and nslcd.conf attached. I am running slapd /openldap 2.4.26 /w nslcd on suse 12.1 mile post 5 Ldap is up and running, without tls. My job here is to get tls running. It was mentioned that nslcd maybe a good possibility for fixing my tls/ssl problems, so I have installed it. I am not sure I have it configured correctly, I have not been able to find much documentation on it besides the nslcd.conf information, so I have setup nslcd.conf in a way I thought reasonable, and made the necessary changes to nsswitch.conf. I am open to further configuration changes if those are required. I used the 185.html for creating certificates, all testing at the moment is being done on a single machine [nightmare.dark.net] which has both slapd and nslcd running on it, so it is the test base for both the server and the client. Ldapsearch still works well with the -ZZ option, for tls. There is an ldap browser for SuSe that also works under tls. I assume from this that the server slapd is working correctly. I am unable to get an ldap client using tls to work under this configuration. Any suggestions or assistance to help resolve the problem would be appreciated. Using nscd, and simple ldap.conf, I captured the logs involved in both the successful ldapsearch, and the unsuccessful client attempts to use slapd [see below.] Sincerely, tob On 11/1/11 11:53 AM, "John Tobin" <jtobin@po-box.esu.edu> wrote: > Certificates verify. > That's a neat tool, put that information somewhere useful. > I had been trying to prove that the certificates were good for a long time. > > I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd > > That wasn't too bad. > > I configured nslcd with: > > Uri ldap://nightmare.dark.net:389/ > > Base "dc=dark,dc=net" > > Ssl start_tls > Tls_req never > Tls_cacertfile /var/lib/ldap/cacert.pem > > Tls_cert /var/lib/ldap/server.pem > Tls_key /var/lib/ldap/server.key > > Ldapsearch still works .... With -ZZ > > But su - jtobin > Gets the same error message this time from kdeinit: > > nightmare:/var/log # tail -f messages |grep tls > Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls > failed:stat=-1 > Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls > failed:stat=-1 > > I guess I am wondering if I configured something wrong.... > Why am I seeing nss-ldap in here... > > I installed nslcd, configured it, and didn't change any thing in ldap.conf > or nsswitch.conf, should anything else be changed? > > tob > > > nighttrain:~ johntobin$ > > > > > > > > On 10/28/11 12:08 PM, "Christopher Wood" <christopher_wood@pobox.com> wrote: > >> Cheap advice inline. >> >> On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote: >>> Folks, >>> >>> I have openldap up, it supports vsftpd, sshd, and 5 client linux machines >>> for remote login. >>> >>> I would like to get tls working. I would support either ldaps [port 636], >>> or the tls available on port 389, I am aware of the differences in >>> implementation, and the fact that an administrator effectively has to >>> make >>> a decision to support one or the other in most cases. >>> >>> Currently: >>> I have slapd running configured for tls under ldap [std port 389]. >>> I am testing it on the slapd machine, with a client on the same machine. >>> I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and >>> ldap.conf. >>> >>> With that in place, and the ldap.conf below: >>> nightmare:/etc # cat ldap.conf >>> >>> base dc=dark,dc=net >>> uri ldap://nightmare.dark.net >>> # scope sub >>> # binddn "cn=admin,dc=dark,dc=net" >>> # bindpw jackie >>> bind_policy soft >>> # The user ID attribute (defaults to uid) >>> pam_login_attribute uid >>> pam_lookup_policy yes >>> pam_password exop >>> nss_schema rfc2307bis >>> tls_reqcert never >>> pam_filter objectClass=posixAccount >>> ldap_version 3 >>> nss_map_attribute uniqueMember uniqueMember >>> ssl start_tls >>> tls_cacert /var/lib/ldap/cacert.pem >>> tls_cert /var/lib/server.crt >>> tls_key /var/lib/ldap/server.key >>> >>> I have run ldapsearch: >>> nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b >>> "dc=dark,dc=net" -Z >> >> Always test starttls with -ZZ, so if your starttls isn't working the >> connection will fail. >> >>> ldap_initialize( ldap://nightmare.dark.net:389/??base ) >>> filter: (objectclass=*) >>> requesting: All userApplication attributes >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base <dc=dark,dc=net> with scope subtree >>> # filter: (objectclass=*) >>> # requesting: ALL >>> # >>> >>> # dark.net >>> dn: dc=dark,dc=net >>> dc: dark >>> o: dark >>> objectClass: organization >>> objectClass: dcObject >>> >>> # admin, dark.net >>> dn: cn=admin,dc=dark,dc=net >>> objectClass: organizationalRole >>> cn: admin >>> >>> # Default Policy, dark.net >>> dn: cn=Default Policy,dc=dark,dc=net >>> objectClass: namedObject >>> objectClass: pwdPolicy >>> cn: Default Policy >>> >>> # People, dark.net >>> dn: ou=People,dc=dark,dc=net >>> objectClass: organizationalUnit >>> ou: People >>> description: People is used in mapping the /etc/passwd entries >>> >>> # jtobin, People, dark.net >>> dn: uid=jtobin,ou=People,dc=dark,dc=net >>> uid: jtobin >>> cn: John C. Tobin >>> objectClass: account >>> objectClass: posixAccount >>> objectClass: top >>> objectClass: shadowAccount >>> loginShell: /bin/ksh >>> uidNumber: 5000 >>> gidNumber: 100 >>> homeDirectory: /home/jtobin >>> gecos: John C. Tobin >>> >>> # defaultDNS, dark.net >>> dn: cn=defaultDNS,dc=dark,dc=net >>> cn: defaultDNS >>> objectClass: top >>> objectClass: suseDnsConfiguration >>> suseDefaultBase: ou=DNS,dc=dark,dc=net >>> >>> # DNS, dark.net >>> dn: ou=DNS,dc=dark,dc=net >>> objectClass: top >>> objectClass: organizationalUnit >>> ou: DNS >>> >>> # search result >>> search: 3 >>> result: 0 Success >>> >>> # numResponses: 8 >>> # numEntries: 7 >>> >>> nightmare:~ # >>> ##### >>> >>> So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with >>> tls >>> works. >>> [I looked through the message output in /var/log/message and see the >>> ³STARTTLS² and ³TLS established tls_ssf=256²] >>> I have done a number of similar ldapsearches. This appears to work >>> correctly. >>> >>> On the client machine I now do : >>> >>> nightmare:/media # su - jtobin >>> su: user jtobin does not exist >>> nightmare:/media # >>> >>> /var/log/message - output...... >>> >>> nightmare:/var/log # tail f |grep I tls >>> >>> 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 >> >> Augh. If you can stop using nscd all this will be much easier for you. I >> personally like nslcd rather than nss-ldap, but each to their own. >> >> If not, restart nscd before you start every troubleshooting round. >> >>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept >>> failure error=-1 id=1218, closing >>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS >>> negotiation failure) >> >> First I would test that all the CA certs and server certs in use are >> understandable by each other. Does the server cert on the machine running >> slapd validate against the CA cert on the machine running ldapsearch? Does >> the >> server cert on the machine running slapd validate against the CA cert on the >> client machine? >> >> openssl verify -CAfile cacert.pem servercert.pem >> >> If the output says "ok" then the actual cert part is fine. >> >> At this point I would crank up the slapd debug level (run it in the >> foreground) and match it again your ldap client debug logs. See if you can >> reproduce the error above using a client like ldapsearch, using the same >> search parameters as the nss-ldap client would use. >> >>> [if you want more of the log, I can obviously get it, but these appear to >>> be the important parts.] >>> >>> This is probably a configuration error, or a logical / architecture >>> misunderstanding, ok, I ?m a newbie. >>> Do I have certificates incorrectly generated? [certificates were >>> generated >>> via [1]http://www.openldap.org/faq/data/cache/185.html]. >>> What did I do wrong? >>> >>> This is running openldap 2.4.26 off of Suse 12.1 milestone 5. >> >> I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but >> much the same thing. >> >>> Thanks in advance. >>> tob >>> >>> References >>> >>> Visible links >>> 1. http://www.openldap.org/faq/data/cache/185.html >> > >
Attachment:
nslcd.conf
Description: Binary data
Attachment:
ldap.conf
Description: Binary data
Attachment:
cn=config.ldif
Description: Binary data