In the previous section, I explained what a container is. One of the characteristics of this container is that it has large administrative boundaries. As an example, the Computers container will contain any computers added to the Active Directory by default. It can be a physical server, virtual server, desktop computer, or laptop. The container model is based on a similar concept. This is mainly applicable to small businesses where there are limited administrative and security requirements over the Active Directory objects. When OU boundaries are large, it is not possible to apply tailored group policies or precise delegated control as each OU can contain different classes of objects as well:
In the preceding example, the organization has four main OUs. In the container model, there will not be any child OUs. As we can see, each OU covers a large boundary. As an example, the Standard users OU will contain objects from each and every department. This is not going to apply different policies or delegate control based on each department. In here, the user object's OU will be decided based on its privileges. If a user object has administrator privileges, it will be in the Administrators OU, and if not, it will be in the Standard users OU.
The following table discusses the advantages and disadvantages of the container model:
|
Advantages |
Disadvantages |
|
Easy to implement: No child OUs; no granular-level security and administrative boundary design required. |
Less control: It will not categorize objects in detail. Therefore, administrators will have less control over the objects. Since administrative boundaries are large, it is not practical to implement delegated control either. |
|
Fewer group policies: When OUs contain a large number of objects from different classes, it's hard to be specific about system or security settings. Therefore, each OU will have a smaller number of group policies. Even on those, the settings will be more high level than complex tune-ups. |
Less security: It is difficult to apply different group policies to match the security requirements of objects and workloads as the OU structure doesn't help group the relevant objects together. |
|
Easy to change: Since each OU doesn't contain many group policies and complex inheritance, if needed, the structure can be changed completely with minimum impact. |
Less extensibility: This is not a future-proof design. As the business grows, object management requirements will change as well. If further categorization is required, it will be difficult to implement without a complete structural change. |