Naming Standards

Before you begin to design anything, you need to make sure that you have a naming standard for everything across your entire organization. If this is missing, and everyone just decides what to name the GPO and computers, how usernames are formatted, how service accounts are named, etc., then you will never have a proper structure.

Group Policy Naming

A common thing for administrators to do is name group policies after what they see as the most logical thing at that moment. You should have clear guidelines of how to name GPO's so that they make sense even to a new person. "Internet Explorer Test 3" as a GPO name is not anything that you could guess what it includes, or to whom it applies. Naming conventions are overlooked a lot of the time, not only for GPOs but for many administrative things that do not seem to matter at the time. In short, the naming of the GPO is important so that you can immediately know what the policy does and who it applies to. This makes troubleshooting much easier. The following figure shows GPOs named with a little bit more sense, as it shows that the policy is global and that the settings that these policies set are for users and computers.

Design with Scalability in Mind

Whenever you read books or white papers about Active Directory, they mention the amazing scalability of Active Directory, its security features, and the redundancy. Active Directory was coded from the ground up with mechanisms that make it easy to add or remove domain controllers. With this ability, features are built in to failover to the next domain controller in case of a failure in one of them. The client never really knows about this.

On paper, this is a great thing and reduces the administrative overhead. In practice, it is just as good. Large corporations can have Active Directory structures that work so perfectly that the administrators really do not have to worry about anything regarding stability. This applies even when there are more then 30,000 users over several countries and almost twice as many computer accounts. As the saying goes: "Behind every strong man stands a strong woman". The same goes for Active Directory: "Behind every perfectly working Active Directory, there is a good architect".

Microsoft's recommendation is to have 150 users per domain controller. This is a good recommendation yet you do not need to take it 100% verbatim. In any site with 150-200 users, you should have at least two domain controllers. This is not meant as an issue of scalability but more of a failover issue. In a case of 400 users for example, Microsoft recommends, according to their white paper, three domain controllers. For 400 users in a single site that is a lot. Considering that the heavy load on the domain controllers will be in the morning when people arrive and log in, and after lunch when people log in again, most of the time the domain controllers will sit idle. In this case, the recommendation is rather to spend a bit extra on more RAM and more CPU power than on an extra machine.

If your network is well-designed and your domain controllers have a little more power, you can load a relatively large number of users onto them. It is not unheard of to have over 600 users per domain controller in a large organization and the average load during the day is around 40%. It rises during peak hours of logon and logoff, as is expected, but quite a lot of time they are almost idle.

The key factor here is memory and CPU. If the amount of RAM you have is twice the size of your Active Directory database, the database will be loaded completely into memory by the domain controller. This, combined with a server-class CPU such as XEON or Opteron, will reduce the processing time during authentication per user to fractions of a second. If you could only authenticate five people per second on a domain controller, it would take you two minutes to authenticate 600 users. And 600 users do not all arrive at work at the same time and log in at the exact same time.

Scalability in Active Directory is achieved through the distributed model that it builds on. Every domain controller is writable in the AD and holds more-or-less a complete copy of the directory. When changes occur in one site on one DC, these changes are then replicated out to all the others. This architecture is radically different from Windows NT 4, where there was a primary domain controller and many backup domain controllers.

There is only one problem with this set-up, and this becomes apparent when you have a lot of distributed domain controllers and a lot of sites. If you do not invest time into the design of the sites and site links, you can cause a lot of damage and a lot of unnecessary traffic in a very short time. Site links are there to provide ways of controlling when and how the Active Directory is replicated to other domain controllers. You do not want to end up replicating a 2GB database during business hours over a 2 Mbit link. However, if you do not properly document and implement a good replication design, unnecessary delays will happen. You will then have the nice job of finding out where the replication went wrong, and depending on the number of sites you have, this can be a non-trivial task. The following figure shows different replication schedules and site links that make it quite normal for one site to have a six to eight hour delayed version of the Active Directory.

Replication schedules are not difficult to design and implement, but do require a bit of time and input from other sources. Remember, because Active Directory is so distributed, the site with the slowest site link and the slowest replication will have the most outdated version of Active Directory. It is recommended that in case something unexpected happens, such as dismissing an employee in a remote office, you force-replicate between the main site and that site-as soon as the changes are made. If the person is leaving in two week's time, set his or her account on the date they are scheduled to leave and then verify that the data has been replicated after this date.

Flexible Single Master Operation Roles (FSMO)

When you design your topology, you have to be aware of the Flexible Single Master Operation Roles (FSMO) and place them accordingly.

FSMO roles are roles that only one server in an Active Directory can have. These roles, while not apparent immediately and not needed all the time, are very important, and some of them are very crucial.

There are five FSMO roles and they must be present in an Active Directory. Three of these roles are domain-specific, which means that in every domain in an AD forest, they have to be present. The other two are forest-specific and therefore one of each needs to be present in each of your AD forests. See the table below for a few summary of roles and where they belong:

Each role does different things and in order to understand the importance of the roles, a full description of each role, and the steps you need to take to see which server has what role, is given below:

Relative ID Master (RID Master)

This role allocates security RIDs to DCs within a domain. The DCs use the allocated RIDs and in turn allocate them to security principals, such as users and computers, as they are added. The server that has this role also manages the movement of objects between domains. It monitors all of the pools allocated to all of the DCs within a domain and in doing so allocates more RIDs where needed, to prevent these pools from becoming exhausted, which would result in the inability to create new user or computer accounts.

