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 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 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)
[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 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.
Thanks in advance. tob
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
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
On 1 November 2011 11:53, 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
Did you ever get this to work?
Dear Jaun,
Actually I am just getting back to it. This is finals week. Things will get quiet enough this week that I could pursue it.
And no, I never got it to work, I had it traced via log entries, and was going to compare the traces [ldapsearch works with -ZZ, vs. through the ldap client under linux for nscd or nslcd which fails] and try to do some problem source identification [What actually is the problem, which code is the culprit] starting shortly, and going into January.
I am trying to get a handle on whether I should pursue this with nscd or nslcd. If You have advice there, I am listening. To my knowledge I had nscd configured correctly when it failed, but I need some more information on nslcd.
I would very much like a secure [either tls via ldaps, or tls via straight ldap with tls on] interface, since in the spring some of my networks will have security classes on them, and to best understand [and illustrate] how network security works, the instructors will be putting infectious code on those networks.
FYI I am 2.4.26 openldap on 2 lab networks, ldap is working well in support of a couple of coordinated projects. All of the machines currently supported are suse 12.1 milestone 5. Testing is being done on both separate clients and with the client on the serving machine [both show the same failure at the moment.].
Why are you interested, and is there anything I can assist you with?
[By the way if any of the broader ldap community has input here, I would appreciate it.]
Sincerely, tob
On 12/8/11 9:59 AM, "Juan Miscaro" jmiscaro@gmail.com wrote:
On 1 November 2011 11:53, 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
Did you ever get this to work?
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
On 13.12.2011 19:18, John Tobin wrote:
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.
I guess the problem is your ca cert. ldap command line tools read the ldap.conf including tls_cacert. But maybe your gui ldap client don't read the ldap.conf, did you installed the ca cert globally in your cert storage? You should see some tls ca cert errors on your slapd server.
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 tomake 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" -ZAlways 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/ withtls 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=-1Augh. 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 weregenerated 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. tobReferences
Visible links 1. http://www.openldap.org/faq/data/cache/185.html
openldap-technical@openldap.org
-
Christopher Wood -
John Tobin -
Juan Miscaro -
Raffael Sahli