Active Directory Design

This module looks at the whole concept of the Active DirectoryTM service in the Microsoft® Windows® 2000 operating system and the idea of building the forest, the trees, the domains, and so forth.

The most important thing to remember is to think before you build. When you plan your migration, you've got to build in the time to think about how you're going to implement Active Directory. The ramifications of your decisions are going to be much more far reaching than they would be with a number of different groups that could run stand alone if they needed to.

To that end, this module examines Active Directory, defines both the logical and the physical structure of Active Directory, and talks about how Microsoft has separated the two—and why that is so important in this product.

This module concludes by defining some of the specific domain controller roles, such as PDC emulator, RID master, and Schema Master, and explaining what these do.

The section starts by defining Active Directory and explaining what technologies support it, its naming conventions, and how Active Directory works with DNS.

Basically the Active Directory service is a way to publish objects of interest. And in this case, your user account might be interesting, the printer that a group uses, a shared data folder, even the router you just installed. "Objects of interest" could include the switch or the new PeopleSoft application.

Potentially all of these things can be accessed and managed through Active Directory. As time goes on you will see more and more vendors—both software and hardware—building their products to take advantage of Active Directory, because its intuitive, centralized interface simplifies the organization, management, and control of network resources.

With Active Directory, users log on once and have access to anything in the forest that the administrator chooses to give them. Active Directory should go a long way toward removing any reason for a single user to have more than one account.

These are the technologies currently supported by Active Directory. This list will continue to grow.

Distinguished Name

Every object needs a distinct name so that everything in the forest can be uniquely identified. A forest is like a file structure: You can't put two files of the same name in the same directory, and neither can you put two people with the same name in exactly the same place in the forest. Although you can have two users with the same name, they must exist in different places.

To address the need for every object to have a unique identifier, Active Directory uses the distinguished name. This example shows a user with the very common name of James Smith. He is located in an organizational unit (OU) called Users, which exists in a domain called Contoso.com. This is great—if you're starting at the top of the tree and working down.

Relative Distinguished Name

If you are already in the same organizational unit, however, you don't need to define the entire path to the requested object. The idea of a relative distinguished name specifies that, wherever you happen to be in the forest or tree structure, you only need to identify enough of the name to get you to that object. So in this example, if you're already in the OU called Users, you just say, "I want to find James Smith." If you're already in the domain called Contoso, you say, "Look in Users and find James Smith." You are defining the path to the object relative to your position.

User Principal Name

The user principal name is generally the name that the user logs on with. However, the user still needs to know in which domain the account exists, because some users may have multiple domains, or you may have multiple domains with trusts set up. In your systems, the e-mail accounts you give your clients may not reflect your forest's domain structure. Therefore, you may assign a customer the address johnb, when that user exists in your forest as an object with a completely different, distinguished name.

Globally Unique Identifier

Under the Windows NT® operating system version 4.0, every object in the domain has a unique Security Identifier (SID). In Windows 2000, this concept still applies, but in addition each object needs to be uniquely identified throughout the entire forest. So when you create an object you get the SID, which ties into the domain, as well as something called the GUID, or Global Unique Identifier.

The SID can suddenly change. For example, if you move a user object from domain X to domain Y, you will get a new SID, because the SID is tied to the domain. However, the GUID for that object should never change. As long as the object exists anywhere in the forest structure, its GUID should never change, which means the GUID can be used to track the movement of objects.

Name Resolution

Because you need some way to send server X to an IP address, or to get to a share on server X, which has an IP address, the familiar name resolution methods are still there. You can still do a NetBIOS broadcast and still access WINS. In addition, if you want to access DNS to get to a server, you can build that in.

In addition, the Dynamic DNS Update Protocol can be used to get not only the IP address of a server, but also the IP address of a service. To illustrate the distinction, consider this: Instead of going to DNS to get an IP address for server X, you may just need to log on. At that point, do you care or even need to know which domain controller authenticates you or what its name is? What you do know is that you want to log on to a certain domain, so when you go to DNS now, you're not asking for the name of a box, you're asking for the domain controllers that will let you log on to domain X. WINS is doing this already. Therefore, keep in mind that name resolution doesn't involve just the computer name to IP address, but also the ID of a service.

Locating the Physical Components of Active Directory

Locating the physical components of Active Directory deals with enabling users to easily find the network resources they need to do their job. Once users log on, they may need to find a printer, the shared data directory, or a list of all the users that live in Seattle. This will happen through the Active Directory store, which is stored on domain controllers, with some subsets of those components on the Global Catalogs.

This diagram shows the logical structure of a forest. Domains, which up until today have been drawn in circles, are now shown as triangles. The forest generally will be shown as a sort of a square or rectangle encompassing the other components. Each individual domain, such as organizational units (OUs), will usually be shown as circles, although sometimes they're drawn out as a file folder structure. The next few pages define domains, organizational units, and trees and forests.

Under Windows NT, a domain is a security boundary, an administrative boundary and a unit of replication. If you work in a Windows NT domain, these are the three things you get. If you're the administrator of Domain One, you own it. If you've got two domain controllers in this domain, they're going to talk to each other and they both have a complete copy of every object in that domain. And if in your domain you elect to define a minimum password length of 10 characters, that is a domainwide decision.

In Windows 2000, these three features haven't changed—the domain is still a security boundary, an administrative boundary, and a unit of replication. What's more, in Windows 2000, you can run your domain in one of two modes: mixed mode or native mode.

When you build your first domain controller, it comes up in mixed mode. You don't have an option during the install. Actually, it makes sense that you wouldn't have an option: If you're doing a migration, the difference between mixed and native mode is that if you have backup domain controllers, you have to run in mixed mode.

Imagine that you're ready to start the migration of the Windows NT 4.0 domain (the first row in the diagram). You'll run the upgrade on the primary domain controller, and it will become a Windows 2000 domain controller. At that point, every other domain controller in the domain still needs to see this newly upgraded domain as the primary domain controller. Therefore, you'll be running in mixed mode, which means that items like SIDs will be created sequentially, something that backup domain controllers like to see.

