headers
Ben Wailea, openldap-software | 22 Aug 20:18

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
	#
(Continue reading)

Permalink | Reply |
headers
Philip Guenther | 22 Aug 21:50
Favicon

Re: openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start

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
(Continue reading)

Permalink | Reply |
headers
Ben Wailea, openldap-software | 22 Aug 22:11

Re: openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start

On Fri, Aug 22, 2008 at 12:50 PM, Philip Guenther
<guenther+ldapsoft <at> 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=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?

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_anon
>
> Hmm, 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.
(Continue reading)

Permalink | Reply |
headers
Quanah Gibson-Mount | 22 Aug 22:35

Re: openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start

--On Friday, August 22, 2008 1:11 PM -0700 "Ben Wailea, openldap-software" 
<bwailea+10 <at> 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
(Continue reading)

Permalink | Reply |
headers
Philip Guenther | 22 Aug 23:53
Favicon

Re: openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start

[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 <at> sendmail.com> wrote:
...
> >        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?
> 
> 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_anon
> >
(Continue reading)

Permalink | Reply |

Gmane