Active Directory subnets, sites, and site links

Active Directory subnets

A single, physical network can be broken into smaller segments called subnets in a process called subnetting. Each subnet on a network is connected by routers. Every device in a network, whether it’s a domain controller (DC), a server, or a client, must belong to a particular subnet. By using subnets, an organization won’t need to acquire a new network number through its ISP.

When an organization deploys Active Directory (AD), it needs to create subnet objects for each subnet that exists in its overall network infrastructure. Each subnet object is then associated with a single site object within AD.

AD sites

A site object is made up of one subnet or a group of subnets connected by high-speed links. When promoting DCs, they are placed within a site (called Default-First-Site-Name) which gets created automatically. If additional sites are created, DCs can then be moved between sites.

An organization with offices in different geographical locations may find it beneficial to create sites for the following reasons:

  1. Authenticating and authorizing users can be managed locally as much as possible.
  2. Replication traffic can be streamlined and unnecessary network traffic can be avoided during business hours.

Client computers will always attempt to get their AD services from DCs that are within their same site before contacting DCs in other sites. This enables a more efficient use of network bandwidth.

Site links, site link bridges, and site link bridgeheads

Site links: Site links determine the AD replication paths between sites to help control the path of replication traffic. By creating a site link, two or more sites are enabled to connect to each other. Each site link has the three following attributes:

  1. Cost: The cost represents the preference to use a particular site link as compared to other site links; it has nothing to do with the actual cost of setting up that link, and is a notional value. Cost values can range anywhere from 1 – 32,767. The default cost value is always 100. This attribute becomes critical when multiple site link paths are available between two sites. The site link with the lowest cost is always preferred in such a scenario.In the scenario depicted above, the cost of site link AC is 100, the cost of site link AB is 50, and the cost of site link BC is 60. Therefore, the most cost-effective way for replication between sites A and C is through site link AC (the cost is 100). The site links AB and BC (with a total cost of 110) would only be used if the connection between A and C goes down.

  2. Frequency: The frequency, also known as the interval or replication latency, is the time period between each replication on a particular site link. The frequency can be set anywhere from a minimum of 15 minutes to a maximum of 10,080 minutes (one week). The default is set at 180 minutes.
  3. Schedule: The schedule determines the times when the site link is available for replication between sites. The schedule can be set so that replication only occurs at specific times in a given day, or only on specific days. The default is set to 24 hours a day, on all days.

Site link bridge: All site links are transitive by default since the Bridge all site links value is automatically enabled. This means that if a site link is created between sites A and B, and another site link between sites B and C, an automatic site link bridge is created between sites A and C.

There are some scenarios where the Bridge all site links value needs to be disabled. For example, this might happen if the company’s network is not fully routed and the administrator needs to model the actual routing behavior. It could also happen when the administrator wants to exert more control over the replication process.

Site link bridgehead: When two sites are connected by a site link, one DC is randomly selected in each site as the site link bridgehead server. When replication happens between two sites (intersite replication), data is first sent from one bridgehead server to the other bridgehead server.

For example, when replication needs to happen between site A and site B, site A’s bridgehead server will replicate the data to site B’s bridgehead server. Site B’s bridgehead server will then replicate the data to the other DCs within site B. If the bridgehead is down, another DC is automatically selected as the bridgehead.

Preferred bridgehead server: The site link bridgehead server is automatically selected at random. However, an administrator can override this and specify a particular DC as the preferred bridgehead server. If the preferred bridgehead server goes down, there will be no replication until the link comes back up again. Therefore, administrators usually configure more than one preferred bridgehead server for fault tolerance.

Active Directory sites: An example

Suppose that an organization has three offices. The headquarters is located in Chennai, and two other remote offices are located in Bengaluru and Delhi. Let’s assume that 5,000 employees work out of the Chennai office, and there are 1,000 employees in both the Bengaluru and Delhi offices.

The company has decided to have four DCs in the Chennai office, three DCs in the Bengaluru office, and two DCs in the Delhi office. The company has also decided to divide its network into five subnets in its main office at Chennai. It has two subnets at its Bengaluru office, and one subnet at its Delhi office. The company has assigned the five subnets in Chennai to one site. Similarly, it has assigned the two subnets in the Bengaluru office to one site, and the single subnet in the Delhi office to one site.

