Re: How to configure for delegated authentication
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
Re: How to configure for delegated authentication
- From: Jeff Mitchell <jeff [at] jefferai.org>
- To: nss-pam-ldapd-users [at] lists.arthurdejong.org
- Subject: Re: How to configure for delegated authentication
- Date: Tue, 04 Oct 2011 22:39:49 -0400
On 10/4/2011 5:42 PM, Christopher Wood wrote:
> On Tue, Oct 04, 2011 at 05:22:48PM -0400, Jeff Mitchell wrote:
>> Hello,
>>
>> I have a service (git, via gitolite) that I'd like to make
>> available to users. The problem is that we have about 4k users and
>> I'd like not to have to create and synchronize local accounts on
>> the box for each one.
>>
>> I'm currently having two issues:
>>
>> 1) The best way for me to do this would be to perform what's often
>> called "delegated authentication" against LDAP. Instead of going to
>> LDAP to look up the user credentials, I need to test the given
>> user credentials by doing a bind against LDAP with those given
>> credentials
>
> As near as I can tell, nslcd already tests user login in by binding
> as that user (at least the way it's set up in Debian). I don't have
> binddn/bindpw configured in /etc/nslcd.conf, and my OpenLDAP ACLs
> disallow "read" on the userPassword attribute.
Really? The documentation says that if no binddn/bindpw is set that it
will bind anonymously. So it seems either the documentation is wrong, or
Debian patches things...?
>> (or even better, with a given binddn/bindpw but then do a rebind,
>> I think it's called, with the given user credentials -- it's what
>> many web apps do). Our LDAP server itself goes to a third party to
>> validate credentials, so the LDAP server does not have password
>> information, hence why I need to do authentication based upon bind
>> results. I'm not sure how I can do this, or if I can do this...I'm
>> happy to try to help implement it if needed, but I'd probably need
>> some hand-holding.
>
> This sounds like the translucent proxy in OpenLDAP:
>
> http://www.openldap.org/doc/admin24/overlays.html#Translucent%20Proxy
That seems to just allow you to override attributes, but I can't really
overridde the user's password since I don't actually know it.
>> 2) I would need to return a particular shell for the user in order
>> to continue with the git functionality. From the earlier nss_ldap I
>> should have been able to use the nss_override_attribute_value
>> command, but from the current sources it looks like that's been
>> removed...?
>
> If these aren't shell users, why not change the loginShell for the
> entry to be whatever will enable git? Either in the proxy config or
> in the remote ldap server. (Your mileage may vary.)
Because the entries don't have a loginShell value.
It looks like Translucent Proxy could let me do this, yes, but then I
have to set up an entire OpenLDAP instance to return the same single
value for every user. This seems like the perfect use of
nss_override_attribute_value, but it seems gone, with no indication of why.
Thanks,
Jeff
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/