3.1.1 Abstract Data Model

  • Article

This section describes a possible data organization that an implementation might maintain to participate in this protocol. The described organization is provided to help explain how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with what is described in this document.

The server implementing this protocol MUST create views, as specified in section 3.1.1.1, over domain databases that the server trusts to be able to translate SIDs to names, and vice versa. These views contain SIDs and different types of names, as well as the domain to which each security principal belongs. These views MUST be kept in sync with the original databases whose data is used to create the view. The sync mechanism is implementation-specific, and there is no upper bound on the time from when a change occurs in a domain database to when that change appears in the view. A scoping parameter defined as LSAP_LOOKUP_LEVEL can be considered during message processing by applying these views to different databases.

The following domain databases are used in this protocol.

The domain databases MUST satisfy ACID properties [GRAY] during creation or updates of views.

The abstract data models presented in sections 3.1.1.2 and 3.1.1.3 are used along with domain database information to construct the logical views specified in section 3.1.1.1. The views, in turn, are used to process mapping requests. This process is specified in sections 3.1.4.4, 3.1.4.5, and 3.1.4.9, which describe the server processing of RPC messages.

In this section, Active Directory schema names are referenced when describing attributes stored in the domain database. For more information, see [MS-ADSC], [MS-ADA1], [MS-ADA2], and [MS-ADA3].