Andy Cobaugh <[email protected]> writes: > On 2010-10-01 at 20:30, Russ Allbery ( [email protected] ) 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 ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
