[Freeipa-users] Screensaver unlock with expired password

[Sigbjorn Lie]

On Mon, April 16, 2012 23:43, Nalin Dahyabhai wrote:
> 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
>


Hi Nalin,

Thank you for your reply.

I have testing this and it works with GNOME! It did not work with KDE, I was still advised that
the password had expired, but then there we're not further messages, and I was returned to the
unlock prompt.

Unfortunately we are running KDE in our client production environment.

Do you have any other suggestions I could try?

Thanks.


Regards,
Siggi