1.3.3 Most Frequently Used Types
The role of the DRS_HANDLE type, described in the previous section (Sequencing Issues), plays a central role in capability negotiation, as explained in the specification of IDL_DRSBind.
The type that is most central to this protocol is DSNAME. DSNAME is the concrete type for the abstract DSNAME specified in [MS-ADTS] section 3.1.1.1.5. A DSNAME identifies an object. Nearly every method in the DRS protocol contains a DSNAME either in its request or its response.
Another basic type in the DRS Remote Protocol is ENTINF. An ENTINF structure contains the DSNAME of an object (or object to be) and a list of attributes with associated values–ATTRBLOCK ENTINF and ATTRBLOCK are used in the following ways:
To communicate some or all of the current state of an object:
In the response to an IDL_DRSGetNCChanges request, where multiple ENTINF structures are embedded in a REPLENTINFLIST structure. The request plus the stamps on the object determine what information about the object is included in the response.
In the response to an IDL_DRSVerifyNames request, which includes an ENTINF structure. The request specifies what information about the object is included in the response.
To specify the state of an object to be created by a method:
In an IDL_DRSAddEntry request, where the request message is essentially an ENTINF structure but is not declared as such: The DSNAME and the ATTRBLOCK structures are separate top-level fields of the request.
In an IDL_DRSInterDomainMove request, where an ENTINF structure specifies the state of the object that is being created in another domain (unlike LDAP Add, with a specified objectGUID).
To specify the subset of the current state of an object to be returned in a response:
In an IDL_DRSVerifyNames request, where an ATTRBLOCK structure specifies attributes but not their values.