nslcd + GSSAPI basic design
[Date Prev][Date Next] [Thread Prev][Thread Next]nslcd + GSSAPI basic design
- From: Marc us <coboluxx [at] outlook.com>
- To: "nss-pam-ldapd-users [at] lists.arthurdejong.org" <nss-pam-ldapd-users [at] lists.arthurdejong.org>
- Subject: nslcd + GSSAPI basic design
- Date: Wed, 10 Apr 2013 16:56:05 +0000
Hi all,
I am working on a single sign-on solution on a larger network. From what I have found trough all of my researches there is some issue with all the LDAP account providers and I am wondering if there is something wrong with my understanding about how they should behave. We use Kerberos for authentication and tickets are only granted to machines where the user has access to. This is task is handled by the Kerberos infrastructure so we don't need any LDAP operation at this point. We don’t even need an existing unix account on the host the user signs in at this point. The users TGT is created by the pam_krb5 module, sssd or whatever you prefer for the authentication task. However, for an successful login or further authorization checks we need the Unix account information and this the point where we need the LDAP infrastructure and this is where my problem starts. No matter if I use nslcd/pam_ldap or sssd, the call to getent will use the hosts TGT (or whatever principal+keytab we have configured) for the LDAP bind operation instead of the already existing TGT created during the authentication process. As an result of this behavior the statically configured principal must have permissions to lookup account information on the directory. From my understanding this is a wrong behavior as anyone would be able to enumerate the whole directory. I know that enumeration can be disabled but this won’t stop anyone with root access to retrieve a ticket using the keytab file and start an ldapsearch. On a hosting environment where you can’t trust any root account this is a problem. Restricting the host principal to be able to retrieve only some authorized entries would be an administrative nightmare and would result in a large overhead for security checks on the LDAP servers. Allowing a user principal to retrieve its own account information and nothing else is a simple task without much overhead. I understand that this behavior would result in other issues as UID/GID pairs of other users may not be resolvable with the actually logged on principal but I currently can’t see a real problem with this other than making a caching layer more complicated or unusable. Now I am wondering if this is because of some restrictions on how the getent things work on Unix, if I am doing something wrong or if this is just not implemented the way I thought this should work. Thanks for your ideas on this J
Marcus |
-- To unsubscribe send an email to nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see http://lists.arthurdejong.org/nss-pam-ldapd-users/
- nslcd + GSSAPI basic design, Marc us
- Re: nslcd + GSSAPI basic design,
Arthur de Jong
- RE: nslcd + GSSAPI basic design,
Marc us
- Re: nslcd + GSSAPI basic design, Arthur de Jong
- RE: nslcd + GSSAPI basic design,
Marc us
- Prev by Date: Re: [PATCH] Nested groups
- Next by Date: Re: nslcd + GSSAPI basic design
- Previous by thread: Re: [PATCH] Nested groups
- Next by thread: Re: nslcd + GSSAPI basic design