8.4 Domain Namespace Design

The first stage in your design is to work out the domain, domain-tree, and forest configuration of your network. The best way to do this is to make a first pass at designing the domains and then structure them together into a series of trees. Before we start, however, let's take a look at our objectives for this part of the design.

8.4.1 Objectives

There are two objectives for the design of the domain namespace:

• Designing Active Directory to represent the structure of your business

• Minimizing the number of domains by making much more use of the more flexible Organizational Units

8.4.1.1 Represent the structure of your business

You need to make Active Directory look as much like your business structure, geographical or organizational, as possible. With geographical structure, your business runs itself as self-contained units within each geographical site. In this model, people at those sites handle administration for each site. Under the organizational or political model, the business is based on a series of departments that have members from a number of different geographical sites. Normally, with this structure, the organization has a head office for all departments at one location, but that is not always the case.

In the former model, finance units based in France and Australia would be separate finance departments. In the latter model, France and Australia would have geographical finance branches of a larger finance department controlled from a head office.

It doesn't matter to Active Directory which model you choose, except that the intention is to mirror the structure of your business in the Active Directory design. If your business crosses both of these boundaries, it becomes less clear-cut. To make your design simpler to understand, you should choose to go with one model or the other. We would not suggest a mix-and-match approach unless you can definitely rationalize it, adequately represent it on paper, and delegate administration effectively.

If you already have a large investment in a TCP/IP infrastructure with organization or geographic-centered DNS zones, or you if have a large existing Exchange organization, you can use this as the basis of your design. Simply stated, if your DNS or Exchange setup is based on one model, go with that model for your Active Directory design. It should be obvious that it will be easier for an administrator to think about both areas if the designs are based on the same model.

8.4.1.2 Minimize the number of domains

Remember that implementing Active Directory presents an opportunity to reduce the number of domains you support. Each forest can store tens of millions of objects, which is more than enough for all the users, groups, and computers in most organizations. So size isn't a consideration. Each domain can also be partitioned using Organizational Units, allowing you to delegate different administrators for each Organizational Unit in a domain if you so desire. You do not have to create a new domain if you wish to delegate administration over a part of the system. These two aspects of Active Directory tend to eliminate a number of sizing and permission problems associated with traditional NT installations.

If you're an experienced NT domain designer, start trying to push from your mind the tendency to create multiple domains. Think in terms of multiple Organizational Units instead.

8.4.2 Step 1—Decide on the Number of Domains

Start by imagining that every object is to be stored in one domain. This will give you a much simpler layout for administration. It doesn't matter what the domain is called for now; just label it as your organization's main/sole domain.

Now expand the number of domains that you have by adding other domains that you can give specific justification for. While the number of objects and delegation of administration are not good reasons for creating new domains, there are three main reasons that would require more domains:

• The need to isolate replication

• A requirement for a unique domain policy

• A requirement for keeping a Windows NT domain

If you can match any of these criteria, write down a new domain for that area.

8.4.2.1 Isolated replication

While replication is mainly discussed in the next chapter, it does have a bearing on domain design. If you have a headquarters and a branch office connected via a slow link, and you don't want to use up any bandwidth at all in replicating domain directory data from the main domain to the branch office, you need to consider creating a separate domain for the branch office. This will ensure that only limited traffic is replicated between both offices. In fact, this will be limited to the GC, configuration, and Schema information only.

So if you want to really minimize traffic down a link, create a new domain for the remote office. In most cases, this isn't necessary. Also, you can use Application Partitions to store application specific data and only replicate it to your regional sites.

A slow link in an ideal case is defined as a 259 Kb link with 128 Kb spare capacity. However, each organization will need to make its own decision about what it will accept as a minimum for a slow link; the value could be 64 Kb or 1 Mb. As we are only drafting the namespace and physical site/replication designs and then coming back to revise both using the combined data, the exact figure for a slow link in your organization is not important right now.

8.4.2.2 Unique domain policy

In Chapter 7 and Chapter 10 we explain the basics of GPOs and how to properly design them. For now the important thing to understand is that policies are Active Directory objects that reference a number of settings that can be applied to users or computers. These settings are things like a fixed desktop, a certain core set of applications, the ability of users to perform a shutdown, and so on. If you're coming from a Windows NT background, these are Windows NT system policies on a much grander scale. GPOs can be applied to various parts of your Active Directory structure. If you create an Organizational Unit called Finance and then decide that OU=Finance needs special settings, you can create a GPO and assign it to OU=Finance. Then all the computer settings in the GPO will be applied to all computers in OU=Finance, and all the user settings in the GPO will be applied to the users in OU=Finance.

