On Thu, 19 Oct 2017 09:16:00 -0400, Paul Robert Marino <[log in to unmask]> wrote:

>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?

My only access to the server is via kinit, so I can't see the time there or the krb5.conf file.  But it seems unlikely that they would suddenly have switched to millisecond tolerance for skew when the standard is 5 minutes.

>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 <[log in to unmask]>
>wrote:
>
>> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold <[log in to unmask]>
>> 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
>>
>