RSS feed

Re: How to configure for delegated authentication

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

Re: How to configure for delegated authentication

On 10/05/2011 03:59 PM, Arthur de Jong wrote:
> On Tue, 2011-10-04 at 17:22 -0400, Jeff Mitchell wrote:
>> 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
>> (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).
> This should be what nslcd does. It does anonymous bind by default (use
> binddn/bindpw for non-anonymous bind) to find the user and after that
> tries to bind the with the user's credentials. nslcd doesn't do password
> validation itself.

Hm -- then this is not working for me for some reason. I have a proper
bind user and password, and it finds the user, but it fails to actually
validate the user credentials once it finds the user. I assumed this was
because it was looking for a password attribute in the user's record,
but should it simply be using the username/password given to PAM then?

>> 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...?
> nslcd.conf has the map option which implements the
> nss_override_attribute_value feature like so:
>   map passwd loginShell "/bin/bash"
> The loginShell attribute will no longer be requested from LDAP but
> returned the same for all users. See the nslcd.conf manual page for more
> complex values that you can supply for attribute mapping.

Great, thanks.

To unsubscribe send an email to or see