It also means that whenever the backup domain controller is contacted for changes, it's going to come here to get those changes. As you migrate or upgrade other backup domain controllers, they will become Windows 2000 domain controllers; thus the whole primary domain controller/backup domain controller (PDC/BDC) concept is really going away. Domain controllers are essentially peers now, and changes can be made on any one of those machines.

After you've upgraded all those machines in the front row from BDCs to Windows 2000 domain controllers, you have no compelling reason to run in mixed mode any more. Because all these machines are now Windows 2000 domain controllers, they all understand the concept of transferring data in a peer-to-peer relationship, as opposed to the PDC/BDC relationship, which is pretty much a one-way movement of information.

You will approach the decision to run in native mode when all your domain controllers have been upgraded to Windows 2000. But when you upgrade that first primary domain controller, it will come up in mixed mode, and it will continue to contact the backup domain controllers until you decide to go native.

The transition from mixed mode to native mode is for all practical purposes a one-way trip. To go back to mixed mode from native would involve restoring from backup tapes. Therefore, you'll want to be certain you're ready to move to native mode before you do it.

Note: Running in mixed mode is only required if some of the domain controllers are Windows NT. You can still have Windows NT 4.0–based member servers, workstations, or any other downloadable client workstations and migrate to native mode.

Imagine you have a Windows NT 4.0 domain, and you want one person to be the administrator for half the users and another person to administrate the other half. In Windows NT, this is just about impossible. You can't split a Windows NT 4.0 domain administratively; either you handle all the users, or you handle none of them. Wouldn't it be great if a single domain could be split so that Don administers everyone in Los Angeles, and Mary takes everyone in New York, and they can't affect each other? That's what an organizational unit (OU) structure allows you to do.

Although there are other reasons to create OUs, this ability is certainly one of the primary ones. There are a number of philosophies on how to create this model—you can divide by applications, printers, locations, users, and so on—but one of the best is to model the organizational unit structure after your administrative model rather than your business model.

There's no advantage to users to model the OU on business divisions because they don't need to know their OU in order to log on; they don't ever use their OU name, really. And modeling the OU structure after the business could be a big disadvantage to your administrative people. Instead, look at the administrative model you're using now. If your domain structure is based on geography, that might be a good way to map out your OU structure.

The special nature of the solution provider business may warrant a slightly different approach because you will have certain customers that need access to their own structure, but you obviously don't want them to be able to get to another customer's data. So solution providers may start to map their OU structure based on their customer base, or something similar.

No matter which model you choose for the OU structure, the point is to make the system easier to administer.

When you build that very first domain controller, you are building the root domain in the forest. And it's a very special domain in this forest because it anchors the entire forest structure. All the trusts, all the access to objects, is going to run through this domain. If this domain were to go away, you would have to rebuild your forest. Therefore, some clustering is probably going to be involved at this level.

During the install, you're prompted to name the domain. When you build the root domain, the forest takes on the root domain name. In this example, the root domain is called contoso.com, so the forest will be named that as well.

As you begin to add other domains, you have two basic choices:

1. You can bring the new domains into an existing tree, which is exactly what is happening in this example. Notice that the namespace starts to take on the names of the parent domain; you really don't have an option. So if you bring China into the existing tree, it's going to be named china.contoso.com. If you bring another domain under that, it will be domain1.china.contoso.com, keeping that contiguous namespace down through that tree structure.

2. Your other option is to stay in the same forest but to have a different domain or DNS namespace. At that point, you're saying, join the contoso.com forest, but don't come into the existing tree. Come in as your own tree root.

The diagram shows another tree root, but it isn't another forest root. As mentioned above, if you lose contoso, you'll lose the forest. But now you have created a new DNS namespace, which you can begin to build a tree under, with the same qualification of continuing that DNS name down through the structure. By default, you will get two-way transitive trusts between all the domains in your forest.

This means that if a user in the China domain needs to use a printer in Japan, you can give them that ability. Because of the two-way trust relationship, you can get to any resource in the forest easily.

In addition, you may need to build relationships with other domains. For example, you may be in the middle of the migration and you've got some of the domains into a forest, but not all of them. If you need trusts to be in place during the migration, you have the ability to build what is essentially a Windows NT 4.0 trust because it is one-way and nontransitive. Also, any existing trusts will remain in place during the upgrade process. This diagram shows the two-way transitive trusts coming into place.

What's more, if you want, you can create additional trusts within your own forest. When the user in Japan.nwtraders tries to get to the printer, that request will be handed from the user's domain up to the root and back down. Once that user goes that route once, the system gives him a ticket so that the next time he needs to get to that resource, he can. In the meantime, if you have a large domain, or a large forest with a lot of domains and trees, and you want to grant access from one place to another, you can build a trust to make that happen.

The point is, you're not completely locked into the structure you're given. You can build additional trusts, even within your own forest, if you have the need.

Finally, why is transitive trust so much different from trusts in Windows NT 4.0? It's two-way. In Windows NT 4.0, you could say, if A trusts B and B trusts C, that tells you absolutely nothing about A and C. A transitive trust is the exact opposite of that. In this case, if A trusts B and B trusts C, then you can get from A to C through B. It is a transitive trust.

It also means that you're not going to end up with a lot of domains with an incredibly large amount of two-way trusts going between them; it doesn't take long before you have some really ugly trust diagrams in place. This is going to take care of that problem.

With the concept of the site and the physical structure, questions arise concerning domain controllers, traffic between domain controllers, and the concept of site creation.

If you work with Microsoft Exchange Server, the concept of sites should be somewhat familiar. In terms of sites and domains, Windows 2000 gets around a lot of limitations that you may have experienced with Windows NT 4.0.

Imagine that you have a single domain that spans California and has domain controllers in Los Angeles with a primary domain controller in San Francisco. The West Coast of the United States is doing fine because you can get as much bandwidth as you need. However, you want to move into South America, which doesn't enjoy the level of connectivity that is available in this country.

In Windows NT, all changes must happen on the primary domain controller. But that backup domain controller in Brazil needs to get those changes, too. Because everything happens on the primary domain controller, you just have to deal with the replication traffic. If that link goes down for long enough, when it comes back up, you might see a synch of your entire SAM (Security Accounts Manager) database happening across that WAN link. Because of the way the PDC/BDC relationship operates, when the backup domain controller goes to the change log, it looks for its own time stem. If it sees its time stem, it knows what the changes are and brings them down. If it doesn't see the time stem, the BDC just takes the entire database.

You can try to fix this situation by using replication management and synchronization management to move the changes less often. But that doesn't really do anything to reduce traffic, it just results in more traffic less often. Even so, replication or synchronization traffic will happen no matter what, because if a change happens, the traffic is going to occur. So all these methods can really do is manage when the changes occur.

In the California scenario, you have a primary domain controller, a backup in the same room, and maybe another backup. And you have a backup in L.A. and a backup in Brazil. If you change the replication time on the primary, you're affecting a lot of users because that one domain controller very far away can't handle a synchronization every five minutes (which is the default). But having the two machines in the same room replicate every five minutes would be no problem. Unfortunately, Windows NT 4.0 had no way to specify how often domains would replicate.

All of which leads to the concept of sites. A site is a collection of IP sub-nets. A site can have as many sub-nets in it as you choose to put in, but a sub-net cannot span multiple sites. And if you picture the site as a physical boundary, it makes sense that you wouldn't want a sub-net that would cross from Brazil into L.A. For example, if you've got a lot of users in L.A., it may be perfectly appropriate to have multiple sub-nets as part of that same site. Once you define your sites, you can start to refine the replication between them. You can specify that the two machines in the same site, called San Francisco, replicate to each other whenever they feel like it. This machine in L.A., however, is on a little slower link, so, these machines should replicate only every 30 minutes. And the time period for that one down in Brazil should be six hours.

In other words, although you can't do much about the amount of traffic—it has to move—you have a lot more control over when.

Note: Keep in mind that sites have nothing to do with domains, unless you choose to map your sites to your domain structure, although there's no reason to do that. What you want to do is build your sites around your well-connected sub-nets, so that the borders of your sites are defined by your physical boundaries and by your routers.

Replication still happens, although it's a bit different in Windows 2000. In Windows NT 4.0, if you created a user account, it always happened in only one place, the primary domain controller. In Windows 2000, if you create a user, it's going to happen right in the domain in which you're working. As mentioned previously, the whole PDC/BDC relationship is going away and we're getting much more into a peer-to-peer model.

Within a single domain, replication occurs every five minutes by default. But this is no longer the relatively simple, one-way street it once was—that is, replication happens, then it moves over to the backups. In Windows 2000, changes are happening all over the place, so there needs to be some mechanism in place to define how those changes will be moved.

Keep in mind the definition of a domain given earlier—that a domain is a replication boundary. In Windows 2000, every domain controller in a given domain will contain a complete copy of the Active Directory–based database for that domain. And the domain controller is still tied to a single domain. Therefore, because you want to ensure that you never lose that roof domain, you should have multiple domain controllers in the root. In this way, if you lose the one machine, users can still log on to different domain controllers. And if you have a domain that spans a large geographical area, you can put the backup domain controllers where the users are.

To that end, domain controllers have specific roles, one of which is the Global Catalog, which lets you add different kinds of functionality to a domain controller to serve different purposes.

Operations Masters are a little different in that you can only have either one per forest or one per domain, depending on which role the Operations Master is trying to fulfill.

It's important to know which domain controllers are fulfilling these roles in case, for example, one of them goes down or you choose to move one.

To understand the philosophy behind the Global Catalog server, imagine you're working in China and want to find all the two-sided color printers in your forest. You don't have time to wait for the query mechanism to look through all the trees. What you need is a centralized database of all the objects. That's what the Global Catalog server does.

So the Global Catalog by definition will know about every object in the forest. To keep this database from growing incredibly huge, it limits the amount of information it displays about every object to a subset of the more popular aspects a user might want to search on, such as user's last name, address, and phone number. Many references imply that the Global Catalog contains a partial list of all the objects in the forest, but that is misleading. Instead, the Global Catalog is a complete list of the objects with some of the attributes from each object. The good news is that you as the administrator can determine which attributes are going to appear on that Global Catalog.

If you are running in native mode, Global Catalogs also house Universal Group Membership lists. During logon, Global Catalogs are used to determine which Universal Groups the user is in. Because the Universal Groups need access to that Global Catalog server, you're going to want more than one.

But more important, where are we going to put them? If the users in Brazil do not have a Global Catalog server, every time they search outside their own domain, you're going to see traffic across that link to the Global Catalog server. To remedy that, you build a separate Global Catalog Server in Brazil.

Physical and geographical realities are most important when deciding where Global Catalog servers are located, and this in turn is balanced by where your users are and by how many cross-domain searches they need to conduct. Realize that a domain controller can handle searches for resources within the user's domain; it's only when a resource outside of the user's own domain is being requested that a Global Catalog becomes involved.

Also, remember that if you are in native mode, you will need to access a Global Catalog server for authentication, which is another good reason to put them close to where your users are. It doesn't make sense to have a domain controller geographically close to the users, but then have them cross a slow link to access the Global Catalog just to log them on.

Finally, Global Catalogs are easy to bring up and down. If you don't want a server to be a Global Catalog any more, you just check a box, and it will go away.

The five kinds of Operations Masters are Schema Master, Domain Naming Master, RID (Relative Identifier) Master, PDC Emulator, and Infrastructure Master. The very first box you build in that very first root domain will have all five kinds of Operations Masters. Your second domain will have three of the roles: RID Master, PDC Emulator, and the Infrastructure Master.

You can run without any of these for a limited period of time. You may not even know you lack one until you go to do something that requires one of these roles.

Schema Master

In Windows 2000, you don't have an object class called "router." To add attributes to existing objects or to build completely new object classes, you need to enable Active Directory to know how to build that object, and this involves extending the schema.

