The department model

In the organization, departments help represent the hierarchical order as well as responsibilities. The same structure can be converted into the Active Directory OU structure. Users and asserts related to each department will be categorized together:

In the preceding example, the OU structure starts with the departments. Each department has its own OU, and its objects are further categorized based on the class and responsibilities. This allows you to delegate control to objects in each department easily. As an example, managers in each department can be set up with delegated control to add or modify objects under their own departments.

The advantages and disadvantages of the department model are listed as follows:

Advantages

Disadvantages

Distributed delegated control: Under the department, objects are grouped together based on object classes, and responsibilities. This allows administrators to delegate control to individuals or groups in order to manage objects in their own department operation boundaries. Administrators do not need to change the structure based on delegation requirements as the model will group it the way it is needed by default.

Object locations will be difficult to match with the structure: Not all objects can match with this structure. In organizations, there are asserts and services that are shared by different departments. As an example, printers, file servers, and mail servers are shared by all the departments in the organization. This will need to be represented under the common OU, which is not going to match the organization structure.

Minimum structure changes: Since the model matches the company operation's structural design, the changes to the OU structure will be minimal compared to other models.

Limitation of applying company-wide settings: In an organization, there are operational and security requirements that are not dependent on the departments. For example, an organization's data security policies, network security policies, identity protection measures, and so on are common for every department and every user in the organization. Since objects are grouped based on department levels, we will have limitations of targeting objects to apply these different policies.

Less complex: The organization's operational structures (departments) are not complex usually. Departments have a well-defined structure to manage their asserts and responsibilities. Since the OU structure is going to be almost a replica of that model, the OU structure also will be less complex to manage.

N/A

These different types of models can be used as guidelines to design your OU structure. Maybe none of these models match your business requirements. It is absolutely fine to create a mixed model using all of these, but make sure that you validate the design considering easy object management, GPO requirements, and appropriate delegated control.

There is no limitation to how many sublevels OUs can have. Having more sublevels helps categorize objects in the granular level, but at the same time, it will add to the complexity of managing the structure. This is especially effective in Group Policy management. Therefore, try to keep it under three sublevels.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.219.36.249