One of the common misunderstandings I see working with organizations and their Active Directory deployments is with regard to subnet definitions in Active Directory. This discussion came up recently on the ActiveDir.org mailing list so I thought I would write up a quick summary of how this works.
Subnets are defined in Active Directory solely for defining what sites in Active Directory a set of machines belong to. The subnet definitions do not correspond to the actual layer 3 routing within the organization. This is a key misunderstanding – the layer 3 routing design does not have to correspond to the subnet/site definitions in Active Directory at all. Second, Active Directory will match the most specific subnet. This means that if you have defined two subnet objects in Active Directory – 10.1.0.0/16 and 10.1.2.0/24 and a client with an IP of 10.1.2.5, it will match the second subnet object.
One of the common events that fills up the event log on domain controllers in large organizations is NetLogon warning #5807. There are a couple scenarios where this happens – one is when the AD administrators simply don't define any subnets to go along with their site objects. The second one and also the more common one is that the team that runs AD tends not to talk to the group that provisions subnets on the network. In large organizations subnets tend to come and go at sites all over the place, and while it would be nice to get all this data keyed into Active Directory at that time it's often not very plausible. The solution that I use and recommend is to define very broad reaching super nets at my hub sites. Given a simple hub and spoke with one hub, I would associate 10.0.0.0/8 with the hub site. This guarantees me that any client coming from any 10.0.0.0 IP will match a subnet in AD. 172.16.0.0/12 space is also pretty common in organizations – especially for VPNs, DMZs, etc. I'll usually associate this with my hub site as well.
Now the question becomes what if you have a more distributed hub & spoke topology like the one below?
Ideally the WAN comes with a well designed subnet model and it becomes easy to associate the local supernets with the hub sites like below:
In this simplified scenario it's easy to associate the specific subnets with their spoke sites, and then associate the /16s with the hubs. For example, I would build 10.3.0.0/16 and assign that to Sao Paolo, 10.1.0.0/16 for Chicago, and 10.2.0.0/16 for London. While I didn't add 10.0.0.0/8 to any of the sites because I know that this organization is only cut out of the three networks listed, if I didn't I would make an executive decision based on where the majority of the clients are and associate that subnet there. In reality sometimes this is difficult to do or not immediately obvious. When it comes time to figure this out, the WAN group or whomever handles the network in an organization will have this information readily available if it exists.
Another cool trick that you can do with subnets in Active Directory is defined host subnets - /32 (or 255.255.255.255) masks. With this in mind you can build a site within a site so to speak. An example I ran into once is an organization which wanted a dedicated site for their Exchange environment – a fairly common scenario. For whatever reason the network folks simply weren't willing to provision a dedicated subnet to this. So, what this organization ended up doing was defining subnet objects for each of their Exchange hosts and dedicated DCs with a /32 mask and associating them to this special Exchange site. You could also create a lag site within a subnet by building a site, site link, and /32 subnets for each of the lag site DCs.