Bug#656352: pu: package libpam-krb5/4.3-1squeeze1
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: pu
Filing this in advance of actually doing the update work....
libpam-krb5 4.4-3 in unstable added the following change (from
NEWS.Debian):
The default PAM configuration for the password stack changed in this
version to skip all other modules if the Kerberos password change
succeeded. This works better and with fewer strange errors for the
common case of Kerberos accounts not having a local password.
If you want to instead synchronize your local and Kerberos passwords,
you will need to not manage the module with pam-auth-update and instead
manually configure the password stack to run both pam_krb5 and pam_unix.
See /usr/share/doc/libpam-krb5/README.Debian.gz for more details.
Without this change, users of the module where accounts are only in
Kerberos and some external user source like LDAP and don't occur in
/etc/shadow were unable to use it to change Kerberos passwords, because
pam_unix would reject the password change due to the missing /etc/shadow
entry. The change is basically a single line in the pam-configs
configuration:
--- a/debian/pam-auth-update
+++ b/debian/pam-auth-update
@@ -12,9 +12,9 @@ Account:
required pam_krb5.so minimum_uid=1000
Password-Type: Primary
Password:
- requisite pam_krb5.so minimum_uid=1000 try_first_pass use_authtok
+ [success=end default=ignore] pam_krb5.so minimum_uid=1000 try_first_pass use_authtok
Password-Initial:
- requisite pam_krb5.so minimum_uid=1000
+ [success=end default=ignore] pam_krb5.so minimum_uid=1000
Session-Type: Additional
Session:
optional pam_krb5.so minimum_uid=1000
However, it's not backward-compatible. If one was relying on the previous
behavior, this change will require switching away from the defaults.
Petter Reinholdtsen from DebianEdu requested this change make it into
stable as well, since it's causing problems for them (they set up accounts
in Kerberos and LDAP only by default).
What do the stable release managers think? Is this something that would
be reasonable to do in stable? I think it does improve the package for
the majority use case, but it's a larger change in configuration than I
would normally propose for a stable update.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.1.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Reply to: