From owner-freebsd-questions@FreeBSD.ORG Mon Nov 5 22:00:41 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD9CB16A419; Mon, 5 Nov 2007 22:00:41 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2E45B13C4CC; Mon, 5 Nov 2007 22:00:40 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.67) with esmtp (envelope-from ) id <1Ip9zZ-0003IA-76>; Mon, 05 Nov 2007 23:00:21 +0100 Received: from e178050060.adsl.alicedsl.de ([85.178.50.60] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.67) with esmtpsa (envelope-from ) id <1Ip9zZ-0007SE-08>; Mon, 05 Nov 2007 23:00:21 +0100 Message-ID: <472F9348.4030309@mail.zedat.fu-berlin.de> Date: Mon, 05 Nov 2007 23:03:52 +0100 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.6 (X11/20071101) MIME-Version: 1.0 To: "O. Hartmann" , "O. Hartmann" , freebsd-questions@freebsd.org, freebsd-ports@freebsd.org References: <471B7DCF.2020709@mail.zedat.fu-berlin.de> <20071025214852.GB1458@roadrunner.spoerlein.net> <47222F0D.70802@zedat.fu-berlin.de> <20071104214829.GA1527@roadrunner.spoerlein.net> In-Reply-To: <20071104214829.GA1527@roadrunner.spoerlein.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.50.60 Cc: Subject: Re: OpenLDAP 2.3/pam_ldap/nss_ldap: not working in FreeBSD 7.0-PRE! X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 22:00:41 -0000 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