One machine in the forest should handle that schema extension. Every domain controller will know what the schema looks like and needs to know what types or classes of objects can be created. So to avoid conflicts created by different people changing schema at different times, only one machine should be a read/write copy of that schema database. This will be your Schema Master. The very first domain controller you build will fulfill that Schema Master role. There can be only one Schema Master per forest.

Domain Naming Master

Like Schema Master, there can only be one Domain Naming Master per forest. The Domain Naming Master is the machine that makes sure you don't have two domains in the same tree with the same name. For example, if you set up contoso.com as your root domain and build one.contoso.com, the Domain Naming Master will prevent you from putting in another domain with the same name and thus creating a conflict.

RID Master

If you're running in mixed mode, it means your Backup Domain Controller is online. As part of the synchronization process, Backup Domain Controllers need to see consecutive SIDs (Security Identifiers), and it's up to the RID Master to make sure that happens. When you create a user, that user will go to the RID Master to get the next available SID.

Once you switch to native mode, consecutive SIDS don't matter anymore, but the RID Master is still needed because you do want to make sure that you never duplicate a SID. In native mode, instead of accessing the RID Master every time you create an object, you just grab a block of about 500 IDs to use locally.

So the RID Master role changes a little bit in native mode, but it's still very important to know it's there. If you were to drop it, you probably wouldn't even know until you ran out of IDs and couldn't get anymore.

There is one RID Master per domain.

PDC Emulator

In mixed mode, BDCs go to the PDC Emulator for changes. You can create objects in a Windows 2000 domain, but when the backups need to get changes, they don't go to the domain controller; they only know to go to the PDC Emulator. In addition, when your clients running Windows 95 or Windows 98 need to find a PDC, they go to the PDC Emulator.

When you move from mixed to native mode, the PDC Emulator's role changes a little bit, but it doesn't go away. Certain changes are considered critical changes, such as changed passwords, someone exceeded the maximum number of logon attempts, and so on. Because of the critical and wide-reaching nature of these changes, they are replicated immediately again to the PDC Emulator.

Therefore, even if you're in native mode and you don't really have a machine that is acting as a Primary Domain Controller, you still have the PDC Emulator, and it is still important that it be up and available.

There is one PDC Emulator per domain.

Infrastructure Master

The Infrastructure Master tracks movement of objects, in a sense. If you move a user from one domain or OU to another, part of the user's name is going to change. And you want the group the user is in to reflect that name change as soon as possible. The Infrastructure Master will handle that for you.

During installation, you're asked a number of questions. On the very first machine, the questions are easy:

1. Do you want to build a new domain controller? It's the first one, so it's got to be a new domain.

2. Is it part of an existing domain, or is it a new domain? Obviously, it's going to be new.

3. Is it a new tree, or an existing tree? Again, it's going to be a new tree.

4. Is it a new forest, or an existing forest? It's got to be a new forest, because everything is new.

Then you run the DC promo, see the hourglass for a little while, and reboot. You've built your first domain controller.

But you've just acquired a lot of other things in the process. You now have a Windows 2000 domain. You have a tree, albeit a small, single-domain tree. You have a forest all running on one box. In addition you have the five roles being held in that one box. You also are creating something called the Default First Site Name, which is covered in more detail later. You will want to move or at least duplicate some of those roles on other domain controllers.

As you continue to install, the questions get a little tougher. You get the same questions, but now, because you're fitting a new machine into an existing structure, you've got to work this machine into an established infrastructure, supplying the names of already-created domains and trees along the way.

And for every domain controller that you install, you'll have to make these decisions: Is it new or existing? Is it a new domain in a tree? A new tree in a forest?

After you've done the preparatory work for the installation, you have the root domain. At this point, you have a lot of decisions to make about what type of domain you want. Do you want to use DNS? Are you going with NetBIOS names? Where do you want to put the database log? The shared system volume?

The only element that has to be running on NTFS is the shared system volume, although in general most domain controllers today should be running NTFS.

After the Active Directory service is installed and you reboot your domain controller, you get some administrative tools to help you run Active Directory.

One basic question you will ask yourself is, Do I need to build a new OU or a new domain? As the business grows and you get more clients and more people, you have to make this decision.

Your decision may be driven by business realities and customer service. If a customer wants its own domain, it gets its own domain. If it wants its own forest and has the money, even if it doesn't make sense, it gets the forest.

But from an administrative standpoint, it's easiest to build a new OU, which is easier to manage and involves less replication traffic than a new domain does. In most instances you'll be able to do everything you need to do by building an OU for the customer and giving the customer rights and information based on that OU placement. Regardless, you need to decide how to set up your OUs. For example, you might say, one OU per customer, perhaps with nesting underneath, depending on the customer's needs and how you want to control access.

You will also need to plan for delegation. In Windows NT 4.0, if customers wanted to manage their own systems, they got their own domain because you certainly didn't want to make them administrators on your domain. In Windows 2000, you can put a customer in charge of its own OU, and the customer doesn't even have to know the rest of the forest exists. This means that customers now have the option of managing their own areas.

The most important factors in the decision to go with OUs or domains are administrative and security issues. How many OU levels do you want? The rule of thumb is the fewer, the better. If you nest your object eight OUs deep, logon will take longer than if it's sitting on one or two OUs from the top.

Network traffic is also somewhat of a consideration in deciding between OUs and domains. Remember that the domain is still a replication boundary. If you have very slow links, for example, you might choose to put a domain on either side. But that decision should be made only when you have no other option.

In short, develop a strategy. And, unless there is an overriding reason not to, go with an OU.

If you start to enforce Group Policy based on OU, logon will take much longer because every single policy will have to be down through that structure.

So don't build OU levels just because you can. Before you nest an OU, ask yourself why. Make sure you have a good reason. Generally, the flatter the OU design, the better.

Think of this stage as cleaning the house before you move in. Look at your existing model. Do you like it?

If you do, there's no reason to change it. If you don't, this is your opportunity to figure out why, and whether Windows 2000 addresses the things you don't like. This is a good way to decide which Windows 2000 technologies you want to implement.

Finally, get ready to deploy your structure. Review your OU levels, and make sure that you're not just building them because you can.

