Comment 18 for bug 294977

Revision history for this message
Nick Piggott (nick-piggott) wrote :

The common-account created by pam-auth-update when configuring for cached credentials is failing on my stock Ubuntu Maverick 10.10 install.

The common-account created by pam-auth-update is:

# here are the per-package modules (the "Primary" block)
account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 default=ignore] pam_ldap.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
account required pam_krb5.so minimum_uid=1000
# end of pam-auth-update config

However, this fails because neither pam_unix.so nor pam_ldap.so can succeed when the machine is offline.

This makes all offline logins fail:

user@host:~$ sudo login user
Password:
You have been logged on using cached credentials.

Authentication failure
user@host:~$

If using cached-credentials, common-account needs to be adapted to ignore failures against pam_unix and if the ldap server cannot be reached. My proposed amendment is to amend the criteria for success to the pam_ldap module to:

account [success=1 authinfo_unavail=1 default=ignore] pam_ldap.so

This should ensure that the module "passes" if the LDAP server is unavailable.

A better solution would be to implement the account method for pam_ccreds, which would allow differentiation between a machine that's online but unable to reach the LDAP server, versus a machine that's genuinely offline and relying on cached credentials.