Date: Mon, 15 Jul 2013 22:45:00 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Jan Bramkamp <crest@rlwinm.de> Cc: freebsd-stable@freebsd.org Subject: Re: LDAP authentication confusion Message-ID: <Pine.GSO.4.64.1307152240280.10981@sea.ntplx.net> In-Reply-To: <51E4B0F9.5050200@rlwinm.de> References: <Pine.GSO.4.64.1307151438370.8901@sea.ntplx.net> <CAHDg04v8xV-yaCXDzSbOzWEvHRMhDy8x0A=B2eho4iK4b1UuJA@mail.gmail.com> <Pine.GSO.4.64.1307151507130.8901@sea.ntplx.net> <1373915752.13754.140661255962197.3CA2BD96@webmail.messagingengine.com> <Pine.GSO.4.64.1307151550030.8901@sea.ntplx.net> <20130715224748.GA45649@anubis.morrow.me.uk> <51E480C3.50008@rlwinm.de> <Pine.GSO.4.64.1307152220100.10981@sea.ntplx.net> <51E4B0F9.5050200@rlwinm.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
> 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 <crest@rlwinm.de>:
>>>>> 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.
The root bind password is kept in a separate file that only
root has read rights to. I don't think the password hashes
are available when binding anonymously or through the proxy
agent.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1307152240280.10981>