Re: clock skew too great ** EXTERNAL **

[Stephen Isard]

On Thu, 19 Oct 2017 12:48:42 -0400, Paul Robert Marino  
wrote:

>Here is a question was it using preauth?
>In other words is there a  key tab file in /etc?

No.

>The other question is NTP set to sync the time on shutdown to the bios?

I don't think so.  Certainly no setting in /etc/ntp.conf or /etc/sysconfig/ntp. 
 In any case there was no shutdown between the last successful kinit and the 
first skew error message.

>There are a couple of reasons why I can think this might happen the first
>involves how NTP corrects the time and how it may interact with how an
>option in MIT kerberos client works and that article. There is an incorrect
>statement in that article about disabling the time sync. It's not that the
>option disables the time sync it just corrects for it when the ticket is
>created to mask the issue. The problem with that is NTP usually doesn't
>sync the time in one shot by default it only corrects it in less than 1
>second increments so it doesn't break time dependant things like cron jobs.
>That flag in combination with the default behavior of NTP can cause an
>artificial clock skew issue later.
>Now you can set in /etc/sysconfig an option in the NTP settings to tell it
>to do an initial full sync on boot before starting ntpd but it is not the
>default behavior in 6 if I remember correctly. If a ticket had been created
>and the clock had been more than 5 minutes out of sync you would have
>gotten a clock skew error after the clock had corrected its self because it
>would still have still been compensating for the initial skew. In this case
>kdestroy would clear the skew correction and the new key would be
>unaffected.
>
>The other possibility is that if preauth is being used there could have be
>something wrong in how the service credential was created in the kerberos
>server which is quite common if the server is an AD server, and sometimes
>happens with Heimdal kerberos servers too. Essentially the other
>possibility is it may have a max ticket renewal set on the principal in
>which case a kdestroy may force it to redo the preauth and then create a
>new ticket. Usually you can correct this in the kerberos server if your
>Kerberos admin really knows it well sadly most AD admins don't :(. I've had
>to show more than a few of them over the years articles on Microsoft
>technet,  and tell them just do that and stop insisting it can't be done.
>
>By the way that article is right about one thing the DNS reverse lookup in
>MIT kerberos can be problematic because it can't support the use of CNAMEs
>in the forward lookup, and is not specified any where in any of the
>ratified RFCs ( in fact it was proposed and rejected by committee on that
>basis) so it causes more problem especially when it interacts with other
>kerberos implementation or is implemented in the cloud. It's also the only
>implementation of Kerberos 5 that does it. It's not the only place where
>MIT kerberos violates the RFCs and those violations are the reason why you
>can't use it for Samba version 4 AD server, and why most Linux based
>appliances that support kerberos use Heimdal kerberos.
>
>
>On Oct 19, 2017 11:48 AM, "Stephen Isard" <7p03xy...@sneakemail.com> wrote:
>
>> On Thu, 19 Oct 2017 09:09:32 -0500, Pat Riehecky 
>> wrote:
>>
>> >If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does
>> >not.  This could account for why one works and the other does not.
>> >
>> >Pat
>> >
>> >[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos
>>
>> That looks promising as an explanation.
>>
>> The problem has been "solved", or at least it has gone away, although I
>> don't really understand why.  Without any clear hypothesis as to why it
>> might help, I decided to run "kdestroy -A" on the affected machine to clear
>> expired tickets out of my local cache.  That did it.  No more clock skew
>> messages.  So it looks as if it was a kerberos issue, rather than an ntp
>> one, and the error message wasn't really explaining what was wrong.
>>
>> Thanks to everyone for their advice.
>>
>> Stephen Isard
>> >
>> >On 10/18/2017 07:10 PM, Stephen Isard wrote:
>> >> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold 
>> 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, 

Re: clock skew too great ** EXTERNAL **

[Paul Robert Marino]

Here is a question was it using preauth?
In other words is there a  key tab file in /etc?
The other question is NTP set to sync the time on shutdown to the bios?

There are a couple of reasons why I can think this might happen the first
involves how NTP corrects the time and how it may interact with how an
option in MIT kerberos client works and that article. There is an incorrect
statement in that article about disabling the time sync. It's not that the
option disables the time sync it just corrects for it when the ticket is
created to mask the issue. The problem with that is NTP usually doesn't
sync the time in one shot by default it only corrects it in less than 1
second increments so it doesn't break time dependant things like cron jobs.
That flag in combination with the default behavior of NTP can cause an
artificial clock skew issue later.
Now you can set in /etc/sysconfig an option in the NTP settings to tell it
to do an initial full sync on boot before starting ntpd but it is not the
default behavior in 6 if I remember correctly. If a ticket had been created
and the clock had been more than 5 minutes out of sync you would have
gotten a clock skew error after the clock had corrected its self because it
would still have still been compensating for the initial skew. In this case
kdestroy would clear the skew correction and the new key would be
unaffected.

The other possibility is that if preauth is being used there could have be
something wrong in how the service credential was created in the kerberos
server which is quite common if the server is an AD server, and sometimes
happens with Heimdal kerberos servers too. Essentially the other
possibility is it may have a max ticket renewal set on the principal in
which case a kdestroy may force it to redo the preauth and then create a
new ticket. Usually you can correct this in the kerberos server if your
Kerberos admin really knows it well sadly most AD admins don't :(. I've had
to show more than a few of them over the years articles on Microsoft
technet,  and tell them just do that and stop insisting it can't be done.

By the way that article is right about one thing the DNS reverse lookup in
MIT kerberos can be problematic because it can't support the use of CNAMEs
in the forward lookup, and is not specified any where in any of the
ratified RFCs ( in fact it was proposed and rejected by committee on that
basis) so it causes more problem especially when it interacts with other
kerberos implementation or is implemented in the cloud. It's also the only
implementation of Kerberos 5 that does it. It's not the only place where
MIT kerberos violates the RFCs and those violations are the reason why you
can't use it for Samba version 4 AD server, and why most Linux based
appliances that support kerberos use Heimdal kerberos.


On Oct 19, 2017 11:48 AM, "Stephen Isard" <7p03xy...@sneakemail.com> wrote:

> On Thu, 19 Oct 2017 09:09:32 -0500, Pat Riehecky 
> wrote:
>
> >If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does
> >not.  This could account for why one works and the other does not.
> >
> >Pat
> >
> >[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos
>
> That looks promising as an explanation.
>
> The problem has been "solved", or at least it has gone away, although I
> don't really understand why.  Without any clear hypothesis as to why it
> might help, I decided to run "kdestroy -A" on the affected machine to clear
> expired tickets out of my local cache.  That did it.  No more clock skew
> messages.  So it looks as if it was a kerberos issue, rather than an ntp
> one, and the error message wasn't really explaining what was wrong.
>
> Thanks to everyone for their advice.
>
> Stephen Isard
> >
> >On 10/18/2017 07:10 PM, Stephen Isard wrote:
> >> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold 
> 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 

Re: clock skew too great ** EXTERNAL **

[Stephen Isard]

On Thu, 19 Oct 2017 09:09:32 -0500, Pat Riehecky  wrote:

>If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does 
>not.  This could account for why one works and the other does not.
>
>Pat
>
>[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos

That looks promising as an explanation.

The problem has been "solved", or at least it has gone away, although I don't 
really understand why.  Without any clear hypothesis as to why it might help, I 
decided to run "kdestroy -A" on the affected machine to clear expired tickets 
out of my local cache.  That did it.  No more clock skew messages.  So it looks 
as if it was a kerberos issue, rather than an ntp one, and the error message 
wasn't really explaining what was wrong.

Thanks to everyone for their advice.

Stephen Isard
>
>On 10/18/2017 07:10 PM, Stephen Isard wrote:
>> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold  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-   1600.000
>>> 0.000   0.000
>>> SHM(0)  .GPS.0 l-   1600.000
>>> 0.000   0.000
>>> SHM(1)  .PPS.0 l-   1600.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
>
>-- 
>Pat Riehecky
>
>Fermi National Accelerator Laboratory
>www.fnal.gov
>www.scientificlinux.org

Re: clock skew too great ** EXTERNAL **

[Stephen Isard]

On Thu, 19 Oct 2017 09:16:00 -0400, Paul Robert Marino  
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 <7p03xy...@sneakemail.com>
>wrote:
>
>> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold 
>> 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-   1600.000
>> >0.000   0.000
>> > SHM(0)  .GPS.0 l-   1600.000
>> >0.000   0.000
>> > SHM(1)  .PPS.0 l-   1600.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
>>
>

Re: [SCIENTIFIC-LINUX-USERS] clock skew too great ** EXTERNAL **

[Paul Robert Marino]

As I said they probably have a different setting for the allowed clock skew
so I would check the time on the kerberos server
Note in MIT kerberos in the krb5.conf file this can be set via the
'clockskew' option in the "libdefaults"section. It is specified in seconds
and usually defaults to 300 seconds check out the krb5.conf man page for
details there is also an option to allow the client to compensate for it
and detect the actual skew but I don't recommend tinkering with it because
it can cause issues.
Also note that if you kerberos server is an AD server windows clients
usually use their AD server as their default NTP source otherwise they go
to Microsoft's  pool of NTP servers.

On Oct 19, 2017 10:09 AM, "Pat Riehecky"  wrote:

> If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does
> not.  This could account for why one works and the other does not.
>
> Pat
>
> [1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos
>
> On 10/18/2017 07:10 PM, Stephen Isard wrote:
>
>> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold 
>> 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-   1600.000
>>> 0.000   0.000
>>> SHM(0)  .GPS.0 l-   1600.000
>>> 0.000   0.000
>>> SHM(1)  .PPS.0 l-   1600.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
>>>
>>
> --
> Pat Riehecky
>
> Fermi National Accelerator Laboratory
> www.fnal.gov
> www.scientificlinux.org
>

Re: [SCIENTIFIC-LINUX-USERS] clock skew too great ** EXTERNAL **

[Pat Riehecky]

If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does 
not.  This could account for why one works and the other does not.


Pat

[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos

On 10/18/2017 07:10 PM, Stephen Isard wrote:

On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold  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-   1600.000
0.000   0.000
SHM(0)  .GPS.0 l-   1600.000
0.000   0.000
SHM(1)  .PPS.0 l-   1600.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


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: clock skew too great ** EXTERNAL **

[Paul Robert Marino]

no difference there the time in both protocals are based on EPOC which
means it is always using GMT time regardless of the OS settings.
So that should make no difference in this case, though without NTP involved
that has been a know issue for encrytion in genneral so its not a bad
question just most likely irrelivant in this case.


On Thu, Oct 19, 2017 at 9:42 AM, Howard, Chris <howa...@prpa.org> wrote:

> How about timezone?
>
>
> -Original Message-
> From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:
> owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen Isard
> Sent: Wednesday, October 18, 2017 5:43 PM
> To: scientific-linux-us...@listserv.fnal.gov
> Subject: Re: clock skew too great ** EXTERNAL **
>
> On Wed, 18 Oct 2017 21:02:53 +, Howard, Chris <howa...@prpa.org>
> wrote:
>
> >Is it possible the two boxes are talking to two different servers?
>
> Thanks for the idea, but no.  The admin_server entry in /etc/krb5.conf is
> the same on both machines, and the host command returns the same ip address
> for that machine name on both machines.
>
>
>
> >-Original Message-
> >From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:
> owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen Isard
> >Sent: Wednesday, October 18, 2017 2:47 PM
> >To: scientific-linux-us...@listserv.fnal.gov
> >Subject: clock skew too great ** EXTERNAL **
> >
> >Hello,
> >
> >I have two laptops side by side, one running SL6, the other SL7, both up
> >to date.  According to the date command, their times agree to within a
> >small fraction of a second.
> >
> >On both machines, I normally run kinit to get a kerberos ticket in the
> >same realm.  Today, the SL7 machine gets its ticket normally, but the
> >SL6 one shows an error message "Clock skew too great while getting
> >initial credentials".  Since the clocks of the two machines appear to
> >agree, I would have expected that either both should produce the error
> >or neither.  From what I have read on the web, the standard tolerance
> >for clock skew is 5 minutes, and the agreement between the times on the
> >two machines is well within that.
> >
> >Both machines have ntpd running, using the time servers
> >[0-3].rhel.pool.ntp.org.  Powering off the SL6 machine and rebooting
> >does not restore sanity.  The problem just arose today.  There have been
> >no system updates on the SL6 machine since it successfully got its
> >ticket yesterday.
> >
> >Any suggestions for what to try?
> >
> >Stephen Isard
> >
> >
> > *** This email is from an EXTERNAL sender ***
> >Use caution before responding. DO NOT open attachments or click links
> from unknown senders or unexpected email. If this email appears to be sent
> from a Platte River Power Authority employee or department, verify its
> authenticity before acting or responding. Contact the IT Help Desk with any
> questions.
>

RE: clock skew too great ** EXTERNAL **

[Howard, Chris]

How about timezone?


-Original Message-
From: owner-scientific-linux-us...@listserv.fnal.gov 
[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen 
Isard
Sent: Wednesday, October 18, 2017 5:43 PM
To: scientific-linux-us...@listserv.fnal.gov
Subject: Re: clock skew too great ** EXTERNAL **

On Wed, 18 Oct 2017 21:02:53 +, Howard, Chris <howa...@prpa.org> wrote:

>Is it possible the two boxes are talking to two different servers?

Thanks for the idea, but no.  The admin_server entry in /etc/krb5.conf is the 
same on both machines, and the host command returns the same ip address for 
that machine name on both machines.



>-Original Message-
>From: owner-scientific-linux-us...@listserv.fnal.gov 
>[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen 
>Isard
>Sent: Wednesday, October 18, 2017 2:47 PM
>To: scientific-linux-us...@listserv.fnal.gov
>Subject: clock skew too great ** EXTERNAL **
>
>Hello,
>
>I have two laptops side by side, one running SL6, the other SL7, both up 
>to date.  According to the date command, their times agree to within a 
>small fraction of a second.
>
>On both machines, I normally run kinit to get a kerberos ticket in the 
>same realm.  Today, the SL7 machine gets its ticket normally, but the 
>SL6 one shows an error message "Clock skew too great while getting 
>initial credentials".  Since the clocks of the two machines appear to 
>agree, I would have expected that either both should produce the error 
>or neither.  From what I have read on the web, the standard tolerance 
>for clock skew is 5 minutes, and the agreement between the times on the 
>two machines is well within that.
>
>Both machines have ntpd running, using the time servers 
>[0-3].rhel.pool.ntp.org.  Powering off the SL6 machine and rebooting 
>does not restore sanity.  The problem just arose today.  There have been 
>no system updates on the SL6 machine since it successfully got its 
>ticket yesterday.
>
>Any suggestions for what to try?
>
>Stephen Isard
>
>
> *** This email is from an EXTERNAL sender *** 
>Use caution before responding. DO NOT open attachments or click links from 
>unknown senders or unexpected email. If this email appears to be sent from a 
>Platte River Power Authority employee or department, verify its authenticity 
>before acting or responding. Contact the IT Help Desk with any questions.

Re: clock skew too great ** EXTERNAL **

[Paul Robert Marino]

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 
> 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-   1600.000
> >0.000   0.000
> > SHM(0)  .GPS.0 l-   1600.000
> >0.000   0.000
> > SHM(1)  .PPS.0 l-   1600.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
>

Re: clock skew too great ** EXTERNAL **

[Stephen Isard]

On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold  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-   1600.000
>0.000   0.000
> SHM(0)  .GPS.0 l-   1600.000
>0.000   0.000
> SHM(1)  .PPS.0 l-   1600.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

Re: clock skew too great ** EXTERNAL **

[Stephen Isard]

On Wed, 18 Oct 2017 21:02:53 +, Howard, Chris <howa...@prpa.org> wrote:

>Is it possible the two boxes are talking to two different servers?

Thanks for the idea, but no.  The admin_server entry in /etc/krb5.conf is the 
same on both machines, and the host command returns the same ip address for 
that machine name on both machines.



>-Original Message-
>From: owner-scientific-linux-us...@listserv.fnal.gov 
>[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen 
>Isard
>Sent: Wednesday, October 18, 2017 2:47 PM
>To: scientific-linux-us...@listserv.fnal.gov
>Subject: clock skew too great ** EXTERNAL **
>
>Hello,
>
>I have two laptops side by side, one running SL6, the other SL7, both up 
>to date.  According to the date command, their times agree to within a 
>small fraction of a second.
>
>On both machines, I normally run kinit to get a kerberos ticket in the 
>same realm.  Today, the SL7 machine gets its ticket normally, but the 
>SL6 one shows an error message "Clock skew too great while getting 
>initial credentials".  Since the clocks of the two machines appear to 
>agree, I would have expected that either both should produce the error 
>or neither.  From what I have read on the web, the standard tolerance 
>for clock skew is 5 minutes, and the agreement between the times on the 
>two machines is well within that.
>
>Both machines have ntpd running, using the time servers 
>[0-3].rhel.pool.ntp.org.  Powering off the SL6 machine and rebooting 
>does not restore sanity.  The problem just arose today.  There have been 
>no system updates on the SL6 machine since it successfully got its 
>ticket yesterday.
>
>Any suggestions for what to try?
>
>Stephen Isard
>
>
> *** This email is from an EXTERNAL sender *** 
>Use caution before responding. DO NOT open attachments or click links from 
>unknown senders or unexpected email. If this email appears to be sent from a 
>Platte River Power Authority employee or department, verify its authenticity 
>before acting or responding. Contact the IT Help Desk with any questions.

RE: clock skew too great ** EXTERNAL **

[Howard, Chris]

Is it possible the two boxes are talking to two different servers?



-Original Message-
From: owner-scientific-linux-us...@listserv.fnal.gov 
[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Stephen 
Isard
Sent: Wednesday, October 18, 2017 2:47 PM
To: scientific-linux-us...@listserv.fnal.gov
Subject: clock skew too great ** EXTERNAL **

Hello,

I have two laptops side by side, one running SL6, the other SL7, both up 
to date.  According to the date command, their times agree to within a 
small fraction of a second.

On both machines, I normally run kinit to get a kerberos ticket in the 
same realm.  Today, the SL7 machine gets its ticket normally, but the 
SL6 one shows an error message "Clock skew too great while getting 
initial credentials".  Since the clocks of the two machines appear to 
agree, I would have expected that either both should produce the error 
or neither.  From what I have read on the web, the standard tolerance 
for clock skew is 5 minutes, and the agreement between the times on the 
two machines is well within that.

Both machines have ntpd running, using the time servers 
[0-3].rhel.pool.ntp.org.  Powering off the SL6 machine and rebooting 
does not restore sanity.  The problem just arose today.  There have been 
no system updates on the SL6 machine since it successfully got its 
ticket yesterday.

Any suggestions for what to try?

Stephen Isard


 *** This email is from an EXTERNAL sender *** 
Use caution before responding. DO NOT open attachments or click links from 
unknown senders or unexpected email. If this email appears to be sent from a 
Platte River Power Authority employee or department, verify its authenticity 
before acting or responding. Contact the IT Help Desk with any questions.