Back to Basics: Groups vs. Organizational Units in Active Directory

by [Published on 1 Oct. 2014 / Last Updated on 1 Oct. 2014]

Advertisement GFI Archiver helps system admins archive files, folders, calendar entries and emails in a secure and compliant archive for Exchange server. Get your FREE trial now!

Archiving for productivity, management and compliance

  • Archiving for email, files and calendars
  • Limit legal risk and achieve compliance
  • Identify business issues with MailInsightsŠ¾ reports

Your FREE trial awaits:

Download a 30 day, fully functional, free trial which also includes GFI technical support.

No credit card required

This article takes a look at the differences between an Active Directory group and organizationl unit.


I know this sounds a bit light and easy, but trust me it is obviously not. I train and speak to about 5000 administrators, security professionals, and auditors each year. During my discussions there seems to be a confusion as to what an Active Directory group is compared to an organizational unit. So, instead of constantly beating my head against the wall trying to teach people in smaller groups, I would just write an article that I can send people to in order to reach the masses. If nothing else, for those of you that think you are fully aware of the differences, maybe I can “wow” you with some tidbits of knowledge in this article, so please still read along. At the end of the article you will know more about groups and organizational units than you ever wanted, but it will be extremely useful for everyone who needs to deal with them, either in their configuration or their verification.

In the Beginning

We must go back to Windows NT in order to get the full breadth and view into groups and organizational units. Back in the Windows NT days there was no such thing as an organizational unit. There were also fewer options for domain groups than there is today. We will get to the newer groups soon.

So, back in Windows NT there were two types of groups, which were “global groups” and “local groups.” Global groups were created and stored on domain controllers for a Windows NT domain. Global groups were important to the domain as they had a security identifier (SID) which was how the operating system tracked this object. Local groups also have SIDs and are tracked by the operating system. Local groups could be created on domain controllers or on workstations/servers. The major difference between the two domain groups is the fact that global groups can be seen by all workstations and servers that are joined to the domain and local groups are only visible to the domain controllers. Local groups located on workstations and servers could only be seen by the local computer.

The ideal use of these groups was to have users placed into global groups, then the global groups placed into local groups where the resources (files/folders/etc) resided. This could be the domain controller itself or a server which contained company data.

Introduction of Active Directory

With the introduction of Active Directory the world changed with regard to group options. Also, there was a new object type, the organizational unit. The two objects were not interchangeable, but would be used in conjunction with one another.

Active Directory Groups

The only group that remained the same from Windows NT to Active Directory was the global group. Well, in name at least. An Active Directory global group could contain other global groups, where in Windows NT they could not.

Another domain group type in Active Directory was the universal group. The universal group was designed to cross domain boundaries. Since Active Directory could have many domains in the same forest, the universal group was designed to cross these boundaries so that one universal group could be seen and used by all domains in the forest.

Local groups are no longer available in Active Directory. Instead they are replaced with “domain local groups.” The concept is quite revolutionary actually. Since local groups on domain controllers were only visible to domain controllers, it forced the use of local groups on workstations and servers that were joined to the domain. Domain local groups in Active Directory are visible to all workstations and servers joined to the Active Directory domain. This concept and design could eliminate the use of local groups on workstations and servers.

In the end, the new model for the usage of groups in Active Directory is the following: users are to be placed into global groups, global groups are to be placed into domain local groups, and the domain local groups are to be placed on the access control lists of the data stored on the servers. If there are multiple domains and universal groups are desired, then the global groups containing users are to be placed into universal groups. The universal groups are then placed into the domain local groups, where the domain local groups are then placed on the access control lists.

As you can see, groups are designed to contain users and in the end be granted access to files and folders which are stored on servers throughout the domain. The best practice of the use of groups is not always used. Users, universal groups, global groups, domain local groups, and local groups can all be placed on an access control list for data on a server joined to the domain. The creation of groups can be seen in Figure 1.

Figure 1: Active Directory groups can be universal, global, or domain local.

Organizational Units

Organizational units are dramatically different from groups. Here are just a few ways they are different from groups:

  • Organizational units don’t have SIDs
  • Organizational units can’t be placed on an access control list
  • Organizational units can’t be placed into a group

So, if these are the limitations, what are organizational units used for? Organizational units are used to organize Active Directory objects. I know, I am using the root word of organizational in the definition. However, it is the best way to define the object. Here are some uses of organizational units:

  • Delegation of administration to the objects located in the organizational unit
  • Deploy group policy settings to the objects located in the organizational unit

Let me give you an example. Let’s say that there are 50 financial users. These financial users have their own helpdesk. Ideally, the helpdesk for finance could reset passwords for the finance users if they were to forget their password. The solution would be to place all of the finance users into an organizational unit named Finance, then delegate the ability for the helpdesk to reset passwords for all users in the Finance organizational unit.


In the end, you can see that groups are designed to grant access to data and organizational units are designed to control objects (delegation and group policy settings). Groups have changed over the years and operating systems, which might be the root of the confusion. Organizational units are new (in comparison to groups), which might be the root of the confusion. No matter what, they are different and used in totally different ways. Groups have SIDs, can be placed on access control lists, and can contain other groups (even the same type of group referred to as group nesting). Organizational units do not have SIDs, can’t be placed on an access control list, and can not be placed into a group. Instead, organizational units are used to organize users, groups, and computers within Active Directory. This organization is used to grant delegation and deploy configuration and security settings through group policy. Moving forward it is ideal to use the best practice for group nesting, as it is easiest to manage and provides the best security environment for Active Directory. Of course organizational units can be nested into other organizational units and often are. Just remember the two main reasons for organizational units and the design and deployment of them will be clear.

See Also

The Author — Derek Melber

Derek Melber avatar

Derek Melber (MCSE, MVP) educates and evangelizes Microsoft technology, focusing on Active Directory, Group Policy, Security, and desktop management.