[OpenAFS] Openafs Client with pam krb5 and ldap

[Russ Allbery]

Andy Cobaugh <phalenor@gmail.com> writes:
> On 2010-10-01 at 20:30, Russ Allbery ( rra@stanford.edu ) 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
>> /etc/shadow.

> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>