Re: [Freeipa-users] Screensaver unlock with expired password
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
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Screensaver unlock with expired password
On 04/14/2012 08:20 AM, Sigbjorn Lie wrote: Hi, I ran into a issue with unlocking the screensaver when an users password has expired. These results are from RHEL 5. When running KDE and unlocking a screensaver with an expired password, an error message is displayed advising that the password subsystem has failed with instructions to kill the PID of the screensaver manually. When running GNOME and unlocking the screensaver with an expired password, an unlock is allowed, but no message is displayed, and the kerberos ticket is not renewed. Neither of these situations are ideal. A workaround for KDE is to switch to a console login window with CTRL-ALT-F2, and log in where you will be prompted for changing your password. Switch back to KDE, and unlock the screensaver with the new password. Not really user friendly. We did have the krb5-auth-dialog running, but it turned out that after being away over the weekend there many of these appearing on the screen on monday morning, and once you typed in your password a new kerberos ticket was aquired with start date of when the krb5-auth-dialog appeared!! So if I left the office on Friday, and the krb5-auth-dialog appeared on Saturday, I would get a ticket expiring on the Sunday that's already passed, even though I typed in the password on Monday, rendering the ticket useless for authenticating anywhere... so we removed this package from our workstations. Has anyone else run into these sort of issues? I would like to know how you chose to work around these issues. Thanks. It can also be a client configuration or software problem. What do you use on the client? SSSD? nss_ldap+pam_krb5? I assume you use IPA as a server. You can check the logs on the server to see whether the new password is requested. The client logs would really show what is going on. 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. Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Screensaver unlock with expired password
On 04/16/2012 03:33 PM, Dmitri Pal wrote: On 04/14/2012 08:20 AM, Sigbjorn Lie wrote: Hi, I ran into a issue with unlocking the screensaver when an users password has expired. These results are from RHEL 5. When running KDE and unlocking a screensaver with an expired password, an error message is displayed advising that the password subsystem has failed with instructions to kill the PID of the screensaver manually. When running GNOME and unlocking the screensaver with an expired password, an unlock is allowed, but no message is displayed, and the kerberos ticket is not renewed. Neither of these situations are ideal. A workaround for KDE is to switch to a console login window with CTRL-ALT-F2, and log in where you will be prompted for changing your password. Switch back to KDE, and unlock the screensaver with the new password. Not really user friendly. We did have the krb5-auth-dialog running, but it turned out that after being away over the weekend there many of these appearing on the screen on monday morning, and once you typed in your password a new kerberos ticket was aquired with start date of when the krb5-auth-dialog appeared!! So if I left the office on Friday, and the krb5-auth-dialog appeared on Saturday, I would get a ticket expiring on the Sunday that's already passed, even though I typed in the password on Monday, rendering the ticket useless for authenticating anywhere... so we removed this package from our workstations. Has anyone else run into these sort of issues? I would like to know how you chose to work around these issues. Thanks. It can also be a client configuration or software problem. What do you use on the client? SSSD? nss_ldap+pam_krb5? I assume you use IPA as a server. You can check the logs on the server to see whether the new password is requested. The client logs would really show what is going on. 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. Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Screensaver unlock with expired password
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
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
