Message-ID: <200410221329.i9MDT72m002403@pop-7.dnv.wideopenwest.com>
From: mvp at joeware.net (joe)
Subject: Windows Time Synchronization - Best Practices

> So right off the bat you know you are sacrificing something.  
> Why settle for less than the best when the best is free?

Two reasons. Say you don't need the full feature set of NTP and/or you
manage hundreds of thousands of machines globally and you don't want to have
to add something additional. 

Microsoft Windows Domains are to my knowledge, the only systems out of the
box dependent on kerberos. Time is extremely important for kerberos and
extremely important for Windows Domains. I have seen many examples of the
Windows SNTP implementation working perfectly fine across very large
companies with several hundred thousand machines with no need to
install/manage any other software. These environments fall into the default
Windows Domain configuration of the members talking to their domain
controller for time and their domain controller going up the chain until you
get to the forest root PDC which takes its time from some defined time
source(s). Even if the defined time source isn't correct the entire forest
has the same wrong time which is actually more important for a majority of
the work done in a domain than having the exact right time. Additionally I
managed a Windows AD Domain environment with some 200,000+ Windows machines
for 4 years and almost never had to think about time because the builtin
Windows time system worked. The points I had to think about it were when
someone took it into their own hands and set their own time sources either
with the Windows software or with third party software and that time source
wasn't accurate. If the time is wrong across an entire forest that is almost
certainly the fault of the admins configuring the DCs or the vendor
consultants for the company not knowing what they are talking about - not a
failing in SNTP. 

If you take on one-off home PCs, people can do whatever they want for time.
Managing additional software on your home personal PC is extremely different
from doing it for tens or hundreds of thousands of machines across the
world. Additionally, if your home PC time is different from some other
machine, it usually won't impact your ability to logon to the local machine
because you are using the local PCs IDs though it could impact various other
secure transactions with other systems.


>> Never heard of time.microsoft.com being down or incorrect.

> Me neither, but it has been unreachable.  Since the original requestor 
> was from Brazil I would think that reachability would be an issue for him.


time.microsoft.com is simply a default if nothing else is set. Change it,
that is extremely easy. 

> Yeah, but you are still stuck with only ONE server, you are stuck with
SNTP 
> and you have almost no way to tell if the time daemon is doing the right
thing.

Incorrect on all accounts except you are using SNTP and you still haven't
shown a valid reason why that is bad. 

 
  joe


-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Gary E. Miller
Sent: Thursday, October 21, 2004 5:47 PM
To: Cushing, David
Cc: full-disclosure@...ts.netsys.com
Subject: RE: [Full-Disclosure] Windows Time Synchronization - Best Practices

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo David!

On Thu, 21 Oct 2004, Cushing, David wrote:

> > In my experience NTP will work a lot better for you than Windows 
> > Time server.
>
> Windows time service uses SNTP.

SNTP is RFC 2030, It says:

   "SNTP can be used when the ultimate performance of the full
   NTP implementation described in RFC-1305 is not needed or justified."

So right off the bat you know you are sacrificing something.  Why settle for
less than the best when the best is free?

RFC 2030 Continues:

   "It is strongly recommended that SNTP be used only at the extremities
   of the synchronization subnet. SNTP clients should operate only at
   the leaves (highest stratum) of the subnet and ..."

   "The full degree of reliability ordinarily expected of primary servers
   is possible only using the redundant sources, diverse subnet paths
   and crafted algorithms of a full NTP implementation. "

Seems to me that rules out using it to connect to the stratum 1 in Seattle,
WA from Brazil.

> > The protocol is robust and you are not dependent on the single point 
> > of failure called: time.microsoft.com.
>
> Never heard of time.microsoft.com being down or incorrect.

Me neither, but it has been unreachable.  Since the original requestor was
from Brazil I would think that reachability would be an issue for him.  Last
time I was monitoring reachability to Brazil there were often outages and
bottlenecks to there from the US.

> You can use 'net time' or regedit to change it.
>
> http://www.microsoft.com/windows2000/docs/wintimeserv.doc

Yeah, but you are still stuck with only ONE server, you are stuck with SNTP
and you have almost no way to tell if the time daemon is doing the right
thing.

With NTP you can designate a local master that gets it's time from a diverse
set of sources.  It is easy to verify and monitor it's proper functioning.
Then you can redistribute it to your local hosts.

Contrary to what some may believe, accurate time is very important to
security.

One time keys, like S/Key, depend on accurate time for their functioning.

Any stronge encryption scheme, like IPSec, needs a good clock at both ends
to default antireplay attacks

When debugging a major system crash, involving many routers, switches,
hosts, etc. it is important to have well synced clocks to determine first
failure.

Stick exchanges require members to use accurate clocks to help prevent
fraud.

Etc...

RGDS
GARY
-
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	gem@...lim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBeC5w8KZibdeR3qURAjDhAJ9kue1cKLMrcVykpL4P03XyCnuB+ACbBL4b
mNs+1jkUA470nRGx6ZXPGGA=
=9SAK
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists