There’s no escaping migration to Windows 2000, and it’s going to be painful. Accept the pain and take the time to design an elegant directory now.

Flatten Those Domains!

There’s no escaping migration to Windows 2000, and it’s going to be painful. Accept the pain and take the time to design an elegant directory now.

• By Michael Chacon
• 12/01/1999

Is a domain by the same name still the same domain? Windows 2000 is almost upon us, which means it’s time for many of us to examine our current networks and decide how to approach the upgrade process. Many time-tested ideas exist for any migration; but regardless of the methodology you choose, one central aspect remains with Windows NT: What do we do with our domains?

Domains will still play a significant role in the Win2K Active Directory structure. Most current NT 4.0 domain structures have been driven by two fundamental characteristics. First, an NT domain is an administrative and security boundary; and second, there’s very little granularity in delegating administrative capabilities. Thankfully, the second issue will simply vanish with Win2K, while the first issue still needs some consideration.

Domains Today

Before we look at domains in Win2K, let’s review how domains are used in our current NT 4.0 networks. I’m sure you’re familiar with the three primary domain models, which are single, master, and complete trust. There really are no different domain types. The difference is in how they’re used and the majority of the types of objects that exist in them. The main concept to keep in mind is that NT differentiates between a computer and a user, but they both have Security Identifier-based (SID) accounts within a domain. Therefore, their security context is derived from the domain in which they exist. Even though a User or Computer account might have the same name in different domains, they aren’t the same because their SID is what ultimately identifies a User or a Computer account, and SIDs are bound to a domain. Occasionally you’ll find the same account names—particularly users—instantiated in different domains in a poor attempt to provide permissions in another domain instead of using a trust relationship.

Single Domains

A single domain is the most straightforward and sensible architecture because you already have all of your user and computer accounts in the same domain. If you have a single domain, you’re already well on your way home to a smoother Win2K implementation. The best way to prepare for a Win2K migration is to move your current NT 4.0 system to a single domain. On the other hand, if you have a complete trust model, I feel sorry for you, because you have significant work cut out for yourself. Come to think if it, you have your work cut out with a complete trust model even if you never migrate.

Master and Resource Domains

Most NT 4.0 networks that I come across, however, are in some form of the Master Domain model. A Master Domain model is based upon the idea that most of your User accounts are created in one domain and your computer accounts are created in a separate domain, usually referred to as a Resource Domain. In large or geographically distributed networks, you’ll commonly have several Resource Domains.

The idea is to create a system where you have different administrators in each domain. For example, a large company could have an Account Domain with several thousand users instantiated, and the administrators of that domain would manage those accounts. You’d want to centralize the creation of accounts so administrators could create and disable accounts as people join and leave the organization. The account administrators would also be responsible for moving accounts in and out of groups as users change roles within the organization. However, in the remote offices or in the Resource Domains different administrators control which groups of users will have access to the local resources. This flexibility is based upon the fact that each domain is an independent security boundary.

Multiple-Master Domains

This division of administration can be even more granular with the variation of the Master Domain called a Multiple-Master Domain model. This design is characterized by the existence of two or more Account Domains with the Resource Domains “trusting” the Account Domains for user authentication. The main reason for this type of model is to provide several pockets of administrators in large organizations, such as multinational divisions. The other prominent reason is that the NT Security Accounts Manager (SAM) is held in memory on the PDC/BDCs, and the maximum size that Microsoft has tested and recommends is 40M. In very large organizations one domain won’t be able to hold all the accounts and groups, so they’re distributed among two or more domains that hold only user accounts.

In the real world these domain models aren’t as clean as I describe here. There may be some accounts in the Resource Domains, and workstations in the Account Domains. For the most part a well-implemented system will follow the models as closely as possible to keep the support issues clear and the cost minimal. In some cases, however, people have gone domain happy and created many domains, sometimes even at the departmental level. This isn’t only a problem for migration to Win2K, it’s also a problem for those who plan to hover at NT 4.0 for the foreseeable future. Active Directory is the central component of Win2K, and you’ll hear a lot about the wonders it’ll bring to the NT world. Right now, however, I want to focus on how your current domain model can impact your Active Directory design.

Enter Active Directory

In Win2K domains will still be security and audit boundaries, but for most sites the necessity for this architecture will simply vanish. With Active Directory you can delegate granular administrative rights at the OU level. Now is the time to plan for a completely new administrative design. Just because the NT 4.0 domain models you have in place can be brought into your Win2K environment doesn’t mean that it’s a good idea. Yes, the Kerberos relationships between the domains are transitive, and you won’t have to rely on manually building trust relationships. But don’t follow a similar early crowd that emerged with NT 3.x and built a plethora of domains. The basic rule for building any complex system is to keep it simple. This may sound contradictory, but at closer glance you can see it’s true in all elegant designs.

My first rule for any Active Directory design is if you don’t have a compelling reason to have more than one domain, don’t. There’s much talk about forests and trees. This is great if you need multiple domains. But there’s a lot to be said for a solitary tree with an OU design that provides access to all the resources on your system while managing the replication traffic necessary to keep the directory available all the time.

In Win2K, a domain is a physical partition in the Active Directory namespace. Different domains within the Active Directory namespace don’t share information other than the tree metadata used to create continuity throughout the namespace. In addition, some domain controllers within each domain are designated as Global Catalog servers, which contain a configurable subset of the objects in all the domains for lookup purposes.

Sites

This may encourage some people to build domains along the lines of their physical network. This would be a mistake. There’s another mechanism in Win2K to control replication traffic that better reflects the physical network: sites. A site is a physical collection of network objects, specifically, computer workstations, that exists at its most granular level at the subnet IP broadcast domain. This IP broadcast domain can’t span sites, which is the marrying point between the concepts. However, sites can span subnets, which are the main drivers in physical design.

I’ll cover sites and replication traffic in a later article. But as it relates to domain design, you should be aware that domains shouldn’t be used to control replication; they should be used sparingly to control security and audit boundaries. The site is the proper mechanism for the replication role in the network. In a large decentralized environment, domains can be used to define different administrative policies that may exist in different parts of the world. All of the policy attributes you’re familiar with in NT 4.0, such as account lockout, password length, password history, and, with Win2K, time to live (TTL) of Kerberos authentication tickets, are defined at the domain level.

Multiple Domains in Win2K?

Microsoft recommends bringing Resource Domains over to Active Directory as Child Domains to your previous Account Domains. This actually maintains an NT 4.0 architecture within a Win2K environment. While this makes for an easy “migration” scenario in terms of time and effort, it does little to take advantage of the Active Directory architecture. Why kid yourself? A Win2K migration is going to be a lot of work and a major pain in the derrière. Accept the pain and take the time to design an elegant directory that relies upon OUs to delegate administrative rights. Start with a design that transfers your Resource Domains into OUs. Also keep in mind that there are very few attributes in the SAM that are worth bringing over to Active Directory. This is a good time to take a long, hard look at building your Win2K network from scratch. This ranges from naming conventions, to data storage architecture, to groups, and to permissions.

Regardless of much you’re prepared to invest in an NT 4.0-to-Win2K network, the only argument for multiple domains within Win2K is if you have multiple different security policies or if you have more than one “centralized” administrative team, and they’re unwilling to cooperate or allow the other teams to have the top billing at the root. These political situations will be more common than anyone cares to admit, and I’ll wager that most multiple domain Active Directory implementations are a result of political concerns rather than technical ones.