An OU Can Be A Spoke, Too

  • Article

If you've read any of my other posts, I deal with a number of government organizations at the state and local level helping them deploy Microsoft's infrastructure products. One area where my customers pride themselves is in the autonomy they've created for themselves (technically and sometimes politically) through the years. My typical customer has the following characteristics:

  1. Educational institution, State, County or City Government
  2. Multiple departments with full autonomy and decentralization
  3. Usually, one of the departments is law enforcement of some sort
  4. Little history of working together collectively, but working quite well together when the business of the people requires it. These are typically one-off projects independently owned and operated.
  5. A sense that the pendulum has swung too far to the decentralized model and resources can be aggregated for more functionality at less cost.
  6. A departmental fear of losing control, or subjugating autonomy to peers in other departments.

Generally speaking though, these federations, as I like to call them, all trust one department (usually some sort of centralized IT - possibly a remnant of the mainframe era). Because one department can be trusted above all others, a natural tendency exists to build infrastructure models that reflect this trust. And nothing seems to appeal to these customers more than the hub and spoke model.

The hub and spoke model rises above all others because federated customers want to preserve autonomy, but still gain the benefits of being part of a larger organization. Some central IT group becomes the natural hub and the individual departments the spokes. I've seen this implemented in any number of ways on Windows and Exchange and I hope, that by sharing these observations with you, I can illustrate that if federation is in your future, you should be looking at hubs and spokes.

Hubs and spokes can take many forms in Active Directory. The hub might be the domain in a single forest, single domain model and the spokes OUs. All departments trust the few domain admins, all departments are contained in their own OUs and no one has access to the OUs of the lessor trusted peers. This model is definitely the best because departments can be reoganized, as required, quickly and effortlessly. Centralized policy can be evenly applied since all objects share the same domain boundary, and technical issues like replication can be optimized for performance. 

However, this can be a hard sell to a group of departmental domain admins of NT 4.0 domains who don't like the idea of becoming an OU-pawn and losing those valuable credentials we call "Domain Admins." But the customers I've seen implement this model generally have the best experience with the Windows products, once they get past the politically demeaning role of OU Administrator and realize that they have as much autonomy as they had before, without the concerns of maintaining the complexity of a domain.

The root domain forest may also be the hub, and child domains its spokes. Because domains define replication boundaries, many customers like this approach, in spite of the fact that re-orgs are more difficult to implement if it requires restructuring domains. On the plus side, if a customer is moving from multiple NT 4.0 domains, upgrading the NT 4.0 domain as child domains of the new forest preserves their environment and is considerably easier than migrating to an OU. 

The other benefit to a domain-based hub and spoke model is that replication can be controlled such that it only passes through the trusted hub site. This is particularly popular where departments have put up firewalls and other communication blockers between themselves and their peers (of course, it ignores many of the benefits of a single forest for cross-departmental authentication and resource sharing). One thing to note about this design model, however, is that it somewhat breaks the assumption of the Windows operating system. To work as politically designed, each department requires their own AD site (which doesn't necessarily reflect the physical topology of the network). It also requires disabling the Knowledge Consistency Checker and manually creating site links and replication agreements. Finally, it typically results in far more domain controllers than really necessary to service the larger forest. 

When I work with customers, I generally try to pursuade them to move towards the Single Domain Model. Sometimes this is easy. What remains fairly consistent in my experience is that domain-based hubs and spokes are never designed with technical justification; it is always political. The customers who choose this route often spend considerably more time troubleshooting issues and generally impose far more restrictions on themselves to prevent even troubleshooting from being efficient. However, if such self-restrictive behavior did not exist, they probably would have deployed a single domain. 

If you're currently debating the single forest, single domain, multiple OU model against the single forest, multiple domain model, I would ask that you ask youself the following questions during the planning process. The answers should help you arrive at the proper technical conclusion (but I can't help with the politics):

  1. Are the departments in your federation interested in consolidation and eventually relinquishing control over commodity services such as domain membership and email?
  2. Does everyone in the federation understand that a domain is not a hardened security boundary?
  3. Does everyone understand the difference between isolation and autonomy (this may be harder than you think)?
  4. How many of the current domain administrators really require this level of access (and why)?
  5. What are the service level agreements for availability (simplicity of design = more uptime)?
  6. What are the SLAs/requirements for security (fewer domain admins = higher security)?
  7. How many of the current domain admins have proper training (look at PSS cases)?
  8. If firewalls or other devices exist between departments, why were they put there (historical reference)?