The protocol consists of two RPC interfaces named drsuapi and dsaop. The name of each drsuapi method begins with "IDL_DRS", while the name of each dsaop method begins with "IDL_DSA". This protocol was originally implemented in Microsoft Windows® 2000 Server operating system and is available in all subsequent server releases. It is not available in Microsoft Windows NT® 3.1 operating system, Microsoft Windows NT® 3.51 operating system, or Microsoft Windows NT® 4.0 operating system.
The Microsoft Windows® client operating systems (Microsoft Windows® 2000 operating system, Windows® XP operating system, Windows Vista® operating system, Windows® 7 operating system, and Windows® 8 operating system) can implement a client role for some methods, but cannot implement a server role for any methods. The Windows server operating systems (Windows 2000 Server, Windows Server® 2003 operating system, Windows Server® 2003 R2 operating system, Windows Server® 2008 operating system, Windows Server® 2008 R2 operating system, and Windows Server® 2012 operating system) can implement both client and server roles for all methods. Section 4.1 gives details about the methods for which the Windows client operating systems can implement a client role.
Some functionality exposed by these RPC protocols is also available using the Lightweight Directory Access Protocol (LDAP) protocol ([MS-ADTS] section 18.104.22.168); the overlap is described in section 1.4.
The special typographical conventions used in this document are described in section 3.2.
State is included in the state model for this specification only as necessitated by the requirement that a licensee's implementation of Windows server protocols must be capable of receiving messages and responding in the same manner as a Windows server. Behavior is specified in terms of request message received, processing based on current state, resulting state transformation, and response message sent. Unless otherwise specified, all behaviors are required elements of the protocol. Any specified behavior not explicitly qualified with MAY or SHOULD is to be treated as if it were specified as a MUST behavior.
The following concepts are pervasive throughout this specification.
This specification uses [KNUTH1] section 22.214.171.124 as a reference for the graph-related terms oriented tree, root, vertex, arc, initial vertex, and final vertex.
replica: A variable containing a set of objects.
object: A set of attributes, each with its associated values. Two attributes of an object have special significance:
Identifying Attribute: A designated single-valued attribute appears on every object. The value of this attribute identifies the object. For the set of objects in a replica, the values of the identifying attribute are distinct.
Parent-Identifying Attribute: A designated single-valued attribute appears on every object. The value of this attribute identifies the object's parent. That is, this attribute contains the value of the parent's identifying attribute or a reserved value identifying no object (for more information, see [MS-ADTS] section 126.96.36.199.3). For the set of objects in a replica, the values of this parent-identifying attribute define an oriented tree with objects as vertices and child-parent references as directed arcs with the child as an arc's initial vertex and the parent as an arc's final vertex.
An object is a value, not a variable; a replica is a variable. The process of adding, modifying, or deleting an object in a replica replaces the entire value of the replica with a new value.
As the term "replica" suggests, two replicas often contain "the same objects". In this usage, objects in two replicas are considered "the same" if they have the same value of the identifying attribute and if there is a process in place (that is, replication) to converge the values of the remaining attributes.
When members of a set of replicas are considered to be the same, it is common to say "an object" as shorthand referring to the set of corresponding objects in the replicas.
object class: A set of restrictions on the construction and update of objects. An object class must be specified when an object is created. An object class specifies a set of must-have attributes (every object of the class must have at least one value of each) and may-have attributes (every object of the class may have a value of each). An object class also specifies a set of possible superiors (the parent object of an object of the class must have one of these classes). An object class is defined by a classSchema object.
parent object: See "object", above.
child object, children: An object that is not the root of its tree. The children of an object O are the set of all objects whose parent is O.
See [MS-ADTS] section 188.8.131.52.3 for the particular use made of these definitions in this specification.
Sections 1.8, 2, 3, 4, and 5 of this specification are normative and can contain the terms MAY, SHOULD, MUST, MUST NOT, and SHOULD NOT as defined in RFC 2119. Sections 1.5 and 1.9 are also normative but cannot contain those terms. All other sections and examples in this specification are informative.