[OpenAFS] Openafs Client with pam krb5 and ldap
Fri, 01 Oct 2010 21:22:40 -0700
Andy Cobaugh <email@example.com> writes:
> On 2010-10-01 at 20:30, Russ Allbery ( firstname.lastname@example.org ) said:
>> I wonder if pam_krb5 is a red herring here and what's actually failing
>> is pam_unix. Do the accounts you're trying to log in as exist in
>> /etc/shadow? Does it work if you remove pam_krb5 and only keep
>> pam_unix? pam_unix does require all accounts be present in
> These accounts exist through ldap, so no entries in /etc/shadow.
> It fails in the same manner with just pam_krb5.
> pam_krb5 and pam_permit together work.
Oh, I understand now. pam_unix fails, and you were expecting pam_krb5 to
return success (blindly) to counter pam_unix's failure, but since pam_krb5
(correctly) returns PAM_IGNORE for users about which it has no
information, logins are failing because of the pam_unix failure. Or, if
you remove pam_unix, because all modules in the stack returned PAM_IGNORE.
The problem is that you've worked around this by essentially disabling the
account stack completely. I think what you have now is equivalent to
having nothing but pam_permit.
The right solution to your problem is probably to add pam_ldap to the
account stack so that *something* in the account stack verifies that the
user actually exists, or just shrug and go with just pam_permit and
basically plan on not using the account stack and hope everything checks
things properly during auth. (pam_krb5 will do so; it's account function
just redoes checks that it already did during auth.)
> Is your pam_krb5 returning nothing for pam_sm_acct_mgmt with gssapi ssh
> logins perhaps?
Right, it can't return anything useful since PAM isn't used with GSSAPI
logins, so it returns PAM_IGNORE, which contributes nothing to the PAM
return status. But as you say you have to have something in the stack
succeed, and pam_unix is going to actually fail in your situation.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>