In fact, Microsoft recommends a maximum of three OU levels—any more than that, and you can expect to see a degradation in performance.

Of course, you can do more than that, assuming that you're not associating policy with the OUs. Once you start to associate policy, the logon and authentication processes will begin to slow down.

Groups have changed somewhat in Windows 2000. Everything you already know about groups still applies, but now there's a whole new type to consider.

This new structure has traded simplicity for power, which often is the case. Fortunately it's a lot more powerful in terms of controlling access.

There are now two types of groups, although the purpose of these groups really hasn't changed:

• For the most part you'll be working with security groups, which are used to assign rights and permissions.

• Distribution groups are a new type of group. These are used just to create groups of people that you might want to send e-mail to, for example. But remember that this is an nonsecure grouping, so use them sparingly.

In addition to the type of group, you need to decide the group scope. The three group scopes are domain local, global, and the new type, universal.

• In terms of what is included and where it can be placed, a domain local group is pretty much the same as a local group, with one nice difference.

  In a Windows NT 4.0 domain, if you have a resource on a certain box and it's a member server, you have to create the local group on that box. That's the definition of local. If the resource is not a domain controller, you can create the local group once and expect it to replicate out.

  With Windows 2000, you can create the domain local group on the domain controller, then use it on any domain controller or member server in your domain. If you've got five member servers, you no longer have to create five different local groups to give the same people access to the same type of data. You just take the domain local, and put it where you want. It is still local to the domain, so as long as the resource that users need to get to is in the domain.

• Global groups really haven't changed much at all. They exist on domain controllers. Membership is limited to the domain in which you created it, and groups can for the most part be put into any universal or local group in the forest.

• Universal groups are the "contain anything, go anywhere" choice. As the Microsoft Official Curriculum (MOC) courses teach, "Accounts get put into global groups. Locals get permission." This is still a good guideline and will make management easier.

This table summarizes the salient information about security groups.

Also, you need to be in native mode in order to use universal groups; remember that they exist on Global Catalogs, and that membership is checking during logon. Once you migrate to native mode, you can do some nesting with your domain locals and your groups: You can put a domain local into a domain local within a single domain, and you can put a global into a global.

Creating groups can get a little complicated. Universals can contain almost anything—users, global groups, even other universals. And they can go into local groups.

This diagram shows the old AGLP (accounts > global groups > local groups > permissions) strategy expanded to be AGDLP, but it's same idea. Start with your users, work your way across, and then give them the permissions that they need.

This diagram illustrates what the group types contain and where they can go from a planning perspective.

Once a group is created, you can modify it. You can, for example, add a domain local or global group into a universal group. You can move between security and distribution groups. And when you delete a group, you do not delete the members, but you do delete any rights and permissions that those members had.

Keep in mind that because the group membership of a universal group is contained on the Global Catalog, changes to the membership of a universal group are replicated to every Global Catalog. So if you put users directly into universal groups, every change generates Global Catalog replication traffic throughout the forest.

Therefore, the recommended procedure is not to put users directly into universal groups; instead place users into global groups, as you always have. In this way, you can change memberships in the global groups all day and suffer no traffic associated with those changes.

A good policy with regard to groups is to stick with what you're using if it's working for you. Use universal groups as a last resort. If a number of people from the same domain need access to resources, put them into a global group. If you've got a number of resources in the same domain that people need access to, use a local group to do that.

The universal group should be your last choice. In some cases, it's a wonderful tool—for example, objects in many different domains from all over the forest that all need access to resources in many different domains from all over the forest. Arranging that access using just domain local and global groups is possible, but it's a fair amount of work and a lot of management.

An object can be put onto any resource in the forest. Once this is all set up, you need to decide whether you want users to see every object in Active Directory. And for your purposes, it is probably absolutely critical that they do not.

Not only do you not want these users to have access, but also they shouldn't even know it exists. With Active Directory permissions, users are not just prohibited from gaining access to an object, they don't even see the object.

With the concept of the Access Control List (ACL) in Windows NT, every resource has an associated list that specifies the users or groups that have permission to access it. The most permissive access to that resource is the effective one. That concept has been carried over to objects in Active Directory in something called a DACL, or Discretionally Access Control List.

DACLs assign some type of access to the object in question, which by default inherit down through that part of the Active Directory structure. You can certainly change that to allow a user to see one OU, but not another, or to see certain types of objects, but not others. For example, you may want to allow a customer to see users but not servers. This access is flexible in that way.

If you take this idea a step further, you can allow users to see some of the attributes of the objects available to them. In this case a user could, for example, find out a person's last name and phone extension but not the home address and home phone number.

By their nature, DACLs are set on the basis of the individual objects.

With multiple permissions, you can allow or deny permissions. There are standard sets of permissions, or as explained above, you can get very, very detailed if you have the need.

By default, permissions will roll down the hierarchy. However, such permission inheritance can be prevented, and you have two ways to do that. You can remove a user from the list, which prevents that user from getting in, or you can deny that user access to the object, which means the user can never access the object no matter what.

For example, if an ACL says that the user Don has access, he has access. But if Don is not on the list and is not in any groups that are on the list, Don doesn't get in. If, however, you specifically assign Don no access, it doesn't matter which groups he belongs to or what those groups' permissions are, Don doesn't get in. The same concept applies here.

Therefore, be careful about denying access. If you want to prevent a specific user from getting in, just leave that user off the list. If you want to make sure some user or group never gets in, assign no access.

Also, you can copy existing permissions as you block inheritance, or you can set you own values, which will then inherit by default throughout the rest of that piece of Active Directory.

Another feature of objects is that they can be moved. If an object's permissions are set specifically for that object, you can move it and its permissions will move with it. On the other hand, any permissions that an object has through the inheritance principal will disappear, and the object will inherit permissions at the destination. Unless you have permissions that are set specifically on the object, you can expect the inheritance of the destination to take effect.

What's more, administrators as well as users have the ability to locate objects:

• As an administrator, you can actually go into Active Directory and run a search. You can define what you want to look for, then search an individual organizational unit, a domain, or the entire forest. You can compose advanced searches to find, for example, everyone who lives in New London County or everyone whose home phone number starts with "434."