We now need to look at what settings have to be applied on a domain-by-domain basis. Here's a list of what types of settings can be set only on a domain-wide basis:

• Password policies, such as password length, password expiry interval, and so forth. This is effectively the same as for Windows NT 4.0.

• Account lockout policies, such as lockout threshold, lockout duration, and so forth. Again this is the same as for NT 4.0.

• Kerberos policies.

• Encrypted file system recovery policies.

• IP security policies.

• Public key encryption policies.

• Certificate authorities.

If you know that your organization already has three different password schemes that have to be maintained, you will need three domains. If a special department or geographical area needs special encryption, security safeguards, certificates, and so on, you may have another candidate for a domain.

8.4.2.3 In-place upgrade of current domain

Many organizations have large existing Windows NT infrastructures and will be planning to migrate at some point. During the design of your migration to Active Directory, you will need to consider the option of merging old Windows NT domain hierarchies into single domains. This is known as collapsing old domain structures. However, even though AD usually requires fewer domains than Windows NT, as it can accommodate more objects and allow delegation of administration without domains, organizations may wish to retain some of their current domains.

If your organization has a domain that you feel should not be removed for some reason, you need to indicate it on the list of domains. Then when it comes time to implement your Active Directory rollout, you can do an in-place upgrade on the existing domain rather than bringing it into an existing AD domain.

8.4.2.4 Final notes

You now should have your first draft of the list of domains that you think you will need. There is one more very important point on this subject. Domains are very inflexible and unforgiving, and due to the fact that you can host only a single domain on a domain controller, each domain means one more domain controller you have to support. Depending on how many domain controllers you would have to deploy for a domain, you can greatly decrease your total cost of ownership (TCO) for Active Directory by limiting the number of domains you support.

8.4.3 Step 2—Design and Name the Tree Structure

Now that you have the domains listed, you need to consider what sort of hierarchy to put them in. It is easiest to start with one domain, the one that will become the forest root.

8.4.3.1 Choose the forest root domain

The forest root domain is normally the largest domain left after you split off the smaller ones using the preceding domain design process, but it doesn't have to be. The empty forest root domain approach is also very common: you minimize the amount of data in that domain and put everything in subdomains. The key here is that this domain needs to be centrally managed by an IT group, capable of making solid policy and naming decisions. This domain has special properties. For example, the Schema Admins group exists only in the forest root domain. The administrators of this forest root domain have control over who is added to the Schema Admins group and thus allowed to modify the schema. While the administrators of the forest root domain can add any user from anywhere in the entire forest to the group (due to hierarchical and transitive trusts between all domains), it is the administrators of the forest root domain that call the shots. So this domain is special. Its administrators dictate how the network expands, who can and cannot add domains, and where domains should go. This group has the grand vision for the design and operation of the network.

Whichever domain corresponds to this is the one that should be the forest root domain. If you are having difficulty choosing, pick one of the likely candidates for now. If it becomes obvious later that it was the wrong choice, you can come back and readjust. Once you've chosen, grab a blank piece of paper and draw the forest root domain at the top of the sheet in a triangle. A triangle is the symbol used to represent an Active Directory domain.

8.4.3.2 Design the namespace naming scheme

As each domain has a DNS name to identify it, you need to consider what names you are going to choose. You can use any of the RFC 1123 standard characters:

• A-Z

• a-z

• 0-9

• - (dash character)

Microsoft's DNS supports a wider range of characters, such as the Unicode character set, but if you need compatibility with other DNS flavors, be very careful allowing these.

There are currently two schools of thought on how to pick the DNS names for your Active Directory network: root zone or subzone. The root zone method says that you name your root Active Directory domain based on the root zone for your organization. For the Mycorp Corporation, this would be mycorp.com. The subzone method suggests that you pick a new subdomain from your root zone and make that the base of your Active Directory namespace. For Mycorp, this could be ad.mycorp.com. If you choose the root zone method and wish to have a non-Windows DNS, you will need to either turn on dynamic update or manually register a number of records in the DNS as shown in Chapter 6. If you choose the root zone method and wish to have a Windows DNS at your root, you will need to migrate your existing entries, if you have any, to it. Both methods are fine, but they require configuration or migration at the root. A less invasive procedure would be to choose a new subzone for your Active Directory network and run your network from that. With this setup you still have two choices, but they are less disruptive to any existing structure and you won't have to affect the main root zone. Arguably, the easiest solution is to let two servers on your network run Windows DNS server and manage this DNS zone. This allows you to have a root that doesn't allow dynamic updates and a subdomain that does. The alternative would allow a non-Windows DNS to manage the zone.

