openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start
i've set up openldap for use with TLS.
it launches ok,
ps ax | grep slapd 27182 pts/1 S<+ 0:00 tail -f slapd.log 31441 ? S<sl 0:00 /usr/lib/openldap/slapd -h ldap://ldap.domain.com:389 -f /etc/openldap/slapd.conf -u ldap -g ldap -4 -o slp=on
ldapadd & ldapsearch seem to work over TLS as well,
ldapadd -ZZ -x -D "cn=admin,dc=domain,dc=com" -f /etc/openldap/admin.ldif -w 'secret' adding new entry "dc=domain,dc=com" adding new entry "cn=admin,dc=domain,dc=com"
ldapsearch -v -ZZ -x -D 'cn=admin,dc=domain,dc=com' -b 'dc=domain,dc=com' '(objectclass=*)' -w 'secret' ldap_initialize( <DEFAULT> ) filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base <dc=domain,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # domain.com dn: dc=domain,dc=com objectClass: dcObject objectClass: organization o: DOMAIN dc: domain # admin, domain.com dn: cn=admin,dc=domain,dc=com objectClass: organizationalRole cn: admin # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2
with slapd.log showing,
Aug 22 11:17:07 ldap slapd[31441]: conn=12 fd=12 ACCEPT from IP=192.168.1.17:34861 (IP=192.168.1.17:389) Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 STARTTLS Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 RESULT oid= err=0 text= Aug 22 11:17:07 ldap slapd[31441]: conn=12 fd=12 TLS established tls_ssf=256 ssf=256 Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=1 BIND dn="cn=admin,dc=domain,dc=com" method=128 Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=1 BIND dn="cn=admin,dc=domain,dc=com" mech=SIMPLE ssf=0 Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=1 RESULT tag=97 err=0 text= Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=2 SRCH base="dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=2 SEARCH RESULT tag=101 err=0 nentries=2 text= Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=3 UNBIND Aug 22 11:17:07 ldap slapd[31441]: conn=12 fd=12 closed
but, on slapd service (re)start, i see in slapd.log,
Aug 22 11:02:47 ldap slapd[31441]: slapd starting Aug 22 11:02:48 ldap slapd[31441]: conn=0 fd=12 ACCEPT from IP=192.168.1.17:42320 (IP=192.168.1.17:389) Aug 22 11:02:48 ldap slapd[31441]: conn=0 op=0 BIND dn="" method=128 Aug 22 11:02:48 ldap slapd[31441]: conn=0 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:48 ldap slapd[31441]: conn=0 fd=12 closed (connection lost) Aug 22 11:02:49 ldap slapd[31441]: conn=1 fd=12 ACCEPT from IP=192.168.1.17:42321 (IP=192.168.1.17:389) Aug 22 11:02:49 ldap slapd[31441]: conn=1 op=0 BIND dn="" method=128 Aug 22 11:02:49 ldap slapd[31441]: conn=1 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:49 ldap slapd[31441]: conn=1 fd=12 closed (connection lost) Aug 22 11:02:50 ldap slapd[31441]: conn=2 fd=12 ACCEPT from IP=192.168.1.17:42322 (IP=192.168.1.17:389) Aug 22 11:02:50 ldap slapd[31441]: conn=2 op=0 BIND dn="" method=128 Aug 22 11:02:50 ldap slapd[31441]: conn=2 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:50 ldap slapd[31441]: conn=2 fd=12 closed (connection lost) Aug 22 11:02:51 ldap slapd[31441]: conn=3 fd=12 ACCEPT from IP=192.168.1.17:42323 (IP=192.168.1.17:389) Aug 22 11:02:51 ldap slapd[31441]: conn=3 op=0 BIND dn="" method=128 Aug 22 11:02:51 ldap slapd[31441]: conn=3 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:51 ldap slapd[31441]: conn=3 fd=12 closed (connection lost) Aug 22 11:02:52 ldap slapd[31441]: conn=4 fd=12 ACCEPT from IP=192.168.1.17:42324 (IP=192.168.1.17:389) Aug 22 11:02:52 ldap slapd[31441]: conn=4 op=0 BIND dn="" method=128 Aug 22 11:02:52 ldap slapd[31441]: conn=4 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:52 ldap slapd[31441]: conn=4 fd=12 closed (connection lost) Aug 22 11:02:53 ldap slapd[31441]: conn=5 fd=12 ACCEPT from IP=192.168.1.17:42325 (IP=192.168.1.17:389) Aug 22 11:02:53 ldap slapd[31441]: conn=5 op=0 BIND dn="" method=128 Aug 22 11:02:53 ldap slapd[31441]: conn=5 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:53 ldap slapd[31441]: conn=5 fd=12 closed (connection lost) Aug 22 11:02:54 ldap slapd[31441]: conn=6 fd=12 ACCEPT from IP=192.168.1.17:42326 (IP=192.168.1.17:389) Aug 22 11:02:54 ldap slapd[31441]: conn=6 op=0 BIND dn="" method=128 Aug 22 11:02:54 ldap slapd[31441]: conn=6 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:54 ldap slapd[31441]: conn=6 fd=12 closed (connection lost) Aug 22 11:02:55 ldap slapd[31441]: conn=7 fd=12 ACCEPT from IP=192.168.1.17:42327 (IP=192.168.1.17:389) Aug 22 11:02:55 ldap slapd[31441]: conn=7 op=0 BIND dn="" method=128 Aug 22 11:02:55 ldap slapd[31441]: conn=7 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:55 ldap slapd[31441]: conn=7 fd=12 closed (connection lost) Aug 22 11:02:56 ldap slapd[31441]: conn=8 fd=12 ACCEPT from IP=192.168.1.17:42328 (IP=192.168.1.17:389) Aug 22 11:02:56 ldap slapd[31441]: conn=8 op=0 BIND dn="" method=128 Aug 22 11:02:56 ldap slapd[31441]: conn=8 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Aug 22 11:02:56 ldap slapd[31441]: conn=8 fd=12 closed (connection lost)
what are these multiple connection "text=TLS confidentiality required" errors due to?
i'm guessing it has to do with security restrictions set in slapd.conf.
reading @ http://www.openldap.org/doc/admin24/security.html, i've,
... security ssf=256 tls=256 update_tls=256 simple_bind=256 disallow tls_2_anon require bind LDAPv3 ...
are these settings correct, and/or are they resposible for those slapd.log messages? something else?
On Fri, 22 Aug 2008, Ben Wailea, openldap-software wrote: ...
ldapadd & ldapsearch seem to work over TLS as well,
ldapadd -ZZ -x -D "cn=admin,dc=domain,dc=com" -f /etc/openldap/admin.ldif -w 'secret'
...
with slapd.log showing,
Aug 22 11:17:07 ldap slapd[31441]: conn=12 fd=12 ACCEPT from IP=192.168.1.17:34861 (IP=192.168.1.17:389) Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 STARTTLS Aug 22 11:17:07 ldap slapd[31441]: conn=12 op=0 RESULT oid= err=0 text= Aug 22 11:17:07 ldap slapd[31441]: conn=12 fd=12 TLS established tls_ssf=256 ssf=256
...
Note the EXT/STARTTLS/TLS log messages there, showing that the client (ldapadd) actually used the STARTTLS operation.
...
but, on slapd service (re)start, i see in slapd.log,
Aug 22 11:02:47 ldap slapd[31441]: slapd starting Aug 22 11:02:48 ldap slapd[31441]: conn=0 fd=12 ACCEPT from IP=192.168.1.17:42320 (IP=192.168.1.17:389) Aug 22 11:02:48 ldap slapd[31441]: conn=0 op=0 BIND dn="" method=128
Note the *lack* of those EXT/STARTTLS/TLS messages. The client that made that connection didn't use the StartTls operation, so it wasn't using an encrypted connection so...
Aug 22 11:02:48 ldap slapd[31441]: conn=0 op=0 RESULT tag=97 err=13 text=TLS confidentiality required
...the bind was in the clear, which your slapd configuration rejects.
what are these multiple connection "text=TLS confidentiality required" errors due to?
Those are clients that don't use StartTLS when your server config requires it.
i'm guessing it has to do with security restrictions set in slapd.conf.
reading @ http://www.openldap.org/doc/admin24/security.html, i've,
Hmm, I don't see these options on that web page.
... security ssf=256 tls=256 update_tls=256 simple_bind=256
That seems like an unusual and/or redundant set of requirements. If I'm reading things correctly, that line should have the exact same behavior as this one: security tls=256
I.e., refuse to do _anything_ unless TLS is negotiated with an SSF of at least 256 (i.e., 256 bit encryption cipher). Is that *really* the requirement you mean to enforce?
disallow tls_2_anon
Hmm, why do you set that option? Do you know why the default isn't to do that?
require bind LDAPv3
I get the sense that you want to lock this server down by banning anything you aren't sure about.
are these settings correct, and/or are they resposible for those slapd.log messages? something else?
"Correct" depends on what you're trying to acheive.
Yes, they're responsible: you told the server "require TLS!" so it's refusing the clients that don't use TLS. I'm surprised it's a question.
Philip Guenther
On Fri, Aug 22, 2008 at 12:50 PM, Philip Guenther guenther+ldapsoft@sendmail.com wrote:
Note the *lack* of those EXT/STARTTLS/TLS messages. The client that made that connection didn't use the StartTls operation, so it wasn't using an encrypted connection so...
yes. when i launch the "ldap* -ZZ" from cmd line, it starts TLS as expected.
"all" that's done to generate the above errors is:
service ldap restart
which, iiuc, simply launches slapd. so, per your comment, *specifically* which 'client' is failing to use the StartTLS?
security tls=256I.e., refuse to do _anything_ unless TLS is negotiated with an SSF of at least 256 (i.e., 256 bit encryption cipher). Is that *really* the requirement you mean to enforce?
the goal is to always/only use TLS with an AES-256 encryption cipher. the hope is that that 'security' directive accomplishges that.
disallow tls_2_anonHmm, why do you set that option? Do you know why the default isn't to do that?
the goal is to not allow any anonymous connetion/bind/etc.
to the extent that 'man slapd.conf' shares
tls_2_anon disables Start TLS from forcing session to anonymous status (see also tls_authc). tls_authc disables StartTLS if authenticated (see also tls_2_anon).
that seems to be the right choice. afaict, there's no additional documentation on the matter.
and, that description smacks of "read other side" being written on both sides of a postcard ...
Yes, they're responsible: you told the server "require TLS!" so it's refusing the clients that don't use TLS. I'm surprised it's a question.
YA tired old sarcastic comment. and you were doing so well ...
reading some of your other posts ... knowing so much more than everyone else, you really must get exhausted from being so surprised that people have questions of any kind -- given how everything's so obvious!
--On Friday, August 22, 2008 1:11 PM -0700 "Ben Wailea, openldap-software" bwailea+10@gmail.com wrote:
which, iiuc, simply launches slapd. so, per your comment, *specifically* which 'client' is failing to use the StartTLS?
The ones in the log you posted:
Aug 22 11:02:47 ldap slapd[31441]: slapd starting Aug 22 11:02:48 ldap slapd[31441]: conn=0 fd=12 ACCEPT from IP=192.168.1.17:42320 (IP=192.168.1.17:389)
It's up to you to figure out what client is doing that, we can't magically read your system's mind.
And I'll note your response is unlikely to generate further help from people on the list. Philip's reply was not sarcastic, it was honest. You said you require TLS, and now clients that you have configured to query the server are failing. It's your responsibility to track down which ones those are.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
[Moderator: I believe the following questions particular to OpenLDAP were still unanswered]
On Fri, 22 Aug 2008, Ben Wailea, openldap-software wrote:
On Fri, Aug 22, 2008 at 12:50 PM, Philip Guenther guenther+ldapsoft@sendmail.com wrote:
...
security tls=256I.e., refuse to do _anything_ unless TLS is negotiated with an SSF of at least 256 (i.e., 256 bit encryption cipher). Is that *really* the requirement you mean to enforce?
the goal is to always/only use TLS with an AES-256 encryption cipher. the hope is that that 'security' directive accomplishges that.
Sorta. It makes LDAP requests fail if they didn't use TLS with AES-256, but it doesn't prevent a client from negotiating TLS with, say, AES-128. If you want to require AES-256, then you should set the TlsCipherSuite option to limit the accept ciphers also. The exact syntax will depend on whether you're using OpenSSL or GNUtls and what type of key the server has. See the slapd.conf(5) manpage for details.
(Interestingly, some versions of openssl support AES256, but don't have any way to say "accept AES256 and not AES126". In effect, the cipher suite parsing can't "tell them apart". So test your settings before relying on them!)
disallow tls_2_anonHmm, why do you set that option? Do you know why the default isn't to do that?
the goal is to not allow any anonymous connetion/bind/etc.
to the extent that 'man slapd.conf' shares
tls_2_anon disables Start TLS from forcing session to anonymous status (see also tls_authc). tls_authc disables StartTLS if authenticated (see also tls_2_anon).
that seems to be the right choice. afaict, there's no additional documentation on the matter.
That's not what the "disallow tls_2_anon" option does.
By default, if a client does this: BIND STARTTLS
then the STARTTLS will 'undo' the authentication, reverting it to anonymous. That's good because the connection was unprotected between the BIND and the STARTTLS and could have been hijacked. The option disallow tls_2_anon
changes it so that it _doesn't_ revert to anonymous. That option is *less* secure than the default and should only be used in specific situations where required and the implications are understood.
However, your other settings make the change pointless, because you don't permit BIND before STARTTLS anyway!
and, that description smacks of "read other side" being written on both sides of a postcard ...
Not at all. The tls_2_anon says "if you do permit STARTTLS after BIND, then don't undo the BIND", while "tls_authc" says "don't permit STARTTLS after BIND at all".
Philip Guenther
openldap-software@openldap.org
-
Ben Wailea, openldap-software -
Philip Guenther -
Quanah Gibson-Mount