有关时间服务器的笔记
近日想在校园网上建一台时间服务器，供全校电脑同步时钟。以下是网上找来的资料


http://www.ccw.com.cn/htm/app/salon/01_8_10_3.asp
在局域网中设置Linux时间服务器

吴阿亭 ( Jephe Wu )?
01-8-10 下午 02:20:23

--------------------------------------------------------------------------------


一 概述：?
本文主要目的是简单介绍如何在局域网上设置一台Linux时间服务器与互联网上的时间服务器同步并且如何使局域网上其它Linux及Windows客户向该Linux时间服务器同步。
二 服务器设置
首先说明我们如何设置LAN上的时间服务器同互联网上的第一或者第二级时间服务器同步来保证精确的时间。
1. 如何让LAN的时间服务器(第三级)与互联网上的时间服务器(第一或者第二级)同步
a. XNTP包，包含在大多数Linux CD里面。?
主页在http://www.eecis.udel.edu/~ntp/?
你只需要在/etc/ntp.conf中设置server和driftfile两项参数即可，server项你可以从上面的主页中找公共的时间服务器域名。例如?
server rackety.udel.edu
server umd1.umd.edu
server lilben.tn.cornell.edu
driftfile /etc/ntp/drift?
然后启动XNTPD后台程序?
#/etc/rc.d/init.d/xntpd start
b. "getdate"，随Slackware而来的小程序，推荐使用，大多数时候，我们对时间的精确性要求不是非常的苛刻，所以这个程序完全够用而且很方便。
下载ftp://metalab.unc.edu/pub/Linux/system/network/misc/getdate_rfc868-1.2.tar.gz
然后设置下面的scripts 取名为/usr/local/sbin/get-date.sh
#!/bin/sh
timehosts="otc2.psu.edu wwvb.erg.sri.com ntp.nasa.gov"
if /usr/local/bin/getdate -adjust 10 200 $timehosts > /dev/null; then
/sbin/clock --systohc
fi
现在可以设置cronjob每小时进行同步
0 0-23 * * * /usr/local/sbin/get-date.sh
2. 如何使得LAN上其它linux/windows客户与该台服务器同步
a. 如果该台时间服务器也是局域网上的Samba服务器,则对Windows来说，不需要安装任何时间同步软件，因为windows客户可以用
net time \\timeserver /set /yes来与之同步。可以放该命令在startup
中自次启动windows时自动同步
net time 命令利用Netbios over TCP/IP协议来同步时间?
但仅对Windows客户有效，Linux客户无法使用。
b. 如果服务器运行NTP后台服务程序，例如前面讲的XNTPD，则对
Windows:
可以安装下面的两个免费软件与服务器同步?
http://home.att.net/~Tom.Horsley/ntptime.html (ntptime)
单一的后台程序，自动寻找LAN上的NTP服务器，可在控制面板中设置同步条件?
http://nettime.sourceforge.net/ (Nettime)
支持NTP(udp/123) , time(udp/37), time(tcp/37)
Linux:?
则可以用ntpdate(随XNTPD而来)运行作为cronjob 与 该局域网上的时间服务器同步。
c. 如果该台服务器使用getdate与互联网上时间服务器同步，则
你可以设置/etc/inetd.conf，打开time udp和time tcp服务，让linux/windows客户与之同步。对windows,你可以使用象上面介绍的Nettime软件。
对Linux客户,你可以用rdate -s 运行作为cronjob 与之同步
time stream tcp nowait root internal
time dgram udp wait.200 root internal
Linux下的rdate -s 命令使用time (37/tcp) , Nettime 你可以指定37/tcp或者37/udp
三 FAQ
1. 怎样确定net time用的是Netbios over TCP/IP?
在Samba服务器上运行tcpdump
# /usr/sbin/tcpdump host 192.168.1.3
(192.168.1.3是windows客户端的IP地址)
2. 怎样确定windows NTP客户ntptime正在后台与Linux NTP时间服务器同步？
在NTP服务器上运行
# tcpdump udp port 123?
查看输出
默认是每五分钟ntptime向NTP服务器查询一次，你可以从主页上下载控制面板中的控制条件设置程序

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
http://www.ddvip.net/os/freebsd/index/71.htm
配置系统时间

对于网络操作系统来讲，由于要向多个客户提供服务，因此必须拥有一个精确的系统时间。可以使用 date命令来显示当前的时间：

$ date

1999年 4月10日 星期六 18时51分39秒 CST

date命令按中文方式输出的前提是指定环境变量LC_ALL为zh_CN.EUC，这是用于本地化的一种标准方式。

由于用于 Internet上的网络操作系统的客户可能来自世界的不同地区，因此时间系统必须能标识出不同的时区。计算机中的CMOS时间能设置为两种不同的时间，一种是将CMOS时间设置为格林威治标准时间，使用时区修正给出本地时区的正确时间，另一种方法是将CMOS时间设置为本地时区时间，再使用本地时区修正得到格林威治标准时间。这样系统和其他计算机通信时就能使用标准时间，避免不同时区的计算机时间的差异。

系统安装程序在进行时区设置时将询问用户使用那种时间设置方式及时区设置，系统安装完成之后，也可以直接使用 tzsetup命令来设置时区信息。所有的时区信息保存在/usr/share/zoneinfo目录中，而本机的时区设置信息保存在/etc/localtime文件中。此外，每个用户也可以使用环境变量TZ来设置与系统不同的时区，这个设置将覆盖系统的设置。

root用户可以使用带参数date来更改系统时间，例如以下命令将时间设置为1999年3月1日，下午1点54分。

# date 9903011354

1999年 3月 1日 星期一 13时54分00秒 CST

可以看出时间格式为年、月、日、时、分，每个各占两个数字，其形式即为 yymmddhhmm，大部分情况下是对时间进行小调整，可以略去前面的年月日部分，而仅使用四位数字表示时、分，形如hhmm。

1) 通过 Internet 同步时间
手工设置时间一方面不方便，另一方面也依赖于本地管理员的时钟的正确性，那么网络上不同的管理员管理的计算机时间必然有偏差，不同计算机的时间偏差就会对一些要求时间同步的服务产生影响。解决这种问题的方法很简单，连接到一个能提供精确时间的服务器上进行时间同步。

当计算机连接到了 Internet之后，那么就能同Internet上存在的很多时间服务器通信，以获得精确的时间。TCP/IP协议中，用于同步时间的协议为ntp协议，在Internet上提供ntp服务的站点有clepsydra.dec.com 、ben.cs.wisc.edu、truechimer.waikato.ac.nz等，虽然ntp协议本身考虑了网络延迟，然而网络延迟毕竟会对时间的精确性造成影响，因此应该选用一个离本地计算机最近的时间服务器。

