Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
In this example, a user partitions the directory data using organizational units (OUs). This can be accomplished using LDAP. To perform this task, a user runs a client application from a client computer that targets a directory server in the Active Directory system. The client application creates an organizational unit to represent an organization's department and moves existing directory objects under the new departmental organizational unit.
This example covers the use cases in sections 2.7.1.3, Modify Directory Object - Client Application, and 2.7.1.5, Create Organizational Unit - Client Application.
Prerequisites
The general requirements described in section 2.6, Assumptions and Preconditions.
The Active Directory system meets all preconditions described in sections 2.7.1.3 and 2.7.1.5.
Initial System State
None.
Final System State
The new organizational unit object has been created in the directory with the attributes that were specified. Selected directory objects are moved under the new organizational unit.
Sequence of Events
The following sequence diagram shows the message flow that is associated with this example.
Figure 61: Message flow for partitioning directory data
Unless otherwise noted, all responses that include a return code contain a return code that indicates that the operation was performed successfully.
The client application starts and sends an LDAP bind request ([RFC2251] section 4.2) to the directory server along with credentials.
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.
The client application sends an LDAP search request ([RFC2251] section 4.5.1) to the directory server. The application requests the subtree contents of the domain NC or application NC for AD DS or the application NC for AD LDS.
The directory server sends an LDAP search response ([RFC2251] section 4.5.2) that contains the list of objects under the NC that is to be used to populate data in the client application's user interface. This step is necessary only for user-interface display purposes that are specific to this example.
The user selects a parent directory object under which the new organizational unit (OU) is to be located and provides the name of the new organizational unit to the client application. The client application sends an LDAP add request ([RFC2251] section 4.7) to the directory server. The LDAP add operation contains the distinguished name (DN) and specifies that the object class of the object to be created is organizationalUnit ([MS-ADSC] section 2.196 or [MS-ADLS] section 3.44).
The directory server processes the add request ([RFC2251] section 4.7) and verifies the processing rules and constraints, as described in [MS-ADTS] sections 3.1.1.5.1 and 3.1.1.5.2. It then sends an LDAP add response ([RFC2251] section 4.7) that indicates success.
The user selects directory object(s) to be moved under the new OU. The client application sends a series of LDAP modify DN requests ([RFC2251] section 4.9) to the directory server to move the directory object(s). The LDAP modify DN operation contains the distinguished name (DN) of the object to be moved, the new relative distinguished name (RDN), the DN of the new parent, and a Boolean flag to indicate whether the old RDN has to be retained.
The directory server processes the modify DN request ([RFC2251] section 4.9) for each directory object and verifies the processing rules and constraints, as described in [MS-ADTS] sections 3.1.1.5.1 and 3.1.1.5.4. For each directory object that was moved, the directory server sends an LDAP modify DN response ([RFC2251] section 4.9) to the client application that indicates success.
The client sends an LDAP unbind request ([RFC2251] section 4.3) to the directory server. The LDAP connection to the directory server is closed.