Active Directory

Using Catch-All Subnets in Active Directory

John Policelli

At a Glance:

• The domain controller locator
• The hub and spoke topology
• Implementing a catch-all subnet

Contents

How Clients Locate Domain Controllers
The Problem
The Catch-All Subnet
Wrapping Up

In an ideal world, users are directed to the appropriate domain controller (DC) for Active Directory authentication. However, this is not necessarily the case in most organizations due to IP subnet information not being properly defined in Active Directory. As a result, a number of users authenticate against an arbitrary domain controller, which is not optimal for Active Directory authentication.

In this article, I provide a potential solution to ensure users locate the appropriate DC for authentication when IP subnet information is not fully defined in Active Directory.

How Clients Locate Domain Controllers

When a computer attempts to locate a domain controller, a process called the domain controller locator (Locator) is initiated so the appropriate Active Directory domain controller can be located. Locator uses information that is stored in Active Directory and DNS to attempt to find a domain controller with the desired roles and that is located in a site closest to the client.

The Locator uses information that is defined in the Configuration container in the forest root domain, which is replicated to every domain controller in the forest. Site objects, subnet objects, and domain controller server objects are all imperative for the Locator to find the closest domain controller for a client computer. Site objects are used to represent Active Directory sites. Subnet objects are used to represent IP address segments and are associated with the appropriate site object. Domain controller server objects are used to represent domain controllers and are associated with a site object.

Active Directory domain controllers register DNS records that specify the site in which the DC resides. The number of DNS records that each domain controller registers depends on the roles the DC has. For example, a DC that is a Global Catalog server will register an additional DNS record that advertises itself as such. Similarly, a domain controller that holds an Operations Master role will register a DNS record that advertises itself as this.

The process for a client computer to locate a domain controller is as follows:

1. The Locator is initiated on the client computer as a remote procedure call (RPC) to the local Net Logon service.
2. The client collects the information that is needed to select a domain controller and passes the information to the Net Logon service.
3. The Net Logon service on the client computer uses the collected information to build a query to send to DNS to identify the appropriate domain controller.
4. The Net Logon service on the client computer sends a datagram to the discovered domain controllers.
5. The directory service intercepts the query and passes it to the Net Logon service on the domain controller.
6. The Net Logon service on the domain controller looks up the client IP address in its subnet-to-site mapping table by finding the subnet object that most closely matches the client IP address and then returns the following information to the client: the name of the site in which the client is located, or the site that most closely matches the client IP address; the name of the site in which the current domain controller is located; and a bit that indicates whether the found DC is located in the site closest to the client.
7. The client inspects the information to determine whether it should try to find a better domain controller. The decision is made as follows: If the returned domain controller is in the closest site, the client uses this domain controller; If the client has found a DC in the site in which the DC claims the client is located, the client uses this domain controller; If the DC is not in the closest site, the client updates its site information and sends a new DNS query to find a new DC in the site. If the second query is successful, the new DC is used. If the second query fails, the original DC is used.
8. If the domain that is being queried by the client is the same as the domain to which the computer is joined, the site in which the computer resides is stored in the registry on the client computer.
9. After the client locates a DC, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.

In the case where a client computer uses an IP address that is not represented in the subnet-to-site mapping table, the DC returns a NULL site name and the client uses the returned domain controller, which may reside in any Active Directory site.

The Problem

If the domain controller cannot determine the closest site, due to the IP subnet information not being defined in Active Directory, authentication then uses a DC that is not optimal.

Figure 1 illustrates a sample Active Directory site design that uses a hub and spoke topology. Users who log on from a computer that is on one of the subnets that are defined in Active Directory are directed to a domain controller in their closest Active Directory site for authentication. However, users who log on from a computer that is on any other subnet, for example 10.1.4.0/24, are directed to an arbitrary DC.

Figure 1 Sample hub and spoke topology site design

The appropriate fix to address this issue, of course, is to define the additional subnets in Active Directory and associate them with the appropriate site. However, organizations (especially medium and large organizations) often face issues obtaining the information required to add these additional subnets to Active Directory. More specifically, Active Directory administrators usually become aware of the existence of the additional subnets through errors and log files, but do not know which physical office these subnets belong to, preventing them from identifying which site to associate the subnet with.

