Active Directory Sites and Organizational Units

Active Directory Sites and Organizational Units

This section covers how to use sites for the physical organization of AD DS, and you will learn some of the criteria you should consider when creating Active Directory Sites. The second part of this section discusses organizing Active Directory objects logically by using organizational units (OUs).

Active Directory Sites

According to Microsoft, A Site is a group of well connected networks. In other words, the sites are the networks that are connected to each other via high speed networking devices. A site can be more than one subnet combined together, just like subnet defines the part of your network; a site defines the part of your network.

Active Directory Sites and Subnets
Active Directory Sites and Subnets

To better understand the concept of sites, consider the following example:

You are working as network administrator for a company. The company is using single subnet network with subnet 192.168.10.0/24. Initially your company is spanned into only one floor. Due to suddenly growing business, company rented one more floor in the same building. The second floor contains only a few users. Since it is unexpected growth, you created another network  with 192.168.20.0/24 subnet and connected the both subnets using a high speed Router. In this scenario, it does not make any sense to create two different Sites in Active Directory. So you can combine both subnets into one Active Directory Site. In this case both the subnets will share the network resources with each other. Active Directory treats these two subnets as the one network location or Site.

In other scenario, consider that there is a special department in your company which has a secure network 192.168.30.0/24 which is separated by a firewall. To ensure the privacy of this department, you can create a different Active Directory Site even though the networks are well connected. In this case, creating a different Active Directory Site makes sense.

In most cases the choice of creating sites is decided by different physical locations. In some cases the choice comes due to Firewalls separating networks and limited traffic need to be travelled between networks. You can also create different sites when the speed of the link between two networks in not so fast or already been utilized by other important traffic. This will reduce the amount of traffic that is sent across the link.

AD DS employs a multimaster replication technology that allows nearly every aspect of the directory service to be modified from any of the domain controllers within a domain. Changes that are made to one domain controller within the domain are replicated to all the other domain controllers within the domain. This replication allows all the domain controllers to act as peers and provide the same functionality. However, this same replication can cause problems when you are trying to keep WAN traffic to a minimum.

Intrasite Replication

Intrasite Replication is the process when two or more domain controllers located in the same site exchange the active Directory database and other relevant information with each other. This type of replication happens every 15 seconds after any change occurred in Active Directory. The domain controllers that are all members of the same site will replicate more quickly.

Intra-Site Replication
Intra-Site Replication
Intersite Replication

Two or more Active Directory Sites are interconnected by Site links which are created either manually or automatically by Knowledge Consistency Checker (KCC). The Knowledge Consistency Checker (KCC) is a background process that runs on all domain controllers and creates connection objects that represent the replication paths to other domain controllers within the site to produce an efficient replication path. The replication between sites is done by Bridgehead servers. The Bridgehead server is a domain controller that has been either administratively assigned or automatically chosen to replicate changes collected from other domain controllers in the site to bridgehead servers in other sites.

Inter-site Replication
Inter-site Replication

The KCC is also responsible for generating the intersite connection objects. When a site connector is created to allow replication between two sites, one domain controller is identified as the Inter-Site Topology Generator (ISTG) . The ISTG is responsible for determining the most efficient path for replication between sites. Windows 2000’s version of the ISTG did not have a very efficient algorithm for building intersite connection objects, which left many large companies with 100 or more sites creating their own connection objects between those sites. If you have the ability to put your forest in the Windows Server 2003 forest functional level, the ISTG uses a new algorithm to calculate and build the intersite connection objects. You can identify which domain controller is functioning as the ISTG by using the Active Directory Sites and Services snap-in and displaying the properties of the site. You can choose your own bridgehead server for Site but it is recommended that you do not choose your own and let the KCC do this for you. This is because if you manually choose the bridgehead server for a site and at any time the server becomes unavailable, the replication will not happen. If you let KCC to choose bridgehead server for every site, when one of the domain controller acting as bridgehead becomes unavailable, KCC will automatically choose another available domain controller as bridgehead.  The replication between sites can be controlled via scheduling where you can control when and how often the replication will occur.

Create New Active Directory Site

To create new Site, go to administrative tools and then open Active Directory Sites and Services.

Create New AD Site
Create New AD Site

Then Type the Name of Site and select the Site link object to be used for replication

Create New AD SiteTo move the domain controllers from one site to another, simply drag and drop the selected DC to destination Site as shown below.

Move Domain Controller between sites
Move Domain Controller between sites

Create New Site Link

When you create a new site, the site link is automatically created. If you want to create the link manually, Under Active Directory Sites and Services console, Go to Sites, then Inter-site Transports and then select IP.

Right Click the IP option and select New Site Link.

Create new site link
Create new site link

Type the name for site link and then select the Sites the link is to be used to connect.

