In the first article of this series, ” Designing an Active Directory naming scheme ,” I discuss the importance of using a well-organized naming structure in developing your Active Directory layout. When you build an Active Directory from the ground up, you must consider more than simply what names to use for the various directory objects. You must also decide which computers should be grouped into domains, trees, and forests as well as where to place trust relationships and what resources need to be available across domains. In this article, I’ll walk you through the next phase of designing your Active Directory structure.
Planning your domain structure
“The first Active Directory server on a network must be able to handle quite a workload. “ |
Before you begin planning some massive Active Directory scheme, you need to stop and consider what’s already in place. Unless your company is brand new, there’s a good chance that you’ve already got some sort of existing network. If this network uses Windows NT at the server level, you’ll probably want to take that into consideration when installing the Active Directory. If you are presently running Windows NT, you have the option of installing Windows 2000 on top of the existing Windows version and implementing Active Directory on the spot. Of course, there are several things to consider before doing so. We’ll get to that a little later.
If your existing network uses a platform other than Windows NT, you’ll be able to salvage some of it, but you’ll lose a lot. For example, suppose your existing network is a totally NetWare environment. If this is the case, you’ll be able to migrate your data to the new environment. Depending on the age of the servers, you might be able to reformat them and load Windows 2000. You’ll also be able to continue using any existing wide area links and any other local network hardware.
Now, suppose for a moment that your existing network is running Windows NT Server 4.0. In this case, your first instinct might be to load Windows 2000 onto one of your domain controllers to get the ball rolling. However, if your network is any size at all, I recommend a different approach.
I recommend finding an old PC that you’re not using for anything and loading Windows NT Server 4.0 on it as a backup domain controller. When you’ve done so, physically remove the computer from the network and put it in a safe place. This computer will be your salvation later on should something go horribly wrong during the conversion from the existing domain model to the Active Directory model. You should repeat this procedure for each currently existing domain. Remember that it will take some time for any changes that have been made to the primary domain controller’s security accounts manager to replicate to the backup domain controllers. Be sure to wait until all the changes have been replicated before unplugging the new backup domain controller.
The next thing that I recommend is buying a medium- to high-end server (depending on the size of your network). A quick glance at any book on Active Directory will tell you that setting up an effective Active Directory structure isn’t necessarily a simple process–in fact, it can be overwhelming. You may even wonder where to begin. What better place to begin than with an empty server?
Starting with an empty server offers some big advantages. To begin with, the first server in the Active Directory that you bring online runs something called the global catalog. The global catalog is a database of every Active Directory object (not unlike the Active Directory itself). When a client needs to locate an object within the Active Directory, the client can search the global catalog for the location of the object much more quickly than it can search the Active Directory. As you can imagine, the global catalog can pull some serious resources from the server on big networks. Do you really want this service to run on an existing server that may already be starting to bog down?
Another reason for starting the conversion process with a new server is that when you install Active Directory for the first time, it will expect a DNS server to already be online. If a DNS server doesn’t already exist, Active Directory will load DNS onto the server that you’re working with. If you don’t already have a DNS server, what better place to put it than on a new server that will have no trouble handling the workload?
The first Active Directory server on a network must be able to handle quite a workload. You must consider one other thing when setting up this and future Active Directory servers. Any time that any change is made to the Active Directory database, the change is written to the database and to a log file that is used for disaster recovery purposes. In large networking environments, Active Directory changes can occur very frequently. Having to write to two separate files every time a change occurs can really bog down a server. You should consider placing the Active Directory database and the log file on separate hard drives to avoid bogging down the system. Remember that for this technique to be effective, the two files must be on separate physical hard drives, not just separate partitions on the same hard drive.
Placing your domains
Now that you’ve set up your initial Active Directory server, it’s time to plan the rest of your domain structure. The method of doing so varies greatly depending on the size and geographical layout of your network. The basic technique that I like to use involves doing what feels comfortable and blends well with existing components.
For example, if a company already has a couple of domains that work well, there’s no reason not to maintain that structure when implementing Active Directory. Otherwise, you could group domains by department, geographical location, or both. Keep in mind that under Active Directory, all the domains will fall into a single domain tree (unless your company is big enough to use forests). That single tree will have a name like my_company.com. Therefore, there’s no reason why you can’t create domains that fit your company’s profile. Doing so is especially easy when you consider that Windows 2000 allows for parent and child domains, meaning that a single domain can contain other domains beneath it. Therefore, you can end up with domain names like: accounting.Miami.my_company.com or marketing.second_floor.New_York.my_company.com. Use your imagination. (If you need more detailed information about parent and child relationships, check out ” Designing an Active Directory naming scheme .”)
Where are trust relationships necessary?
Being a Windows NT veteran, I absolutely freaked out the first time I read about parent and child domains. My first thought was that such a structure would require some seriously complicated trust relationships and would be virtually impossible to manage. This isn’t necessarily the case. To truly appreciate how Windows 2000 handles this arrangement, it’s necessary to understand a little bit about the way that Windows NT handles trust relationships.
As you may recall, in Windows NT, a trust relationship is used to join two domains. Its purpose is to allow users in one domain to access resources in a separate domain without having to create a user account in both domains. When a trust relationship is put into place, the administrators of the two domains get together and decide whether to use a one-way or a two-way trust. In English, this means that just because users in domain A want to use resources in domain B, it doesn’t necessarily mean that users in domain B should be able to access domain A. A one-way trust relationship allows users in one domain to access resources in another, whereas a two-way trust relationship allows users in either domain to access resources in either domain. I should also mention that just because a trust relationship exists, it doesn’t necessarily mean that a user can access a resource within a foreign domain. The administrator of the foreign domain must grant permission to the user before they can access a thing. The trust relationship merely lays the groundwork for the administrator to be able to grant that permission.
You can see why parent and child domains within Windows 2000 require some sort of trust relationship. The good news is that Windows 2000 implements these trust relationships automatically. However, they work a little bit differently than the Windows NT trust relationships I just discussed.
When you create a child domain in Windows 2000, Windows 2000 automatically applies a two-way trust relationship to those domains. This relationship allows users in either domain to access resources in either domain, assuming they have the necessary permissions. But unlike the Windows NT-style trust relationships, these trusts are transitive in nature. For example, suppose that you had a domain named A and you created a child domain named B. As you’d expect, Windows 2000 would create a two-way trust relationship between the two domains. Now, suppose that you created a child domain off B, called C. Windows 2000 would create a two-way trust between B and C. The transitive part comes into play because although C is a child of B, it’s also a grandchild of A and therefore needs to be able to communicate with A. Therefore, if A trusts B and B trusts C, then A will automatically trust C.
The Windows NT-style trust relationships still exist within Windows 2000. They are used to tie together otherwise unrelated domain trees. However, the Windows NT-style trust relationships aren’t transitive in nature–only the automatically created trusts are transitive.
Conclusion
As you can see, quite a bit of planning goes into building an effective Active Directory structure. Sure, you can build an Active Directory structure without much planning, but doing so can cause some serious growing pains down the road. Therefore, I recommend carefully considering your company’s current and long term needs when designing an Active Directory structure. //
CrossLinks
- EarthWeb Networking & Communications: Active Directory: Allowing or Denying Access
- EarthWeb Networking & Communications: Active Directory: Modifying Default Permissions
Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the Director of Information Systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.