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
