[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: How to Secure openLdap nss_ldap



On Thursday 02 April 2009 15:43:12 Matthew.GARRETT@external.total.com wrote:
> Folks
>
> Note sure if this is the right list ?
>
> I have a new OpenLdap (version 2.3) Server that uses Kerberos for Password
> Authentication

Do you mean you are authenticating simple binds to the Kerberos server? Why 
are you not using Kerberized access?

> , which is going to be a Replacement for NIS (YP)
> All Normal access works fine and users can login , access automount maps
> etc
>
> However there are 2 types of Ldap binding
>
> Simple
> TLS

No, the two types of binds are Simple and SASL. Simple can use unencrypted 
connections, connections using SSL/TLS via LDAPS or START_TLS, and can be 
anonymous or authenticated.

> At the moment any body can run the following
> ldapsearch -x

An anonymous simple bind without START_TLS (but, maybe to an LDAPS URI?, you 
don't say).

Of course, whether an anonymous bind works or not has nothing to do with how 
much data you are exposing to anonymous binds ...

> I would like to try and disable Simple Binding

What are you trying to achieve? Protect data from anonymous access? Or protect 
passwords used in simple binds? Or, protect the data from "sniffing" ?

> But if I select "disallow bind_anon" in slapd.conf file
> Things start to break like authentication stops working.
> /var/log/messages
>
> Apr  1 15:42:15 apricot sudo[31515]: pam_ldap: error trying to bind
> (Inappropriate authentication)
> Apr  1 15:42:18 apricot sudo[31515]: pam_ldap: error trying to bind
> (Inappropriate authentication)
> Apr  1 15:42:25 apricot sudo[31515]: pam_ldap: ldap_result Can't contact
> LDAP server
>
> How do I get a Machine to authenticate to Ldap ?

Well, the first question is, why are you using LDAP for authentication if you 
have Kerberos? You have pam_krb5, so why are you bothering with pam_ldap?

> I think the problem lies with nss_ldap ?

With the evicnce you have provided thus far, it's not easy to tell. For 
example, does 'getent passwd user_in_ldap' work? As non-root? As root?

With your /etc/ldap.conf below, you have configured nss_ldap to bind 
anonymously. To bind it non-anonymous, you should add 'binddn', and 'bindpw' 
to /etc/ldap.conf, or rootbinddn to /etc/ldap.conf, and put the password in 
/etc/ldap.secret, see 'man nss_ldap'.

> When I add the following line to /etc/ldap.conf
>
> ssl start_tls

Did you setup SSL correctly on the server side?

Have you tested START_TLS with an OpenLDAP client?

> I start to get the following error's
> Apr  2 14:09:11 bruce vmware-guestd: nss_ldap: reconnecting to LDAP server
> (sleeping 4 seconds)...
> Apr  2 14:09:15 bruce vmware-guestd: nss_ldap: reconnecting to LDAP server
> (sleeping 8 seconds)...
> Apr  2 14:09:18 bruce nscd: nss_ldap: reconnecting to LDAP server
> (sleeping 16 seconds)...
> Apr  2 14:27:06 bruce sshd: pam_ldap: ldap_starttls_s: Operations error
> Apr  2 14:27:06 bruce sshd(pam_unix)[11233]: authentication failure;
> logname= uid=0 euid=0 tty=ssh ruser= rhost=apricot.uk.ad.ep.corp.local
> user=mgarrett
> Apr  2 14:27:06 bruce sshd[11233]: pam_krb5[11233]: authentication
> succeeds for'mgarrett' (mgarrett@UK.AD.EP.CORP.LOCAL)

So, pam_krb5 works ...

> /etc/ldap.conf
>
> base dc=unix,dc=total
> bind_timelimit 120

^^ Too much IMHO, if anything goes wrong, there's no way you'll log in ...

> idle_timelimit 3600
> ldap_version 3
> pam_password md5
> scope sub
> ssl start_tls
> timelimit 120
> tls_cacertdir /etc/openldap/cacerts

Does the CA cert that signed the /etc/openldap/cacerts/cacert.pem on the LDAP 
server exist in this directory? Did you create the hash symlinks there? 
(alternatively, you could use tls_cacert /path/to/cacert.pem).

Also, where is uri or host? The name you use *must* be the subject CN (or 
subjectAlternateName) on the SSL certificate ...

> tls_checkpeer no

I think the OpenLDAP library has more effect on this than tls_checkpeer ... 
what do you have for 'TLS_REQCERT' in /etc/openldap/ldap.conf ?

> Can any body point me in the right direction

Regards,
Buchan