OpenLDAP 2.3/pam_ldap/nss_ldap: not working in FreeBSD 7.0-PRE!

[O. Hartmann]

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

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
> reasonable?
>   

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  <<===
>> openldap-client-2.3.38
>> openldap-server-2.3.38
>> pam_ldap-1.8.2
>>     
>
> My other computer is running with nss_ldap-1.257 and showing no problems
> either.
>
> Cheers,
> 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:

http://wiki.unixboard.de/index.php/FreeBSD_-_Samba

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

Regards,
Oliver