Re: question about user authentication and authorization in nss-ldapd -> nslcd -> slapd
[
Date Prev][Date Next]
[
Thread Prev][Thread Next]
Re: question about user authentication and authorization in nss-ldapd -> nslcd -> slapd
- From: Liu Yubao <yubao.liu [at] gmail.com>
- To: Arthur de Jong <arthur [at] arthurdejong.org>
- Cc: nss-pam-ldapd-users [at] lists.arthurdejong.org
- Subject: Re: question about user authentication and authorization in nss-ldapd -> nslcd -> slapd
- Date: Wed, 28 Dec 2011 13:02:48 +0800
On Wed, Dec 28, 2011 at 12:26 AM, Arthur de Jong
<arthur@arthurdejong.org> wrote:
> On Fri, 2011-12-16 at 18:46 +0800, Liu Yubao wrote:
>> Recently I'm playing nss-ldapd + nslcd + slapd + kerberos to implement
>> SSO, I'm confused about the authentication and authorization parts.
>>
>> (1) user process calls nslcd by nss-ldapd library, nslcd knows uid
>> and gid from the UNIX domain socket; (I guess there is no GSSAPI
>> authentication between user process and nslcd)
>
> That is correct, nslcd doesn't do any checking of the client for
> handling requests with the exception of shadow lookups and password
> change operation in which case the caller should be root.
>
Reasonable in NSS usage, thanks!
>> (2) nslcd authenticates to slapd by GSSAPI, nslcd thinks the client is
I meant "...slapd thinks the client is...."
>> nslcd's Kerberos principal, such as "host/HOSTNAME@REALM".
>
> Probably correct but I don't know that much about Kerberos.
Per your comment to 2.b, I guess slapd can distinguish users if I use pam-ldapd.
Verified from slapd log, with only nss-ldapd, slapd always think the
user is nslcd's
Kerberos principal.
>> a. slapd can't authenticate users directly by GSSAPI, so slapd can't
>> limit authorization based on users' Kerberos principal names, right?
>> /etc/nslcd.conf can specify authzid for nslcd, but that's fixed, can't
>> change according to requesting user.
>
> This is correct. Most databases are expected to be the same for all
> users (compare to /etc/passwd). If you use caching (nscd) even nslcd
> cannot find out the user requesting the information (probably one of the
> reasons that shadow lookups aren't cached).
>
Thanks, that's very reasonable for NSS usage.
>> b. I heard there is a rebind on nslcd to slapd, I setup userA on
>> kerberos and slapd (uid=userA,ou=People,dc=example,dc=com) , then I
>> run "kinit" as userA, then "getent passwd", but I don't see nslcd
>> tries to rebind as userA. why?
>
> nslcd does all normal lookups with one configuration (caller information
> is not used). Perhaps it is possible to do something like this using
> PADL's nss_ldap though but I'm not sure.
>
I don't verify with nss-ldap, I just checked its configuration file, seems
nss-ldap also uses fixed credential to do nss lookup, I'm not sure whether
it rebinds.
> If you let nslcd perform the authentication (using the PAM module) it
> will bind with the provided credentials.
>
I roughly checked the code, seems actions triggered by pam-ldapd such as
changing passwd, requesting authorization to other service will bind with
caller credential or root dn, but actions triggered by nss-ldapd such as
getent*() won't, nslcd always uses nslcd's credential configured
in /etc/nslcd.conf to bind against slapd.
>> c. the uid and gid is provided by nslcd to slapd, how can slapd to
>> avoid malicious nslcd to provide "uid=0,gid=0" to slapd for a normal
>> user?
>
> I don't fully understand what you mean. nslcd can perform some extra
> filtering of the results it received from the LDAP server with the
> nss_min_uid option and minimum_uid for the PAM module. nslcd doesn't
> perform anything on the LDAP server that you couldn't do with ldapsearch
> (all nslcd's secrets should be in nslcd.conf) so it should be safe.
>
I realized I worried unnecessarily, let me explain more.
(I) For administrated host, suppose two users userA and userB with
uid 2000 and 2001,
if nslcd is attacked by userB and nslcd can report uid=2000 for userB,
then userB
can pretend as userA. Stronger authentication between nslcd and userA
doesn't help,
no solution for this attack except userA bypasses nslcd totally.
Luckily, this is just paranoid,
I don't hear any vulnerability for that yet.
(II) For host owned by malicious user, he can read information if
he has binding privilege
to slapd, nslcd doesn't expose more risk and it's fault of bad trust
between the user and slapd
administrator.
>> d. I only installed nss-ldapd + nslcd, not pam-ldapd because I already
>> have pam-krb5, I find "chsh" complains the user isn't in /etc/passwd,
>> seems it doesn't look into slapd, how can I make chsh LDAP-aware?
>
> There is currently no support for chsh (or chfn) because there is no
> standard interface for that (not part of PAM or NSS). You could
> implement those as small applications that off-load the request to nslcd
> and implement it there though but that is currently not implemented.
It's not a big issue for me, people rarely change their login shell and
they can exec() to other shell in ~/.profile anyway. Actually I feel more
comfortable that nslcd can't write my LDAP directory:-)
Thank you very much for your detailed explanation!
Regards,
Yubao Liu
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/