Access Denied: Understand the Difference Between AD OUs and Groups

What's the difference between organizational units (OUs) and groups in Active Directory (AD)? I need to understand the difference between putting a user in the Human Resources OU and putting the user in the Human Resources group.

In Windows 2000 and AD, groups have the same function that they have in Windows NT or other OSs: You put a user in a group to control that user's access to resources. You put a user in an OU to control who has administrative authority over that user. To understand the difference between groups and OUs, consider this: Objects with SIDs (i.e., users, groups, and computers) can act on objects and be granted authority. Groups have a SID, and OUs don't.

For example, in Figure 1, Harry is a member of the Human Resources group and is contained in the Human Resources OU. The Human Resources group has Change access to the HRData folder. Therefore, Harry has Change access to HRData because he's a member of the Human Resources group. The Human Resources OU ACL grants Alice, the departmental administrator, Full Control of user objects, which means that Alice can administer Harry's user account because it's in the Human Resources OU.

An analogy might help you understand OUs. OUs are to AD as folders are to a file server. You no doubt know that each file on a file server has its own ACL but that, by default, files inherit the same permissions their parent folders have. Administrators believe best practice is to avoid maintaining file access on individual file ACLs and to instead use folder-level ACLs to manage access in the same way for all the files in the folder. In AD, like files on a file server, each user and group object has its own ACL that governs not what that user or group can access but who can view or edit that user's or group object's properties.

In AD, because users and groups have ACLs, you can delegate portions of administrative authority to subadministrators. But, just as separately maintaining the ACL of every file is impractical, so is separately controlling administrative authority on each user or group object. Therefore, you can collect into an OU all the users and groups that you want to enable a particular subadministrator to manage, then grant the proper authority over the OU to that subadministrator. Permissions you define in an OU's ACL flow down to all the users and groups in that OU, just as folder ACLs flow down to all the files in a folder. To help you keep OUs and groups straight, remember that a user can be a member of many groups but can reside in only one OU, just as a file can reside in only one folder.

End of Article