Leicester University had a very large existing DNS infrastructure branching down from the root domain that we didn't want to affect with this new Active Directory infrastructure. The main DNS servers, while being dynamic update-capable, did not have dynamic update turned on for specific reasons. So we set up two domain controllers to run the Windows DNS service and gave them a subdomain to host. We then delegated that subdomain on the main DNS servers and told them which servers had authority for the new zone. We then modified DHCP to point all new client workstations at the two Windows DNS servers and configured the DNS servers to pass any queries that they could not resolve back to the main campus DNS servers. Clients could update the Windows DNS without affecting the main campus servers. However, external queries were still resolved by passing them to the main campus servers for resolution.

Start with the forest root and assign a DNS name to the domain, writing the name inside or beside the triangle on the paper. You should pick the name very, very carefully, for two reasons: first, renaming a domain is impossible in Windows 2000 Active Directory, and while it is possible under Windows Server 2003 Active Directory, the process is very invasive and requires all machines in the domain to be rebooted. Second, you can never remove the forest root domain from Active Directory. You would have to wipe your entire setup and start again.

8.4.3.3 Create additional trees

Having created and named your forest root, you need to consider your other domains. If you have two distinct business units that will require discontiguous names, you need two trees coming from a domain root. Draw all the other root domains that you think you will need as separate triangles at the same horizontal level on the paper and assign them valid DNS names. These domains are all root domains. A real-world example is the Microsoft brand name and the MSN brand name. Both msn.com and microsoft.com could be separate trees in the same forest. They couldn't be in the same tree without giving them a hierarchical link, i.e., msn.microsoft.com.

If we think that Mycorp's finance department needs a separate domain, we will make a subdomain and call it finance.mycorp.com. Within Active Directory we could make finance.mycorp.com a separate tree in its own right, but as hierarchical and transitive trusts exist throughout a forest, we gain absolutely nothing by doing this. The only differences come in choosing finance to be a new domain (which we did) or a new forest in itself. Making it a new tree gains absolutely nothing.

8.4.3.4 Create additional forests

So far, we've been considering domains that will exist in the same forest. You may have business units that will require two entirely separate forests. How do you know if that is the case? If you have business units in an organization that are independent and in fact wish to be isolated from each other, then you must not combine them in a single forest. If you simply give each business unit its own domain, these business units can get the idea that they are autonomous and isolated from each other. However, in Active Directory, this level of autonomy and isolation can be achieved only through separate forests. This is also the case if you need to comply with regulatory or legal isolation requirements.

The first and most common reason may be political: certain business units may decide that they want to be as autonomous as possible. It may be that, politically, the finance department has to be completely separate, so you end up making a second forest with finance.mycorp.com as the second forest's forest root domain. In effect, you are treating this business unit as a separate, autonomous, and discontiguous part of the tree.

The second reason you may need two forests involves having two businesses that must be separately maintained.

The third reason is one born out of necessity. Remember from Chapter 2 that certain aspects of a namespace are forestwide in scope. If you want to isolate a separate schema, configuration, or GC, your only solution is to create a separate forest.

If any of these reasons is true, you need to create a second forest root domain and give it a unique DNS name, as you did for the first forest root domain. In effect, you need to separate your designs and do each forest individually. The best thing to do now is to figure out how many forests you need, which domains from your list are going to be the forest root domains, name these roots, and then use a separate piece of paper to draw each forest. Maintain separate lists of domains for each forest. You're now doing x designs, where x is the number of forests you have.

There is one other important point that you need to be aware of. While domains and trees in a forest maintain automatic trust relationships, it is possible to set up manual trust relationships with domains external to a forest. You can therefore set up manual trust relationships between forests. These relationships can be one-way trusts (A trusts B but B does not trust A) or two-way trusts (A trusts B and B trusts A).

If you require a limited trust situation (in the Windows NT/2000 sense), in which you wish to give access to your forest to vendors and partners, you can do this manually. If you have two forests that you wish to link, you have a few options: establish an explicit one-way trust, distribute a public Kerberos ticket, or create a transitive forest trust.

The first option allows other domains that are members of another domain tree in a different forest or that do not support Kerberos authentication to have limited access to a domain in the forest. Only resources in the domain will be visible; no other resources in the tree are available for access.

The second option allows a Kerberos negotiation to start with a client that is not already a trusted member of the domain. A public Kerberos ticket allows a user that is not a member of the domain at all to be authenticated by using an explicitly distributed and dated Kerberos ticket.

The last option is new to Windows Server 2003 Active Directory. Under Windows 2000, if you wanted all domains in one forest to trust all domains in a second forest, you had to create individual trusts to and from each domain. With the new forest trust, you can simply create a single transitive trust between two forests, and all domains in both forests will trust each other.

