LDAP authentication confusion

[Daniel Eischen]

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.

-- 
DE