Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
3.1.5.12 Security Pattern

3.1.5.12 Security Pattern

These methods enable a client to set the access control on a server, domain, group, alias, or user object.

These methods require a handle obtained from an "open" or a "create" method. See sections 3.1.5.1 and 3.1.5.4.

A non-normative description of these methods is helpful to understand the intent of the message processing. The remainder of this section contains such a description.

Two points are significant:

  1. The message processing requirements between DC and non-DC configurations are very different.

  2. All known clients use a very small subset of the functionality exposed in these methods.

The DC message processing requirements differ from the non-DC case because the database objects on which the server operates are also exposed through the LDAP model for read and update, and have a different ACE format than what this protocol exposes. Specifically, in the DC case, the database objects have security descriptors with an object ACE format (specified in [MS-ADTS] section 5.1.3), whereas these methods expect and return security descriptors with a simple ACE format (specified in [MS-ADTS] section 5.1.3). Therefore, the message processing for these methods converts between these two models. In general, this would be an intractable problem because new access masks and object ACE types can be added that are not expressible through this protocol.

Fortunately, all known clients use a small subset of the functionality exposed through these methods. Specifically, all known clients use SamrQuerySecurityObject and SamrSetSecurityObject only to control whether a password can be changed for a user account (the relevant access mask is USER_CHANGE_PASSWORD, specified in section 2.2.1.7). Accordingly, the server of these methods is required to support only this narrow request; other requests can be safely ignored.

In the DC case, general security-descriptor manipulation is best achieved through LDAP. [MS-ADTS] section 5 specifies the Active Directory security model in detail.

For the non-DC case, because the security descriptor on the database objects is not exposed through any other protocol, a server implementation has much greater breadth in implementing the access control specified in the security descriptor presented in a method call to SamrSetSecurityObject. Furthermore, because no other protocol can modify the security descriptor on the database objects in a non-DC configuration, it is possible to translate an object ACE format security descriptor to a simple ACE format. Non-DC servers have the requirement to return, via SamrQuerySecurityObject, the same access control specification that was specified to a previous call to SamrSetSecurityObject, and to enforce all access control permissions specified through SamrSetSecurityObject.

See section 1.3 for a description of the "security" pattern of methods.

Show:
© 2015 Microsoft