Infrastructure Manager

The server having this role maintains security Globally Unique Identifiers (GUIDs) and Distinguished Names (DNs) for all objects that are referenced across different domains. However, its most common task is to update user and group links.

PDC Emulator

This is a crucial role, not only because it emulates a Primary Domain Controller for Windows NT, but because other DCs look at the PDC as the primary source for confirmation of authentication, and it is the most trusted source for time within a domain.

To change any of the three domain-specific roles, open Active Directory Users and Computers, right-click on the domain name and click on Operations Masters. You will then get the following screen where you can assign the roles in your domain.

Schema Master

The server having this role maintains all schema information and all modifications to the schema. The schema in a forest determines what types of objects are permitted and what types of attributes an object can have. A typical scenario for this role would be an installation or deployment of Exchange, or an upgrade from Windows 2000 to 2003, because these operations contain schema modifications.

Domain Naming Master

The server having this role follows all of the names of the domains in a forest. This role is needed in order to add or remove domains.

To change the Domain Name Master, open Active Directory Domains and Trusts, right-click on Active Directory Domains and Trusts and then click on Operations Master. On the resulting screen, you can change the Domain Naming Master.

There are generally three rules for how to place these roles within an AD (outlined in http://support.microsoft.com/kb/223346), in order to make administration and maintenance easier.

1. In a forest, the Schema and Domain Naming Master should be placed in the same DC.
2. The Infrastructure Master should be placed in a DC that does not hold a Global Catalog or, if every DC holds a Global Catalog, it can be placed on any DC.
3. The RID Master and PDC Emulator should reside on the same DC, which should have quite good hardware. If the load on this server calls for a separation, make sure that these two roles are located on DCs that are direct replication partners of each other in the same site.

Placement and maintenance of these roles is very important, and the next table shows each of the five FSMO roles and the consequence of a failure of these roles.

Name of Role	Consequence of failure
Schema Master	No updates to the Active Directory schema will be possible. Since schema updates are rare (usually done by certain applications or possibly an administrator adding an attribute to an object), a malfunction of the server holding the Schema Master role will not pose a critical problem in the short term.
Domain Naming Master	The Domain Naming Master must be available when adding to or removing a domain from the forest (i.e. running DCPROMO). If it is not, then the domain cannot be added or removed. It is also needed when promoting or demoting a server to or from a Domain Controller. Like the Schema Master, this functionality is only used on occasion and is not critical unless you are modifying your domain or forest structure.
PDC Emulator	The server holding the PDC Emulator role will cause the most problems if it is unavailable. This would be most noticeable in a mixed mode domain where you are still running NT 4 BDCs and if you are using downlevel clients (NT and Win9x). Since the PDC Emulator acts as a NT 4 PDC, any actions that depend on the PDC would be affected (User Manager for Domains, Server Manager, changing passwords, browsing, and BDC replication). In a native-mode domain, the failure of the PDC Emulator isn't as critical because other domain controllers can assume most of the responsibilities of the PDC Emulator.
RID Master	The RID Master provides RIDs for security principles (users, groups, computer accounts). The failure of this FSMO server would have little impact unless you are adding a very large number of users or groups. Each DC in the domain has a pool of RIDs already, and a problem would occur only if the DC to which you are adding the users/groups on runs out of RIDs.
Infrastructure Master	This FSMO server is only relevant in a multi-domain environment. If you only have one domain, the Infrastructure Master is irrelevant. Failure of this server in a multi-domain environment would be a problem if you are trying to add objects from one domain to another.

The other thing to consider is, of course, the future of the company and its strategy. If your business is in an industry or sector where fast organizational change, such as mergers or acquisitions, is quite possible or even likely, then you should adopt a design that will allow you to incorporate newcomers whilst maintaining the security of your own infrastructure.

The basic motto to follow when designing your Active Directory is to think of the future and not of the present.

Migration from Other Authentication Services

Even though the time of Windows NT 4 is long gone, a lot of companies still have NT 4 domains running and are only now planning to migrate them to Active Directory. When you migrate from other domains, there is nothing more frustrating than installing a domain controller and, when prompted for the future NetBIOS name, it tells you that this name is already used in the network.

You have to do your research beforehand and make a decision as to what name to take. Then, scan your network and make sure no-one is using that name for some purpose at the time of installation. If your organization decides to use something that is already in use on the network, find out who is using it and explain to them that they have to change it due to company policy or, if it is used without authorization, have them remove it. Do not do this without proper approval from higher management.

Migration into Active Directory is, with the tools provided by Microsoft, not really a difficult task any more. The main issues you will face aren't the users and the fact that their logins might not work-this can be fixed fairly quickly by your helpdesk. The real challenge comes with applications that run on Service Accounts or authenticate against specific servers. Suppose NailCorp's accounting software is installed on a server and no one knows how it works any more, or the person who does know is unavailable. Suppose documentation, as it is often the case, is virtually non-existent. Then the machine is migrated to the new domain and the application stops working. After the migration is complete, the old domain controllers are turned off. As it happens, all of this was done during a weekend and the old machines have been removed and placed onto trolleys to be decommissioned or recycled. When the mistake eventually surfaces, things can become quite hectic in trying to get the application running again.

The key point in making a smooth migration is to properly plan it. This is especially true when you have a completely re-designed and very organized OU structure. Once you have policies in place, you don't want to migrate the wrong users or the wrong computers into the wrong OU.