6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.

The following tables show the relationships between Microsoft product versions or supplemental software and the roles they perform.

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.3.2: Windows 2000 operating system extends time synchronization based on SNTP, as specified in [RFC2030]. Windows XP and later and Windows Server 2003 and later extend time synchronization based on NTP [RFC1305].

<2> Section 2.2: Windows implements the NTP.MINPOLL and NTP.MAXPOLL elements in the Windows registry by using the following registry values (respectively).

These elements can be set by using the Remote Registry Protocol [MS-RRP].

<3> Section 2.2.1: Windows implementations of the protocol client set this field to 0, and Windows implementations of the protocol server ignore this field.

<4> Section 2.2.2: In Windows Server 2003, Windows domain controllers set this field to 0. In Windows 2000 and in Windows Server 2008 and later, Windows domain controllers set this field to the value of the Key Identifier subfield of the Client NTP Request message.

<5> Section 2.2.2: A server running Windows 2000 Server returns a response that contains a Reference Timestamp value equal to the value sent by the client. Additionally, a server running Windows 2000 Server returns a response that contains a Root Dispersion value equal to the value sent by the client when the server is unsynchronized.

<6> Section 2.2.4: A server running Windows 2000 Server returns a response that contains a Reference Timestamp value equal to the value sent by the client. Additionally, a server running Windows 2000 Server returns a response that contains a Root Dispersion value equal to the value sent by the client when the server is unsynchronized.

<7> Section 3.1.1: On Windows 2000 the NtpServer registry value was named "LocalNTP". It exists in the same location with the same value.

<8> Section 3.1.2.1: In Windows XP and later and in Windows Server 2003 and later, the minimum polling interval and the maximum polling interval vary between domain roles (member machine versus domain controller).

By default, for a member machine acting as an NTP client, the minimum polling interval is 10 and the maximum polling interval is 15; for a domain controller acting as an NTP client, the minimum polling interval is 6 and the maximum polling interval is 10. These interval values are expressed (as in [RFC1305] section 3.2.7) in units of seconds and are exponents to a power of two; thus, the default minimum polling interval for a domain controller is 2 ^ 6 = 64 seconds, and the default maximum polling interval is 2 ^ 10 = 1,024 seconds.

[RFC1305] section 3.2.7 defines constants that specify the minimum (NTP.MINPOLL) and maximum (NTP.MAXPOLL) values permissible for a client's polling interval. The Windows implementation defines different constants for the minimum and maximum permissible values. These constants are used to validate any values specified in configuration for the minimum polling interval and maximum polling interval. The following table shows the definitions of maximum (NTP.MAXPOLL) and minimum (NTP.MINPOLL) permissible values for a client's maximum and minimum polling intervals for different Windows versions.

In Windows XP and later and in Windows Server 2003 and later, the Poll Interval (as specified in [RFC1305] Appendix A) is initialized to NTP.MINPOLL. If the client continuously receives valid responses, the Poll Interval is incremented from NTP.MINPOLL to no more than NTP.MAXPOLL. If the client fails to receive a valid response after three consecutive attempts, the Poll Interval is decremented. If the client continues to fail to receive valid responses, the Poll Interval is decremented further below the minimum polling interval but never falls below the value defined for NTP.MINPOLL by Windows.

After eight consecutive failures to receive a valid response, the client pauses its synchronization attempts for a "back-off" interval (15 minutes), after which it returns to its initial Poll Interval. The back-off interval is doubled for each subsequent occurrence of eight consecutive failures. This doubling occurs no more than six times for a maximum back-off interval of no more than 960 minutes.

In Windows XP and later and in Windows Server 2003 and later, the client incorrectly sets the Poll Interval field of the first Client NTP Request message to the value defined for NTP.MAXPOLL by Windows.

Windows 2000 SNTP clients do not implement a true minimum or maximum polling interval. Instead, Windows 2000 clients initially poll by default every 45 minutes (the Poll Interval value in the SNTP message is set to 11 for this phase). After three successful poll operations, Windows 2000 clients jump to polling every 8 hours (the Poll Interval value is 14 for this phase). After every unsuccessful poll attempt, the interval reverts to 45 minutes.

<9> Section 3.1.3.1: Windows implementation imposes no constraints on the LargePhaseOffset, HoldPeriod, SpikeWatchPeriod, SpecialPollInterval, ResolvePeerBackoffMinutes, and ResolvePeerBackoffMaxTimes element values.

<10> Section 3.1.3.1: Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 do not use "VMTP" for the sys.refid element. In Windows 7 and later and in Windows Server 2008 R2 and later, the VMTP value is used when the client or server is in a Windows virtual environment. The determination of whether the client or server is in a Windows virtual environment is a local-only process that is specific to the Microsoft implementation of its virtual environment.

