OpenLDAP 2.3/pam_ldap/nss_ldap: not working in FreeBSD 7.0-PRE!
ohartman at mail.zedat.fu-berlin.de
Mon Nov 5 14:00:41 PST 2007
Ulrich Spoerlein wrote:
> Sorry for the late reply ...
> On Fri, 26.10.2007 at 20:16:45 +0200, O. Hartmann wrote:
>> All right, here I am. nss_ldap.conf and ldap.conf are located in
>> /usr/local/etc and are identical (link). I copied all tags I use and deleted
>> commented out tags:
> Seems ok to me, though I don't claim to be an expert.
This method has been recommended by many sites and tutorials, so I guess
it should be approved ;-)
>> The slapd.conf is this, comments roped:
>> include /usr/local/etc/openldap/schema/core.schema
>> include /usr/local/etc/openldap/schema/cosine.schema
>> include /usr/local/etc/openldap/schema/nis.schema
>> include /usr/local/etc/openldap/schema/inetorgperson.schema
>> # additional schema
>> include /usr/local/share/examples/samba/LDAP/samba.schema
>> pidfile /var/run/openldap/slapd.pid
>> argsfile /var/run/openldap/slapd.args
>> logfile /var/log/slapd.log
>> loglevel 512
> loglevel is a bitmask. It you want to have lots of debugging try 255 and
> run a tail -f /var/log/debug.log
Thanks, I did so and found several usefull messages in the log.
>> sizelimit unlimited
>> allow bind_v2
>> modulepath /usr/local/libexec/openldap
>> moduleload back_bdb
>> everse-lookup off
> typo I guess?
Sorry, yes, copy-and-paste mistake.
>> NSCD is up and running, my nsswitch.conf looks like this:
> Please try without nscd first, it's just another possible source of
Due to a recommendation not to use NSCD with FreeBSD and SAMBA I
switched that off.
>> group: cache ldap[ unavail=continue notfound=continue ] files
>> passwd: cache ldap [ unavail=continue notfound=continue ] files
>> #group_compat: nis
>> hosts: compat
>> networks: files
>> #passwd_compat: nis
>> shells: files
>> services: compat
>> services_compat: nis
>> protocols: files
>> rpc: files
>> And I changed some lines in /etc/pam.d/sshd,login,system,other like this
>> *commented out due to system gets stuck forever when enab;ed
> I'm using softbind and a short timeout in ldap.conf/nss_ldap.conf to
> avoid this unresponsiveness.
> # Bind/connect timelimit
> bind_timelimit 3
> # Reconnect policy: hard (default) will retry connecting to
> # the software with exponential backoff, soft will fail
> # immediately.
> #bind_policy hard
> bind_policy soft
> Also, make NSS work first, then turn to configuring PAM (at least,
> that's what I would do)
Great!! That did the trick and it is very helpful in saving a lot of
time and prevented me from loosing more hairs.
>> Some errors from console:
>> (At boot time)
>> Oct 26 17:00:36 gauss kernel: Oct 26 17:00:36 gauss slapd: nss_ldap:
>> could not search LDAP server - Server is unavailable
> Expected. slapd want to change its user to ldap:ldap, which it needs to
> look up the UID for. Chicken & Egg. That's why I need to use soft
> bind+timeout on my (disconnected) laptop here.
>> Oct 26 11:59:08 gauss kernel: Oct 26 11:59:08 gauss cron: nss_ldap:
>> could not search LDAP server - Server is unavailable
>> Oct 26 12:41:44 gauss kernel: Oct 26 12:41:44 gauss login: nss_ldap: could
>> not search LDAP server - Server is unavailable
> That seems broken then. Is slapd running? Can you ldapsearch -Lx -h
> localhost? What's /var/log/debug.log telling you? Can you id(1) some ldap
> users? Does the output of 'getent group' and 'getent passwd' look
Too many switches switched at the same time, so I guess I messed up
things and couldn't get a clear sight anymore. The point is, without any
TLS the user authetication works fine for SSHD/LOGIN and SU, even
password changes via a patched 'passwd' works fine, but when trying
using TLS/OpenSSL everything gets messed up again, I'll report this at
The main reason for blocking access was the ACL misbehaviour. I took the
example slapd.conf and especially the line describing access to everything
access to * ...
The line 'by anonymous auth' needs to be changed into 'by anonymous
read' otherwise LDAP won't let you even access for authetication. I
found this by watching exhaustive logs ...
>> One point: what is about compile time options of OpenLDAP? Does LDAP forces
>> itself using SSL although not configured explicitely in slapd.conf?
> No. It is purely optional. You would need certificates before it can
> even possibly start working anyways.
Yes, but OpenLDAP openldap-server-2.3.38 seems to reject connections via
TLS when used with self-signed certificacates.
>> nss_ldap-1.257 <<===
> My other computer is running with nss_ldap-1.257 and showing no problems
> Ulrich Spoerlein
Well, thanks a lot for helping.
At this moment OpenLDAP seems to work with the OpenLDAP-Clients (only)
and for authetication via ssh/login. I tried to install the famous and
often mentioned 'smbldap-tools' as recommended in many tutorials and I
followed the setup instructions given. But the tools still reject
connection attempts du to some authetication issues even if I let
"access to * by * write", clearly everyone has access to everything. But
this is another story.
A much more critical and also boring issue is the lack of up to date
tutorials! Many tutorials found are quite outdated, simnply wrong and
especially those parts regarding to TLS in some manner wacked. I tried
using a setup as described here:
and found myself incapable of connecting via 'a self signed
certificate'! OpenLDAP rejects connections (one-way-SSL/TLS) secured by
self signed certificates and I do not know how to force the server to
I would appreciate any hint where to find deeper insights and the right
way to use SSL/LDAP as a 'USER', not as a developer with a close insight
into how the beast works insight ...
More information about the freebsd-questions