Hi there!

With the default sid configuration, pam_ccreds.so fails to authenticate
(at least) LDAP users with the following message:
=====
luca@gismo:~$ su luca.capello
Password:
You have been logged on using cached credentials.
su: Authentication failure
luca@gismo:~$
=====

The problem is the pam_deny.so entry in /etc/pam.d/common-account
(attached): as the comment states, "the default is to only deny service
to users whose accounts are expired in /etc/shadow".  Obviously, LDAP
users are not in /etc/shadow and the LDAP server can not be contacted,
thus the failure.

FYI, this situation has already been reported in Ubuntu:

  <https://bugs.launchpad.net/ubuntu/+source/libpam-ccreds/+bug/294977>

The only solution I found is to disable the pam_deny.so entry, but I
agree with Nick Piggott (X-Debbugs-Cc:ed) about the optimal solution:

  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.

Please note that per se this bug is not IMHO in libpam-ccreds, so feel
free to either reassign it to libpam-modules or, probably better, to
downgrade it to wishlist for the account method implementation.

Thx, bye,
Gismo / Luca

tags 618722 +help
severity 618722 wishlist
thanks

Hi Luca,
On Thu, Mar 17, 2011 at 11:30:18PM +0100, Luca Capello wrote:
[..snip..]

I've always used s.th. similar to what is suggested in the pam-ccreds
documentation:

other   account [user_unknown=ignore default=done]      /lib/security/pam_unix.so
other   account [authinfo_unavail=ignore default=done]  /lib/security/pam_ldap.so
other   account [default=done]                          /lib/security/pam_permit.so

but I agree that handling this via pam-ccreds makes sense. I'm tagging
this +help and whishlist then. Would be great if somebody comes up with
a patch. Detecting that the machine is offlince is the hard part.

It would also be great to have a co-maintainer since I'm not using
pam-ccreads myself at the moment.
Cheers,
 -- Guido

Hi!

Struggled with this bug for a few days and tried various approaches,
including removing the pam_deny.so in common-account. Turned out to be a
bad idea, as adding new users to the system resulted in a chfn error.

I ended up with the following solution, which doesn't break pam-auth-update.

Change the common-account file in /usr/share/pam, and replace
"requisite" with "optional". Run pam-auth-update and make sure that the
/etc files are updated.

pam-ccreds should now work properly (tested on debian wheezy).


Raymond Pettersen

user contact@itopie.ch
usertags 618722 + itopie.ch-installation
user it@codha.ch
usertags 618722 + codha.ch-installation
thanks

Hi there,
common-account does the trick.

However, that should not be done in /usr/share/pam/common-account, since
such modification will be lost whenever the package will be upgraded (or
reinstalled).  Thus, it is better to modify /etc/pam.d/common-account
instead, which is preserved even after a pam-auth-update run.

To answer Guido's request for co-maintenance: I moved to sssd for a
while now, but I am currently testing a wider setup and evaluating again
pam-ccreds...

Thx, bye,
Gismo / Luca