Re: How to configure for delegated authentication

[Christopher Wood <christopher_wood [at] pobox.com>]

On Tue, Oct 04, 2011 at 10:39:49PM -0400, Jeff Mitchell wrote:
> 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...?

Crank up the debug level and see!

> >> (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.

I definitely assumed that you were using standard ldapauth schema. Drat.

> 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/
> 
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/