An LDAP directory such as Active Directory stores data in a hierarchy of containers and leaf nodes called the directory information tree (DIT). Leaf nodes are end points in the tree, while containers can store other containers and leaf nodes. In Active Directory, the two most common types of containers are organizational units (OUs) and container objects. The container objects are generic containers that do not have any special properties about them other than the fact that they can contain objects. Organizational units, on the other hand, have some special properties, such as the ability to link a Group Policy Object (GPO) to an OU. In most cases when designing a hierarchy of objects in Active Directory, especially users and computers, you should use OUs instead of containers. There is nothing you can do with a container that you can’t do with an OU, but the reverse is certainly not the case.
Organizational units can be created as a child of a domain object
or another OU; by default, OUs cannot be added as a child of a container
object. (See Assigning or Removing a Manager for an OU
for more on how to work around this.) OUs themselves are represented in
Active Directory by organizationalUnit objects. Table 5-1 contains a list of
some interesting attributes that are available on organizationalUnit objects.
Table 5-1. Attributes of organizationalUnit objects
Attribute | Description |
|---|---|
| Text description of the OU. |
| List of GPOs that have been linked to the OU. |
| Contains |
| Approximate number of direct child objects in the OU. See Determining Approximately How Many Child Objects an OU Has for more information. |
| DN of user or group that is in charge of managing the OU. |
| Relative distinguished name of the OU. |
| Timestamp of when the OU was last modified. |
| Timestamp of when the OU was created. |
You can create a new OU using the built-in DSAdd utility, as well as AdMod. To create an OU using DSAdd, use the following syntax:
> dsadd ou "<OrgUnitDN>" -desc "<Description>"
To create an OU with AdMod, use the following syntax:
> admod -b "<OrgUnitDN>" objectclass::organizationalUnit↵ description::"<Description>" -add
For example, creating the Finance OU with the description of “Finance OU” in the adatum.com domain would look like this:
> admod -b ou=Finance,dc=adatum,dc=com objectclass::organizationalUnit description::"Finance OU" -add > AdMod V01.18.00cpp Joe Richards ([email protected]) March 2012 > > DN Count: 1 > Using server: dc1.adatum.com > Adding specified objects... > DN: ou=Finance,dc=adatum,dc=com... > > The command completed successfully
OUs are used to structure data within Active Directory. Typically, there are three reasons you might need to create an OU:
- Segregate objects
It is common practice to group related data into an OU. For example,
userobjects andcomputerobjects are typically stored in separate containers (in fact, this is the default configuration with Active Directory). One reason for this is to make searching the directory easier.- Delegate administration
One of two primary reasons for creating an OU is to delegate administration. With OUs you can give a person or group of people rights to perform certain administrative functions on objects within an OU.
- Apply a GPO
An OU is the lowest-level container object that a GPO can be applied to. If you have different types of users within your organization that need to apply different GPOs, the easiest way to set that up is to store the users in different OUs and apply GPOs accordingly.
In each solution in this recipe, the description attribute of the new OU was set.
This is not a mandatory attribute, but it is good practice to set it so
that others browsing the directory have a general understanding of the
purpose of the OU. Also, consider setting the managedBy attribute to reference a user or group that is the owner of the OU. The
–ProtectedFromAccidentalDeletion
parameter configures the OU so that it cannot be deleted by using the
traditional deletion methods (e.g., right-clicking on it and then
selecting Delete from the menu).
You want to enumerate all containers and OUs in a domain, which effectively displays the structure of the domain.
The following command will enumerate all OUs in the current domain of the user running the command using the built-in DSQuery utility:
> dsquery ou
You can also retrieve this information with AdFind, using the following syntax:
> adfind -default -f "objectcategory=organizationalUnit" -dn
This adfind syntax can be
shortened as follows:
> adfind -default -sc oudmp
Output from the adfind
command will resemble the following:
> adfind -default -f "objectcategory=organizationalUnit" -dn > > AdFind V01.46.00cpp Joe Richards ([email protected]) March 2012 > > Using server: dc1.adatum.com:389 > Directory: Windows Server 8 > Base DN: dc=adatum,dc=com > > dn:ou=Domain Controllers,dc=adatum,dc=com > dn:ou=Finance,dc=adatum,dc=com > dn:ou=FinanceTemps,ou=Finance,dc=adatum,dc=com > > 3 Objects returned
If you want to expand all containers and OUs within an OU, you have to manually expand each one within ADUC or the Active Directory Administrative Center; there is no “expand all” option.
If you need to change domains, right-click on the Active Directory Users and Computers label in the left pane, select Change Domain, enter the domain name, and click OK.
Right-click on the domain node and select Find.
In the Find drop-down box, select Organizational Units. In the Name: text box, enter the name of the OU.
To find any OU with “Test” in the name under the EMEA OU, run the following command:
Get-ADOrganizationalUnit -SearchBase "ou=emea,dc=adatum,dc=com" -LDAPFilter {(ObjectCategory=OrganizationalUnit)} | Where {$_.Name -Match "Test"}The command can be shortened to omit the search base, which will then search the current domain, as shown in the following command:
Get-ADOrganizationalUnit -LDAPFilter {(ObjectCategory=OrganizationalUnit)} | Where {$_.Name -Match "Test"}In a heavily nested environment, you may need to locate an OU
based on its name when you don’t necessarily know its location. By using
the ADUC GUI or a command-line tool with a search scope of subtree, you can easily recurse through the
entire domain structure to find an OU based on its name, description, or
any other attribute. In AdFind, you can use wildcards.
Warning
When designing your Active Directory structure, you should try to keep OU nesting from becoming too deep, since processing many levels of Group Policy Objects can greatly increase the logon times for your clients. In the interests of keeping things simple, it’s often a good idea to keep your OU structure shallow whenever possible.
The following solutions will enumerate all the objects directly under an OU. Refer to section for more on how to display all objects under an OU regardless of the number of objects involved.
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Change Domain, enter the domain name, and click OK.
In the left pane, browse to the OU you want to view.
The contents of the OU will be displayed in the right pane.
By default, ADUC will display only 2,000 objects. To view more than 2,000 objects, click View→Filter Options. Then modify the maximum number of items displayed per folder.
Using -limit 0, all objects
under the OU will be displayed. If -limit is not specified, 100 objects will be
shown by default. You can also specify your own number if you want to
display only a limited number of objects.
The -scope onelevel or
-s one (for AdFind) option causes
only direct child objects of the OU to be displayed. Displaying all
objects regardless of depth is referred to as the subtree
scope, which is the default search scope for AdFind and
DSQuery. If you want to return all objects regardless of depth,
including the OU being searched, simply omit the -scope switch entirely.
To save on typing, you can use the -default switch with AdFind, which
automatically uses the Domain DN as its search base. You can use this
in combination with the -rb
(Relative Base) switch, which will only require you to type in the
relative DN of the OU that you want to search. So to list the objects
in the cn=Finance,dc=adatum,dc=com
OU, you can use the following abbreviated AdFind syntax:
> adfind -default -rb ou=Finance -s one -dn
Another option would be to use the -incldn switch, which will return objects
that contain a particular search string anywhere within the
Distinguished Name. So specifying -incldn
"ou=Finance" would return the cn=Finance,dc=adatum,dc=com OU, as well as
the cn=FinanceTemps,cn=Finance,dc=adatum,dc=com
OU.
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Change Domain, enter the domain name, and click OK.
In the left pane, browse to and select the OU that contains the objects you want to delete.
Highlight all the objects in the right pane and press the Delete key on your keyboard.
Press F5 to refresh the contents of the OU. If objects still exist, repeat step 4.
To delete all objects within an OU, but not the OU itself, you
need to use the -subtree and -exclude options with the dsrm command:
> dsrm "<OrgUnitDN>" -subtree -excludeYou can also perform this task by piping the results of an
adfind query into admod, as follows:
>adfind -default -rb ou=<OU Name> -s one -dsq | admod -unsafe -delIf you want to delete the objects in an OU and re-create the OU, you can delete the OU itself, which will delete all child objects, or you could just delete the child objects. The benefit to the latter approach is that you do not need to reconfigure the ACL on the OU or relink any Group Policy Objects after you’ve re-created the OU.
Enumerating the Objects in an OU for enumerating objects in an OU; Deleting an OU for deleting an OU; MSDN: IADsDeleteOps::DeleteObject
You want to delete an OU that is not protected from accidental deletion along with all of the objects in it.
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Change Domain, enter the domain name, and click OK.
In the left pane, browse to the OU you want to delete, right-click on it, and select Delete.
Click Yes for the confirmation prompt.
If the OU contains child objects, you will be asked for confirmation again before deleting it. Click Yes to continue.
To delete an OU and all objects contained within, use the
-subtree option with the dsrm command. If you don’t use -subtree and the object you are trying to
delete has child objects, the deletion will fail:
> dsrm "<OrgUnitDN>" -subtreeYou can also delete an OU and all of its contents using the
following admod command:
> admod -b "<OrgUnitDN>" -del -treedeleteDeleting OUs that do not contain objects is just like deleting any other type of object. Deleting an OU that contains objects, however, requires a special type of delete operation. The Tree Delete LDAP control (OID: 1.2.840.113556.1.4.805) must be used by the application or script to inform AD to delete everything contained in the OU. All three solutions in this case use the control behind the scenes, but if you were going to perform the operation via an LDAP utility such as LDP, you would need to enable the control first.
Warning
In Windows Server 2008 R2 and Windows Server 2012, the Active Directory Users and Computers console adds an option to the delete confirmation prompt to use the Delete Subtree server control. By using the control, you can delete all child objects in an OU, even if the objects are protected from accidental deletion.
Using LDAP Controls for using LDAP controls; MSDN: IADsDeleteOps::DeleteObject
You want to move some or all of the objects in an OU to a different OU. You may need to do this as part of a domain restructuring effort.
If you need to change domains, right-click on the Active Directory Users and Computers node in the lefthand pane, select Change Domain, enter the domain name, and click OK.
In the left pane, browse to and select the OU that contains the objects you want to move.
Highlight the objects you want to move in the right pane, right-click on them, and select Move.
Browse to and select the parent container you want to move the objects to, and then click OK.
Press F5 to refresh the contents of the OU. If objects still exist, repeat steps 3–5.
When you move objects from one OU to another, you need to be aware of two significant Active Directory design factors that can affect the behavior of the objects that you’re moving: delegation and Group Policy Object inheritance.
The first factor to be aware of is delegation. As an administrator, you can delegate permissions at the OU level so that specific users and groups can (or cannot) access or modify information concerning the objects contained within that OU. When you move an object from one OU to another, that object inherits the delegation settings from its new parent OU. This means that a user or group who had rights to an object before it was moved may no longer have rights to it afterward, and a user or group who did not have rights to the object before may have been delegated rights to the destination OU. You need to be aware of this setting to be sure that you do not allow or prevent object access unintentionally. Active Directory security and delegation is discussed further in Chapter 14.
The second factor to keep in mind is that of GPO inheritance. You can link a GPO at the site, domain, or OU level; any child objects that you move to a new OU will cease to receive the GPO settings that were applied to the old OU and will receive those settings associated with the new OU instead (unless the GPO is linked to the source OU and the destination OU).
The one exception to this would be if you were moving an object
from a parent OU to its child OU—for example, moving from ou=Finance,dc=adatum,dc=com to ou=FinanceTemps,ou=Finance,dc=adatum,dc=com.
In this example, the rules of GPO inheritance would cause the moved
objects to receive any GPO settings linked to the Finance OU, followed
by any GPO settings linked to the Finance Temps OU. Again, you need to
be certain that moving an object from one OU to another does not create
any unintended effects.
Note
You can use the Group Policy Management Console’s Resultant Set of Policy (Modeling) Wizard to simulate the effect that the move will have on objects within the originating OU before you actually perform the move.
If you want to move more than 2,000 objects at one time, you will need to modify the default number of objects displayed, as described in the “Discussion” section of Enumerating the Objects in an OU.
Moving an Object to a Different OU or Container for moving objects; Enumerating the Objects in an OU for enumerating objects in an OU; MSDN: IADsContainer::MoveHere
You want to move an OU and all its child objects to a different location in the directory tree. Note that this scenario covers OUs and child objects that are not protected from accidental deletion.
Open the ADUC snap-in (dsa.msc).
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Change Domain, enter the domain name, and click OK.
In the left pane, browse to the OU you want to move.
Right-click on the OU and select Move.
Select the new parent container for the OU and click OK.
One of the benefits of Active Directory is the ability to structure and restructure data easily. Moving an OU, even one that contains a complex hierarchy of other OUs and objects, can be done without impacting the child objects.
If any applications have a dependency on the location of specific objects, you need to ensure that either they are updated with the new location or, preferably, they reference the objects by GUID, not by distinguished name.
You should also be mindful of the impact of inherited ACLs and the effect of any new GPOs that are linked to the new parent OU. Keep in mind that any GPOs that were already linked to the OU will stay intact, and the link will follow the OU to its new location in the directory structure.
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Change Domain, enter the domain name, and click OK.
In the left pane, browse to the OU you want to rename.
Right-click on the OU and select Rename.
Type in the new name for the OU and press Enter.
Before you rename an OU, ensure that none of your production
applications references it by name. You can make objects rename-safe by
requiring all applications that must store a reference to an object to
use the GUID of the object, rather than the name. The GUID (stored in
the objectGUID attribute) is
effectively unique within a forest and does not change when an object is
renamed.
Renaming an Object; MSDN: IADsContainer::MoveHere
The following examples set the description (description) attribute for the Finance
OU.
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Change Domain, enter the domain name, and click OK.
In the left pane, browse to the OU you want to modify.
Right-click on the OU and select Properties.
Modify the Description field and then click OK.
To modify an object using AdMod, you’ll use the following general syntax:
> admod -b<ObjectDN><attribute>:<operation>:<value>
For example, you can add a description to an OU object using the following syntax:
> admod -b cn="ou=Finance,dc=adatum,dc=com" description::"Finance Department"
You can modify a limited number of object types with DSMod. Run
dsmod /? from a command line for
more details.
Modifying the attributes of an OU is a relatively straightforward process that’s similar to modifying other types of objects within Active Directory. You can modify most attributes of an OU using the Active Directory Computers and Users MMC snap-in, but some attributes will be available for editing only by using ADSI Edit or a command-line or scripting utility.
You want to quickly determine a rough approximation of how many child objects, if any, an OU contains.
Note
Another option would be to run a search using the onelevel scope and count the number of
objects returned by the query. In LDP you can suppress the display
of results so that it displays only the number of objects returned
rather than displaying the specifics of each item.
You can retrieve the number of child objects that are contained in an OU using either DSQuery or AdFind. To perform this task using DSQuery, use the following syntax:
> dsquery * "<OrgUnitDN>" -scope base -attr msDS-Approx-Immed-SubordinatesThe syntax for AdFind is as follows:
> adfind -b "<OrgUnitDN>" -s base msDS-Approx-Immed-SubordinatesThe msDS-Approx-Immed-Subordinates attribute was
introduced in Windows Server 2003. It contains the approximate number of
direct child objects in a container or organizational unit. Note that
this is an approximation and can be off by 10% or more, sometimes
significantly more, of the actual total for large containers. (For
instance, we ran this query for a container with 2,008 objects in it
that reported a value of 1306 for the
msDS-Appox-Immed-Subordinates
attribute.) The main reason for adding this attribute was to give
applications an idea of the rough order of magnitude of how many objects
a container has so that it can display them accordingly.
msDS-Approx-Immed-Subordinates
is a constructed attribute—that is, the value is not actually stored in
Active Directory like other attributes. Rather, Active Directory
computes the value when an application asks for it.
You want to delegate administrative access of an OU to allow a group of users to manage objects in the OU.
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Change Domain, enter the domain name, and click OK.
In the left pane, browse to and select the target OU, and then select Delegate Control.
Click Next and then click Add to select the users and/or groups to delegate control. Click OK to close the selection window and then click Next.
Select the type of task to delegate to the users or groups you selected in step 4 and then click Next.
Click Finish.
ACLs can be set via the command line with the dsacls utility. See Changing the ACL of an Object for more information.
Although you can delegate control of an OU to a particular user, it is almost universally a better practice to use a group instead. Even if there is only one user to delegate control to, you should create a group, add that user as a member, and use that group in the ACL. That way, in the future when you have to replace that user with someone else, you can simply make sure the new person is in the correct group instead of modifying ACLs again. The Delegation of Control Wizard is discussed further in Using the Delegation of Control Wizard.
Changing the ACL of an Object for changing the ACL on an object; Using the Delegation of Control Wizard
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Change Domain, enter the domain name, and click OK.
Locate the OU in the left pane and then right-click on the OU and select Properties.
Select the Managed By tab.
Click the Change button.
Locate the group or user to delegate control to and click OK.
Click OK again to close the OU properties window and apply the changes.
To remove a manager from an OU, follow the same steps but click Clear instead of Change on the Managed By tab.
To add a manager for an OU, use the following syntax:
> admod -b<ObjectDN>managedBy::<ManagerDN>
To clear the managedBy
attribute, use the following:
> admod -b <ObjectDN> managedBy:-You can use the following command to configure the Test OU to be managed by the account with a CN of Administrator:
Set-ADOrganizationalUnit "ou=test,dc=adatum,dc=com" -ManagedBy "Administrator"
Or, you can also specify the DN in place of the CN as shown in the following example:
Set-ADOrganizationalUnit "ou=test88,dc=woodgrovebank,dc=com" -ManagedBy "cn=aministrator,cn=users,dc=adatum,dc=com"
In the case of an OU, specifying a user, group, computer, or
another OU in the Managed By tab does not confer any particular rights
onto the manager; this is used as a strictly informational field. When
you configure a manager for an OU, the manager’s DN is placed in the
OU’s managedBy attribute, and the
OU’s DN is placed in the manager’s managedObjects attribute. managedObjects is the backlink attribute of
managedBy, showing all objects where
that manager is specified.
You want to apply the settings in a GPO to the users and/or computers within an OU, also known as linking the GPO to the OU.
Expand Forest in the left pane.
Expand Domains, expand the targeted domain name, and then navigate down to the OU in the domain you want to link the GPO to.
Right-click on the OU and select either “Create a GPO in this domain, and Link it here” (if the GPO does not already exist) or “Link an Existing GPO” (if you have already created the GPO).
To unlink a GPO, right-click on an existing link and remove the checkmark next to Link Enabled.
The GPOs that are linked to an OU are stored in the gpLink attribute of the OU. The format of the
gpLink attribute is kind of strange,
so you have to be careful when programmatically or manually setting that
attribute. Since multiple GPOs can be linked to an OU, the gpLink attribute has to store multiple values;
unfortunately, it does not store them in a multivalued attribute as you
might expect. Instead, the links are stored as part of the single-valued
gpLink attribute. The ADsPath of each
linked GPO is concatenated into a string, with each enclosed in square
brackets. The ADsPath for each GPO is followed by ;0 to signify the link is enabled or ;1 to signify the link is disabled. Here is an
example gpLink with two GPOs
linked:
[LDAP://cn={6491389E-C302-418C-8D9D-
BB24E65E7507},cn=policies,cn=system,dc=adatum,dc=com;0]
[LDAP://cn={6AC1786C-016F-
11D2-945F-00C04fB984F9},cn=policies,cn=system,dc=adatum,dc=com;0]Creating a GPO Link to an OU for more information on the Group Policy Management snap-in
Open Active Directory Users and Computers (dsa.mc). Click on View and confirm that Advanced Features is selected.
Drill down to the current domain. To connect to a different domain, right-click on the top-level node and click “Change domain”; select the appropriate domain and then drill down to it.
Right-click on the OU that you want to modify and click Properties.
Click on the Object tab.
Place a checkmark next to “Protect object from accidental deletion.”
One of the challenges in delegating permissions within Active
Directory is the potential for accidental deletions, particularly when
administrators delete an entire organizational unit when they had only
intended to delete a single object within that OU. Since Windows Server
2008, a new option is exposed in the Active Directory Users and
Computers and Active Directory Sites and Services MMCs that will prevent
an object from being deleted by means of a “fat-finger” deletion. By
default, all new OUs that are created via the Active Directory Users and
Computers MMC will have this protection enabled; however, any
preexisting OUs or OUs created through other methods will not unless you
enable it manually using one of the methods shown in this recipe.
Additionally, built-in Active Directory containers, such as the BUILTIN, Computers, and Users containers, as well as the Domain
Controllers OU and other built-in containers, do
not have this protection enabled by default. If you
attempt to delete an OU that is protected using this option, even when
signed on as a Domain Admin or other similarly elevated account, you
will receive an “Access Denied” message until you manually remove the
checkbox or manually remove the deny ACE associated with it.
If you wish to enable this protection for all OUs that were
present in your environment, you can automate the use of dsacls with a for
do loop, as follows:
for /f "tokens=*" %i in ('dsquery ou -limit 0') do dsacls %i /d everyone:SDDTYou can also automate the process through PowerShell by piping the
results of a Get-ADOrganizationalUnit
query into the Set-ADOrganizationalUnit cmdlet, as
follows:
Get-ADOrganizationalUnit -Filter * | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion:$True
One advantage to using the command-line or PowerShell method is that this protection can be applied to container and leaf objects in all versions of Windows Server, even though the GUI checkbox is available only in Windows Server 2008 and later.