Design your Active Directory
In most corporations and large organizations, there are people with job titles such as “Network Architect”, “Windows Server Configuration Owner” or “Network Designer”. These people do not have these titles just for fun. In large organizations, there is an actual need for people whose sole purpose is to design or optimize the networking topology according to how technology progresses. This is also valid for people who work in the Security and the actual Business Solutions sections of large corporations.
There are always new ways of doing things and new designs surfacing in the IT world, and those people need to stay on top of their respective fields. If you are a medium to small-sized company, you can probably combine all of those roles into one person or have several roles distributed over few people.
This is especially true for Windows Server architecture and Active Directory. When designing your Active Directory, you need to really open your mind and focus on the future. A bit of clairvoyance doesn’t hurt here. The problem with an Active Directory design for a medium to large-sized company is actually two-fold. One, you need to be able to make your design scalable in the future and two, you need to be able to migrate to your new architecture with the least user impact.
In order to make this a bit easier, here are two small checklists. The first one contains things to consider when designing a global AD, and the second one is a checklist of things to consider when finalizing the design, or when migrating. These points are not in any particular order as they should all be considered.
Checklist When Designing a New AD
- Is the name future-proof (DNS)? Do you own the DNS name?
- How many users are in each office?
- What’s the bandwidth available between offices?
- Is it enough for smaller offices to authenticate in a central location?
- Who will administer the AD?
- Who will perform day-to-day tasks (password resets, user and computer account creation)?
- Are there plans to build on the AD with additional services, such as Exchange, SharePoint etc.?
- Which DCs will be Global Catalog Servers?
- Where will the FSMO roles be located?
- Will the new design support all the current business functions?
- If not at the beginning, will there be a transition period and if so how long?
- Have you cleared this with business?
- Will all the third-party applications still work with this design?
Checklist When Finalizing the Design or When Migrating to an AD
- Have you chosen a design?
- If yes, have you considered the model carefully, taking into account future growth?
- Is the DNS name available and is it future-proof?
- Have you calculated the appropriate number of DCs?
- Have you considered DC failover and the network strain?
- Is the number of administrators and their roles clearly defined?
- Do you have processes for change mangement in place?
- If no, should you?
- Do you have back-up designs and solutions in place where it matters (hub sites and data centers)?
- Is your staff trained or will there be training to bring them up-to-date with the new methodologies?
- How significant will the user impact be?
- Are mechanisms in place to inform the users of the coming changes?
- Are all networked applications accounted for?
- Have service accounts been assigned and possibly consolidated across the enterprise?
- Is a realistic implementation schedule in place?
- Has it been approved and discussed?
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.
Username and service account naming
There are endless ways of naming your user accounts and you probably already have one or another in place. If, however, you have a multitude of different ways because of acquisition, or autonomy of certain offices in the past, defining a universal way of naming user accounts is crucial. This will not only help you with administration, but also with deploying services across your organization. If you name the service accounts using a standard, every administrator knows exactly what the account is for. When you name the users in a standard way, processes regarding user administration can be very streamlined. You should also consider the lockdown of service accounts, for example by defining what machine they can authenticate from and what they can access. The same goes for user accounts.
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:
Name of the role
Where is it needed
RID Master (Relative ID Master)
In each domain
In each domain
In each domain
In each forest
Domain name Master
In each forest
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.
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.
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.
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.