3.2.5.1.1 Domain Controller Processing of the Authenticated Server NTP Response
If the server is a domain controller (DC), the server processes the response as follows.
The following diagram illustrates the server logic for providing authentication when responding to a message using these extensions. Other NTP processing is specified in [RFC1305] section 3.4.3.<25>
Figure 6: Authentication request processing
The server prepares the Server NTP Response or Server ExtendedAuthenticator NTP Response message in the same way as for the base protocol, which is described in [RFC1305] section 3.4.3. Afterward, the server follows the server-encryption procedure.
If the request message length is 68 bytes, the server processes the request as a Client NTP Request:
The server MUST ignore the Crypto-Checksum subfield of the Client NTP Request message.
The server retrieves the RID from the least significant 31 bits of the Key Identifier subfield of the Authenticator field of the Client NTP Request message. The server uses the NetrLogonComputeServerDigest method (as specified in [MS-NRPC] section 3.5.4.8.2) to compute crypto-checksums with the following input parameters:
ServerName MUST be set to NULL.
Rid MUST be set to the RID value retrieved from the Client NTP Request message.
Message MUST refer to the first 48 bytes of the Server NTP Response message.
MessageSize MUST be set to 48.
The NetrlogonComputeServerDigest method computes two crypto-checksums using the pair of passwords associated with the trusted account given by the RID.
If the NetrlogonComputeServerDigest method returns ERROR_NO_TRUST_LSA_SECRET, the server instead performs the processing for read-only domain controllers (RODCs) specified in section 3.2.5.1.2, and performs no further processing in this section.
If the Netlogon Remote Protocol method fails, the server SHOULD<26> fail the authentication and ignore the request without responding.
The server retrieves a 1-bit key selector from the most significant bit of the Key Identifier subfield of the Authenticator field in the Client NTP Request message. If the 1-bit key selector is set to 0, the server selects the crypto-checksum that was computed using the new password. If the 1-bit key selector is set to 1, the server selects the crypto-checksum that was computed using the old password.<27><28>
The server sets the Authenticator field of the Server NTP Response message as described in section 2.2.2, writing the computed crypto-checksum into the Crypto-Checksum subfield of the Authenticator.
If the request message is 120 bytes, the server processes the request as a Client ExtendedAuthenticator NTP Request:
The server MUST ignore the SignatureHashID and Crypto Checksum fields of the request.
If the ClientHashIDHints field does not have the NTLM_PWD_HASH bit set, the server MUST stop processing and MUST ignore the request.
If the USE_OLD_KEY_VERSION bit is set in the Flags field, the server MUST retrieve the NTOWFv1 (as specified in [MS-NLMP] section 3.3.1) of the previous account password for the account identified by the Key Identifier subfield; otherwise, the server MUST retrieve the NTOWFv1 of the current account password for the account. The server MUST treat all 32 bits of the Key Identifier subfield as valid when looking up the account.
If the server does not have the NTOWFv1 hashes stored locally for the account identified by the Key Identifier subfield, the server performs the processing for RODCs specified in section 3.2.5.1.2, and performs no further processing in this section.
The server MUST invoke the checksum generation algorithm (section 3.1.5.5) with input parameters as follows:
Key: The NTOWFv1 retrieved in step 2.3.
Label: The ANSI string "sntp-ms".
Context: The contents of the Key Identifier subfield.
Message: The first 48 bytes of the response message.
The server MUST set the NTLM_PWD_HASH bit in the SignatureHashID field to 1, and MUST set all other bits to zero.
The server MUST write the results of step 2.4 into the Crypto-Checksum field of the Server ExtendedAuthenticator NTP Response message.