• Users have a somewhat less powerful search capability. They can use Search on the Start menu, in Windows Explorer, and My Network. Even though somewhat limited, these mechanisms still allow users to find printers, machines, and so on.

First of all figure out what your goal is for Active Directory. Do you want every customer to see just its own OU? Do you want every customer to at least see its OU and the domain it is in? Are customers to have access to all the objects, some of the objects, or some of the objects with a subset of the attributes?

Next, identify what your customers' needs are. With any luck, they will be similar, but even if the majority of your customers have the same set of needs, you can define and modify that set until you get it right, and then automate that process.

At this point, the discussion moves back into sites—specifically, exactly how replication takes place, what protocols are available, how should multiple sites be set up, and how to handle inevitable conflicts.

Also the Knowledge Consistency Checker will be covered. If you have, for example, 10 domain controllers in a site, and you make a change on one of them, should this domain controller tell every other domain controller, which are then going to tell every other domain controller, and so on?

You could end up with a lot of domain controllers trying to communicate information that the others already know about. The solution is Knowledge Consistency Checker, which builds a replication ring so that data will move more uniformly throughout your structure.

Keeping in mind the description of a site as being one or more well-connected IP subnets, consider this: Replication can be much more closely controlled from site to site than within a single site. What's more, you don't want a roaming user to log on from the domain controller in Europe if she's sitting in New York City. Sites let you give the user the IP addresses of the machines in her area that can service her requests.

Also, another thing that happens when you build that first domain controller is that the Default First Site Name is created so that you have a place to put the first domain controller. Other domain controllers, as they are built, will generally go here, too, and then later you can move them to other sites as you create them.

This diagram shows the various replication components:

• Server objects

• NTDS (Windows NT Directory Service) settings

• Connection objects

The Knowledge Consistency Checker keeps all these components straight so you don't have to.

There are two issues related to replication. The first was discussed earlier: If the change happens in one place, does it tell every other machine? The answer is no, because that's kind of silly. But the flip side is, when a change happens on one domain, how long should you wait until the last machine in the domain knows about it?

The recommendation is that the delay be no more than 15 minutes. The solution is to have the Consistency Checker build what's called a replication ring. When a change happens, the Knowledge Consistency Checker identifies two domain controllers in the vicinity for the first domain controller to contact. That first domain controller replicates to two other domain controllers, which then replicate to two other domain controllers, etc. You don't ever want a change to move more than three "hops" from domain controller to domain controller.

Picture the synchronization traffic moving in two directions around a ring. Once you have too many domain controllers in that ring, you will build cross-connectors to make sure that within a single site you have no more than a 15-minute lag between a change being made and every domain controller in the site knowing about it.

You can override the Knowledge Consistency Checker if you choose to. And you can specify certain machines that you want to know about changes immediately. You can also have the Knowledge Consistency Checker running, yet build manual links on top of that. In general, however, this tool should be able to handle replication all by itself.

It also monitors domain controllers as they come and go, so that when one replication partner drops offline, the Consistency Checker knows to rebuild the ring. Even so, because you may want to check on how the Knowledge Consistency Checker is running, you can use Site Manager to do this. The Resource Kit also includes a handy utility called Replimon, which lets you actually see the replication ring being built and the inner site connectors taking place.

You can expect to see three types of traffic in a Windows 2000 forest. And the three separate replication rings created to facilitate this traffic will share the same goal: no more than three hops until every machine that needs to know, knows. The three types of traffic are:

• Within a single domain, you will have domain controllers communicating because the database needs to be the same on every machine.

• Every Global Catalog throughout the forest needs to have exactly the same database, so they all need to communicate with each other. And they will build their own replication ring, which is not dependent on the domain that they're in, but rather dependent on the fact that they are Global Catalog servers. What's more, they build the ring differently according to whether it's within the same site or going out to another site.

• Infrastructure or trust traffic, which is the "glue" that holds the whole forest together.

This list encompasses just the schema, the domains that exist in the forest, and any type of trusts, either automatic or manually created, that exist within this forest. Therefore, if you see a machine talking to a machine in another domain, or you see something that doesn't look quite right, remember that there are three different types of traffic. It's not always going to be domain controller to domain controller within the same domain that you're looking at.

Microsoft recognizes that there is a trade-off between compression and processing power. So in writing Windows 2000, the developers defined "well-connected" not so much by the bandwidth inherent in a system, but by the site boundaries that you choose to set. Within that well-connected network, traffic compression doesn't matter much.

What does matter is the speed of data movement, because you need to minimize the time it takes a machine to process changes. Therefore, within a site, traffic is uncompressed, and urgent replication (e.g., the password was changed, a user logon failed three times, etc.) will happen between a domain controller and a PDC Emulator.

Other, less urgent changes (you create an object or you put a person into a new group) get moved within the site the next time the synchronization clock comes around. At this point, the domain controller looks in the change log, discovers changes, and notifies its replication partners. You start to see the data move across the domain.

As soon as replication goes outside of a single site, the amount of traffic being moved becomes more important than the processing power it takes to move it. Therefore, replication between sites switches from uncompressed traffic to compressed traffic—and Microsoft is reporting a phenomenal compression rate of about 85 percent.

In short, it requires more processing power to compress and then decompress the traffic, but the amount of traffic generated is much lower. And this gives you a lot more control over scheduling the replication between different sites.

Within a single site you are probably going to be using RPC (Remote Procedure Call) over IP, as the method of moving the data. Even between sites you will probably still use RPC over IP most of the time, which is all right because you have a good compression rate.

But if you are going between sites and you are also going between domains, you have the option of moving the data with SMTP (Simple Mail Transfer Protocol) instead of RPC (remote procedure call).

Most likely you will only want to use this method in the rather unusual case of having a link that is not only very slow link, but also very unreliable—the kind of link that RPC just doesn't handle that as well as SMTP.

Note: Keep in mind that if you choose SMTP, the replication must be between two separate domains. You cannot do SMTP traffic intersite within the same domain.

