well the clock sqew allowed is a client side setting and may be different on the two the real question is what is the time on the kerberos server? the clock sqew probably there not on the clients, The clock sqew allowed is set in the/etc/krb5.conf file by default (and also has a default value if not specified) however may be overriden by the library call so in other words the pam module may also over ride the defaults. Sometime they have been known to change the default for clock sqew in the MIT Kerberos libraries between major releases so thats probably why you are seeing this. looking at differences in the upstream NTP servers is only something you should consider when all of the other possibilities are exausted because the public ones are usually getting their time from the same upstream source (usually GPS which is fed by NORAD's atomic clock, or NTP from NIST's or CERN'satomic clocks or other simmilar autoritative source all of which syncronize with eachother regualrly ), and there for are very unlikely to have more than a few miliseconds difference between them which is not enough to cause such an error.
In short look at your Kerberos server not the clients NTP servers as that is most likely where the real clock drift issue is. Then next thing to check is the firewalls because NTP works in a veru unusual way when compared to other protocols on the internet, for example in netfilters firewalls you need to load a special conntrack helper module to support it other wise it breaks due to the inability to the blocking of related connections the source server tries to make back to the client durring the syncronization process. . On Wed, Oct 18, 2017 at 8:10 PM, Stephen Isard <7p03xy...@sneakemail.com> wrote: > On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold <herr...@owlriver.com> > wrote: > > >On Wed, 18 Oct 2017, Howard, Chris wrote: > > > >> Is it possible the two boxes are talking to two different servers? > > > >as the initial post mentioned and showed it was using remote > >host lists to a pool alias, almost certainly -- > > Oh, I took the question to be about the kerberos server. Yes, you are > right, > ntpd -q returns different results on the two machines. However, as I said > in the original post, the time on the two machines is the same to within a > very small amount., well within the five minute tolerance used by > kerberos. So I don't understand why it should matter that the two machines > have arrived at the same time by syncing with different servers. > > >as a way around, set up ONE unit to act as the local master, > >and then sync against it, to get 'site coherent' time > > Could you tell me how to do this, or point me at a document that does? > > Thanks. > > >[a person with more than one clock is never quite _sure_ what > >time is correct ;) ] > > > > > >for extra geek points, spend $25 on AMZN, and get a GPS USB > >dongle; run a local top strata server (the first three > >lintes of the following) > > > >[root@router etc]# ntpq -p > > remote refid st t when poll reach delay > >offset jitter > > ============================================================ > ================= > > GPS_NMEA(0) .GPS. 0 l - 16 0 0.000 > >0.000 0.000 > > SHM(0) .GPS. 0 l - 16 0 0.000 > >0.000 0.000 > > SHM(1) .PPS. 0 l - 16 0 0.000 > >0.000 0.000 > >+ntp1.versadns.c .PPS. 1 u 665 1024 377 51.817 > >-12.510 19.938 > >*tock.usshc.com .GPS. 1 u 294 1024 377 34.608 > >-8.108 10.644 > >+clmbs-ntp1.eng. 130.207.244.240 2 u 429 1024 377 31.520 > >-5.674 7.484 > >+ntp2.sbcglobal. 151.164.108.15 2 u 272 1024 377 23.117 > >-6.825 10.479 > >+ntp3.tamu.edu 165.91.23.54 2 u 1063 1024 377 63.723 > >-3.319 16.813 > >[root@router etc]# > > > > > >configuring ntp.conf is not all that hard > > > >-- Russ herrold >