使用 /stand/sysinstall也能设定时间同步，可以根据地域来选择合适的时间服务器，然而由于网络连接并不一定和地域相一致，因此不能完全根据地域的远近来选择时间服务器。

u 使用 ntpdate
使用 ntp协议更新自己计算机上的时间的一个简单的应用程序为ntpdate，同样这也需要使用root权限执行：

# ntpdate clepsydra.dec.com

10 Apr 19:26:49 ntpdate: step time server 204.123.2.5 offset 517.837146

ntpdate运行过之后就退出了，为了保持时间的正确性，就要每隔一段时间自动进行时间同步，可以将ntpdate放入cron中，每隔一段时间就执行一次。使用ntpdate的问题是时间的改变是跳跃性的，这样就有可能发生时间标记的不一致性，有可能一个后建立的文件，其文件标记却比较早，这对于一些依赖于时间标记进行分析的程序，例如make，就带来了致命性的问题。

u Ntpd守护进程
然而系统提供了另一个守护进程， ntpd（老版本下为xntpd），能够自动周期进行时间同步的工作，它的一个非常重要的特点就是：它不会跳跃性的改变时间，而是一点点的改变时间，直到与标准时间完全一致。这也导致它从不正确到正确的时间需要一段时间，那么如果时间差距太大，就不是很合适，因此最好在执行它之前，使用ntpdate先同步一下时间。

事实上，如果时间差距太大， ntpd会抱怨而退出，此时需要额外的参数强制ntpd正常运行。

由于 ntpd永久运行，不断同步时钟，这更为适合与Internet有永久连接的计算机。为了运行ntpd守护进程，首先要创建/etc/ntp.conf文件，其中应包括时间服务器的名字和一个临时文件名。

server clepsydra.dec.com

driftfile /etc/ntp.drift

然后就需要运行这个守护进程，进行时间同步。

# ntpd -c /etc/ntp.conf -p /var/run/xntpd.pid
其中 -c参数指定了ntp.conf作配置文件，用xntpd.pid记录ntpd的进程标识序号。

ntpdate和ntpd都可以通过更改rc.conf中的选项，在启动时自动执行。

xntpd_enable="YES" # Run xntpd Network Time Protocol (or NO).

xntpd_program="ntpd" # path to xntpd, if you want a different one.

xntpd_flags="-c /etc/ntp.conf -p /var/run/xntpd.pid" # Flags to xntpd (if enabled).

如果要想让本地网络上的多台计算机都进行时间同步，那么每个计算机都与外部时间服务器连接的方法并不是一个好主意。更好的想法是使用一个计算机与外部时间服务器同步，那么它的时间就成为了标准时间，可以用作本地时间服务器，而其他计算机与这台本地时间服务器同步就可以了。 xntpd就是设计为这个目的，它能够用作提供时间的ntp服务器。用作时间服务器的xntpd的配置文件应该为：

server clepsydra.dec.com

driftfile /etc/ntp.drift

broadcast 192.168.1.255

其中增加了一项广播地址： 192.168.1.255，定期向局域网上的其他计算机广播正确的时间。这个广播地址要根据自己的网络进行修改，或者使用对应于NTP协议的D类组播（multicast）网址224.0.1.1，但用户的网络必须支持组播能力。由于使用了广播或组播，这样网络内的其他计算机可以不配置ntp.conf，直接启动ntpd，ntpd就能通过听服务器的广播信息来得到精确的时间。当然也可以不设定广播地址，而配置每个计算机中的ntp.conf文件，指定所有的计算机都访问这台时间服务器。

如果服务器没有和 Internet连接，那么就有一些麻烦。此时ntpd需要一个精确的时间源，来提供标准时间，才能用做时间服务器。一般这需要一个卫星接收设备，接收卫星发送的标准时间脉冲，通过串口传入计算机。一种简单的方式是使用计算机的内部时钟，不要求时间百分之百的精确，只需要所有的计算机时间的一致性。此时，配置文件为：

server 127.127.0.1

driftfile /etc/ntp.drift

与标准用法略有不同， ntpd使用127.127.0.1代表本地时钟。但是这样的做法，ntpd通常需要一段时间进行调整，在ntpd刚刚启动的时候还不能正常提供时钟服务。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
http://www.shanghainese.net/discuz/viewthread.php?tid=1027
系统时间同步及ntp服务的提供

电脑的时间放置不理的话过不久就会出现误差。
这个误差会反映在email送信时刻的time stamp上，会反映在你的论坛帖子发表时刻上。至少我遇到过这个问题。
网络上有ntp(network time protocol)服务器，提供当前的时刻。我们可以将本地的时刻与ntp服务器的时刻进行同步。

目的如下：
1，启动时用ntpdate进行时刻修正。
2，启动中，通过ntpd进行时刻校正的同时，将各个客户端电脑的时刻也进行同期校正。
3，如果不能找到ntp服务器，那么就使用local time，同时同步客户

全世界约有100多个ntp服务器，从下面地址找一个离你最近的
http://www.eecis.udel.edu/~mills/ntp/clock1a.html
我选择了两个
clock.nc.fukuoka-u.ac.jp 133.100.9.2
clock.tl.fukuoka-u.ac.jp 133.100.11.8

步骤：

FreeBSD中有两个标准的ntp程序，其一为ntpdate.

ntpdate通过从ntp服务器获取时刻，调整本地时刻。
# ntpdate clock.nc.fukuoka-u.ac.jp
9 Oct 18:12:23 ntpdate: step time server 133.100.9.2 offset -19.112674

大约有19秒钟的误差

自动设定
# grep ntpdate /etc/defaults/rc.conf >>/etc/rc.conf
# vi /etc/rc.conf
ntpdate_enable="YES" # Run ntpdate to sync time on boot (or NO).
ntpdate_program="ntpdate" # path to ntpdate, if you want a different one.
ntpdate_flags="clock.nc.fukuoka-u.ac.jp" # Flags to ntpdate (if enabled).

重新启动以后就运行了，当然设定没有完，不必急着启动

FreeBSD的另一个标准ntp程序，ntp

ntp程序使的获取ntp时刻的同时，向其他pc提供时刻。