The Catch-All Subnet

A more practical solution to the issue is to use one or more catch-all subnets in Active Directory. A catch-all subnet is an Active Directory subnet that is used to catch the authentication from clients that are on subnets that are not defined in Active Directory. A catch-all subnet is essentially a super-subnet.

As shown in Figure 1, the 10.1.1.0/24 subnet is defined in Active Directory and associated with the Toronto Active Directory site. Say you notice that a number of clients on the 10.1.4.0/24 and 10.1.5.0/24 subnets are authenticating against Active Directory. You believe these subnets are in the Toronto office based on the prefix (10.1.x.x). You want to ensure that computers on these subnets, as well as any other subnets that use the 10.1.x.x prefix, authenticate against a DC in the Toronto site. So you create a catch-all subnet, which uses the 10.1.0.0/16 prefix, to direct authentication from all subnets you believe to be located in the Toronto office, and you ensure the authentication uses a DC in the Toronto site. The catch-all subnet mapping for this example is shown in red text in Figure 2.

Figure 2 Using a catch-all subnet for hub sites

In most organizations, IP subnet information for remote offices is communicated to Active Directory administrators. The gap usually exists for IP subnets for central offices, hub locations, and data centers. The catch-all subnet can be used to improve authentication in these cases as well. Since the IP subnets for remote offices are fairly static, and you usually have a good grasp on these subnets, you can create a catch-all subnet for all other subnets.

In this example, you can create a catch-all subnet, which uses the 10.0.0.0/8 prefix, to catch authentication from all subnets you believe do not belong to a remote office and ensure the authentication uses a DC in the central Toronto site. The catch-all subnet mapping for this example is shown in red text in Figure 3. And you can even use multiple catch-all subnets, as shown in Figure 4, if you desire.

Figure 3 A catch-all subnet for all locations

Figure 4 Using multiple catch-all subnets

Notice in Figure 3 and 4 that the catch-all subnets use a prefix that overlaps the prefixes used in the remote sites (10.0.0.0/8 covers 10.1.1.0/24 for example). You may be wondering whether authentication from computers in the remote offices will still be directed to a domain controller in the appropriate remote office as a result. The answer is yes. When overlapping IP subnets exist in Active Directory, the IP subnet with the smallest matching subnet mask is used. For example, 10.1.1.0/24 will be used instead of 10.0.0.0/8 if the computer has an IP address of 10.1.1.5/24 subnet. However, 10.1.1.1./32 will be used instead of 10.1.1.0/24 for a computer that has an IP address of 10.1.1.5.

Wrapping Up

Before you go ahead and implement catch-all subnets, you need to be aware that the concept of a catch-all subnet is not suited for all environments. The feasibility of such a solution depends greatly on your IP addressing scheme.

In the examples I've provided here, the IP addressing scheme is fairly straightforward. However, as the IP addressing scheme becomes more complex, the feasibility of using catch-all subnets becomes less likely. For example, if your environment consists of multiple network segments and your IP addressing scheme is not sequential across each location, it will be virtually impossible to create catch-all subnets that will provide any value. As with all solutions, you need to consider the technical, business, and environmental factors specific to your environment when determining the viability of implementing catch-all subnets.

And note that the use of catch-all subnets does not resolve the issue of missing subnets entirely. In fact, if you introduce catch-all subnets in your environment, it is even more important that you explicitly define all known subnets in Active Directory.

The use of catch-all subnets will increase the number of users that locate the closest domain controller. However, your goal should still be to address the source of the issue and ensure you receive the appropriate information for all additions, modifications, and removals of network subnets so you can maintain an up-to-date Active Directory site design that provides efficient authentication for all users.

John Policelli (Microsoft MVP for Directory Services, MCTS, MCSA, ITSM, iNet+, Network+, and A+) is a solutions-focused IT consultant with over a decade of combined success in architecture, security, strategic planning, and disaster recovery planning. John has spent the past nine years focused on Identity and Access Management and providing thought leadership for some of the largest installations of Active Directory in Canada. John maintains a blog at https://policelli.com/blog.