<11> Section 3.1.3.1:  On Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10 v1507 operating system, and Windows 10 v1511 operating system running inside Hyper-V, which is the Microsoft implementation of virtual machines, the sys.stratum element is set to 2. On Windows 10 and Windows Server 2016 and later running on a Windows Server 2012 R2 virtualization host, the sys.stratum element is set to 2.

<12> Section 3.1.5.1: Windows 2000 clients do not use the most significant bit of the Key Identifier subfield and always set the most significant bit to 0. In Windows XP and later and in Windows Server 2003 and later, the client sets the Key Identifier subfield as described in section 2.2.1. The most significant bit is initialized to the value of the Key Selector abstract element.

The client sets the Crypto-Checksum subfield as described in section 2.2.1.

<13> Section 3.1.5.1: In Windows 2000, the client always sets the Mode field of its Client NTP Request messages to 0x3 ("Client").

<14> Section 3.1.5.1: In Windows, the NetrLogonComputeClientDigest method, as specified in [MS-NRPC] section 3.5.4.8.3, generates only two crypto-checksums for the current and previous passwords.

<15> Section 3.1.5.2: Windows 2000 servers return the Reference Timestamp value from the client request in the response.

<16> Section 3.1.5.2: Windows 2000 clients do not set the Reference Timestamp value to 0xAAAAAAAA and do not process Test 6.

<17> Section 3.1.9: Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 always set the ExtendedAuthenticatorSupported element to false.

<18> Section 3.2.1: Windows 2000 implements only the following values. Note that the string names of the values were "Reliable_Time_Source_No" and "Reliable_Time_Source_Yes" with identical semantics.

<19> Section 3.2.1: Windows 2000 exposes this ADM element via the following registry key

This element can be set by using the Remote Registry Protocol [MS-RRP].

<20> Section 3.2.1: The ResponseMode element is valid only on Windows 2000.

<21> Section 3.2.3: Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 do not use "VMTP" for the sys.refid element. In Windows 7 and later and in Windows Server 2008 R2 and later, the VMTP value is used when the client or server is in a Windows virtual environment. The determination of whether the client or server is in a Windows virtual environment is a local-only process that is specific to the Microsoft implementation of its virtual environment.

<22> Section 3.2.3:  On Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10 v1507, and Windows 10 v1511 running inside Hyper-V, which is the Microsoft implementation of virtual machines, the sys.stratum element is set to 2. On Windows 10 and Windows Server 2016 and later running on a Windows Server 2012 R2 virtualization host, the sys.stratum element is set to 2.

<23> Section 3.2.3.1: Windows 2000 performs the following initialization:

• If the machine is a DC or the ResponseMode abstract data model element is set to Response_Mode_Yes, then the implementation sets the "Time service is running" bit to 1.

• If the AnnounceFlags abstract data model element is set to Time_Source_Yes and either the machine is a DC or the ResponseMode abstract data model element is set to Response_Mode_Yes, then the implementation sets the "Time service with clock hardware is running" bit to 1.

<24> Section 3.2.5.1: Windows 2000 Server does not process the Client NTP Request message when the NTP message length is 48 bytes.

<25> Section 3.2.5.1.1: According to [RFC1305], Receive Timestamp, Originate Timestamp, and Poll Interval need to be updated for every received NTP message. However, the Windows implementation of the NTP protocol ignores packets with invalid data or invalid headers. An NTP message is marked as having invalid data if it fails any of tests 1 through 4 documented in [RFC1305] section 3.4.4. An NTP message is marked as having an invalid header if it fails any of tests 5 through 8 documented in [RFC1305] section 3.4.4.

<26> Section 3.2.5.1.1: Windows NTP servers in Windows 2000, Windows XP, and Windows Server 2003 do not honor the above "SHOULD". Instead, they respond to the request. In Windows 2000, the server responds with a Server NTP Response message without an Authenticator field if authentication fails. In Windows XP and Windows Server 2003, the server responds with a Server NTP Response message that includes an Authenticator field in which the Crypto-Checksum subfield is set to zero. In either case, the client reads the Server NTP Response message as an authentication failure.

<27> Section 3.2.5.1.1: In the situation where the machine account has only a current password (that is, an old password does not yet exist) and a client requests a digest computed using the old password, Windows computes the digest using the current password. Windows 2000 is a special case in that it returns an unauthenticated response when an old password does not exist.

<28> Section 3.2.5.1.1: On Windows implementations of the protocol server, machine accounts do not keep a password history and therefore have only a current password. Only domain trust accounts keep the password history; therefore, a domain trust account can have an old password and a current password. In the absence of an old password, the current password is used (for both the 0 and the 1 values of the 1-bit key selector).

<29> Section 5.1: The client accepts any Server NTP Response message regardless of the time difference in authenticated NTP time synchronization inside a Windows domain.