添加文件ntp.conf：
用来作为标准时刻的ntp服务器我选择了两个
clock.nc.fukuoka-u.ac.jp 133.100.9.2
clock.tl.fukuoka-u.ac.jp 133.100.11.8
同时指定复数个服务器也没有问题，系统会自动选择一个可以信赖的。
这里，为避免多余的DNS数据包传递，我们直接指定IP地址。
server行 server 127.127.1.0 为参考本地时刻时用的地址。然后用fudge指定阶层编号为5，降低其优先度。
接着用restrict对每一个IP地址指定相应的规则。
最后，指定波长校正用的drift文档保存地址。关于这个命令行，具体的含义不太清楚。不过如果没有的话，时间校正起来就会比较慢
# vi /etc/ntp.conf
server 133.100.9.2 #clock.nc.fukuoka-u.ac.jp
server 133.100.11.8 #clock.tl.fukuoka-u.ac.jp
server 127.127.1.0
fudge 127.127.0.1 stratum 5
restrict default ignore
restrict 127.0.0.0 mask 255.0.0.0
restrict 192.168.1.0 mask 255.255.255.0 noquery nopeer notrust
restrict 133.100.9.2 noquery
restrict 133.100.11.8 noquery
driftfile /etc/ntpd.drift

启动测试
# ntpd -p /var/run/ntpd.pid
# tail /var/log/messages
Oct 9 16:46:56 chiwawa ntpd[89409]: ntpd 4.1.0-a Thu Apr 3 08:26:24 GMT 2003 (1)
Oct 9 16:46:56 chiwawa ntpd[89409]: kernel time discipline status 2040
......
Oct 9 16:50:10 chiwawa ntpd[89409]: time set -0.189546 s
看到类似的结果就可以了

运行测试
ntpd的运行用ntpq命令
# ntpq -p
remote refid st t when poll reach delay offset jitter
－－－－－－－－－－－－－－－－－－－－－－－－－－－
*clock.nc.fukuok .GPS. 1 u 43 64 37 19.067 -6.884 10.339
+clock.tl.fukuok .GPS. 1 u 36 64 35 19.670 -3.259 2.341
LOCAL(0) LOCAL(0) 5 l 45 64 37 0.000 0.000 0.001

启动后到时刻校正完成需要一点时间。*是第一候补，+是第二。
本地时刻校正完成以后就可以为其他PC提供时刻校正服务了。

自动启动的设定
完成以上设定，确认运行无误以后：
# grep ntpd /etc/defaults/rc.conf >>/etc/rc.conf
# vi /etc/rc.conf
xntpd_enable="YES" # Run ntpd Network Time Protocol (or NO).
xntpd_program="ntpd" # path to ntpd, if you want a different one.
xntpd_flags="-p /var/run/ntpd.pid" # Flags to ntpd (if enabled).

往rc.conf追加上面3行内容，并修改。



客户端PC设定：

UNIX OS
# vi /etc/ntp.conf
server [local ntp server IP] prefer
driftfile /etc/ntpd.drift
或者追加下面内容到crontab，这样，每过一个小时0分的时候就自动更新。
# vi /etc/crontab
0 * * * * root ntpdate [ntp server IP] >/dev/null 2>&1
当然，你的主机其实也是一个客户机，这些内容也可以用上。


Windows
精工的网站上有下载软件，不过是日语的
http://www.seiko-p.co.jp/systems/down/time.html
windows2000自带了sntp机能，请自己研究吧。




======================================================================

微软公司的官方文档，详细介绍了w32time，w32tm，net time等工具的使用，是学习windows time service的权威资料
The Windows Time Service

By Shala Brandolini and Darin Green, Microsoft Corporation
Published:?April 2001


Abstract
The Windows® 2000 operating system implements Kerberos V5 as the primary protocol for network authentication. One requirement of the protocol is that system clocks must be synchronized. To achieve the degree of clock synchronization that Kerberos authentication requires, Windows 2000 implements the Windows Time service (or W32Time). This paper describes how W32Time is designed and explains how to configure and troubleshoot the service.







The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the
part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2001 Microsoft Corporation. All rights reserved. Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA
4/2001


Contents

Introduction 1
Time and the Kerberos Authentication Protocol 2
Potential Security Vulnerabilities 3
Ticket Acceptance Attacks 3
Replay Attacks 4
Denial of Service Attacks 4
Time Protocols 6
Network Time Protocol 6
Simple Network Time Protocol 6
SNTP Security 7
Windows Time Service 8
Time Convergence 8
Time Convergence Hierarchy 9
Domain Hierarchy Based Synchronization 10
Manually Specified Synchronization 13
No Specified Synchronization 14
W32Time Service Tools 15
Net Time 15
W32tm 16
Configuring W32Time 18
W32Time Registry Entries 18
Designating an External Time Source 19
Manually Starting and Stopping W32Time 20
Adjusting the Kerberos Time Skew Variable 20
Troubleshooting Time-Related Errors 21
Unable to Locate Time Server 21
Access Denied 21
Failure to Bind 22
Unable to Log On to the Network 22
FAQ 23
Appendix A: Microsoft Windows IP Security 25
Creating IPSec Policies 25
Related Links 28



