not clear how to configure with pam-auth-update

[Brian May]

Binary package hint: libpam-ccreds

Hello,

It is not clear how to configure the pam config files in intrepid to support libpam-ccreds without risking pam-auth-update overwriting the common-auth file.

The example supplied with libpam-ccreds suggests to use:

auth [success=done default=ignore] pam_unix.so
auth [authinfo_unavail=ignore success=1 default=2] 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
auth [default=bad] pam_ccreds.so action=update

However this conflicts with the Ubuntu default:

auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so

in that it would require changing the pam_ldap entry. Doing that the pam-auth-update way seems to imply modifying /usr/share/pam-configs/ldap which is not a conffile.

Improved documentation on the best way to use this with intrepid would be good.

Brian May

[Colin Whittaker (colin-netech)]

I am facing the same problem and any guidance would be gratefully received.

[Steve Langasek (vorlon)]

Here's a patch to add pam-auth-update integration to libpam-ccreds. I haven't tested it with pam_ldap because I don't have LDAP authentication here; further changes to the LDAP pam-auth-update profile may be needed to get this working as desired (changes that are worth doing for the general case).

Brian, can you test whether this works for you?

[Brian May (brian-microcomaustralia)]

Hmmm. You appear to have missed the action=store, so the cached credentials will never be saved in the first place. My understanding the actions should look something like:

pam_ldap.so use_first_pass
if (authinfo_unavail) {
  pam_ccreds.so action=validate use_first_pass
  pam_ccreds.so action=store
  pam_ccreds.so action=update
} else if (success) {
  pam_ccreds.so action=store
  pam_ccreds.so action=update
} else {
  pam_ccreds.so action=update
}

Where action=validate will check the password with the cached version, and action=store will save it on successful authentication.

I am not really certain what this action=update is - probably need to read the source to find out

Also see <https://help.ubuntu.com/community/PamCcredsHowto>.

Unfortunately I it doesn't seem to install properly either :-(