You can also allow access to Active Directory via a digital certificate. Effective use of digital certificates allows secure communication between two machines. A digital certificate is used for public-key encryption applications, mostly seen on the Internet where pages need a special certificate installed on the client to allow authentication over Secure Sockets Layer (SSL). A certificate server, such as the Microsoft Certificate Server that ships with Windows 2000 or Windows Server 2003, can be set up to issue, renew, and revoke digital certificates that allow access to Active Directory. The certificates are used to authenticate connections via specific computers and users. Active Directory has extensions that allow individual user and computer accounts to have digital certificates assigned to them, allowing authentication over this mechanism. While these concepts aren't difficult, they are outside the scope of this book.

8.4.3.5 Arrange subdomain hierarchy

You now have a forest root domain with a valid DNS name. You may have other domains that act as the roots of separate trees in the same forest; you may even have extra forest root domains representing separate forests entirely. Now you need to lay out the domain tree hierarchies. If you have a number of remaining domains listed on your sheet of paper from Step 1, these are the subdomains that will form your domain-tree hierarchy.

Start with the first forest. Representing each domain with a triangle on the paper, lay the forest out in a hierarchical fashion beneath one of the domain tree roots in the forest. Name the domain appropriately, according to its position in the hierarchy. Repeat this process for all domains in this forest, then move on to the next forest and repeat.

For example, if we have mycorp.com as a tree root, and finance, marketing, and sales all need separate domains, we call them finance.mycorp.com, marketing.mycorp.com, and sales.mycorp.com. If the sales domain needed separate domains for pre-sales and post-sales, we arrange these two domains beneath sales, as pre.sales.mycorp.com and post.sales.mycorp.com.

Each subdomain can manage its own accounts and data, or its parent in the hierarchy can manage them. That's the reason the hierarchy exists.

8.4.4 Step 3—Design the Workstation and Server Naming Scheme

You now have one or more forests of domain trees. Each tree is uniquely named in a hierarchical fashion. You can now consider the naming scheme for the servers and workstations.

While we are considering the naming scheme here, the exact placement of machines in Active Directory is covered in Chapter 10 on designing GPOs. That is because GPOs can impact clients based on machine location.

Each client or server in an Active Directory network has to have a computer account somewhere in the forest to let users log on via that client. When a workstation is added to a domain in a forest, the computer account is created in Active Directory, and a trust relationship is set up between the client and the domain, so that the client is recognized as a valid member of the domain.

Where a client is placed in the forest determines part of the name. Standalone servers and DCs are placed in the individual domains that they host. Clients can be placed anywhere, but they are usually placed in the domain that the users of that client normally log on to.

Under Windows NT 4.0, if you had a single-master or multimaster domain model in which multiple resource domains had one-way trusts to one or more master user domains that held the accounts, the workstations normally were placed in the resource domains. This enabled the workstations to log on to both the resource domain and the user domain. Putting the clients only in the user domain would have meant that the clients could not be used to access the resources in the resource domains, as no trust existed in that direction.

Cast this completely out of your mind in Active Directory. Each domain has a hierarchical and transitive trust between it and every other domain, so it no longer makes any difference where the clients are located.

All hosts are named computer.domain. For example, a server called moose in mycorp.com would be called moose.mycorp.com; a server called moose in the finance domain would be called moose.finance.mycorp.com.

While deploying Active Directory does not force you to change the names of any existing hosts that you have, if you are due to amalgamate a series of domains and have clients with identical names, you need to make modifications so that hostnames are unique throughout the entire forest. You can easily make use of ADSI (discussed in Part III) to script a query for a list of computers from every one of your domains and then check the lists via a second script for duplicate names.

If you don't already force a naming scheme, now is the time. Fully Qualified Domain Names must be unique across the entire forest. This is achieved by appending the domain component onto the computer name. That leaves you to worry about the prefix, meaning that computer names have to be unique only domain-wide.

To maintain backwards compatibility, names cannot be longer than 15 characters. This is because Active Directory still has some legacy support for NetBIOS names, and the hostname that you choose will be incorporated as the NetBIOS name on the client. NetBIOS names are limited to 15 characters.

You need to work out a forest-wide naming scheme, determining how you will name the clients within the 15-character limit using only the characters from the previous list. We can't help you much here; the choice of your naming scheme is up to you.

Remember that Windows 95 and Windows 98 devices do not require computer accounts in the domain. However, if you do deploy these clients and anticipate upgrading them later to Windows NT Workstation, Windows 2000 Professional, or Windows XP, the names of these clients will become an issue. It would be better to designate a name now to facilitate an easier upgrade later.