From owner-freebsd-stable@FreeBSD.ORG Tue Jul 16 02:33:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A9CA798 for ; Tue, 16 Jul 2013 02:33:30 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:140:72e1::ac16:e45e]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2B58F4 for ; Tue, 16 Jul 2013 02:33:30 +0000 (UTC) Received: from hexe.rlwinm.de (p4FE67BC6.dip0.t-ipconnect.de [79.230.123.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 47355117A0 for ; Tue, 16 Jul 2013 02:33:28 +0000 (UTC) Message-ID: <51E4B0F9.5050200@rlwinm.de> Date: Tue, 16 Jul 2013 04:33:29 +0200 From: Jan Bramkamp User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130707 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: LDAP authentication confusion References: <1373915752.13754.140661255962197.3CA2BD96@webmail.messagingengine.com> <20130715224748.GA45649@anubis.morrow.me.uk> <51E480C3.50008@rlwinm.de> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 02:33:30 -0000 On 16.07.2013 04:28, Daniel Eischen wrote: > On Tue, 16 Jul 2013, Jan Bramkamp wrote: > >> On 16.07.2013 00:47, Ben Morrow wrote: >>> Quoth Jan Bramkamp : >>>> On 15.07.2013 21:51, Daniel Eischen wrote: >>>>> >>>>> Wouldn't it be easier just to edit /etc/nsswitch.conf >>>>> anyway? >>>> PAM and NSS switch are two different subsystems. NSS is just for >>>> resource lookups (users, groups, hosts, ...). PAM is for access >>>> control. >>>> >>>> With ldap in nsswitch.conf for users and groups you can lookup a LDAP >>>> user but the user can't log into $service through PAM. This requires >>>> pam_ldap.so in pam.d/$service. >>> >>> The default pam_unix.so calls getpwent, so if nss_ldap returns cryptable >>> passwords in its result I think pam_unix can authenticate against those. >>> >>> This is not the same as authenticating by LDAP bind, but may end up >>> accepting the same passwords. >> >> If you want every process to read your hashed passwords and you use >> non-portable crypt hashes it could work. The correct solution would be >> authenticate users by LDAP binds without allowing anyone to read the >> password or to use the {SASL} password style and authenticate users >> against Kerberos with saslauthd. Just don't let you users play with >> passwords. Either your password policy allows dumb users to pick trivial >> password or it forces complex password structures on them resulting in >> post-it notes with passwords around every second desk. > > I think something is lost on me here. getpwent/getpwuid do > not return the password hashes in the returned struct passwd > unless the calling process is root. So you have to be root in > order to see the hashes anyway. Not all users are going to > have access to the hashes, unless your machine's compromised > or otherwise allows root privileges to others. > If the crypted password can be read by an LDAP client with the information available to every process in (nss_)ldap.conf you're crypted passwords are easily accessible for offline attacks. Their is no reason for an attacker to go through the getpwent/getpwuid API.