Selecting previously deselected package libpam-ccreds.
(Reading database ... 172884 files and directories currently installed.)
Unpacking libpam-ccreds (from .../libpam-ccreds_8-1ubuntu1_i386.deb) ...
Setting up libpam-ccreds (8-1ubuntu1) ...
Use of uninitialized value $3 in split at /usr/sbin/pam-auth-update line 237, <INPUT> line 16.
Use of uninitialized value $modline in substitution (s///) at /usr/sbin/pam-auth-update line 239, <INPUT> line 16.
Use of uninitialized value $mod in substitution (s///) at /usr/sbin/pam-auth-update line 242, <INPUT> line 16.
Use of uninitialized value $mod in hash element at /usr/sbin/pam-auth-update line 243, <INPUT> line 16.
Use of uninitialized value $mod in hash element at /usr/sbin/pam-auth-update line 244, <INPUT> line 16.
Use of uninitialized value $modline in concatenation (.) or string at /usr/sbin/pam-auth-update line 258, <INPUT> line 16.

Brian May

[Brian May (brian-microcomaustralia)]

Ok, so I am blind. I double checked and action=store is there.

Unfortunately the resultant /etc/pam.d/common-auth file was not valid, possibly as a result of the perl warnings. So I can't test it any further.

Brian May

[Brian May (brian-microcomaustralia)]

Somehow pam-auth-update also chmod 600 my /etc/pam.d/common-* config files! So xscreensaver wouldn't authenticate anymore :-(.

Maybe it doesn't like my umask of 077?

[Steve Langasek (vorlon)]

On Tue, Mar 10, 2009 at 02:11:03AM -0000, Brian May wrote:
> Hmmm. You appear to have missed the action=store, so the cached
> credentials will never be saved in the first place.

The ccreds config is split between two separate profiles, needed because the
generated config snippets are concatenated linearly.

> I am not really certain what this action=update is - probably need to
> read the source to find out

According to the documentation, "update" is (for some reason) a synonym for
"delete".

> Unfortunately I it doesn't seem to install properly either :-(

> Selecting previously deselected package libpam-ccreds.
> (Reading database ... 172884 files and directories currently installed.)
> Unpacking libpam-ccreds (from .../libpam-ccreds_8-1ubuntu1_i386.deb) ...
> Setting up libpam-ccreds (8-1ubuntu1) ...
> Use of uninitialized value $3 in split at /usr/sbin/pam-auth-update line 237, <INPUT> line 16.
> Use of uninitialized value $modline in substitution (s///) at /usr/sbin/pam-auth-update line 239, <INPUT> line 16.
> Use of uninitialized value $mod in substitution (s///) at /usr/sbin/pam-auth-update line 242, <INPUT> line 16.
> Use of uninitialized value $mod in hash element at /usr/sbin/pam-auth-update line 243, <INPUT> line 16.
> Use of uninitialized value $mod in hash element at /usr/sbin/pam-auth-update line 244, <INPUT> line 16.
> Use of uninitialized value $modline in concatenation (.) or string at /usr/sbin/pam-auth-update line 258, <INPUT> line 16.

Not able to reproduce this here. Can you provide a copy of
/etc/pam.d/common-auth, /var/lib/pam/auth, and /var/lib/pam/seen?

> Somehow pam-auth-update also chmod 600 my /etc/pam.d/common-* config
> files! So xscreensaver wouldn't authenticate anymore :-(.

> Maybe it doesn't like my umask of 077?

Correct. Debian bug #518042, fixed in pam 1.0.1-7.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Brian May (brian-microcomaustralia)]

Just to clarify, do you want these files before or after I install libpam-ccreds?

I will assume after:

brian@sys11:~$ cat /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
auth [success=4 default=ignore] pam_unix.so nullok_secure
auth [success=3 default=ignore] pam_ldap.so use_first_pass
auth [success=2 default=ignore] pam_ccreds.so action=validate use_first_pass
auth
# here's the fallback if no module succeeds
auth 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
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_ccreds.so action=store
auth optional pam_smbpass.so migrate
# end of pam-auth-update config

brian@sys11:~$ cat /var/lib/pam/auth
Module: unix
[success=end default=ignore] pam_unix.so nullok_secure
Module: ldap
[success=end default=ignore] pam_ldap.so use_first_pass
Module: ccreds-check
[success=end default=ignore] pam_ccreds.so action=validate use_first_pass
 [default=ignore] pam_ccreds.so action=update
Module: ccreds-save
optional pam_ccreds.so action=store
Module: smbpasswd-migrate
optional pam_smbpass.so migrate

brian@sys11:~$ cat /var/lib/pam/seen
cracklib
ccreds-save
unix
ldap
smbpasswd-migrate
consolekit
ccreds-check

Not the auth line after action=validate doesn't appear to be valid - this is not a cut&paste error ;-).

Brian May

[Steve Langasek (vorlon)]

On Tue, Mar 10, 2009 at 03:43:31AM -0000, Brian May wrote:
> Just to clarify, do you want these files before or after I install
> libpam-ccreds?

> I will assume after:

Yes, after is fine.

> brian@sys11:~$ cat /var/lib/pam/auth
> Module: unix
> [success=end default=ignore] pam_unix.so nullok_secure
> Module: ldap
> [success=end default=ignore] pam_ldap.so use_first_pass
> Module: ccreds-check
> [success=end default=ignore] pam_ccreds.so action=validate use_first_pass
> [default=ignore] pam_ccreds.so action=update
> Module: ccreds-save
> optional pam_ccreds.so action=store
> Module: smbpasswd-migrate
> optional pam_smbpass.so migrate

> Not the auth line after action=validate doesn't appear to be valid - this
> is not a cut&paste error ;-).

Ok, this is bug #295441, fixed in jaunty but not yet in intrepid, sorry.

I'll work on fixing that; in the meantime you probably want to pull the
jaunty version of pam for testing.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Brian May (brian-microcomaustralia)]

Hello,

My initial attempt at pseudo-code of the example was incorrect, I missed the default=done bit.

Next attempt:

pam_unix.so
if (!success) {
  pam_ldap.so use_first_pass
  if (authinfo_unavail) {
    pam_ccreds.so action=validate use_first_pass
  } else if (success) {
    pam_ccreds.so action=store
  } else {
    pam_ccreds.so action=update
  }
}

Now this makes more sense (action=update - delete - is only called if authentication failed).

Your patch produces something a bit different:

# here are the per-package modules (the "Primary" block)
auth [success=4 default=ignore] pam_unix.so nullok_secure
auth [success=3 default=ignore] pam_ldap.so use_first_pass
auth [success=2 default=ignore] pam_ccreds.so action=validate use_first_pass
auth [default=ignore] pam_ccreds.so action=update
# here's the fallback if no module succeeds
auth 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
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_ccreds.so action=store
auth optional pam_smbpass.so migrate
# end of pam-auth-update config

Which I think is more like:

pam_unix.so nullok_secure
if (!success) {
  pam_ldap.so use_first_pass
}
if (!success) {
  pam_ccreds.so action=validate use_first_pass
}
if (!success) {
  pam_ccreds.so action=update
  pam_deny.so
}
...
pam_ccreds.so action=store

I guess the main difference is the example will only fall back to action=validate if pam_ldap.so returns authinfo_unavail, where as this will fall back to pam_ccreds.so if the passwords mismatch.

ie. consider the case when the user's LDAP password has been changed. Maybe the old password was compromised. Obviously the old password will still be valid with the network disconnected. However, here both the old and new passwords will be valid when the system is connected to the network again, until the user enters the new password at least once. I could imagine this could be potentially confusing.

Another difference is it will call action=update if the user enters the password incorrectly, and there is no network connection.

If I try to log in using cached credentials, it seems to work fine, but then kicks me off again.

% ssh localhost
brian@localhost's password:
You have been logged on using cached credentials.
Connection closed by 127.0.0.1

Oh, right, this is probably because /etc/pam.d/common-account was not updated.

The example config is:

account [user_unknown=ignore authinfo_unavail=ignore default=done] pam_unix.so
account [user_unknown=ignore authinfo_unavail=ignore default=done] pam_ldap.so
account required pam_permit.so

I don't know why the "user_unknown=ignore" is required, I think the important part is the "authinfo_unavail=ignore" for the pam_ldap.so line. Or in the case of the intrepid file, I added "authinfo_unavail=1" to skip the pam_deny.so

Fo...

[Brian May (brian-microcomaustralia)]

FYI I filed bug #340836 on the issue of action=update being a NOP.

Brian May

[Josh North (josh-north)]

Just wondering if this is still an issue in jaunty? I've been working with Hardy LTS for a couple of networks I manage and have been considering updating a dev net to start testing openldap in Jaunty.

Also, was it ever determined what the correct order should be in the pam conf files (common-account and common-auth by the looks)? I realize this isn't a support forum but I'm willing to offer my time/resources for testing if it helps.

[Brian May (brian-microcomaustralia)]

I never got a response to my last email to Steve Langasek. I could always hope that it has been fixed in Jaunty (I haven't updated any of my systems yet).

I suspect, if there was a solution, then Steve Langasek would have already asked me to test it.

The problem is that 3 return values from pam_ldap are significant (user unknown, auth unavailable, anything else), and I suspect the pam-auth-update infrastructure is not flexible enough to be able to handle this, not without changing the pam

Brian May

[Brian May (brian-microcomaustralia)]

oops. Got distracted.

I meant to say "...without changing the pam configuration for pam_ldap which is possibly not a very good solution as it would then affect everyone".

Brian May

[Brian J. Murrell (brian-interlinx)]

I'm quite interested in this too. Any progress/update? An update that says "cannot be done with current implementation" would at least set expectations correctly.

Thanx!

[Petter Reinholdtsen (pere-hungry)]

I tested the configuration from the patch in comment #2 on lucid, and it seem to work just fine.
I'm testing with libpam-ldapd and libnss-ldapd.

[Mathias Gug (mathiaz)]

Marking Fix Released in Maverick since libpam-ccreds supports pam-auth-update since 10-3 and maverick has 10-5.

[Schlomo Schapiro (sschapiro)]

I would like to see this backported to lucid because I had to use auth-client-config to configure libpam-ccreds and I got lots of problems with pam-auth-update overwriting the common-* files each time a new pam module gets installed.

[Nick Piggott (nick-piggott)]

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.

[David Burke (bufke)]

Still failing in Lucid. Nick's suggestion gets rid of the authentication error, but in my case I still get user not known to underlying authentication module. Anyone have this working on Lucid?

[David Burke (bufke)]

The user not known issue was caused by pam_ldap accepting capital letters in usernames while pam-ccreds doesn't. So Nick's suggestion does seem to solve the problem.

Also IMO common-auth pam-ccreds should be above pam_ldap. Otherwise a user not on the network will have to wait for the timeout each time logging in. I don't see any disadvantage here and switching them seems to work fine for me.

[Etienne Goyer (etienne-goyer-outlands)]

David, the disadvantage of placing pam_ccred before pam_ldap in the stack is that the password will be validated first against the local cache. If it have just been updated, the old one will still work for a little while, which is not good in most circumstance.