pam-auth-update creates a 'common-account' that fails with cached logins

[Nick Piggott]

Running Ubuntu 11.04 on a Dell Mini 1018 Netbook

On a system running LDAP, Kerberos and Cached Credentials, pam-auth-update creates a 'common-account' file that will always fail if the machine uses cached credentials (presumably because it's offline).

The relevant lines from the common-account file:

# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.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
account [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore authinfo_unavail=ignore default=bad] pam_ldap.so minimum_uid=1000
# end of pam-auth-update config

This will always fail if the machine is off-line, because pam_unix.so will fail and cause the module to end with the next line which makes pam_deny.so a requisite.

As a patch, I have commented out all of common-account except the line requiring pam_permit.so, but this is unsatisfactory.

Two solutions could be proposed:
* Write a common-account file that will pass if all the component modules fail due to the user or the service being absent. That is - only fail if it is explicitly required to fail, rather than failing if pam_unix.so fails because the user is in ldap or cached.
* Implement a (dummy?) "account" method in pam_ccreds and add that into the relevant profile for cached credentials in pam_auth_update

[Steve Langasek (vorlon)]

> * Implement a (dummy?) "account" method in pam_ccreds and add that into the
> relevant profile for cached credentials in pam_auth_update

That's what needs to happen here. pam_unix has no way of knowing why the user's shadow entry is missing; and arguably this is a bug in your NSS setup anyway rather than anything to do with PAM, because NSS should be cached as well for offline use.

[Nick Piggott (nick-piggott)]

I agree that cached shadow would enable pam_unix to operate correctly.

As far as I'm aware, nss_updatedb does not support local caching of shadow, only passwd and group, and the db option can't be used on the shadow entry (only files and ldap) in nsswitch.conf. I presume that's because of security implications?

The absence of cached shadow would rule out using pam_unix at this stage.

It looks like your preferred option is to add "account" method support to pam_ccreds, and the presumably amend pam-auth-update to include that in the module processing.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[uwe (maabdulhaq)]

I've also got it to work by commenting out the line:

account requisite pam_deny.so

in common-account

This is also not satisfactory i guess; it will never deny, right?

[Nick Piggott (nick-piggott)]

I've subsequently implemented a slightly more elegant solution:

# 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)
# end of pam-auth-update config

This works. There are more useful options in the pam_ldap.so module, but I can't get them to behave properly and I am not a PAM guru. I'm a bit fed up of locking myself out of my own system.

pam-auth-update needs an update.

[Nick Piggott (nick-piggott)]

** PLEASE IGNORE THE ABOVE COMMENT **
It's the wrong common-account.

This is the correct one:

# here are the per-package modules (the "Primary" block)
account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 authinfo_unavail=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)
# end of pam-auth-update config

The critical section is "authinfo_unavail=1" in the pam_ldap.so line, which causes the module to pass if LDAP is absent.

[uwe (maabdulhaq)]

i second #6 , the recipe here http://ubuntuforums.org/showthread.php?t=1708785 works for me too, the critical section is also as mentioned authinfo_unavail=1 . fixing this will boost ubuntu linux usage in network environment with central auth !

[uwe (maabdulhaq)]

So, what can fix this bug? does pam-update-auth have a mechanism to make complix or mutually exclusive selections?

If not, either such a capability is to be impleneted; or a package for ldap+ccreds is created and user will have to manaully select it from the menu of pam-update-auth. is there other options?

[yahia reda abdulqawi (yahiareda0)]

a file that can be placed in /usr/share/pam-configs that will create another choice in pam-update-auth to use ldap in conjunction with ccreds is attached.

should it be included in ccreds package for example? or is there a totally different and/or better approach?

[uwe (maabdulhaq)]

the ldap-with-ccreds should include a line after priority saying:

Conflicts: ldap

as it does not stack over ldap, but actually is a slight modification of it, unless there is a cleaner way to actually modify ldap pam defs when used in conjunctions with ccreds.

my guess this https://wiki.ubuntu.com/PAMConfigFrameworkSpec is relevant.

uwe

[uwe (maabdulhaq)]

Modified version of the ldap-with-ccreds

[Reinhard Mayr (czerwinski1977)]

This helped me on 16.04: http://kennywest.blogspot.co.at/2007/04/pamccreds-howto.html

>> QUOTE
Update /etc/pam.d/common-auth:

auth sufficient pam_unix.so
auth [authinfo_unavail=ignore success=1 default=die] pam_ldap.so use_first_pass
auth [default=done] pam_ccreds.so action=validate use_first_pass
auth [default=done] pam_ccreds.so action=store use_first_pass
auth [default=done] pam_ccreds.so action=update use_first_pass

Update /etc/pam.d/common-account:

account sufficient pam_unix.so nullok_secure
account sufficient pam_ldap.so
account required pam_permit.so
<< QUOTE