3.4.1 Abstract Data Model
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
The Netlogon Protocol client maintains the following variables in addition to the ones described in section 3.1, Netlogon Common Details, which are part of the abstract state.
ClientCapabilities: A 32-bit set of bit flags (section 126.96.36.199) that identify the client's supported options.
domain-name (Public): For client machines, the NetBIOS name of the domain to which the machine has been joined. This ADM element is shared with DomainName.NetBIOS ([MS-WKST] section 188.8.131.52). For domain controllers, the domain name to which the domain controller has a direct trust.
The Netlogon client variables which are registry keys are as follows:
RejectMD5Servers: A Boolean variable that indicates whether the client MUST reject servers that are using MD5 encryption.<109> Implementations that use the Windows registry to persistently store and retrieve the RejectMD5Servers variable SHOULD use the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Netlogon\Parameters registry path and RejectMD5Servers key.
RequireSignOrSeal: Indicates whether the client SHOULD continue session-key negotiation when the server did not specify support for Secure RPC as described in the negotiable option Y of section 184.108.40.206. Implementations that use the Windows registry [MS-GPSB] section 2.2.5 to persistently store and retrieve the RequireSignOrSeal variable SHOULD use the following:
RequireStrongKey: A Boolean variable that indicates whether the client MUST negotiate the use of a strong key during secure channel creation as described by the negotiable option O of section 220.127.116.11. <110> Implementations that use the Windows registry [MS-GPSB] section 2.2.5 to persistently store and retrieve the RequireStrongKey variable SHOULD use the following:
These registry keys and values MUST be exposed at a specified registry path via the Windows Remote Registry Protocol [MS-RRP]. For each abstract data model (ADM) element that is loaded from the registry, there is one instance that is shared RRP and the protocol(s) that uses the ADM element. Any changes made to the RejectMD5Servers registry key will not be reflected in the ADM elements until the Netlogon server is stopped and restarted. Any changes made to the RequireStrongKey and RequireSignOrSeal registry keys will be reflected in the ADM elements when [MS-GPSB] a PolicyChange event is received (section 3.1.6).
When a secure channel is established, the client maintains:
ServerSessionInfo: A table indexed by PrimaryName with the following members:
ClientSequenceNumber: See section 3.3.1 for ClientSequenceNumber details.
ServerSequenceNumber: See section 3.3.1 for ServerSequenceNumber details.
Session-Key: See section 18.104.22.168 for Session-Key computation details.
NegotiateFlags: See section 3.1.1 for NegotiateFlags details.
ClientStoredCredential: See section 3.1.1 for ClientStoredCredential details.
DomainName: See section 3.1.1 for ClientStoredCredential details.
ConnectionStatus: See section 3.1.1 for ClientStoredCredential details.
LastAuthenticationTry: A FILETIME ([MS-DTYP] section 2.3.3) indicating the time when the last authentication attempt was made. The time stamp is used to determine if at least 45 seconds have passed since the last authentication attempt.