On Tue, 2017-05-23 at 15:45 +0200, Joakim Tjernlund wrote: > On Tue, 2017-05-23 at 15:31 +0200, Jakub Hrozek wrote: > > On Tue, May 23, 2017 at 01:03:49PM +0000, Joakim Tjernlund wrote: > > > On Tue, 2017-05-23 at 11:40 +0200, Lukas Slebodnik wrote: > > > > On (23/05/17 09:19), Joakim Tjernlund wrote: > > > > > On Tue, 2017-05-23 at 11:07 +0200, Lukas Slebodnik wrote: > > > > > > On (23/05/17 08:39), Joakim Tjernlund wrote: > > > > > > > On Tue, 2017-05-23 at 10:11 +0200, Joakim Tjernlund wrote: > > > > > > > > On Mon, 2017-05-22 at 22:29 +0200, Lukas Slebodnik wrote: > > > > > > > > > On (22/05/17 14:53), Joakim Tjernlund wrote: > > > > > > > > > > > The time is not synchronised between client and server. > > > > > > > > > > > MIT krb5 can handle small offset. But I would highly > > > > > > > > > > > recommends > > > > > > > > > > > to keep time in sync. > > > > > > > > > > > > > > > > > > > > There is some time problem on and off but this has never > > > > > > > > > > been too much. I don't > > > > > > > > > > think this was the root problem here ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > As I already mention I would highly recommend to keep time in > > > > > > > > > sync. > > > > > > > > > It will reduce possible errors. > > > > > > > > > > > > > > > > > > Configure ntpd/chrony on client and server is not a rocket > > > > > > > > > science :-) > > > > > > > > > > > > > > > > Sure, no rocket science but I have little control over the AD > > > > > > > > servers. :( > > > > > > > > Anyhow, I did a "net ads info" and it came back with Server > > > > > > > > time offset: 0 > > > > > > > > so I don't think there is a time difference(or very small)? > > > > > > > > The clients are already on NTP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Renewing of a ticket failed because it is already expired. > > > > > > > > > > > Maybe due to time shift between client and server(KDC) > > > > > > > > > > > > > > > > > > > > Yes, it is expired to begin with. I got a ticket, then > > > > > > > > > > suspended the computer long enough for > > > > > > > > > > the ticket to expire(10 hours here) and then woke up and > > > > > > > > > > unlocked the screen. > > > > > > > > > > The problem is that sssd never tries to get a new ticket > > > > > > > > > > using my creds I gave when unlocking. > > > > > > > > > > Even if I do several lock/unlocks after the network is > > > > > > > > > > restored, sssd will not get me a new ticket. > > > > > > > > > > > > > > > > > > > > > > > > > > > > sssd would get new ticket if it was in online mode. > > > > > > > > > But it offline mode. > > > > > > > > > > > > > > > > > > I would highly recommend to keep time in sync with server > > > > > > > > > and then debug why sssd was in offline mode. > > > > > > > > > Or why it went to offline mode. > > > > > > > > > > > > > > > > > > With 1.15 you can use sssctl e.g. > > > > > > > > > > > > > > > > I did run sssctl domain-status infinera.com and it came back > > > > > > > > with: > > > > > > > > Unable to get online status [3]: Communication error > > > > > > > > org.freedesktop.DBus.Error.NoReply: Did not receive a reply. > > > > > > > > Possible causes include: the remote application > > > > > > > > did not send a reply, the message bus security policy blocked > > > > > > > > the reply, the reply timeout expired, or the > > > > > > > > network connection was broken. > > > > > > > > Check that SSSD is running and the InfoPipe responder is > > > > > > > > enabled. Make sure 'ifp' is listed in the 'services' > > > > > > > > option in sssd.conf. > > > > > > > > Unable to get online status > > > > > > > > > > > > > > > > I then just added 'ifp' to 'services' and restarted sssd and > > > > > > > > now it works: > > > > > > > > sssctl domain-status infinera.com > > > > > > > > Online status: Online > > > > > > > > > > > > > > > > Active servers: > > > > > > > > AD Global Catalog: not connected > > > > > > > > AD Domain Controller: se-dc01.infinera.com > > > > > > > > ..... > > > > > > > > > > > > > > > > Could the problem I saw be related to not having ifp in > > > > > > > > services ? > > > > > > > > I will check again when the ticket expires again. > > > > > > > > > > > > > > > > Jocke > > > > > > > > > > > > > > but krb5_child log just repeats: > > > > > > > > > > > > > > > > > [SNIP] > > > > > > > > > > > > > > > > > > > (Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] > > > > > > > [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640416: > > > > > > > Response was not from master KDC > > > > > > > > > > > > > > (Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] > > > > > > > [sss_child_krb5_trace_cb] (0x4000): [30164] 1495527829.640436: > > > > > > > Got cred; -1765328352/Ticket expired > > > > > > > > > > > > > > (Tue May 23 10:23:49 2017) [[sssd[krb5_child[30164]]]] > > > > > > > [map_krb5_error] (0x0020): 1643: [-1765328352][Ticket expired] > > > > > > > > > > > > The most confusing for me was a reason why we went offline. > > > > > > And after checking the source code I found out a reason. > > > > > > > > > > > > We map expired ticket(KRB5KRB_AP_ERR_TKT_EXPIRED) to network error > > > > > > (ERR_NETWORK_IO) since 1.14.2 > > > > > > > > > > > > https://pagure.io/SSSD/sssd/issue/3174 > > > > > > https://pagure.io/SSSD/sssd/c/d3348f49260998880bb7cd3b2fb72d562b1b7a64 > > > > > > > > > > > > It might be a reasonable with first kinit. Because new ticket > > > > > > should be valid. > > > > > > But we should treat it differently for renewing ticket. > > > > > > > > > > Ahh, nice. I wonder though if there could be a short wait for the > > > > > network to come on? > > > > > Usually the unlock window is presented shortly before network is on > > > > > so when fast unlock > > > > > sssd will be offline and no new ticket which causes some grief for > > > > > users. > > > > > > > > > > > > > > > > > Thank you very much for bug report. > > > > > > And sorry that it took me so long to find a bug. > > > > > > > > > > NP, glad you found something. Please send patch my way, I will test > > > > > it directly. > > > > > > > > > > > > > ATM I do not have a higher priority tasks. And I am not sure when > > > > someone > > > > from developers will have a time to fix it. > > > > > > > > The fastest workaround should be to revert the patch > > > > d3348f49260998880bb7cd3b2fb72d562b1b7a64. > > > > > > Right, this seems to be the right thing anyhow, mapping these to errors > > > to network IO error > > > does seem odd. > > > > So what would you propose the deamon does if libkrb5 tells it that the > > server is out of sync? > > Not sure, possibly the same as now but it should be handled separately so one > can differentiate(don't pretend it is an network error).
hmm, what will happen now that I have reverted the above patch w.r.t KRB5KRB_AP_ERR_TKT_EXPIRED ? Will sssd not let me in at all unless I get a network connection to the AD? Jocke _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