create new site link Click OK to create the Site link.

After the Site Link is created, you can modify the properties of link and adjust the site link cost and replication schedule according to your requirements.

To adjust the Site link cost and replication schedule, right click the Link name and select properties. Here you can change the settings as shown below.

Adjust Site Link Cost & Replication Schedule
Adjust Site Link Cost & Replication Schedule

Create Subnets for AD Sites

The process of creating subnets is similar to that of creating Sites. Under Active Directory Sites and Services console, Go to Sites, then right click Subnets option and select new Subnet.

Create New Subnet
Create New Subnet

Type the Subnet information and then Select the Sites you want to assign for that subnet.

Creating new subnets for Sites
Creating new subnets for Sites

Click OK to create the subnet.

Organizational Units (OU)

Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. An organizational unit cannot contain objects from other domains.

Organizational unit is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority. Using organizational units, you can create containers within a domain that represent the hierarchical, logical structures within your organization. You can then manage the configuration and use of accounts and resources based on your organizational model. The below image shows the hierarchical structure of OUs in a test domain.

Organizational Units
Organizational Units

Organizational Unit Design Criteria

As you build your company’s OU hierarchy, make sure it uses the most efficient layout possible. Designing the OU hierarchy can prove very challenging. If you build too many OUs with several child OUs beneath them, you could create problems when trying to apply group policies.

One of the most fundamental reason for creating OU is applying Group Policies. So, the OU hierarchy should be designed by keeping Group Policies in mind. I will cover Group Policies in lot more details in the next section.

Delegating Control on OU

The OU owners are responsible for making sure that the appropriate users and groups have the ability to manage the objects for which they are responsible. By delegating administration control, you can assign a range of administrative tasks to the appropriate users and groups. You can assign OU administrative tasks to help-desk users or groups so that they can create new users, computers etc in specified OUs. Delegation control does not need you to add the users or groups into Domain Admins or Enterprise Admins groups.

Delegation Methods

Object-based delegation grants a user control over an entire object type. Objects within AD DS comprise users, groups, computers, OUs, printers, and shared folders. If a user needs to have control over computer accounts, you can use the Delegation of Control Wizard to allow full-control permission over only computer objects within the OU. You might have another user who administers the user and group objects within the OU. This level of control can be delegated as well.

Task-based delegation grants a user the ability to perform specific functions against objects within the OU. Controlling objects at this level is more difficult to manage and maintain, but sometimes may be necessary. For example, a company has a help-desk, and one of its job duties is to reset passwords for users. However, you don’t want helpers to modify any of the user properties.
If you delegate the ability to work with user objects, the help-desk personnel will have too much power. Instead, you can delegate the ability to reset passwords at the task level, thereby preventing the help-desk personnel from affecting the objects in any other way.

It is much more difficult to manage the permissions granted at the task level than those at the object level. You will need to document the groups to which you are delegating permissions. Otherwise, you may find it problematic to track down where permissions are applied and troubleshoot access problems. As a best practice, design the OU structure so that you can take advantage of object-based delegation as much as possible.

Understanding Inheritance

Inheritance allows the permissions set at a parent level to be assigned automatically, or propagated, to each child level. The inheritance of object permissions from the parent object to the child object eases some of the administration headaches. Any object created within an OU will inherit the applicable permissions from the OU. With this being the case, whenever an account is granted permissions at the OU level, all of the child OUs and objects within those OUs inherit the settings. OU owners can control all the objects within their OU tree after the domain owner delegates the appropriate permissions to the top-level OU.

Occasionally the permissions set at higher levels within AD DS are not the permissions needed at a lower level. If this is the case, inheritance can be blocked, which means that permissions set at the parent level will no longer pass to the child objects. When blocking the inheritance of permissions, the administrator who is initiating the block can choose whether to copy the inherited permissions to the object or to remove them completely. You may want to copy the permissions if the majority of the permissions will stay the same, but you may only want to change one or two permissions. This will allow you to keep the majority of the permission entries and simply remove the permission entries you do not want instead of recreating the entire permission list. If the inherited permissions are removed from the object, only the permissions that are explicitly set at the object level will apply. This could restrict an upper-level OU owner, OU administrator, domain owner, or forest owner from being able to perform actions against the object. If this happens, the OU owner, OU administrator, domain owner, or forest owner can reset the inheritable permissions on the object or objects that were affected.

The OU Design Options

The OU design should be predicated on the administrative structure of the organization, not the departmental organization as seen on the company’s organization chart. Most companies do not base the administration of resources on the organization chart. Usually, the IT department is responsible for objects within the company no matter which department is using the resource.

