[Freeipa-users] Screensaver unlock with expired password

[Nalin Dahyabhai]

On Mon, Apr 16, 2012 at 11:17:35PM +0200, Sigbjorn Lie wrote:
> The clients use nss_ldap+pam_krb5, SSSD was crashing for us on RHEL 5.
> 
> The server is the IPA server provided in RHEL 6.2.
> 
> When I check the logs on the client it states that authentication
> succeeded, and that the password has expired.  And that's where the
> screensaver fails. It show an info message that the password has
> expired, and then an error message advising that "The password
> subsystem has failed..."
> 
> >Best would be if you provide a clear reproduction steps and file a
> >ticket attaching logs and configuration to it.
> >If it is a bug in SSSD we would need to fix it ASAP though we have not
> >seen this behavior in SSSD ever.
> 
> This is not SSSD, I believe it either comes down to lack of support
> in the KDE screensaver or a requirement for change in the PAM
> configuration. The current PAM configuration is set by the
> system-config-auth script with the" --enable-ldap --enable-krb5"
> options.
> 
> I was hoping for a change in the PAM configuration and that someone
> had an example that works to advise me about.

Short version: try turning on the "chpw_prompt" option for pam_krb5, by
setting something like this in /etc/krb5.conf:

 [appdefaults]
  pam = {
   chpw_prompt = kscreensaver gnome-screensaver
  }

Long version: as you've noticed, some applications don't quite do what
PAM expects of them when the user's password has expired.  When the user
needs to set a new password, PAM is supposed to succeed in the
authentication phase, and then return an specific status, indicating
that a password change is needed, in the account management phase.

Based on that second result, the application can either start a password
change through PAM (and then allow access only if that change operation
succeeds), or reject the user if it can't handle a password change
(think of FTP servers, where the protocol keeps a server from being able
to ask for a new password).  Some applications don't know to do either,
so the password-expired status is treated as a fatal error, and that
appears to be what's going on here.

Turning on the "chpw_prompt" option causes pam_krb5 to let libkrb5
attempt to change the password, during authentication, if a password
change is needed.  Depending on the application, that might be enough to
fix things.  It depends on the application to not just reply with the
same password without relaying the question to the user, and you don't
get the chance to add any client-side password quality checking via PAM,
but it might work if the application can handle multiple prompts
correctly.

If that change allows users to log in (or unlock their screens, in this
case), then you've found a bug in the PAM-enabled application, which is
unfortunately not unheard of.  The need to provide this option was first
reported [1] after we fixed pam_krb5 to do the right thing [2].

HTH,

Nalin

[1] https://bugzilla.redhat.com/show_bug.cgi?id=509092
[2] https://bugzilla.redhat.com/show_bug.cgi?id=402721