Introduction
Time synchronization is important in a Windows® 2000 environment because Windows 2000 implements the Kerberos V5 authentication protocol, a standards-based authentication protocol defined by RFC 1510. W32Time meets the requirements specified by the Kerberos authentication protocol to provide clock values that are "loosely synchronized" across a network. This service is not designed for use by applications that require greater precision.
This document provides a detailed description of the Windows Time service, how it operates on a Windows 2000 network, and how it can be configured to best meet the needs of your enterprise. It also covers issues involving time service security.
Time and the Kerberos Authentication Protocol
Windows 2000 uses Kerberos V5 as the primary method of authenticating users and computers in a network domain. Details of the Kerberos authentication protocol are beyond the scope of this paper. For our purpose here, what is important to know about the Kerberos protocol is that a Kerberos client proves its identity to a server by presenting a ticket. Since only parts of the ticket are encrypted, (some parts are encrypted, but this encryption doesn't thwart replay) and might be intercepted and reused by an attacker, additional information is sent with the ticket to prove the identity of the client. This information (called the authenticator) is encrypted by the client with a secret key, and includes a timestamp. The timestamp proves that the message was recently generated and is not a replay.
When the server receives the ticket, it decrypts the authenticator and extracts the client’s clock time. The server then performs the following checks before acknowledging the client:
• Checks the client's time to make sure that it falls within the server's time and the allowable skew.
• Checks the client's time to make sure that the time is not the same as or earlier than the time of another authenticator.?
If the client's time falls within the allowable skew and its timestamp is unique, the server then slightly modifies the contents of the original authenticator and re-encrypts it with the client's secret key, establishing mutual authentication. The server then acknowledges the client by sending the modified authenticator with the client’s original timestamp back to the client for identification.
For a more detailed description of Microsoft's implementation of the Kerberos V5 authentication protocol, see Windows 2000 Kerberos Authentication on the Windows 2000 Web site.
Potential Security Vulnerabilities
Tickets presented by Kerberos clients include a timestamp in order to prevent attacks by malicious users. By modifying or spoofing the intended time source, a malicious individual might attempt to compromise an enterprise in one of the following three ways:
• Ticket Acceptance – A malicious user attempts to cause the time server to accept a Kerberos ticket that has expired. Kerberos tickets rely on time for validation and expire after a period of time.
• Replay Attacks – A malicious user captures an authentication request, for which he/she has managed to determine the session key, and replays it in order to gain access to an otherwise restricted resource.
• Denial of Service – A malicious user continually skews the time of the time source to produce an excessive amount of time resynchronization traffic, eventually causing a denial of service.?
Windows 2000 can defend against each of these types of attacks. The methods for defense are listed below:
Ticket Acceptance Attacks
Windows 2000 Professional computers, and stand-alone and member servers get their time from a domain controller in the domain to which they are joined. When the server receives the ticket, it decrypts the authenticator and extracts the client’s clock time. Before acknowledging the client, the server checks the client's time to make sure that it falls within the server's allowable time skew. If the client's time is not within the allowable skew, the server returns the following error:
KRB_AP_ERR_SKEW 0x25 "Clock skew too great"
The client compensates for the skew error by using the time returned in the error. A time skew between the client and server does not cause the client to change its system time, only the time that is used to communicate with that server. This can only work if the skew is within the lifetime of a ticket. The client uses this server skew value until it detects another time skew error (usually when the time is changed on any server that the client is communicating). When a computer detects that its time is skewed relative to its domain, it will call on the Windows Time service to correct the skew by synchronizing with a domain controller. It is possible for multiple trusted domains (and forests) to have different times. By using skew correction, clients can successfully authenticate to servers in domains with different times without having to resynchronize the client clock.
If the time is within the allowable skew, the server accepts the authentication request from that client. By default, the allowable skew is set at five minutes, but this can be modified to allow a larger or smaller window of time for the exchange of authenticators between client and server. (For details about how to change the Kerberos skew setting and reasons for doing so, see "Configuring W32Time" later in this article.)
Note After receiving a clock skew error, a client is allowed to re-attempt authentication up to four times before Kerberos forces the client's clock to synchronize with its own.
A Windows 2000 domain controller attempting to authenticate to another Windows 2000 domain controller attempts to thwart a ticket acceptance attack the same way that a Windows 2000 Professional computer, or stand-alone or member server does. Domain controllers communicate with each other only for replication. When replication occurs, one domain controller acts as the client and the other acts as the server.
The following technical paper describes this mechanism in detail: Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks Adrift: History, Protocols, and Implementation" http://world.std.com/~dtd/synch/synch.ps
Replay Attacks
The following terminology is necessary to understand how Windows 2000 defends against replay attacks:
security context?? The security attributes or rules that are currently in effect. For SSPI, a security context is an opaque data structure that contains security data relevant to a connection, such as a session key or an indication of the duration of the session.
security protocol??A specification that defines security-related data objects and rules about how the objects are used to maintain security on a computer system.
security support provider (SSP)??A dynamic-link library (DLL) that implements the SSPI by making one or more security packages available to applications. Each security package provides mappings between an application's SSPI function calls and an actual security model's functions. Security packages support security protocols such as Kerberos authentication and the Microsoft® LAN Manager. For more information about SSPI see MSDN.
When a server receives a client's ticket, it decrypts the authenticator and extracts the client’s clock time. Before acknowledging the client, the server also checks the client's time to make sure that the time is not the same as or earlier than the time of another authenticator. The server keeps a record of the times stamped on each authenticator received within the allowable skew time. If the server receives any messages during that skew time with a timestamp that is the same as or earlier than the time of the last message from the client, it?rejects those messages and returns the following error to the client:
KRB_AP_ERR_REPEAT 0x22? "The request is a replay"
However, if the application developer has used the Security Support Provider Interface (SSPI) EncryptMessage() or MakeSignature() APIs to protect the data, the underlying security protocol (i.e., Kerberos) in Windows 2000 provides additional protection against replay attacks. The following two “detections” are enforced by using these SSPI APIs in the Kerberos context:
• Out-of-Sequence Detection – The Kerberos Out-of-Sequence flag checks the sequence numbers on each message to ensure that the messages arrive in the correct order.?
• Replay Detection – With Kerberos Replay Detection, one side of the application checks to see whether it has received the same message previously. The initiator can specify that it wants messages to be checked against a message replay cache. This is used to determine if the message is a replay of a previous message.
It is important to note that some applications do not protect the data stream using the Kerberos security context. Instead, they use Kerberos only for authentication, which leaves them vulnerable.
Denial of Service Attacks
Secure time synchronization occurs with no additional configuration if the time source is within the Windows 2000 domain (or forest) hierarchy. However, in some organizations, the time source is external to the domain hierarchy. If you are operating in a Windows 2000 environment, it is possible to receive time from an external time source; however, if you choose to implement this configuration, it is imperative that it be secure and protected against compromise. You might use external time sources for the following Windows 2000 computers in an enterprise:
• The domain root (PDC emulator) – This is commonly the case when the entire forest relies on this single point for time synchronization.
• Child domains or workstations – You might use an external time source when an application requires more accurate time than what w32time’s SNTP implementation can provide. For more information about the SNTP Protocol, see “Simple Network Time Protocol” later in this whitepaper.
• The computer is not a member of a domain.
Securing External Time Sources with IP Security (IPSec)
The best method for securing connections to external time servers is to apply the industry standard IPSec transport mode and using IKE Identity Protection Mode (Main mode/quick mode). For a description of IPSec and example policies that can be used to secure your environment, see Appendix A: Microsoft Windows IP Security.

Time Protocols
The Kerberos V5 specification requires the use of a distributed time synchronization protocol. The protocol must be able to read a server clock, transmit the reading to one or more clients, and adjust each client clock as required.
How well a time protocol is able to synchronize time depends on the limits of the underlying computer hardware and operating system. For example, the clock on a Windows 2000 system ticks approximately once every 10 milliseconds; therefore, no matter what time protocol is used on a Windows 2000–based system, it will not be accurate to more than 10 milliseconds. The time synchronization protocol, along with factors such as clock frequency drift, clock resolution, and network delay, determines how closely the server clock and the client clock are synchronized. W32Time uses the Simple Network Time Protocol (SNTP), which is derived from the Network Time Protocol (NTP).
Network Time Protocol
The Network Time Protocol, specified in RFC 1305, is the most widely used protocol for computer clock synchronization. NTP synchronizes the system time on a computer to that of a server that has been synchronized by a reference source such as a radio, satellite receiver, or modem. With the appropriate hardware, NTP is capable of achieving synchronization to within microseconds, depending on the synchronization source and the network paths.
NTP synchronization is part of a software package that includes a full suite of NTP options and algorithms, which are relatively complex, real-time applications. The sheer size and complexity of the NTP suite is not appropriate for many environments that do not have stringent accuracy requirements.
Simple Network Time Protocol
The Simple Network Time Protocol, specified in RFC 1769, is a simplified access strategy for servers and clients that do not require the degree of accuracy that NTP provides. SNTP is designed to operate in a dedicated server configuration. With careful design and control of the various latencies that are typical in a dedicated network design, it is possible to deliver time accurate to the order of milliseconds by using SNTP.
SNTP is a basic version of NTP. Because the network packet formats of both protocols are identical, the two are interoperable. The main difference between the two protocols is that SNTP does not have the error management and complex filtering systems that NTP provides. The SNTP protocol allows room for error and might not be suitable for some corporations, such as those in the financial industry, that have very strict accuracy requirements. For this reason, RFC 1769 indicates "the use of SNTP rather than NTP in primary servers should be carefully considered."
Because the design goal behind W32Time was operability with Kerberos V5 authentication, and not keeping time accurate to the microsecond (as provided by the NTP protocol), developers chose to incorporate SNTP into the W32Time service running on primary servers and clients in Windows 2000. By using the SNTP protocol, W32Time meets the requirement of "loose synchronization" with other hosts on the network as specified in RFC 1510. The SNTP protocol ensures that all clocks in an enterprise are within 20 seconds of one another, and all clocks in a site are within two seconds of one another.
It is important to recognize that W32Time, run on its own, might not be sufficient for networks that require synchronization accuracy to within microseconds. SNTP is best for environments that do not need or cannot justify a full NTP implementation and that can function when clocks are loosely synchronized. If your organization requires greater accuracy, you can designate reliable time sources throughout your domain against which computers can check their local time. (For information on designating reliable time sources, see "Time Convergence Hierarchy" later in this article.) If you require greater accuracy across a site, employ third-party software.
SNTP Security
To ensure the security of the SNTP protocol, NTP authentication provisions have been added to the Windows 2000 implementation of SNTP. When a Windows 2000–based client that is a member of a domain logs on to the network, the Net Logon service provides a single access point to a domain controller. The client then provides its account password to its authenticating domain controller. Because the password is provided over a discreet communication channel, known as the Net Logon Secure Channel, only the domain controller and the client know the password. The secure channel is an encrypted connection that the Net Logon service established between the client and the nearest domain controller for its domain. W32Time uses the client's secure account password to generate a signature on SNTP packets that are sent across the network.
Because the Net Logon Secure Channel is used to set up and maintain the computer account password, the security of the time service is only as good as the security of the Net Logon Secure Channel, even though the secure channel is not directly involved in the activities of the time service. When a client requests the time from a domain controller in a domain hierarchy, the client requires that the time be authenticated. The domain controller then returns the required authentication in the form of a signed 64-bit hash of the time information. If the returned time is not signed or is signed incorrectly, the time is rejected. All such authentication failures are logged in the Event Log.
If a client is manually configured to access time from an NTP time server outside of the domain hierarchy, the SNTP packets sent between the client and the time server are not authenticated and therefore are not secure.
Windows Time Service
W32Time is installed by default on all Windows 2000–based computers (Microsoft Windows 2000 Professional, Windows 2000 Server, Microsoft Windows 2000 Advanced Server). W32Time uses coordinated universal time (UTC), which is based on an atomic time scale and is the correct term to use when talking about time and time synchronization. UTC is the name for time that is independent of time zone. Time zone information is stored in the computer's registry and is added to the system time just before it is displayed to the user.
The W32Time service starts automatically on computers that are joined to a domain. For computers that are not joined to a domain, you can start the time service manually. (See "Configuring W32 Time" later in this article.)
On computers that are joined to a domain, time synchronization takes place when the W32Time service turns on during system startup. The Net Logon service looks for a domain controller that can authenticate and synchronize time with the client. When a domain controller is found, the client sends a request for time and waits for a reply from the domain controller. This communication is an exchange of SNTP packets intended to calculate the time offset and roundtrip delay between the two computers. (For complete information on SNTP packet structure, refer to RFC 1769).
Time Convergence
Time convergence occurs throughout a network as each computer accesses time from a more reliable time server. A client issues a request to a time server for synchronization using the client computer's Relative ID (RID). The time server determines the secret password for the client's RID, and this password is renegotiated every 30 days between each computer and the Active Directory domain. The reliable server sends the current time the computer in the clear in the form of a signed SNTP packet. When the client receives the packet, it verifies its integrity and that the source of the packet is the requested time server. The information provided within the packet determines whether an adjustment needs to be made to the computer's current clock time so that it becomes synchronized with the more reliable server. If the client determines that the packet is intact, it synchronizes its time with the server.
To determine the actual local time, the local clock offset is calculated according to this standard SNTP equation:
LocalClockOffset=((ReceiveTimestamp-OriginateTimestamp)+
(TransmitTimestamp-DestinationTimestamp))/2
Note This equation is from RFC 1769. It takes into account network delays and assumes that they are symmetrical.
Each of the following variables are specified within the SNTP packet:
• ReceiveTimestamp is the local time at which the server receives the latest time request from the client.
• OriginateTimestamp is the local time at which the client sends its latest time request.
• TransmitTimestamp is the local time at which the server sends the time reply.
• DestinationTimestamp is the local time at which the client receives the time reply.
Many factors go into determining whether or not an SNTP packet is valid and whether or not it will be accepted for time synchronization. These factors include:
• Packet size and the fields within the packet that can indicate loss of synchronization (see RFC 1769 for a detailed description of SNTP packet format).
• Verification that the current response is a response to the last request made by the client.
• Verification that the year is greater than or equal to 1995. (This date holds no particular significance.)
If a packet does not meet the preceding qualifications, the packet is disregarded and time is not synchronized.
When the local clock offset has been determined, the following algorithm is used to adjust the time:?
• If the local clock time of the client is behind the current time received from the server, W32Time will change the local clock time immediately.
• If the local clock time of the client is more than three minutes ahead of the time on the server, W32Time will change the local clock time immediately.
• If the local clock time of the client is less than three minutes ahead of the time on the server, W32Time will quarter or halve the clock frequency for long enough to bring the clocks into sync. If the client is less that 15 seconds ahead, it will halve the frequency; otherwise, it will quarter the frequency. The amount of time the clock spends running at an unusual frequency depends on the size of the offset that is being corrected.
The Basic Time Synchronization process is illustrated in Figure 1 below.

Figure 1??Basic Time Synchronization

W32Time will periodically check its local time with the current time by connecting to the time source, usually the authenticating domain controller. This process starts as soon as the service turns on during system startup. W32Time attempts synchronization every 45 minutes until the clocks have successfully synchronized three times. When the clocks are correctly synchronized, W32Time then synchronizes at eight-hour intervals, unless there is a failure to obtain a timestamp, or a validation failure. If there is a failure, the process starts over from the beginning.
The result is that all computers within the enterprise running W32Time reliably converge to a common time.
Time Convergence Hierarchy
To synchronize computers on a Windows 2000 network, W32Time must have a reliable time source from which to sync. W32Time can be configured to use one of three methods for synchronization by modifying entries in the registry (see "W32Time Registry Entries" later in this article). These methods are domain hierarchy based synchronization, using a manually specified synchronization source, or using no synchronization at all. Domain hierarchy based synchronization is the default on every Windows 2000–based computer, and meets the time synchronization requirements specified by the Kerberos V5 protocol. The accuracy of a time server is indicated by a number called the stratum, with the most accurate time server located at stratum one and each level downward in the hierarchy a number one greater than the preceding level. In a Windows 2000 forest, the stratum number of a local computer is determined by how many hops away it is from the external and most accurate time source.?
Domain Hierarchy Based Synchronization
Domain hierarchy based synchronization uses the hierarchy of Active Directory, the directory service included with Windows 2000. In domain hierarchy based synchronization, the Flexible Single-Master Operation of the primary domain controller emulator (PDC emulator) is located in the forest root domain and is connected to an external time source. The external time source holds the position of greatest accuracy, or stratum one. The PDC emulator is at stratum two. The forest root domain can also be called the parent domain, and each domain under the parent or forest root can be called a child domain. Any domain controller that accesses time directly from the PDC emulator of the forest root domain is designated as stratum three. As the stratum increases from one, the achievable accuracies degrade depending on the network paths and local clock stabilities. Figure 2 illustrates the hierarchical relationship between computers in a forest.

Figure 2??Time synchronization in an Active Directory hierarchy

In this illustration, the PDC emulator located in the parent domain is at stratum 2. It gets its time directly from the external NTP time source, which is located at stratum 1, and therefore keeps the most accurate time in the forest. Domain controllers in the parent domain are at stratum 3. They rely on the PDC emulator for synchronization, and therefore, due to network latency and other factors affecting convergence, have a lesser degree of accuracy. Domain controllers and workstations located at stratum 4 tend to be less accurate than the computers located at stratum 3, and so on. Table 1 identifies computers within a forest and the stratum they usually occupy.


Table 1??Stratum Hierarchy of Computers in a Forest

Stratum Description
1 External NTP time source
2 PDC emulator of the forest root domain
3 Domain controllers in the forest root domain or PDC emulators in child domains
4 Workstations and member servers in the forest root domain or domain controllers in child domains
5 Workstations and member servers in child domains

Reliable Time Source Entry
The ReliableTimeSource entry in the registry is used to optimize how time is transferred throughout the domain hierarchy. When the reliable time source entry is set to 1 on a domain controller, the Net Logon service announces that computer as a reliable time source when it logs on to the network. When domain controllers look for a time source to synchronize with, they will choose a reliable source if one is available. The primary purpose of this registry entry is to identify a domain controller that is synchronizing with a manually configured time source.
Caution? Setting a computer that is already synchronizing from the domain hierarchy as a reliable time source can create loops in the synchronization tree and cause unpredictable results.
Another use of the entry is to identify the root of the time service, which is by default the PDC emulator of the forest root domain. The root of the time service, usually the PDC emulator of the forest root domain, is customarily the computer configured to retrieve time from an external source, and is the authoritative server for the domain. The role of PDC emulator can move between computers, which means that every time the role of PDC emulator moves, the new PDC emulator must be manually configured to point to the external source, and the manual configuration must be removed from the original PDC emulator. To avoid this process, you can set one of the domain controllers in the parent domain as reliable and manually configure just that computer to point to an external source. Then, no matter which computer is the PDC emulator, the root of the time service stays the same and thus remains properly configured. Setting the value of the ReliableTimeSource entry to 1 is only useful on a domain controller. (For details about changing the value of ReliableTimeSource, see "W32Time Registry Entries" later in this article.)
Time Source Identification
A computer uses one of three methods to identify the source against which it synchronizes its time:
1. If the computer is not a member of a domain, it must be configured to use a specific time source. (For more information about configuring a specific time source, see "Configuring W32Time" later in this article.)
2. If the computer is a member server or workstation within a domain, it follows the Active Directory hierarchy and synchronizes its time with any domain controller in its local domain that is currently running W32Time. Each time a computer starts, it will synchronize its time by requesting a time server from Active Directory. Active Directory then returns the DNS name of a single time server. The client resolves the DNS name to the IP address of the time server and synchronizes its time with that of the time server.
3. If the computer is a domain controller, it makes up to three queries to locate another domain controller with which to synchronize. The queries are designed to identify a time source with certain attributes. These attributes, in order of most to least important, are:
• Whether a domain controller is in the same site.
• Whether the domain controller is marked as a reliable time source.
• Whether the domain controller is in the parent domain.
• Whether the domain controller is a PDC emulator.
Computers choose a time source according to a specific order of preference. This order, from most preferred to least preferred, is listed in Table 2.
Table 2 Preferences for Selecting a Time Source

Preference Computer Location Reliability of Time Source
1 Parent domain controller In-site Reliable
2 Local domain controller In-site Reliable
3 Parent domain controller In-site Not reliable
4 Local PDC emulator In-site Not reliable
5 Parent domain controller Out-of-site Reliable
6 Local domain controller Out-of-site Reliable
7 Parent domain controller Out-of-site Not reliable
8 Local PDC emulator Out-of-site Not reliable

Note?If priority 6 (local domain controller, out-of-site, reliable) is found, the existence of priority 4 (local PDC emulator, in-site, not reliable) will be ignored. Also, a computer will never choose itself to sync from, so if this computer is the local PDC emulator, it will not choose priority 4 or priority 8.
If a computer is the PDC emulator in the forest root domain, there is no computer in the domain hierarchy from which it can synchronize. The time on the PDC emulator will be governed by the computer's internal hardware clock, unless an external time source has been manually configured using the Net Time command. (For information about how to manually configure an external time source, see "Configuring W32 Time" later in this article.)
Manually Specified Synchronization
Manually specified synchronization allows you to configure a client to request time from a specific time source by using the net time command: /setsntp:ntpserver. (For more information about Net Time configuration, see "Net Time" later in this article.) This manual configuration requires extensive administration to implement over a large network and might compromise network security. Manually specified time sources are not authenticated, and therefore can enable an attacker to manipulate the time source and then start Kerberos V5 replay attacks. Also, if a computer does not synchronize with its domain controller, the two might be out of sync. This causes Kerberos V5 authentication to fail, which in turn causes other actions requiring network authentication, such as printing or file sharing, to fail. When only one computer in the forest root domain is getting time from an external source, all computers within the forest remain synchronized to each other, making replay attacks difficult.
No Specified Synchronization
It is possible to use third-party software to synchronize with an external source outside of a forest, and still use W32Time to securely distribute time within the forest. You can do this by disabling synchronization while leaving W32Time active on the server. To do this, stop W32Time and install the third-party software on the PDC emulator in the forest root. Then disable the third-party software’s ability to serve time by setting the value for the Type entry to “NoSync” in the registry, and then restart W32Time. (For details about changing registry entries, see "W32Time Registry Entries" later in this article.) The domain will be securely synchronized to the PDC emulator's clock, while the PDC emulator's clock will be using the third-party software to synchronize with an accurate source outside of the forest.
W32Time Service Tools
Two W32Time service tools located in the \system32 folder can be accessed from the command line in Windows 2000. The Net Time tool allows you to configure the W32Time service. The W32tm tool is used primarily for diagnostic purposes and does not allow you to make any configuration changes.
Note? It is important to remember that if you make any configuration changes to the W32Time service using any of the tools described in this section you must stop and restart the service for the changes to take effect. By default, only administrators have the permission to stop W32Time.
Net Time
You can use Net Time to manually configure the time source for a computer. Although W32Time starts automatically at system startup, you can manually stop and start the service by typing the appropriate syntax at a command prompt. You can also use Net Time to check the time on a remote computer and set the clock of the local computer to match the remote computer.
To manually stop W32Time
At the command prompt, type:
net stop w32time?
To manually start W32Time
At the command prompt, type:
net start w32time
Typing net time /? at a command prompt provides the following syntax:
Net time [\\computername | /DOMAIN:domainname]
/RTSDOMAIN[:domainname] [/set]
\\computername /querysntp
\\computername /setsntp[:ntp server list]
Note? It is recommended that only one IP address or DNS server name be used at a time with this command. W32Time will only use the first IP address or DNS server name specified even if more than one listed.
Table 3 lists the parameters available for Net Time.
Table 3?? Net Time Parameters

Parameter Description
net time Displays the time on a time server in this computer's domain.
net time \\computername Displays the time on computername.
net time /domain:domainname Displays the time on a domain controller in domainname.
net time /domain /set Sets this computer's time to match the time on a domain controller in this computer's domain.
net time /rtsdomain:domainname Displays the time on a time server in domainname. Note that the /rtsdomain flag does not actually require a time server to be marked as reliable.
net time /querysntp Displays the manually configured time source for this computer, if there is one.
net time /setsntp:ntpserver Sets the manually configured time source for this computer. It is important to note that only one DNS name or IP address can be specified.
net time /setsntp Clears the manually configured time source for this computer, if one has been specified, and then determines the time source from the domain hierarchy.

W32tm
The W32tm tool is used for diagnosing problems that can occur with W32Time. If you are going to use the W32tm tool on a domain controller, it is necessary to stop W32Time. Running W32tm and W32Time at the same time on a domain controller generates an error because both are attempting to use the same UDP port. When you finish using W32tm, W32Time must be restarted.
Typing w32tm /? at a command prompt provides the following syntax:
W32tm [-tz | -s [computer] | -adj | -adjoff | -source | -once] [-test]
[-v] [-p port] [-period freq]
Table 4 describes the functions of the W32tm tool.
Table 4?? W32tm Primary Parameters

Parameter Description
-tz Prints the local time zone information and exit.
-s computer Forces computer (or the local computer if none is specified) to resynchronize, then exits.
-adj Sets the computer's system clock frequency to the last frequency determined during synchronization, then exits.
-adjoff Sets the computer's system clock frequency as the system default, then exits.
-source Chooses a synchronization source, then exits. Note that you choose a source before each synchronization, so this is useful only in showing that a source cannot be found.
-once Synchronizes once, and then exits. Otherwise, runs continuously as a client, synchronizing the local clock until ctrl-c is pressed.

The program will also run as a server any time the service would (for example, when it is on a domain controller, or when the data string for the value of the LocalNTP registry entry is changed from 0 to 1).
Table 5 shows optional parameters that can be used in conjunction with the parameters shown in Table 4.
Table 5??W32tm Optional Parameters

Parameter Description
-test Prevents the time on the local system from being modified.
-v Prints out a detailed description of what the program is doing. This is usually needed because otherwise the program produces no output. The exceptions are -s and -tz.
-p port Sets the server port.
-period freq Sets the sync period just as in the registry. (For more information, see “W32Time Registry Entries” later in this article). That is:
0 = once per day
65535 = once every two days
65534 = once every three days
65533 = once every week (seven days)
65532 = once every 45 minutes until you get three good
syncs, then once every eight hours (three/day)
65531 = once every 45 minutes until you get one good
sync, then once every day
Otherwise freq specifies the number of times per day. If you choose to add a value other than any of those specified above, you must use this option.

Examples:
• w32tm -s computer - Makes computer resynchronize. The computer resynchronizes with the computer with which it was set to sync at system startup. Note that a return value of zero (0) means that communication with computer was successful and computer made an attempt to resync. It does not mean that the resync attempt was successful.
• w32tm -once -test -v - Watches an attempt to sync this computer to its time source, but does not actually change the time. This shows where in the process the time service client is failing. Note that when the time source is chosen automatically, a different source might be chosen each time.
Configuring W32Time
Achieving optimal performance from your network implementation of W32Time requires some fine-tuning. Net Time and a registry editor are both valuable tools for configuring W32Time. You can configure W32Time to designate an external time source or to start or stop manually rather than automatically at system startup. In addition, you can adjust the setting for the Kerberos default time skew, which defines the range of time allowed for a server to accept authenticators from a particular client.
W32Time Registry Entries
All registry entries for the W32Time service are in the HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters subkey. Table 6 gives a complete list of all configurable registry entries associated with W32Time. In addition to the Parameters subkey, there are two additional subkeys located under HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\W32Time. These are Enum and Security. It is important to note that these subkeys are service specific and are used only by the Service Control Manager. These subkeys must never be configured manually.
Note? Remember, after changing the configuration, you must stop and restart the W32Time service for the changes to take effect.
Caution? Do not edit the registry directly unless you have no alternative. The registry editors bypass standard safeguards, allowing settings that can degrade performance, damage your system, or even require you to reinstall Windows. You can safely alter most registry settings using the programs in Control Panel or Microsoft Management Console (MMC). If you must edit the registry directly, back it up first. Read Registry Editor Help for more information.
Table 6??W32Time Registry Entries

Entry Name Data Type Description and Values
ReliableTimeSource REG_DWORD
optional Used to indicate that this computer has reliable time.
0 = Do not mark computer as reliable. [default]
1 = Mark computer as reliable. This is only useful on a domain controller.
Period REG_DWORD
or
REG_SZ Used to control how often the time service synchronizes. If a value is given, it must be one of the special values listed below.
65531, "DailySpecialSkew" = once every 45 minutes until successful one time, then once every day
65532, "SpecialSkew" = once every 45 minutes until successful three times, then once every eight hours (three times per day) [default]
65533, "Weekly" = once every week (seven days)
65534, "Tridaily" = once every three days
65535, "BiDaily" = once every two days
0 = once per day
freq = freq times per day. If you choose to add a value other than any of those specified above, you must use this option.
AvoidTimeSyncOnWan REG_DWORD
optional Used to prevent the computer from syncing from a computer that is in another site and thus connected by a costly temporary connection.
0 = The site of the time source is ignored. [default]
1 = The computer will not synchronize with a time source that is in a different site.
LocalNTP REG_DWORD Used to start the SNTP server.
0 = Do not start server unless this computer is a domain controller. [default]
1 = Always start server.
Type REG_SZ Used to control how a machine synchronizes.
Nt5DS = Synchronize to domain hierarchy or manually configured source. [default]
NTP = Synchronize to manually configured source. NoSync = Do not synchronize.
NtpServer REG_SZ
optional Used to manually configure the time source. This can be set to the DNS name or IP address of the server from which to sync. Only one DNS name or IP address can be specified. This can be modified from the command line. See net time. [default = blank]
GetDcBackoffMinutes REG_DWORD
optional The initial number of minutes to wait before looking for a domain controller (time source) if the last attempt to find a domain controller failed. [default = 15]
GetDcBackoffMaxTimes REG_DWORD
optional The maximum number of times to double the backoff interval when successive attempts to find a domain controller fail. An event is logged every time a wait of the maximum length occurs. If the value of this entry is 0, then the wait between successive attempts is always the minimum and no event is logged. [default = 7]
The time service tries to find a domain controller according to its usual sync schedule, but if the backoff interval has not expired, then that attempt will be skipped. For example, if given the default values, the backoff interval will follow this pattern: 15 minutes, 30 minutes, 1 hour, 2 hours, 4 hours, 8 hours, 16 hours, 16 hour, 16 hours, etc. However, the time service will only attempt to sync on 45 minute intervals, so the attempts to find a domain controller will actually occur after 45min, 1 hour 30 minutes, 2 hours 15 minutes, 4 hours 30 minutes, 8 hours 15 minutes, 16 hours 30 minutes, etc.

The Adj and msSkewPerDay entries are used to preserve information about the computer's clock between system start-ups, and they must never be manually edited.
Designating an External Time Source
The Net Time tool allows you to designate an external time source. It is important to note that even though the net time /? command returns a syntax that specifies that an "NTP List" can be designated, it is highly recommended that you only list one DNS name or IP address at a time. W32Time only recognizes the first DNS name or IP address listed and listing more than one might return an error.
To designate an external time source
At the command prompt, type:
net time /setsntp:DNSName
– or –
net time /setsntp:IPAddress
Manually Starting and Stopping W32Time
By default, W32Time starts automatically at system startup. However, you can start or stop W32Time manually by accessing services in Administrative Tools or by using the Net Time tool.
To manually start W32Time using the graphical interface
1. From the Start menu, point to Settings, and then click Control Panel.
2. Double-click Administrative Tools, and then double-click Services.
3. Select Windows Time from the list of services.
4. On the Action menu, click Start to begin the service.
To manually stop W32Time using the graphical interface
1. Follow steps 1 through 3 in the previous procedure.
2. On the Action menu, click Stop to discontinue the service.
To manually start W32Time using Net Time
• At the command prompt, type:
net start w32time
To manually stop W32Time using Net Time
• At the command prompt, type:
net stop w32time
Adjusting the Kerberos Time Skew Variable
In Kerberos, the variable of "time skew" defines how "loosely" two participants' clocks need to be synchronized. By default, this variable is set at five minutes. However, if you wanted more protection from replay attacks and your network connectivity allowed for it, you could shorten the time skew variable. On the other hand, if your network connectivity was poor and five minutes was not enough time for the clients on your network to be authenticated, you may want to lengthen the variable.
To change the Kerberos time skew variable
1. From the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Domain Security Policy.
2. Expand Security Settings, Account Policies, and Kerberos Policy.
3. Right-click Maximum tolerance for computer clock synchronization.
4. Click Security.
5. In the Security Policy dialog box, change the maximum tolerance variable.
Troubleshooting Time-Related Errors
You might encounter several types of errors while working with W32Time. Recognizing these errors and knowing what steps to take to fix them will be helpful to you as you administer W32Time on your network.
When W32Time is running on the PDC emulator, it commonly sends messages to the Event Log indicating that it has no time source. When this error occurs, the solution is to either configure a manual time source for the PDC emulator of the forest root domain or set the PDC emulator to not synchronize at all by changing the value for the Type entry in the registry to "NoSync".
Many other errors affecting W32Time are specific to the Net Time tool. Some of these errors are described below.
Unable to Locate Time Server
When using the Net Time tool, you might receive the following error message:
Could not locate a time server.
More help is available by typing NET HELPMSG 3912.
This error message can occur even if you set a valid Simple Network Time Protocol (SNTP) time server using the net time /setsntp command, and a network connection to the external time server exists. The manually specified time source might not be in the local workgroup or in the domain, or it might not be announcing itself as a time server. Receiving this message does not mean that the time service is not synchronizing time.
To verify that the time service is synchronizing time
• At the command prompt, type:
w32tm –v –once –test
This error message can also occur when the time service was not stopped before the configuration change was made. To avoid this error, you must stop the W32Time service before using the net time /setsntp command, and then restart the service when the change has been made.
This error can also be generated when UDP port 123 is closed on the firewall or router between the client and the server or is being used by another service. UDP port 123 is the default SNTP port. Note that the other service using UDP port 123 might be W32Time, in which case stopping and restarting the W32Time service probably fixes the problem.
Access Denied
While running net time \\computer /set you receive an access denied error.
This error occurs when a remote procedure call (RPC) fails to authenticate, usually because a user does not have permission to access the remote computer and run Net Time. If you know the user name and password of an account that does have access rights, you can establish credentials by using the net use command.
To establish credentials using net use
• At the command prompt, type:
net use \\computer\ipc$ \user: username.*.
Failure to Bind
When using the net time command, you receive the following error message:
Bind Failed: 0x80072740
Only one usage of each socket address protocol/network address/port is normally permitted.
Two instances of the same service are trying to start using the same port. The W32Time service is already using UDP port 123 (the default port for the time service); therefore the W32tm tool is not able to use the port. You must stop W32Time by using net stop before running the W32tm tool.
Unable to Log