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.

LS
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to