Export (0) Print
Expand All

3.1.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 interface is used to create a secure connection between a client and a server, where the server is a domain controller (DC). The client of the Netlogon interface can be a member of the domain, another DC in the same domain, or a DC in a different but trusting domain. This secure connection is often referred to as the secure channel.

The connection is secured by the use of cryptographic algorithms. The key used for these algorithms, the session key, is computed on both the client and the server and is based on a shared secret that has been previously shared between the client and the server. After the session key is computed on both sides, it is used to encrypt the communication between the two parties. There are two methods of deriving the key. The method used is version-dependent, as specified in section 3.1.4.3.

Abstract variables of the session key operations are as follows:

ClientStoredCredential: A NETLOGON_CREDENTIAL (section 2.2.1.3.4) structure containing the credential that is created by the client and received by the server and that is used during computation and verification of the Netlogon authenticator (section 3.1.4.5).

ClientChallenge: A pointer to a NETLOGON_CREDENTIAL structure that contains the client challenge.

NegotiateFlags: A 32-bit set of bit flags that identify the negotiated capabilities between the client and the server.

ServerStoredCredential: A NETLOGON_CREDENTIAL structure containing the credential that is created by the server and received by the client and that is used during computation and verification of the Netlogon authenticator.

ServerChallenge: A pointer to a NETLOGON_CREDENTIAL structure that contains the server challenge response.

SharedSecret: An even-numbered sequence of bytes, with no embedded zero values, that is a plain-text secret (password) shared between the client and the server. Implementers can choose to store the unicodePwd ([MS-ADA3] section 2.332) instead of a clear text version of the shared secret.<79><80><81> For more information, refer to the ADM element Password in [MS-DISO] section 4.3.1.1; initialization of this shared ADM is covered in the domain join sections of [MS-DISO] (sections 6, 7, and 8).

TrustPasswordVersion: An unsigned 32-bit integer which indicates the number of times that a trust password has changed.<82>

SealSecureChannel: A Boolean setting that indicates whether the RPC message has to be encrypted or just integrity-protected ([C706], section 13.2.5). When TRUE, the message will be encrypted; otherwise, it will be integrity-protected.

StrongKeySupport: A Boolean setting that indicates whether a strong method of creating the session key will be used. A strong method, in the context of Netlogon, is one that uses the MD5 message-digest algorithm [RFC1321]. The behavior of this setting is specified in section 3.1.4.3.

The Netlogon client and server variables are as follows:

LocatedDCsCache: A cache SHOULD be implemented containing a set of previously located DCs. The fields of the cache are implementation-specific but are required to contain enough information to be able to respond correctly to a DC locator request. Any cache implementation MUST be able to return the set of cache results given a domain name. The results SHOULD be equivalent to the DOMAIN_CONTROLLER_INFOW structure. Also, each entry SHOULD maintain, and return with any cache lookup, two timestamps. The first timestamp indicates when the entry was created so that age checks can be performed in order to invalidate stale cache entries. The second timestamp indicates the last communication with the indicated machine in order to facilitate periodic liveliness tests with the cached DC (see section 3.5.4.3.1 for more information).

SealSecureChannel: A Boolean setting that indicates whether the RPC message has to be encrypted or just integrity-protected ([C706], section 13.2.5). When TRUE, the message will be encrypted; otherwise, it will be integrity-protected.

Implementations that use the Windows registry [MS-GPSB] section 2.2.5 to persistently store and retrieve the SealSecureChannel variable SHOULD use the following:

  • RegistryValueName: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Netlogon\Parameters

  • RegistryValueType: 4

  • RegistryValue: SealSecureChannel

The implementation SHOULD also expose the key and value at the specified registry path using the Windows Remote Registry Protocol [MS-RRP]. For each abstract data model element that is loaded from the registry, there is one instance that is shared between [MS-RRP] and the protocol(s) that uses the abstract data model element. Any changes made to the registry keys will be reflected in the abstract data model elements when a PolicyChange event is received ([MS-GPOD] section 2.8.2).

 
Show:
© 2015 Microsoft