[clug] LDAP over SSL/TLS not working

Jade Barton jade.barton at gmail.com
Sun Oct 2 14:20:16 GMT 2005


On 02/10/05, Kim Holburn <kim.holburn at anu.edu.au> wrote:
> Hi Jade,
>
> Reading the man page for ldap.conf (and you will have to read the one
> that came with yours because they are all slightly different):
>
> You could try this line in ldap.conf:
>
> TLS_REQCERT never

Yay, that one got it!  Thank you! The confusing part was which file to
add it to.  The system added "ssl start_tls" to the /etc/ldap.conf
file but the "TLS_REQCERT never" had to be added to
/etc/openldap/ldap.conf file (??).  I'll have to read more on distro's
specifics as the O'Reilly book mentions nothing of this.  "never" was
the only option that worked too.

As a side note I did try following the instructions on the OpenLDAP
web-site for creating my own CA, signing my own cert and implementing
it into LDAP (also not required according to the O'Reilly book, now in
the bin) but this also failed.  If anyone has got this to work I would
be interested to hear about it.

Here was the end result of the two files for those interested...
[root at xxxx ~]# more /etc/ldap.conf | grep -v ^# | grep .
uri ldap://192.168.2.1/
base dc=xxxx,dc=net
ssl start_tls
[root at xxxx ~]# more /etc/openldap/ldap.conf | grep -v ^# | grep .
HOST 192.168.2.1
BASE dc=xxxx,dc=net
TLS_REQCERT never

Thanks again for your help Kim.


