通过

2.2.1.2 CHALLENGE_MESSAGE

  • 项目

The CHALLENGE_MESSAGE defines an NTLM challenge message that is sent from the server to the client. The CHALLENGE_MESSAGE is used by the server to challenge the client to prove its identity. For connection-oriented requests, the CHALLENGE_MESSAGE generated by the server is in response to the NEGOTIATE_MESSAGE (section 2.2.1.1) from the client.


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

Signature

...

MessageType

TargetNameFields

...

NegotiateFlags

ServerChallenge

...

Reserved

...

TargetInfoFields

...

Version

...

Payload (variable)

...

Signature (8 bytes): An 8-byte character array that MUST contain the ASCII string ('N', 'T', 'L', 'M', 'S', 'S', 'P', '\0').

MessageType (4 bytes): A 32-bit unsigned integer that indicates the message type. This field MUST be set to 0x00000002.

TargetNameFields (8 bytes): A field containing TargetName information. The field diagram for TargetNameFields is as follows.


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

TargetNameLen

TargetNameMaxLen

TargetNameBufferOffset

If the NTLMSSP_REQUEST_TARGET flag is set in NegotiateFlags, indicating that a TargetName is required, the fields are set to the following values:

§ TargetNameLen (2 bytes): A 16-bit unsigned integer that defines the size, in bytes, of TargetName in Payload.

§ TargetNameMaxLen (2 bytes): A 16-bit unsigned integer that SHOULD be set to the value of TargetNameLen and MUST be ignored on receipt.

§ TargetNameBufferOffset (4 bytes): A 32-bit unsigned integer that defines the offset, in bytes, from the beginning of the CHALLENGE_MESSAGE to TargetName in Payload. If TargetName is a Unicode string, the values of TargetNameBufferOffset and TargetNameLen MUST be multiples of 2.

If the NTLMSSP_REQUEST_TARGET flag is not set in NegotiateFlags, indicating that a TargetName is not required, the fields take the following values, and MUST be ignored upon receipt.

  • TargetNameLen and TargetNameMaxLen SHOULD be set to zero on transmission.

  • TargetNameBufferOffset field SHOULD be set to the offset from the beginning of the CHALLENGE_MESSAGE to where the TargetName would be in Payload if it were present.

NegotiateFlags (4 bytes): A NEGOTIATE structure that contains a set of flags, as defined by section 2.2.2.5. The server sets flags to indicate options it supports or, if there has been a NEGOTIATE_MESSAGE (section 2.2.1.1), the choices it has made from the options offered by the client. If the client has set the NTLMSSP_NEGOTIATE_SIGN in the NEGOTIATE_MESSAGE the Server MUST return it.

ServerChallenge (8 bytes): A 64-bit value that contains the NTLM challenge. The challenge is a 64-bit nonce. The processing of the ServerChallenge is specified in sections 3.1.5 and 3.2.5.

Reserved (8 bytes): An 8-byte array whose elements MUST be zero when sent and MUST be ignored on receipt.

TargetInfoFields (8 bytes): A field containing TargetInfo information. The field diagram for TargetInfoFields is as follows.


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

TargetInfoLen

TargetInfoMaxLen

TargetInfoBufferOffset

If the NTLMSSP_NEGOTIATE_TARGET_INFO flag is not clear in NegotiateFlags, indicating that TargetInfo is required, the fields SHOULD<8> be set to the following values:

§ TargetInfoLen (2 bytes): A 16-bit unsigned integer that defines the size, in bytes, of TargetInfo in Payload.

§ TargetInfoMaxLen (2 bytes): A 16-bit unsigned integer that SHOULD be set to the value of TargetInfoLen and MUST be ignored on receipt.

§ TargetInfoBufferOffset (4 bytes): A 32-bit unsigned integer that defines the offset, in bytes, from the beginning of the CHALLENGE_MESSAGE to TargetInfo in Payload.

If the NTLMSSP_NEGOTIATE_TARGET_INFO flag is clear in NegotiateFlags, indicating that TargetInfo is not required, the fields take the following values, and MUST be ignored upon receipt.

  • TargetInfoLen and TargetInfoMaxLen SHOULD be set to zero on transmission.

  • TargetInfoBufferOffset field SHOULD be set to the offset from the beginning of the CHALLENGE_MESSAGE to where the TargetInfo would be in Payload if it were present.

Version (8 bytes): A VERSION structure (as defined in section 2.2.2.10) that SHOULD<9> be populated only when the NTLMSSP_NEGOTIATE_VERSION flag is set in the NegotiateFlags field; otherwise, it MUST be set to all zero. This structure is used for debugging purposes only. In normal (non-debugging) protocol messages, it is ignored and does not affect the NTLM message processing.

Payload (variable): A byte array that contains the data referred to by the TargetNameBufferOffset and TargetInfoBufferOffset fields. Payload data can be present in any order within the Payload field, with variable-length padding before or after the data. The data that can be present in the Payload field of this message, in no particular order, are:


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

TargetName (variable)

...

TargetInfo (variable)

...

TargetName (variable): If TargetNameLen does not equal 0x0000, TargetName MUST be a byte array that contains the name of the server authentication realm, and MUST be expressed in the negotiated character set. A server that is a member of a domain returns the domain of which it is a member, and a server that is not a member of a domain returns the server name.

TargetInfo (variable): If TargetInfoLen does not equal 0x0000, TargetInfo MUST be a byte array that contains a sequence of AV_PAIR structures. The AV_PAIR structure is defined in section 2.2.2.1. The length of each AV_PAIR is determined by its AvLen field (plus 4 bytes).

Note An AV_PAIR structure can start on any byte alignment and the sequence of AV_PAIRs has no padding between structures.

The sequence MUST be terminated by an AV_PAIR structure with an AvId field of MsvAvEOL. The total length of the TargetInfo byte array is the sum of the lengths, in bytes, of the AV_PAIR structures it contains.

Note If a TargetInfo AV_PAIR Value is textual, it MUST be encoded in Unicode irrespective of what character set was negotiated (section 2.2.2.1).