Once you build multiple sites, you need to start looking at site links. Another justification for creating sites is to allow users to authenticate locally and access resources locally. Sites also give you a handy way to monitor replication traffic, through site links. By default, as you build multiple sites, you will stay within a single default site link. Most companies choose to leave it set up this way.

The diagram shows three sites within the same site link. If you have three domain controllers in one site, two in another, and four in another, you don't want more than one domain controller communicating changes across that slow link. Rather than allow that to happen, the Knowledge Consistency Checker elects one of them to be a bridge head server. That server will collect all the changes from its site and then talk to the bridge head server at the next link, a process that will be repeated with the bridge head server at the next site. In this way, as changes happen, they get moved throughout the sites in a timely manner.

There's a possible problem inherent in this method, however. For example, if you define one site link to be four hours and another site link to be four hours, it takes eight hours plus any of the 15 minute intervals to get through each site. If you want to get around this delay, you can build a site link bridge.

In this way you can specify that if a change is made at site X, when site X tells site Y, it should go ahead and move it over to site Z also. So what you are doing is turning an eight-hour period into a four-hour period.

This approach does require more management than just putting your sites into the same site link and letting them replicate as changes happen. Therefore you should only consider this approach if you are dealing with some relatively slow, possibly unreliable links.

To make all this happen, you need to create another site in addition to the default for a site name. Remember that sites are associated with subnets. Therefore you will define the different subnets for the site where the machines are going to be. Then you need to move the server objects.

This section addresses Group Policy settings and the fact that Group Policy essentially becomes an object in its own right in Active Directory.

Note: Group Policy deals with configuration and has no relation to types of groups.

Group Policy enables you to affect the registry, set different options for security, install and remove software, publish updates, and handle a lot of other issues relating to centralized software distribution and management.

In addition, you can run scripts for logging on, startup, shutdown, and logging off. For example, you can write a script that cleans up a configuration during the log off process.

Group Policy also enables folder redirection. Imagine you want a user's folders to always be on the server, whether they choose to put them there or not. You can put their home directory on a server. Users will be saving to the server, and if you choose, you can bring the folder back down to their machine for offline viewing. This enables users to make changes when the machine is offline. When the machine comes back online, those changes will get copied back up to the server. And all of this will be transparent to the user. The folder redirection concept is part of the IntelliMirrorTM management technologies built into Windows 2000.

With Group Policy in Windows 2000, you are basically creating a Group Policy object that is usable anywhere in the forest. A Group Policy object is very much a "create once, use anywhere" type of entity, because you have the ability to create a set of group objects, store them centrally, and then apply policy to users or groups from your central store, as appropriate.

Order of Inheritance

This diagram shows the order of inheritance of Group Policy. Order of inheritance is expressed as the acronym SDOU, which stands for site, domain, organizational unit.

1. At the highest level, Group Policy can be applied to a site. When a user logs on, site-level policy is the first thing that's checked. Site-level policy can cause trouble for users if they move around geographically. For example, the desktop they get in New York may be different from their desktop in Paris, because when they logged on in the France site, a different policy was invoked.

2. The next level that's checked is domainwide policy.

3. And then the OUs and all their levels are checked for policy. If your OU structure is fewer than three OUs deep, and each one of those OUs has a policy applied to it, the user can expect to wait for all three of those policies to run before logon is completed.

Plus, if you apply scripts to all those policies, you'll actually see the three separate scripts run as they come down through the order of inheritance.

By default, policy is inherited from above, and the policy at the next level either aggregates or overwrites the inherited policy. If the domain policy says remove a desktop icon, and the OU policy says put it back, the user's ends up with the icon on the desktop because, basically, "The last one to run, wins."

Modifying the Inheritance

The order of inheritance default can be modified in two ways:

• Block Inheritance stops policies from rolling down to the subsequent levels.

• No Override is exactly the opposite. It prevents the child containers from overriding the policy of parent containers. The child containers can still add their own policy, but in the event of a conflict, the parent will win.

If both of these options are set, No Override is always going to win.

Group Policy and Site Issues

Although policies can be used anywhere, they exist within a single domain. If you write a policy in the domain called Front Row, which exists in the site called North America, and someone in the Europe site chooses to use that policy, the system will come back to North America to run it. While you can use a policy in other domains, the actual object does not cross domains.

Therefore, you'll want to be aware that if you assign Group Policy to a site, you might end up running a policy across a land link. Of course, unless you have a very specific reason to, you want to avoid associating Group Policy with a site, anyway.

This diagram shows the sequence of how Group Policy objects are processed.

When the user logs on, any associated site, domain, or organizational unit policies are run.

Group Policy refreshes every 90 minutes (give or take 30 minutes) thereafter. This automatic refreshing enables you to make changes to the policy and have them take effect quickly, without requiring users to log off, then log on again.

This graphic shows the basic steps you will take to create Group Policy objects:

1. Locate the domain, OU, etc., that you want to associate a Group Policy with, and open Properties.

2. Select the Group Policy tab.

This dialog box displays a list of Group Policies that can be associated with an individual organizational unit; in this graphic there are no associated policies.

If you click Add, you will be prompted to supply the Group Policy that you want to use. Also, there is a Group Policy snap-in for the Microsoft Management Console, which lets you look for all the Group Policies available and edit them.

At this point, you've created your Group Policy object and applied it. Unfortunately, you have a problem: You just set a domainwide policy that took the Run command away from all users, including the administrator—yourself.

Therefore, in addition to being able to create and apply the Group Policy, you can also go back later to define who uses it. Because this policy is now an object, you can handle it like any other object. You can modify the object's DACL to say that the policy doesn't apply to administrators. To make this modification, you can either leave administrators off the list, in which case it won't affect them, or you can specifically deny it, which prevents the policy from affecting them at this OU as well as any other place that the policy is applied.

Modifying Inheritance Options

The order in which policies run is very important because of the "last one wins" principle. That is, if the first policy says remove something, and the second policy says put it back, you're going to get it. If you are getting so detailed in specifying access that you are putting multiple policies into effect, you need to be very aware that you can change the order in which policies run, to ensure that users end up with what you want them to have.