>
> All the other options look to me like they deal with CA certs not a
> standalone server cert which is probably what you have.
>
>
>         TLS_REQCERT <level>
>                Specifies what checks to perform on server
> certificates in a TLS
>                session, if any. The <level> can be specified as one
> of the fol-
>                lowing keywords:
>
>                never  The  client will not request or check any
> server certifi-
>                       cate.
>
>                allow  The server certificate is requested. If no
> certificate is
>                       provided,  the  session  proceeds normally. If
> a bad cer-
>                       tificate is provided, it will be ignored and
> the  session
>                       proceeds normally.
>
>                try    The server certificate is requested. If no
> certificate is
>                       provided, the session proceeds normally. If  a
> bad  cer-
>                       tificate  is  provided, the session is
> immediately termi-
>                       nated.
>
>                demand | hard
>                       These keywords are equivalent. The server
> certificate  is
>                       requested.  If  no certificate is provided, or
> a bad cer-
>                       tificate is provided, the session is
> immediately  termi-
>                       nated. This is the default setting.
>
>
> On 2005 Oct 02 at 12:52 PM, Jade Barton wrote:
> > Thanks Kim, unfortunately the line (or many variations of similar)
> > didn't work.  I suspect you have pointed me in right direction though,
> > and it's something to do with the clients ldap.conf file for the
> > following reason...  I ran the following commands successfully from
> > the client:
> >
> > ldapsearch -H ldap://xxxx.net/ -b dc=xxxx,dc=net -x   (simple auth,
> > no encrypt.)
> > ldapsearch -H ldaps://xxxx.net/ -b dc=xxxx,dc=net -x   (simple
> > auth, over SSL)
> > ldapsearch -H ldap://xxxx.net/ -ZZ -b dc=xxxx,dc=net -x   (simple
> > auth, over StartTLS)
> >
> > They all returned the user data from the server.  As soon as I drop
> > the "-x" it tries to use SASL and fails.  I am wondering if, by
> > enabling the checkbox in the "Authentication" dialogue on the client
> > it is trying to use SASL also.  I haven't set up SASL and don't really
> > care if it doesn't use it, as long at the (simple) auth traffic is
> > over SSL/TLS.
> >
> > So in the ldap.conf file I changed
> > host 192.168.111.1
> > to
> > uri ldaps://192.168.111.1/
> > but it didn't work :(
> >
> > As a bit of background these certificates & keyfiles have been
> > generated and signed using the OpenSSL software by me.  I'm pretty
> > confident that they're ok because I use similar ones for encrypted
> > SMTP and IMAPS and they seam to work for the LDAP addressbook data via
> > the e-mail clients.  To encrypt the addressbook traffic I simply
> > enabled the SSL checkbox which automatically changed the port to 636.
> >
> > Confused,
> > Jade
> >
> > On 02/10/05, Kim Holburn <kim.holburn at anu.edu.au> wrote:
> >
> >>
> >>
> >> On 2005 Oct 02 at 1:11 AM, Jade Barton wrote:
> >>
> >>> Hi all,
> >>>
> >>> I am having some dramas with LDAP over SSL/TLS for authentication
> >>> purposes.  I have got the following to work:
> >>> - Authentication without SSL/TLS (from FC4 box to server).  Users
> >>> are
> >>> able to log on in insecure mode.
> >>> - SSL/TLS or insecure mode works when accessing the address book
> >>> from
> >>> e-mail clients (ie. ou=AddressBook,dc=domain,dc=net). This works
> >>> with
> >>> or without authentication.
> >>>
> >>> The bit I haven't got to work is as soon as I enable the "Use TLS to
> >>> encrypt connections" box in the FC4 authentication dialogue it won't
> >>> authenticate.  One of the things that is confusing me is that FC4
> >>> has
> >>> 2 ldap.conf files on the client (/etc/ldap.conf &
> >>> /etc/openldap/ldap.conf shown below). The former appears to be
> >>> the one
> >>> requiring change(?).  I have tried putting "port 636" into the
> >>> ldap.conf client file but it didn't seem to help.  All I had to
> >>> do to
> >>> get the e-mail clients to connect via SSL/TLS was change their port
> >>> number to 636 and accept the cert when prompted.  I have placed the
> >>> server certificate in the /etc/openldap/cacerts folder on the
> >>> client.
> >>>
> >>> Google and a copy of "LDAP System Admin. - O'Reilly" aren't
> >>> helping me
> >>> much.  Mainly due to the fact that I am still learning and no doubt
> >>> have a few knowledge holes.  Any help would be most appreciated,
> >>> especially good references.  Also, feel free to pick on any other
> >>> parts of the slapd.conf file you notice in error.  Apologies is some
> >>> of this lacks sense, it's late and my head hurts.
> >>>
> >>> Copy of slapd.conf on server... (comments and stuff removed)
> >>> -----------------BEGIN-----------------
> >>> include            /etc/openldap/schema/core.schema
> >>> include            /etc/openldap/schema/cosine.schema
> >>> include            /etc/openldap/schema/inetorgperson.schema
> >>> ##Include for NIS support
> >>> include            /etc/openldap/schema/nis.schema
> >>> loglevel        296
> >>> pidfile            /var/run/slapd.pid
> >>> argsfile        /var/run/slapd.args
> >>> ##TLS options
> >>> TLSCipherSuite        HIGH:MEDIUM:+SSLv2
> >>> TLSCertificateFile    /usr/share/ssl/certs/XXXX_slapdcert.pem
> >>> TLSCertificateKeyFile    /usr/share/ssl/private/XXXX_slapdkey.pem
> >>>
> >>
> >> I assume these are a real cert/key pair, not example ones.
> >>
> >>
> >>> password-hash    {SSHA}
> >>> # bdb database definitions
> >>> database        bdb
> >>> suffix            "dc=domain,dc=net"
> >>> rootdn            "cn=Manager,dc=domain,dc=net"
> >>> rootpw            {SSHA}removed
> >>> directory        /var/lib/ldap/xxxx
> >>> mode            0600
> >>> ##Indexes to maintain
> >>> index objectClass,uid,uidNumber,gidNumber    eq
> >>> index cn                    eq
> >>> ##ACL's
> >>> access to attrs=userPassword
> >>>     by self write
> >>>     by * auth
> >>> access to *
> >>>         by * read
> >>> ####################################################################
> >>> ##
> >>> #
> >>> -----------------END-----------------
> >>> Copy of lapd.conf on client... (comments and stuff removed)
> >>> -----------------BEGIN-----------------
> >>> [root at xxxx ~]# more /etc/ldap.conf | grep -v ^# | grep .
> >>> host 192.168.111.1
> >>> base dc=domain,dc=net
> >>> ssl start_tls
> >>> tls_cacertdir /etc/openldap/cacerts
> >>>
> >>
> >> I think you need a line here saying something like:
> >> tls_certfile /usr/share/ssl/certs/XXXX_slapdcert.pem
> >>
> >>
> >>> pam_password md5
> >>> -----------------END-----------------
> >>> -----------------BEGIN-----------------
> >>> [root at xxxx ~]# more /etc/openldap/ldap.conf | grep -v ^# | grep .
> >>> HOST 192.168.111.1
> >>> BASE dc=domain,dc=net
> >>> TLS_CACERTDIR /etc/openldap/cacerts
> >>>
> >>
> >> tls_certfile /usr/share/ssl/certs/XXXX_slapdcert.pem
> >>
> >>
> >>> -----------------END-----------------
> >>>
> >>>
> >>> --
> >>> Jade
> >>>   --  Of all the manifestations of power,
> >>>             restraint impresses men the most --
> >>>                                       Thucydides
> >>> --
> >>> linux mailing list
> >>> linux at lists.samba.org
> >>> https://lists.samba.org/mailman/listinfo/linux
> >>>
> >>>
> >>
> >> --
> >> Kim Holburn
> >> Network and Security Manager, National ICT Australia Ltd.
> >> Ph: +61 2 61258620 M: +61 417820641  F: +61 2 6230 6121 aim://
> >> kimholburn
> >> Email: kim.holburn at nicta.com.au  - PGP Public Key on request
> >> callto://kholburn
> >> Cacert Root Cert: http://www.cacert.org/cacert.crt
> >> Aust. Spam Act: To stop receiving mail from me: reply and let me
> >> know.
> >>
> >> Use ISO 8601 dates [YYYY-MM-DD] http://www.saqqara.demon.co.uk/
> >> datefmt.htm
> >> Democracy imposed from without is the severest form of tyranny.
> >>                            -- Lloyd Biggle, Jr. Analog, Apr 1961
> >>
> >>
> >>
> >
>
> --
> Kim Holburn
> Network and Security Manager, National ICT Australia Ltd.
> Ph: +61 2 61258620 M: +61 417820641  F: +61 2 6230 6121 aim://kimholburn
> Email: kim.holburn at nicta.com.au  - PGP Public Key on request
> callto://kholburn
> Cacert Root Cert: http://www.cacert.org/cacert.crt
> Aust. Spam Act: To stop receiving mail from me: reply and let me know.
>
> Use ISO 8601 dates [YYYY-MM-DD] http://www.saqqara.demon.co.uk/
> datefmt.htm
> Democracy imposed from without is the severest form of tyranny.
>                            -- Lloyd Biggle, Jr. Analog, Apr 1961
>
>
>


--
Jade
  --  Of all the manifestations of power,
            restraint impresses men the most --
                                      Thucydides


More information about the linux mailing list