LDAP authentication confusion

[Jan Bramkamp]

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