Disabling Group Policy Objects

If you're not going to use pieces of a Group Policy, you can disable those pieces, or disable an entire Group Policy object from an OU. To illustrate, imagine that you created a policy in a test OU. You don't actually want the policy to affect users in that OU; you just wanted to create the policy so that you could apply it elsewhere. This feature lets you actually shut off the policy in the test OU without affecting the policy's effect elsewhere.

Modifying Inheritance Options

You can delete Group Policy objects, but once you do, you have to recreate them from scratch or reclaim them from backup if you want to put them back.

This table outlines all the options available to you for modifying security settings.

The concept of folder redirection was discussed earlier. This graphic shows the interface used to implement and configure folder redirection.

The guidelines for implementing Group Policy are very simple and common-sense:

• Limit the use of Block Inheritance and No Override. It may make sense to use Block Inheritance more—if you set a policy at the domain, you don't want OU administrators overriding that. But as a rule, the less you do it, the easier your policies will be to manage. On a similar note, be careful of Group Policies linked across domains, which might actually generate traffic across a WAN link.

• Limit the number of Group Policy objects.

• Get rid of unused portions. If you're not using portions of a Group Policy, disable them.

• Build Group Policy objects around certain functionality. For example, set one Group Policy object that controls what users see on the desktop. Another Group Policy object, called Scripting, for example, would contain logon scripts. By separating objects in this way, you can farm them out to different people to manage.

• Consider the performance issues raised by implementing Group Policy. Every time you run one, performance will take a little hit. That's just the nature of the beast.

The schema defines which classes of objects you can create and the attributes you can associate with those objects. For example, for the object called User, the properties associated with that object could include the name, fax number, e-mail address, etc. All these are defined in the schema.

When you install Windows 2000, you get the schema that comes out of the box. At some point, you will want to extend this. The ability to extend the schema is much more extensive than what you were allowed with the SAM database in Windows NT. For example, if you decide that your user object needs an attribute called spouse, you have the ability to add one.

Be aware that while extending the schema may make it slightly larger, it does not incrementally increase any database size. You're not storing objects here; you are only defining the types of objects that you can create. If you add a new object called router, that's just a little bump in a database. And you can build a million routers with that new object, but the database doesn't really get any bigger.

It's also very important to keep in mind that schema extension is not something to be afraid of. Many customers are very concerned about extending the schema improperly or think that it's too dangerous. Clearly, these fears are unfounded. Extending the schema is not only something that you're going to have to do, but also something that you're going to want to do. Just understand the ramifications, conduct it conscientiously, and realize that it's inevitable.

There is one schema for the entire forest. If you have different customers existing within the same forest, and one of them has a need that is going to force a schema extension, the object class created for that one customer will become available to everybody. This really isn't a major issue; just because the other customers have the new capability doesn't mean they have to use it.

Neither does this kind of extension imply any extra security issues; it just means the extension is forest wide. So you add an attribute, you add a new object class, figure everyone in the forest is going to have the ability to build that.

Like everything else in Active Directory, the schema basically becomes a set of objects stored in Ntds.dlt.

The default schema is created on the very first domain controller you create.

This diagram shows the required schema attributes. In addition, there are several dozen optional attributes. The right side illustrates that to create new objects is very common; to extend the schema is relatively rare.

Extending the schema generally involves introducing a new product, a new application, a piece of hardware, and so on. Modifications to the schema happen when you:

• Decide to use Active Directory to create, modify, or deactivate classes or attributes manually.

• Write scripts that will automate the process of modifying the schema.

• Just purchased hardware or software that requires schema extensions.

There are a handful of reasons why you would modify the schema:

• You don't have a class of object that meets you needs, so you need to create a new class.

• You have a class, but it does not have the attributes that you need. Therefore, you need to create a new attribute for an existing class.

• You need to disable an existing object or attribute. While you cannot back out of a schema change, you can disable objects or attributes you no longer need. Disabling an object or attribute does not remove it from the database, but it does mean that you cannot create any more objects with it. The ones that already exist will certainly be there until you choose to delete them and make them go away.

The left side of the diagram shows the different classes, while the right side shows the list of attributes stored separately. Logically what you have on the left is all the different objects you can create; on the right, you have all the different attributes that you might ever need. Then you just start to associate. So when you create, for example, the class User, you then associate with it the two dozen attributes it needs. Now those attributes can be linked to other places, as well—in fact, you can reuse them wherever you need to.

You can define classes and child classes to take advantage of the default inheritance property of the schema. The diagram demonstrates that rather than create a new object at the top level, and then reassign all the attributes, you can just create a subclass. All the attributes assigned to the user object will flow down, plus you have the ability to add any extra attributes at this lower level that you choose to. Taking this one step further, you can create a sub-sub-class, so to speak, and again add the attributes that are specific to that object class.

For the most part, you'll want to base your decision about where in the hierarchy to create a new object on whether an object already exists that meets most of you needs. If so, think about bringing the new attribute in as a child underneath the existing object.

As for the unique identifier, your job will be to keep the back part of that number unique throughout your organization.

If you decide to change the schema, the first thing you need to do is install the snap-in to the Microsoft Management Console. Second, you need to make sure that, as the person extending the schema, you are in the Schema Admins group. The Schema Admins group is a special group that exists only in the root domain. Make sure you limit the membership to it.

Finally, by default, the write access on the Schema Operations Master is not enabled. So you need to go in and check a box to make the Schema Operations Master editable, or "writable." Once you do, you are ready to make modifications.

This dialog box controls indexing and replicating. As was discussed earlier, you need to define the things that are going to be in the indexes and the Global Catalogs.

Finally, if you decide that you won't ever need to make any more objects of a particular class, you may as well deactivate that class. You're not deleting it, nor are you deleting anything that's ever been created with it. You're just turning it off.

Deactivating a class is easily reversible. You can always turn it back on later if you find that you need to create those objects again.

Essentially, what you need to develop a schema modification policy is a little bit of planning, a little bit of preparation, and thinking it all out up front.

It is recommended that someone present the validation and justification of the policy to the people that run the forest.