2. Time Services in Basic Authorization
After the user obtains a session ticket, he or she
can present that ticket to any server in the domain or a trusted domain
to access resources such as file shares, databases, printers, and so on.
This is referred to as authorization. The server hosting the resource authorizes use of the resource if the following are true:
The session ticket hasn't expired.
The user was properly authorized by a KDC in the domain.
The user has necessary permissions to perform the desired operation on the resource.
The session ticket needs to be presented only once
during the ticket lifetime (default ten hours) to a server to access any
resources that server is responsible for. For example, if a ticket is
presented to SRV1 for access to a printer, SRV1 does not require the
ticket to be presented for access to a file share it hosts if the
request is made within the lifetime of the ticket, as shown in Figure 6.18.
However, if the user accesses a resource on another server, the session
ticket must be presented to that server. This is basic Kerberos
authorization with the exception that in the Windows environment, the
KDC is located via the DNS Kerberos SRV record.
3. Security Functions
The use of Time Services in user authentication
prevents Expired Ticket Acceptance Attacks where the attacker uses a
previously sent ticket that has been used for authentication to a server
whose clock is slow. Kerberos requires the computers to have their time
synchronized within a defined time skew. In Windows 2000 and 2003, the
default is five minutes and is configurable via Group Policy in Computer
Configuration\Windows Settings\Security Settings\Account
Policies\Kerberos Policy\Maximum Tolerance for computer clock
synchronization, as shown in Figure 6.
Kerberos also prevents Replay Attacks in which the attacker uses an
authentication request to gain access to a restricted resource. When the
server decrypts the client's time stamp, it's checked to ensure that
the time is not the same or earlier than the time of another access
request made by the same client. The server checks each request with a
list of times stamped on access requests made within the skew time. If
the time received is the same or earlier than the time of the last entry
from that client, an error is logged on the client and access is
denied.
4. Configuring Kerberos Policies
Although the ticket lifetime and the time skew are
configurable via Group Policy, I would not recommend modifying the
default values, because this will have performance and security
consequences. Shortening the time skew or the ticket lifetime makes
security tighter by limiting the time a ticket could be used by an
attacker, but it also reduces the performance for the user by requiring a
new ticket more frequently (ticket lifetime) and reduces the allowable
window that the computers in the domain can be out of sync with each
other, making time management more difficult. Before you modify these
values, remember to carefully analyze the need and potential risks and
test it before putting it in production.
5. External Time Source
External time sources are not necessarily required for Windows; however, by default, Windows 2003 Server and Windows XP define time.windows.com
as the external time server. This can be seen on the Internet Time tab
in the Date and Time Properties dialog box for standalone computers or
by entering the command net time /querysntp at the command
prompt. The Internet Time tab is hidden from view if the computer is a
member of a domain or if the user does not have Administrator
privileges. Note that Windows 2000 Server and Professional have no
default external time source defined.
An external time source is useful for configuring
Kerberos trusts across multiple forests. Although Time Services can be
synchronized across forests, there is no way to provide security for NTP
outside the domain/forest. Therefore, if each forest uses an external
time source for the PDC of the root domain in each forest, both forests
will be in sync, making cross forest trust functions work reliably.
6. Domain Time Hierarchy
Each Windows 2003 server or XP client must find an
authoritative time source when it boots. DCPromo also performs time
synchronization during the promotion of a new DC. When booting, each
client and member server computer uses its authenticating DC as a time
source. DCs in a child domain use the PDC Emulator of their domain or
any DC in the parent domain as the authoritative time source when they
boot, and the PDCs of child domains use the PDC of the forest root
domain or any DC in the root domain as the authoritative time source.
DCs in the root domain use the PDC of the root domain as the reliable
time source. The PDC of the root domain should be configured to point to
a reliable external time source. The PDC can point to itself as the
time source, and Windows will be happy. However, you might have
applications or external trusts that dictate the configuration of an
external time source.
Designation of Reliable Time Source
Although the domain hierarchy just described is the
default and is recommended to use, you can designate a reliable time
source of your choosing. A reliable time source must synchronize with a
DC in the parent domain; like any DC, this DC will never attempt to
synchronize with itself. A reliable time source can be manually
configured via Group Policy in Computer Configuration\Administrative Templates\System\Windows Time Service.
Go to Global Settings, click the Enabled option; then find Announce
Flags in the list below that, and set that value to 6 as shown in Figure 7.
Designation of NTP Server
You can manually designate an NTP server or
optionally use a third-party NTP service. If you do the latter, you must
disable the Windows Time Service and disable the Windows NTP client in
Group Policy under Computer Configuration\Administrative Templates\System\Windows Time Service\Enable Windows NTP Client.
The NTP server can be specified manually in the W32tm.exe command-line tool built into the OS. The syntax is:
W32tm /config /syncfromflags:MANUAL /manualpeerlist:list DNS or IP address /update
The manualpeerlist specifies the DNS name or IP address of the NTP server to be used. Multiple entries must be separated with commas.
This is intended for standalone computers that are
not members of a domain. However, you can specify the NTP server in a
domain, but this is not recommended. I had one customer who complained
about Time Services not working correctly—he was logging W32tm errors
and warnings in the system event log, replication was broken, and
authentication was sporadic. On questioning him, he admitted to
“designing” his Time Services and specifying an NTP server. Thus, he had
overridden all of the automatic configuration built into Windows for
Time Services. It took awhile, but we reset everything back to
default—removed the Group Policy, reset the W32tm configuration, and so
on. After everything was back to default, it all worked again.
warning
Windows 2003 Time Services in a Windows 2003 domain
with Windows 2003 DCs does not require any configuration or
intervention. Unless you have good, supportable reasons to change it,
leave it alone. Time Services are critical to the security and health of
the environment. Don't configure them on a whim.
Basic Troubleshooting with W32tm.exe
One of the most common problems regarding Time
Services is the failure of a client (including DCs) to find a time
source for synchronization. Microsoft provided the W32tm.exe tool native
to Windows 2000 to help resolve these issues. However, the errors and
solutions are very different between Windows 2000 and 2003, and the
W32tm tool has different options and behaviors.
In Windows 2000, Event ID 54 and 64 (warnings) are
recorded in the system event log, with a W32time source. Failure to
correct this condition could result in authentication failure if the
system clocks are more than five minutes (or whatever you defined the
time skew to be in Group Policy) out of sync with each other. This will
not only prevent users from logging in, but will cause replication and
other services to fail. This is a fairly easy problem to resolve. Note
the description of Event ID 64:
12/2/2003 8:21:19 PM w32time Warning None 64 N/A ATL-DC1
"Because of repeated network problems, the time service has not been able to find a domain controller to synchronize with for a long time.
To reduce network traffic, the time service will wait 960 minutes before trying again.
No synchronization will take place during this interval, even if network connectivity is restored. Accumulated time errors may cause certain network operations to fail.
To tell the time service that network connectivity has been restored and that it should resynchronize, execute the following command from the command line:
C:/> w32tm /s
This event is usually caused by a network
connectivity issue, the server being down, or the server being otherwise
unavailable. The command shown in bold in the event is incorrect. There
are actually two common commands that can be used:
C:> w32tm –s [computer]
Forces the local computer to synchronize if [computer] is blank, or enter a computer name to execute this for a remote computer.
OR
C:> w32tm –once Forces the local computer to synchronize once.
There are a lot of command options, but these two are
usually the only ones you need. Look at the online help for information
on the other options. You could also manually synchronize with the time
server using the SNTP command C:> Net Time /setsntp=<time server name>, but it's not the preferred method.
In Windows 2003, there are more warnings, better
descriptions, and a more tolerant algorithm for synchronizing
out-of-step servers. Typically, a DC records Event ID 14 and 29 (W32Time
source) in the system log:
8/21/2003 11:40:15 PM W32Time Error None 29 N/A ATL-DC1
The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible.
No attempt to contact a source will be made for 15 minutes. NtpClient has no source of accurate time.
8/21/2003 11:40:15 PM W32Time Warning None 14N/A ATL-DC1
The time provider NtpClient was unable to find a domain controller to use as a time source. NtpClient will try again in 15 minutes.
This event will be repeated 6 more times indicating
retry periods of 30, 60, 120, 240, 480, and 960 minutes. At last, it
will record Event ID 49:
9/12/2003 2:47:15 AM W32Time Warning None 49 N/A ATL-DC1
The time provider NtpClient was unable to find a domain controller to use as a time source. NtpClient will continue trying to locate a DC every 960 minutes.
This message will not be logged again until after a domain controller is found.
Obviously these need to be monitored, but they also
indicate effort on the part of W32time to synchronize with a reliable
time source. If it does, Event ID 35 will be recorded:
8/28/2003 6:09:34 AM W32Time Warning None 50 N/A ATL-DC1
The time service is now synchronizing the system time with the time source hemlock.internal.myhappyvpn.com (ntp.d∣10.0.7.253:123->10.0.2.252:123).
Also note that Event ID 50 will indicate the client is outside the time skew:
8/28/2003 6:09:34 AM W32Time Warning None 50 N/A ATL-DC1
The time service detected a time difference of greater than 5000 milliseconds for 900 seconds.
The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions.
The time service is no longer synchronized and cannot provide the time to other clients or update the system clock.
When a valid time stamp is received from a time service provider, the time service will correct itself.
These logs came from a Windows 2003 DC that is in a
domain deployed across several sites, all connected by VPN links. The DC
was trying to synchronize with a time source (the PDC Emulator for the
domain) across the VPN link, and occasionally failed due to the
unreliability of the VPN connection.
The solution again is in the built-in Windows 2003
W32tm.exe tool. The options commonly used to resolve time
synchronization errors (assuming the time server is accessible) include
W32tm /resync:
This forces the computer to resync its clock.
W32tm /config /manualpeerlist:<peers>:
Defines the computer to synchronize time with those in the peer list.
W32tm /config /synchfromflags:DOMHIER:
This permits the computer to synchronize from the domain hierarchy as
explained previously in this section. This is typically the best
solution.
w32tm /stripchart /computer:<target>:
This command produces a strip chart of the time difference between the
local computer and the computer specified in the command as <target>. This is an easy way to observe the time skew.
note
The Windows 2000 version of W32tm.exe is
very different from the Windows Server 2003 version. The options in the
previous list are not available for the Windows 2000 version, but one
handy command is w32tm /once, which synchronizes to the time
server once. You can get additional information about w32tm in the
online help and at the Microsoft Web site.
