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?



Freeipa-users mailing list

Reply via email to