Hide Forgot
Description of problem: The auth diaglog renews the Kerberos tickets usually however if a ticket has expired (perhaps if it's past it's renewal time I'm unsure it doesn't renew correctly). Version-Release number of selected component (if applicable): How reproducible: Every time but need to be careful. Steps to Reproduce: 1. Configured krb5.conf to offer a short term ticket to ease testing. Set ticket_lifetime = 10m and renew_lifetime = 15m in the libdefaults and pam= section of krb5.conf. 2. kdestroy and kinit and waited for expire and past renewal time (unsure if this step is necessary) and waited about 10 mins extra to check. Left krb5-auth-dialog on screen during expiration period. 3. After renewal time has passed, typed password into krb5-auth-dialog. Actual results: Below the old valid TGT but it has now exired as shown by the date command: [torwood]csimpson: date Fri Mar 31 10:58:23 BST 2006 [torwood]csimpson: klist Ticket cache: FILE:/tmp/krb5cc_2000_ZUe7wv Default principal: csimpson.IOROOT.TLD Valid starting Expires Service principal 03/31/06 10:32:17 03/31/06 10:42:10 krbtgt/UNIX.IOUK.IOROOT.TLD.IOROOT.TLD renew until 03/31/06 10:47:10 Kerberos 4 ticket cache: /tmp/tkt2000 klist: You have no tickets cached Password typed into krb5-auth-diag: [torwood]csimpson: klist Ticket cache: FILE:/tmp/krb5cc_2000_ZUe7wv Default principal: csimpson.IOROOT.TLD Valid starting Expires Service principal 03/31/06 10:58:16 03/31/06 10:42:47 krbtgt/UNIX.IOUK.IOROOT.TLD.IOROOT.TLD renew until 03/31/06 10:47:40 Kerberos 4 ticket cache: /tmp/tkt2000 klist: You have no tickets cached I now seem to have a ticket that expires before it's valid starting date!! The times of the new TGT seem based on the old ticket times rather than the current time or something like that. Typing amother password into krb5-auth-diag continues the problem: Valid starting Expires Service principal 03/31/06 10:59:08 03/31/06 11:08:46 krbtgt/UNIX.IOUK.IOROOT.TLD.IOROOT.TLD renew until 03/31/06 11:13:46 [torwood]csimpson: date Fri Mar 31 11:20:28 BST 2006 Expected results: A new valid TGT. Additional info:
krb5-auth-diaglog still seems broken under FC6 (and on our production systems running RH EL 4 so presumably EL 5 when it appears). The fundamental problem is that it when it brings up the dialog saying that the credentials have expired it renews the TGT from the time that that dialog was brought up rather than the current time. This means that if a TGT expires say in the early evening, the dialog gets brought up. Then when the user appears in the morning and types in the password they get a TGT that has already expired. Not so useful. Then krb5-auth-diag brings up yet another dialog box to renew the expired TGT. To reproduce: % klist Valid starting Expires Service principal 01/26/07 12:02:04 01/26/07 22:02:04 krbtgt/UNIX.IOUK.IOROOT.TLD.IOROOT.TLD renew until 02/02/07 12:02:04 % kdestroy (the krb-auth-diag now appear, but leave it for say a minute) % date Fri Jan 26 12:17:03 GMT 2007 (type password into krb5-auth-diaglog window) % klist Valid starting Expires Service principal 01/26/07 12:16:06 01/26/07 22:15:04 krbtgt/UNIX.IOUK.IOROOT.TLD.IOROOT.TLD renew until 02/02/07 12:15:04 The "Valid starting" time is before current time ie it is set to the time the dialog came up. In the above example the TGT should start somewhere after 12:17 not 12:16.
Since no one is rushing to this one, I've had a look into this myself. I traced this down to a call to krb5_get_init_creds_password that is called with the gnome window being the prompter function passed to it. It turns out kinit behaves this way too. Obviously not a huge problem for it as it isn't run over a long period of time (certianly not like auth-diag is). So say I have shell1 and shell2 on different terminals. shell1% kdestroy shell1% kinit Password for csimpson at UNIX.CSL.CO.UK: shell2% date Sun Mar 25 12:41:22 BST 2007 (wait for a little while) shell2% date Sun Mar 25 12:42:44 BST 2007 (type password into kinit on shell1) shell1% klist Ticket cache: FILE:/tmp/krb5cc_2000_UAdQxX Default principal: csimpson at UNIX.CSL.CO.UK Valid starting Expires Service principal 03/25/07 12:41:08 03/25/07 22:41:08 krbtgt/UNIX.CSL.CO.UK at UNIX.CSL.CO.UK renew until 04/01/07 12:41:08 So I have a TGT valid from the time it prompted and not now. So I presuming that krb5_get_init_creds_password goes and gets the TGT before it asks for the password. I suppose there are valid reasons for this like checking the principal exists or whether the password has expired before prompting etc. Now I posted this query upstream to the MIT krbdev mailing list. The one reply I got says, ========= Don't randomly pop up dialogs that interrupt what the user is doing. Ideally, use renewable tickets when possible. If you're actually going to have to interact with the user, provide a visual indication that the tickets are expired (for example, something in the notification area), and wait for the user to indicate they are ready to renew. If you really feel you must interrupt the user by popping up a dialog when they haven't asked for it, you can work around the problem you described by waiting until the terminal is non-idle before doing so. How to accomplish this is left as an exercise for the reader. -- Jeffrey T. Hutzelman (N3NHS) ========= Now it would be nice is krb5-auth-diag would check if the ticket is renewable and if so renew it when it gets near expiring (at least if that behaviour was flagable)? Any chance. As to the other point about we shouldn't randomly pop up a dialog bog, he's perhaps correct. However without fundamentally rewriting krb5-auth-diag to do this, is another way not to start a timer and if it goes off after say an hour restart the dialog box so we get a decent length TGT. The timer could be reset if the box gets typed in (or maybe focused too) so it wouldn't disappear when someone started typing a password. A bit of a hack but would fix the problem. I don't really want to do this myself unless you have no plans to fix this app.
I looked into doing this at one point. Note that only popping up the dialog when the user requests is still doesn't really fix the problem as they can still leave it up for a long time before entering their credentials even though it is less likely to happen. I then looked into creating a dialog via GTK+, and not going via the krb5 prompter methods, but the problem is that kerberos doesn't provide an API to know whether to login via smartcard or password or other means, so I can't accurately say "please enter your krb5 password" or "please enter your smartcard PIN". I spoke with Nalin, our kerberos developer a few months back and he said he was going to look into updating the timestamp for the request right before the password was sent. Copying him for extra feedback. An additional note though is that krb5-auth-dialog _does_ support renewable credentials already, which should help if you configure your setup to use them. It won't pop up anything in this case and simply renew the ticket automatically for you.
Chris, didn't we already have renewing-if-renewable functionality? To answer your other question, changing the start-time in the AS request right before we transmit it isn't a workable option because preauthentication may involve generating a signature over the request body as it existed while we were prompting the user for information (for example, PKINIT), and mucking around with the request contents would totally break that.
So where should this app go from here, it's very confusing the way it operates just now in that it looks like it's failed to the user when. How about the timer idea I had as a hack , to reset the diag window after say an hour.
Yeah it already has renewing functionality. Preferably kerberos setups would use that. I suppose I'll resurrect my work for the systray stuff and rip out the pieces that would break the prompt. Probably not until next weekend though as I'm sort of strapped this weekend with other stuff.
We do issue tickets that are renewable, however some of our users manage to stay logged in for longer than the renewable time of 7 days. Thanks for your help on this.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
It's still in Fedora 8 and RH5. SO I guess still a bug unless this has changed in F9. Someone earlier said they'd work on it the following weekend, a year a ago...I know priorities etc....
I can confirm it's still in FC9.
changing version to 9 based on comment #10
> The fundamental problem is that it when it brings up the dialog saying that the credentials have expired it renews the TGT from the time that that dialog was brought up rather than the current time. I'm seeing this a lot post thaw/resume. It picks up the old time and the ticket ends up with the time that's too skewed to be useful. Maybe the tool should check if ntpd is configured on the box and if it is wait until the time is synced from the server before renewing? Also, clock script /usr/lib/pm-utils/sleep.d/90clock has a delay of 20 seconds (for the network to come up). Maybe this tool should have a longer delay on thaw/resume to allow for all this to happen?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 234837 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've changed to F10 as it's still in there, haven't tried F11 yet.
New upgrade of krb5-auth-dialog was provided as https://admin.fedoraproject.org/updates/krb5-auth-dialog-0.10-1.fc11, which may affect this bug. Please retest and let us know, whether you can still reproduce this bug.
The krb5-auth-dialog-0.10-1.fc11 does seem to work more cleanly. Even though if you bring the password dialog and leave it there it still just gets a ticket from when the dialog was brought up, this is massively mitigated by it grabbing the keyboard so the user has to pretty much complete this operation (I guess your intention with this implementation). So should fix the original problem, great stuff! One minor wrinkle I noticed was if you leave the password dialog up, it seems to prevent the screen saver running (gnome-screensaver). I presume as it's grabbed the keyboard, there may not be a good way around that. (still don't know why gnome-screen saver's password dialog doesn't renew the TGT, given that you are giving it a password that is check in Kerberos)
(In reply to comment #18) > One minor wrinkle I noticed was if you leave the password dialog up, it seems > to prevent the screen saver running (gnome-screensaver). I presume as it's > grabbed the keyboard, there may not be a good way around that. (still don't > know why gnome-screen saver's password dialog doesn't renew the TGT, given that > you are giving it a password that is check in Kerberos) Assuming the TGT renewal works in gnome-screensaver (which it does for me on EL5), I think the ideal behaviour here is that krb5-auth-dialog closes its window when the screen saver triggers, and that it doesn't open any windows as long as the screen saver is active. This (different) fix from Ubuntu may be of interest: https://bugs.launchpad.net/ubuntu/+source/krb5-auth-dialog/+bug/73550
Regarding comment #18: > still don't know why gnome-screen saver's password dialog doesn't renew the TGT, given that you are giving it a password that is check in Kerberos Gnome screensaver is relying on PAM for authentication. Whatever pam_krb5 does, that is what happens. Try this: kinit -l 10s -r 10s In 10 seconds, your ticket will expire. Do: tail -f /var/log/secure In a terminal. Also, watch the tickets with: watch klist 2>/dev/null Now, lock the screen. Unlock and you'll see messages like this in secure log: Jun 23 21:23:08 machine gnome-screensaver-dialog: pam_krb5[27056]: authentication succeeds for 'bojan' (bojan) However, the ticket times will not move (ie. the ticket will not be reissued). So, this is something that pam_krb5 does or doesn't do, I think. Maybe PAM folks should change something?
Maybe bug #187341?
Hmm, interesting... Strace of gnome-screensaver on lock/unlock doesn't show any file named /tmp/krb5cc_* being opened.
The bug in gnome-screensaver was fixed in RH in my bug #187341. However that bug does appear to be again present in later Fedora distro's, I've just tried F11 and the gnome-screensaver neither renews an expired TGT, renews a current TGT or renews a nonexistent TGT. Even though it takes my Kerberos password to unlock the screen saver.
Here is a bit of code from gnome-screensaver (src/gs-auth-pam.c): ---------------------- /* Each time we successfully authenticate, refresh credentials, for Kerberos/AFS/DCE/etc. If this fails, just ignore that failure and blunder along; it shouldn't matter. Note: this used to be PAM_REFRESH_CRED instead of PAM_REINITIALIZE_CRED, but Jason Heiss <jheiss.edu> says that the Linux PAM library ignores that one, and only refreshes credentials when using PAM_REINITIALIZE_CRED. */ status2 = pam_setcred (pam_handle, PAM_REINITIALIZE_CRED); if (gs_auth_get_verbose ()) { g_message (" pam_setcred (...) ==> %d (%s)", status2, PAM_STRERROR (pam_handle, status2)); } ---------------------- Not sure if the fact that we don't care about credentials being refreshed above matters or not.
I tried this patch with gnome-screensaver: ----------------------------- --- a/src/gs-auth-pam.c +++ b/src/gs-auth-pam.c @@ -545,15 +545,11 @@ gs_auth_thread_func (int auth_operation_fd) } /* Each time we successfully authenticate, refresh credentials, - for Kerberos/AFS/DCE/etc. If this fails, just ignore that - failure and blunder along; it shouldn't matter. - - Note: this used to be PAM_REFRESH_CRED instead of - PAM_REINITIALIZE_CRED, but Jason Heiss <jheiss.edu> - says that the Linux PAM library ignores that one, and only refreshes - credentials when using PAM_REINITIALIZE_CRED. + for Kerberos/AFS/DCE/etc. Use PAM_ESTABLISH_CRED to get new + ticket. */ - status2 = pam_setcred (pam_handle, PAM_REINITIALIZE_CRED); + status2 = pam_setcred (pam_handle, PAM_DELETE_CRED); + status2 = pam_setcred (pam_handle, PAM_ESTABLISH_CRED); if (gs_auth_get_verbose ()) { g_message (" pam_setcred (...) ==> %d (%s)", status2, ----------------------------- However, this creates _another_ ticket - doesn't replace the existing one. In any event, PAM_REINITIALIZE_CRED doesn't appear to do anything to the ticket at all. Hmm, weird... I even tried setting KRB5CCNAME before running gnome-screensaver, but that didn't do anything either. Probably because the environment passed to the libexec program in question didn't pass it along or something. Anyhow, I'll stop now - somebody actually familiar with this code should have a look.
Interesting text in this document: http://www.freeipa.org/page/Automatic_Ticket_Renewal ------------------------- Another factor to keep in mind is that in normal circumstances the user can obtain a completely new ticket simply performing an authentication. A common method to force a new authentication is to lock the machine and provide the user password to the screensaver. This will generate a new PAM authentication which will allow us to obtain a completely new TGT extending renewal time to 14 days from that point on. ------------------------- Except that the screensaver doesn't do that :-(
In reply to comment #25: > Probably because the environment passed to the > libexec program in question didn't pass it along or something. In fact, this environment variable makes it all the way to spawn_on_window() function just fine. Probably something in pam_krb5 after all...
Another interesting test with pam_krb5. It provides a little test program called harness in the src directory, which exercises pam_krb5 machinery. When this program is run like this: src/harness --auth --setcred-reinitialize It will actually reissue the ticket if KRB5CCNAME is set to the correct credentials cache file (usuallly /tmp/krb5cc_`id -u`). If that environment variable is not set, nothing happens to the ticket. I have no idea why gnome-screensaver has no luck doing that when KRB5CCNAME is set, given it's essentially using the same PAM API calls. Weird... BTW, this should work even when KRB5CCNAME is _not_ set in pam_krb5: default ticket should be reinitialised by default. I'll try to contact pam_krb5 developer to see if it can be changed.
For a patch to pam_krb5 that enables gnome-screensaver to obtain a new ticket on unlocking, see bug #507984. Not sure if it is correct, but I'm sure pam_krb5 maintainer will let us know.
Regarding comment #25: > I even tried setting KRB5CCNAME before running gnome-screensaver, > but that didn't do anything either. Not actually true. It does work when this is set.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.