passwd_compat: ldap?

[Brian K. Jones]

OK, I'm still trying to get this straight. Things work, but I have some 
questions about exactly *how*. I hope someone can help, as I'm not a 
very good source code reader.

I guess I really want to understand why it is that you need pam_ldap at 
all for 'auth' and 'account' settings in '/etc/pam.d/system-auth'. I'm 
using 'passwd_compat: ldap' successfully right now, but not if I change 
my pam settings to just use pam_unix.

The only conclusion I can come up with is that glibc's libnss_compat 
only implements an understanding of the '+' syntax in the passwd/shadow 
files to perform a search, but doesn't implement doing an actual bind 
operation to perform authentication. I'm guessing nss_ldap doesn't 
support a bind for authentication either (or doesn't support returning a 
success/fail value back to the caller). I *believe* that this is 
different from the Sun implementation (not that that's necessarily bad - 
I just want to make sure I understand this right). I'm pretty sure you 
don't even need pam_ldap (even if you've replaced their {pam,nss}_ldap 
with PADL's) to perform authentication against LDAP in that environment.

Since nss_ldap/nss_compat can do a search, they must support binding, 
since they bind anonymously to search.  Why, then, can they not perform 
a bind for the purpose of authentication - or do I have something else 
goofed up in my logic?

Thanks,
brian.



Nalin Dahyabhai wrote:
> On Wed, Jan 28, 2004 at 01:47:35PM -0500, Brian K. Jones wrote:
> 
>>I've asked this question before, and on several other mailing lists, but 
>>no answer yet.
>>
>>I want to be able to authenticate users using 'compat' against an ldap 
>>directory, such that this notation works (in nsswitch.conf)
>>
>>passwd: compat
>>passwd_compat: ldap
>>
>>I've heard rumours that this does work in RHEL 3, so I'm trying to
>>figure out what the magic incantation is to get it working in FC 1.
>>Under FC1, the syntax in nsswitch doesn't cause an error - but it
>>doesn't enforce the '+username' notation in /etc/passwd either -
>>anyone with a valid account on the ldap server gets in. Presumably,
>>this is a glibc-specific, and not a nss_ldap-specific issue, since
>>libnss_compat is bundled with glibc.
> 
> 
> First, check that you have glibc 2.3.2-58 or newer -- its changelog
> suggests that this is a minimum.  Then, bypass login and check what
> applications get from glibc to make sure you understand what's going on
> (i.e., start with the basics and work your way up).
> 
> Do that by running "getent passwd" to get the entire list of users which
> are visible to your system.  Or try "getent passwd username" to check if
> applications can look up information about a particular user.  Check
> this both as "root" and as an unprivileged user to make sure you don't
> have a permissions problem somewhere on the client system.
> 
> If that all works (and it did on my test box), then the problem may be
> something else.
> 
> HTH,
> 
> Nalin
> 
>