I have the following problem:
We are managing the authentication of several servers with Kerberos. The
issue lies in the fact that the servers are in different time-zone, so we
have problem with clock skew errors. Are there any solution or workaround
that accomplish this requirement using different ntp in different time zone
in a way that the KDC server knows which is the real clock skew between two
different time zone?
Let's say i have a server located in Rome and its time is synch with an
italian ntp and we have a server located in New York with time synch with an
American NTP. Considering the time zone the two times are synch, however for
kerberos are desynch.
Is there any workaround or solution to this issue?
We are planning to use a bigger clock skew which will cover the difference
between the two time zones ( this is the worst solution).
Any hint would be helpful.
Thanks in advance.
--
Andrea Cirulli
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
--
Andrea Cirulli
Is this feasible?
________________________________
From: Andrea Cirulli [mailto:acir...@gmail.com]
Sent: Friday, April 17, 2009 4:52 PM
To: Xu, Qiang (FXSGSC); kerb...@mit.edu
Subject: Re: kerberos and time zone
Obviously it is not possible....I cannot make such a decision, because there are sensible data that needs that time is synch with the country in which are located.
So there is no solution?
> Kerberos mailing list Kerb...@mit.edu<mailto:Kerb...@mit.edu>
The time synchronized by NTP is not zone-dependent. Think of it as
getting all machines to agree on what the current UTC time is; the
local time each machine displays will be correct as long as the
machine (including the NTP service) is configured correctly.
> Let's say i have a server located in Rome and its time is synch with
> an
> italian ntp and we have a server located in New York with time synch
> with an
> American NTP. Considering the time zone the two times are synch,
> however for
> kerberos are desynch.
That shouldn't be a problem if the NTP servers are accurate.
A common time-sync problem we used to see in Kerberos is for machines
in different time zones to have their clocks set by hand to the
correct local time, but for the local time zone information to be set
incorrectly so that the machines' ideas of UTC differ. (You'd also
see a local display of the time zone to be incorrect, but since many
clock programs only display the time and not the time zone, it would
be easy to miss.) This can happen, for example, if your OS
installation software sets some default time zone and you don't fix
it, or if you move an installed machine across time zones and "fix"
the clock instead of setting the correct time zone. I've never heard
of this happening with NTP though; the implementations should be using
the operating system's notion of UTC.
If you're still seeing this problem with NTP, I strongly suggest you
investigate why the NTP servers disagree. (One possibility that
occurs to me is that they might be mistakenly configured to
synchronize to locally-set servers that have bad time zone settings
and no synchronization to stratum-1 time servers.)
Ken
I neglected to mention this in my previous message, but the Kerberos
protocol uses UTC time. This is why getting all machines to agree on
UTC (which NTP should do, when configured correctly) is important, and
the time-zone problems we used to see (mostly on really old Windows
systems, I think) were important even if the displayed local time was
correct.
Ken
Let me respond in my capacity as one of the NTP developers.
NTP deals only with UTC. It knows nothing about local timezones. All
national labs that have time standard setups have atomic clocks that
agree with each other to the order of nanoseconds based on the weighted
average of about 250 atomic clocks at the International Bureau of
Weights and Measures in Paris. Kerberos only needs to two systems to be
within 5 minutes of each other by default, which is hardly an onerous
requirement since ntp will keep the clocks within milliseconds of each
other.
In other words, as long as you are running NTP on each system and they
are synching to their servers you have nothing to worry about.
Disagreements between ntp servers based in different countries are too
small for you to measure using ordinary methods.
I hope this helps.
Danny
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.