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?
FYI, after reverting d3348f49260998880bb7cd3b2fb72d562b1b7a64 our expired ticket problem
is no more.
Jocke