3.2.18 Example 18: Manage Access Control on Directory Objects

  • Article

In this example, an administrator reads and modifies the access control settings of a directory object. This permits the administrator to control who has access to that object, and what type of access they have.

This example applies only to AD DS.

This example covers the use case in section 2.7.4.1, Convert a SID to/from a Human-Readable Format - Client Application.

Prerequisites

The general requirements described in section 2.6, Assumptions and Preconditions.

The Active Directory system meets all preconditions described in section 2.7.4.1.

Initial System State

None.

Final System State

The access control entries (ACEs) on the object that is specified by the administrator have been updated to secure that object as specified by the administrator.

Sequence of Events

The following sequence diagram shows the message flow that is associated with this example.

Message flow to manage access control on a directory object

Figure 63: Message flow to manage access control on a directory object

Unless otherwise noted, all responses that include a return code contain a return code indicating that the operation was successfully performed. There is no dependency between LDAP and LSAT messages in this scenario. Those messages can come in any order.

  1. The client application starts and sends an LDAP bind request ([RFC2251] section 4.2) to the directory server with credentials.

  2. The directory server verifies the credentials ([MS-AUTHSOD] section 2), and sends an LDAP bind response ([RFC2251] section 4.2.3) to the client application.

  3. An LDAP search request ([RFC2251] section 4.5.1) is sent to the directory, querying the directory for the object specified by the administrator to the client application in order to retrieve the nTSecurityDescriptor attribute ([MS-ADTS] section 5.1.3 and [MS-ADA3] section 2.36).

  4. The directory server performs an access check to ensure that the client has permissions to read the attribute ([MS-ADTS] section 5.1.3) and then sends an LDAP search response ([RFC2251] section 4.5.2) that contains the current value of the nTSecurityDescriptor attribute for the object that is specified in the request.

  5. The client extracts the SIDs of the security principals that are specified in the ntSecurityDescriptor attribute of the object ([MS-ADTS] section 5.1 and [MS-DTYP] section 2.4.6) and then sends an LsarOpenPolicy<7> request ([MS-LSAT] section 3.1.4.2) with the DesiredAccess parameter set to POLICY_LOOKUP_NAMES ([MS-LSAD] section 2.2.1.1.2) to the server to retrieve a context handle that it can later use to request name/SID translations.

  6. The directory server processes the LsarOpenPolicy request by performing an access check for the desired access ([MS-LSAD] section 3.1.4.2) and constructing an LSAPR_HANDLE ([MS-LSAD] section 2.2.2.1), as described in [MS-LSAT] section 3.1.4.2. It sends the response to the client.

  7. The client sends an LsarLookupSids<8> request ([MS-LSAT] section 3.1.4.11) using the server handle from step 6. In this request, it specifies the SIDs that it wants to be translated to names for display to the administrator.

  8. The directory server processes the request, as described in [MS-LSAT] section 3.1.4.11, and sends a response to the client that includes the names of the security principals whose SIDs were passed in the request.

  9. The client receives input from the administrator as to which users he or she wants to define access control entries (ACEs) for on the object. It then sends an LDAP search request to query the directory for user attributes.

    Note Some client and server implementations use a different set of messages at this point in the exchange, as shown in the following sequence diagram fragment. <9>

    Partial, previous message flow to manage access control on a directory object

Figure 64: Partial, previous message flow to manage access control on a directory object

  1. The directory server performs an access check to ensure that the client has permissions to read the requested attributes and objects ([MS-ADTS] section 5.1.3) and then sends an LDAP search response ([RFC2251] section 4.5.2) that contains the attributes for the objects that are specified in the request. See the note in the previous step.

  2. The client prepares the updated value for the nTSecurityDescriptor attribute ([MS-ADTS] section 5.1) and sends an LDAP modify request ([RFC2251] section 4.6) to commit that update.

  3. The directory server verifies that the client has permissions to update the attribute and then processes the modify request and performs validation, as described in [MS-ADTS] sections 3.1.1.5.1 and 3.1.1.5.3. It then sends an LDAP modify response that indicates success.

  4. The client finally sends an LsarClose request ([MS-LSAT] section 3.1.4.3 and [MS-LSAD] sections 3.1.4.3 and 3.1.4.9.4) to the directory server to release the context handle that was opened in step 6.

  5. The directory server releases the handle and sends a response to the client that indicates success.

  6. The client application sends an LDAP unbind request ([RFC2251] section 4.3) to the directory server. The LDAP connection to the directory server is closed.