lists.arthurdejong.org
RSS feed

Re: nss-pam-ldapd, AD and binding

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: nss-pam-ldapd, AD and binding



Arthur de Jong <arthur@arthurdejong.org> writes:

> On Wed, 2014-05-07 at 15:17 +0200, Henrik Grindal Bakken wrote:
>> What I'd like is for my pam module to bind to AD using short form
>> (username@domain.com or DOMAIN\username) -- which it has -- and the
>> user's password (which it has).  Further, I'd like nslcd to retrieve
>> enough info at that time so it wouldn't have to look up anything else
>> (otherwise how would nss later work, since the password is now lost).
>> 
>> In a pinch, nslcd could cache the user password, but that sounds like a
>> bad idea.
>> 
>> Is this possible?
>
> It would be very difficult, mostly because the NSS calls are done
> before and irrespective of the user authentication. One of the first
> things the PAM stack does is get the account information from the
> provided username (using NSS, before the user is asked for a
> password).

My system here is somewhat special, and I can live with NSS not finding
the user before he/she actually logs in, but I realize that's a
special-case, and not something you'd like to add cludges for in a
package.

> There are also plenty of things on a system (e.g. mail servers, cron,
> login managers, etc., etc.) that lookup user information that is not
> related to authentication.
>
> While having something like doing a BIND without a search to get the
> DN first is doable in some environments (e.g. some web applications
> support this) for a *nix system this will likely cause problems.
>
> Furthermore, I don't know about AD access controls, but I would
> imagine that a logged-in user is only able to get their own account
> information and not information on all accounts in the directory. Such
> a BIND would not be very useful for retrieving other information.

Actually, no, they can look up lots of stuff.  Not that it matters much,
as the only thing I really need is group memberships of the user in
question (and possibly password expiry status).

> So while Kerberos and other solutions may be available to handle the
> authentication part, the NSS part is difficult to solve without some
> general access to the directory.
>
> Hope this helps,

Yeah, it definitely helps.  I'll keep looking for some option here,
possibly the GSSAPI stuff mentioned.  Thanks.

-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/