Editing Active Directory (section)

====Organizational units====
The objects held within a domain can be grouped into [[organizational unit]]s (OUs).<ref>{{Cite web | title = Organizational Units | url = https://technet.microsoft.com/en-us/library/cc978003.aspx | work = Distributed Systems Resource Kit ([[Microsoft TechNet|TechNet]]) | publisher = Microsoft | quote = An organizational unit in '''Active Directory''' is analogous to a directory in the file system | year = 2011 }}</ref> OUs can provide hierarchy to a domain, ease its administration, and can resemble the organization's structure in managerial or geographical terms. OUs can contain other OUs—domains are containers in this sense. Microsoft recommends using OUs rather than domains for structure and simplifying the implementation of policies and administration. The OU is the recommended level at which to apply [[group policies]], which are Active Directory objects formally named group policy objects (GPOs), although policies can also be applied to domains or sites (see below). The OU is the level at which administrative powers are commonly delegated, but delegation can be performed on individual objects or attributes as well.

Organizational units do not each have a separate namespace. As a consequence, for compatibility with Legacy NetBios implementations, user accounts with an identical SamAccountName are not allowed within the same domain even if the accounts objects are in separate OUs. This is because SamAccountName, a user object attribute, must be unique within the domain.<ref>{{cite web |date=4 January 2012 |title=SamAccountName is always unique in a Windows domain... or is it? |url=http://blog.joeware.net/2012/01/04/2357/ |access-date=18 September 2013 |publisher=Joeware |quote=examples of how multiple AD objects can be created with the same SamAccountName}}
</ref> However, two users in different OUs can have the same common name (CN), the name under which they are stored in the directory itself such as "fred.staff-ou.domain" and "fred.student-ou.domain", where "staff-ou" and "student-ou" are the OUs.

In general, the reason for this lack of allowance for duplicate names through hierarchical directory placement is that Microsoft primarily relies on the principles of [[NetBIOS]], which is a flat-namespace method of network object management that, for Microsoft software, goes all the way back to [[Windows NT 3.1]] and [[MS-DOS]] [[LAN Manager]]. Allowing for duplication of object names in the directory, or completely removing the use of NetBIOS names, would prevent backward compatibility with legacy software and equipment. However, disallowing duplicate object names in this way is a violation of the LDAP RFCs on which Active Directory is supposedly based.

As the number of users in a domain increases, conventions such as "first initial, middle initial, last name" ([[Name order|Western order]]) or the reverse (Eastern order) fail for common [[family names]] like ''Li'' (李), ''Smith'' or ''Garcia''. Workarounds include adding a digit to the end of the username. Alternatives include creating a separate ID system of unique employee/student ID numbers to use as account names in place of actual users' names and allowing users to nominate their preferred word sequence within an [[acceptable use policy]].

Because duplicate usernames cannot exist within a domain, account name generation poses a significant challenge for large organizations that cannot be easily subdivided into separate domains, such as students in a public school system or university who must be able to use any computer across the network.

=====Shadow groups=====
[[File:Active directory - OUs can not be given rights to objects.png|thumb|In Active Directory, organizational units (OUs) cannot be assigned as owners or trustees. Only groups are selectable, and members of OUs cannot be collectively assigned rights to directory objects.]]
In Microsoft's Active Directory, OUs do not confer access permissions, and objects placed within OUs are not automatically assigned access privileges based on their containing OU. It represents a design limitation specific to Active Directory, and other competing directories, such as Novell [[Novell eDirectory|NDS]], can set access privileges through object placement within an OU.

Active Directory requires a separate step for an administrator to assign an object in an OU as a group member also within that OU. Using only the OU location to determine access permissions is unreliable since the entity might not have been assigned to the group object for that OU yet.

A common workaround for an Active Directory administrator is to write a custom [[PowerShell]] or [[Visual Basic]] script to automatically create and maintain a ''user group'' for each OU in their Directory. The scripts run periodically to update the group to match the OU's account membership. However, they cannot instantly update the security groups anytime the directory changes, as occurs in competing directories, as security is directly implemented into the Directory. Such groups are known as ''shadow groups''. Once created, these shadow groups are selectable in place of the OU in the administrative tools. Microsoft's Server 2008 reference documentation mentions shadow groups but does not provide instructions on creating them. Additionally, there are no available server methods or console snap-ins for managing these groups.<ref>Microsoft Server 2008 Reference, discussing shadow groups used for fine-grained password policies: https://technet.microsoft.com/en-us/library/cc770394%28WS.10%29.aspx</ref>

An organization must determine the structure of its information infrastructure by dividing it into one or more domains and top-level OUs. This decision is critical and can base on various models such as business units, geographical locations, IT service, object type, or a combination of these models. The immediate purpose of organizing OUs is to simplify administrative delegation and, secondarily, to apply group policies. While OUs serve as an administrative boundary, the forest itself is the only security boundary. All other domains must trust any administrator in the forest to maintain security.<ref>{{Cite web | title = Specifying Security and Administrative Boundaries | url = https://technet.microsoft.com/en-us/library/cc755979(WS.10).aspx | publisher = Microsoft Corporation | quote = However, service administrators have abilities that cross domain boundaries. For this reason, the forest is the ultimate security boundary, not the domain. | date = 23 January 2005}}</ref>