By creating sites, the company can ensure that users from a particular site (Chennai, Bengaluru, or Delhi) always get authenticated by a local DC. It can also ensure that intersite replication only takes place during non-business hours, if it so desires. This could help the company reduce the strain on its network during business hours. In this way, traffic could be contained to local networks powered by high speed LANs as much as possible. The figure below depicts our discussion in the example.

What if sites were not created?

If this company hadn’t created sites, replication between all nine domain controllers in the three different geographical locations would happen in the default manner. The company would only have one site, with all nine DCs associated with that site. Intrasite replication would take place so that each DC gets updated with the most recent data. And when this happens, replication traffic would be sent over the slow WAN links that usually exist between geographic locations.

Furthermore, authentication could happen through any DC. When a user wants to join the office network, they would need to send a request to all nine DCs. The first DC to respond would establish a connection and authenticate the user. This means there could be a situation where an employee from the Bengaluru office wants to log in to the network, but they reach the DC at the Chennai office. This may not seem like it would use much data because it’s only for a single user. However, if thousands of users try logging in and each of them reaches DCs at the Chennai site, it could lead to bandwidth issues, reduced connection speeds, and decreased employee productivity.

1 Star2 Stars3 Stars4 Stars5 Stars (7 votes, average: 2.86 out of 5)

Active Directory tombstones

When you delete an object from the Active Directory (AD) database, it’s marked as a tombstoned object instead of being fully removed. By default, each tombstoned object remains in the database for 180 days. Once this tombstone lifetime value is exceeded, the tombstoned object is automatically deleted by the garbage collection process. Administrators can change the default tombstone lifetime value by using the ADSI Edit tool.

Benefits of tombstones

There are three main situations in which a tombstone can help:

  • Accidental object deletion: If you accidently delete an object which had particular attributes, you can’t just create a new object with the same name and expect everything to work as before. Whenever an object is created, a unique security identifier (SID) gets associated with it. It’s the SID which enables an object to get access to resources, be a part of groups, etc. Even if you create a new object with the same name, the SID will be different. Luckily, you can restore a tombstoned object with its original SID.
  • Replication of a deletion action: All the domain controllers (DC) in a domain follow the multimaster replication model. This means making changes to any DC will replicate those changes in all the other DCs in the domain. If an object is deleted at a particular DC without being tombstoned, there is no way this information can be replicated to the other DCs. Tombstoning enables the deletion action to be replicated.
  • Deletion action is captured during an AD restore: It’s always a good practice to take frequent backups of your DCs. If a DC crashes, you’ll need to rebuild it from the last available backup. Now, imagine if you deleted an object before an AD restore. In this scenario, the last available backup will still contain the deleted object. If not for tombstones, the deleted object would find its way back into AD. By marking the deleted object as a tombstone, you can ensure that the object does not become active after being replicated to the restored DC.

What happens in the back end when you delete an object?

When you try to delete an object, AD will first run a series of checks to ensure that the object can be deleted in the first place. Once AD determines that the object can be deleted, it turns it into a tombstone by setting the object’s isDeleted attribute to TRUE. AD then strips the unnecessary attributes from the object and only preserves certain important attributes, such as the object’s globally unique identifier (GUID) and security identifier (SID), in the tombstone. It’s important to note that user-group links are not preserved in tombstones and are thus lost forever if objects belonging to a group are tombstoned. After AD has updated the object’s attributes, it’s moved to a special container called Deleted Objects in the naming context (NC).

The description given here is not exhaustive; however, it captures the main essence of how tombstones are created and stored.

How do you view tombstoned objects?

To view and restore tombstoned objects, follow these steps:

  1. At the DC’s console, choose Run.
  2. Type LDP.EXE and then press Enter. You’ll get the screen below.
  3. Go into the Connection menu, and choose Bind. Ensure that Bind as currently logged on user is selected, and click OK. You will see the screen shown below. This confirms that you are authenticated as the administrator of the DC.
  4. Click on the Options menu, choose Controls, and then choose Return deleted objects under the Load Predefined drop-down. Click OK.
  5. Go into the View menu, select Tree, and then choose the fully qualified distinguished name of your domain. In our example, this would be DC=vaidyar,DC=com. You will then get the screen below.
  6. Expand the details of your domain on the left side, and then double-click on the relevant item with details on deleted objects. In our example, this would be CN=Deleted Objects,DC= vaidyar,DC=com. The screen below will then open up. This will show you all the objects that have been deleted in the domain.