Although this centralized approach is the most basic method of controlling the objects within AD DS, some organizations cannot utilize one single administrative group that has power over all the objects. Other organizations will not have a centralized administrative team; instead they will have decentralized control over objects. In such cases, design decisions will have to be made that will dictate where the objects will reside within the OU structure. Microsoft has identified five design options to use when developing the OU design: by location, organization, business function, location and then business function, or organization and then location.

OUs Based on Location

If an organization has resources that are centralized but the administrative staff is based at different geographic locations, the OU design should take on a location-based strategy. Using this strategy, the OU structure is very resistant to reorganizations, mergers, and acquisitions. Because all the objects are located beneath the top-level OU, which is based on company location, as shown in diagram below, the lower-level OUs can be modified and the objects moved within the OUs to accommodate the changes. Consider the alternative: having domains that are used to host the objects. Moving objects between domains has many more implications because the security ID of the objects will have to change, as will the domain owners.

OU Structure based on Location
OU Structure based on Location

There are some disadvantages of location-based strategy. Unless the inheritance of permissions has been blocked, administrative groups that are granted authority at an upper-level OU will have the ability to affect objects in the lower-level OUs. This could create unwanted administrative control over objects as well as pose security concerns. You might want to prevent some administrative personnel from controlling some of your resources.
The location-based strategy works well within organizations that are using the departmental model but have geographically dispersed resources. In this manner, administrators located at the site where the resources are will have control over the objects that represent them in AD DS.

OUs Based on Organization

If a company has an administrative staff that reports to divisions and is responsible for the maintenance of the resources for that division, the OU structure can be designed to take advantage of the company’s departmental makeup, as shown in diagram below. Using this design strategy makes the OU structure much more vulnerable to change within the organization should a reorganization occur. However, it does allow departments to maintain autonomy over the objects they own.

OU Structure based on Organization
OU Structure based on Organization

This strategy is usually employed whenever business models based on cost center, product/service, or project are employed. This allows the resources to be grouped so that the cost centers are separate OU structures. The product, service, or project resources can likewise be isolated within an OU tree, and the administrators who are responsible for the resources can be delegated the ability to control the objects within AD DS.

OUs Based on Business Function

Smaller organizations that have an administrative staff that provides specific functions to the organization typically use an OU design strategy based on job functions, as shown in diagram below. In these smaller organizations, the administrators will have several job responsibilities. Building the OU structure based on the job responsibilities allows the controlled objects to be grouped together based on the tasks that have to be administered. This type of OU deployment is resistant to company reorganizations, but because of the way the resources are organized, replication traffic may increase.

This strategy can be employed with any business model. Because it is usually implemented in smaller companies, a single administrative group such as IT is responsible for maintaining all the objects. The functions can be broken out based on the staff responsible for maintaining user objects, group objects, shared folders, databases, mail systems, and so on. Of course, the administrative staff will have to be trusted by all divisions if this model is employed, but this is usually not as much of an issue in smaller companies.

OU structure based on Business Function
OU structure based on Business Function
OUs Based on Location and Organization

Two hybrid methods of organizing resources exist. Each one is based on a combination of the location of resources and the method the company uses to organize the objects.

OUs based on location then organization
When you use an OU design strategy that is based first on location and then on organization, the upper-level OUs are based on the location of the objects within the directory, and the lower-level OUs are broken out by the organization’s departmental structure, as shown in diagram below.

This strategy allows the organization to grow if necessary, and it has distinct boundaries so that the objects’ administration is based on local autonomy. Administrative staff will need to cooperate if administrative groups are responsible for the departments within the OU structure, because OU owners will have control over all the objects within the OU tree.
Large companies that employ the departmental business model might have several locations that have administrative staff controlling the resources. If this is the case, the OU owner for a given location can control all the accounts that are OU administrators for the individual departments within that location. This allows the OU owner to control users within the location for which they are responsible, while still maintaining control over their location.

OUs based on location then organization
OUs based on location then organization

OUs based on organization then location
With an OU design strategy that is based first on organization and then on location, the OU trees are based on the organization’s departmental makeup, with the objects  organized based on location, as shown in below diagram. Using this strategy, the administrative control of objects can be delegated to administrative staff responsible for objects at each of the locations, whereas all the resources can be owned by a department’s own administrative staff. This allows a strong level of autonomous administration and security; however, the OU structure is vulnerable to reorganization because the departmental design of the company could change.

OUs based on organization then location
OUs based on organization then location

Notice that each of the design options has its own unique set of advantages and disadvantages. To choose the best design for your company, weigh the pros and cons of each strategy so that you come up with the design that is the best fit for your environment.

Back

 



Microsoft Certified Professional | Cisco Certified Network Associate

1 Comment

  • Christian Louboutin Azienda

    Good information. Lucky me I recently found your
    website by chance (stumbleupon). I have book marked
    it for later!

Comments are closed.