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 nss_ldap/pam_ldap):

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[757]: 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[13480]: 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 end.

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 accept those.

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 ...

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to