How do you restore tombstoned objects?

To restore tombstoned objects, follow these steps:

  1. Perform steps 1-6 from the section above.
  2. Double-click on the object you want to restore to obtain more information about it. This step is critical to ensure that you choose the right object for restoration. If you have created objects in the past with the same name, they’ll look similar. One way to make sure you choose the right object is by checking the whenChanged and whenCreated details.
    In our example, we’ll try restoring the user object Sudhir Pillai. You’ll see the screen below at this point.
  3. Right-click on the user object you want to restore, click Modify, and type “isDeleted” in the Edit Entry Attribute field. Click the Delete operation, then hit Enter. When the object was tombstoned, its isDeleted attribute was changed to TRUE. In this step, we’re modifying this attribute.
  4. Now choose Replace under Operation. Type “distinguishedName” under Edit Entry Attribute, and type the object’s lastKnownParent value under Values. Press Enter, then click Run. The screen below shows how this looks.

    The object will now be restored to its last known location. In our example, this location would be CN=Users,DC=vaidyar,DC=com. If you need to restore the object to a different location, you would need to specify the appropriate FQDN in step 4 above.
1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 4.50 out of 5)

The structures and benefits of organizational units

Organizational units (OUs)

When you deploy Active Directory (AD) in your company, you may decide to create multiple organizational units (OUs) within your domain. An OU is a container within your domain that holds users, groups, computers, and other objects. You use an OU to store similar objects, making it easy to access and administer them. An OU will always be contained within a single domain.

You can also place sub-OUs within an OU—in a process called nesting—to create a hierarchical structure. OUs are usually created in such a way that they mimic the company’s functional or business structure.

Creating the OU structure

Here are some OU models that you can implement in AD:

  1. Functional/divisional: Each division or function within your company will have its own OU. For example, there could be a marketing OU, sales OU, research OU, and so on. All objects that belong to a particular function are placed in its respective OU.
  2. Geographic: As the name suggests, these OUs are created to mirror your company’s business operations in different geographic locations. For example, if your company operates in three different locations (New York, London, and Mumbai), you could have a New York OU, London OU, and Mumbai OU.
  3. Object: In this type of OU model, you would have different OUs for different object types. For example, you could have a users OU, privileged users OU, computers OU, and so on.

You can also combine the above models in your OU design. Here’s an example:

Questions to answer when designing OUs

OU design is a critical task when deploying AD. Answers to the following questions will help you design the OU structure:

Benefits of using OUs

There are three main benefits of using OUs:

  1. Manage objects efficiently: You can think of an OU as a folder you create on your computer. You’d put similar files within a folder to find them easily. In a very similar way, putting similar objects together in an OU (especially in an OU that mirrors your business practices) helps you manage objects efficiently.
  2. Deploy Group Policy Object (GPO) settings: A GPO is a set of user and computer configuration settings that you can apply to (and thus impose on) users and computers within a domain, site, or OU. After creating an OU and placing relevant objects inside it, you can link specific GPOs to that OU. The GPO will be applied to all objects within the OU.Imagine all of your company’s call center employees are part of one OU. If you don’t want these employees to access the internet from their machines, you can simply deploy a GPO with this configuration and apply it to that OU.
  3. Delegate administrative control: OUs provide you with new opportunities for distributed administrative authority. Larger companies will find this particularly useful.Imagine your company has three offices, with its headquarters in New York and two more offices in London and Mumbai. Let’s assume that the primary IT team works out of the headquarters in New York, the marketing team works out of London, and the research team works out of Mumbai. If the primary IT team in New York is tasked with attending to password reset requests from all three locations, it may cause bottlenecks in IT operations and affect the IT team’s productivity. Instead, the primary IT team could enable the marketing manager in London and the research lead in Mumbai to take care of these kind of password requests from any of their respective team members.
1 Star2 Stars3 Stars4 Stars5 Stars (6 votes, average: 3.67 out of 5)