The one thing to keep in mind is that when designing your Active Directory, never go at it from a, present needs, point of view. Technology and systems are changing so fast nowadays that you have to design with the most open and future-proof concept that you can think of.
It was only a few years back when Windows 95 revolutionized the personal computing platform by pushing 32-bit addressing to the mainstream. Before that it was 14 years where everyone ran 16-bit programs on 16- or 32-bit processors. In April 2003, Microsoft launched the 64-bit version of its Server Operating System and in April 2005, the 64-bit version of its Desktop Operating System, Windows XP. These are less then a decade after the big Windows 95 push. Active Directory was introduced with Windows 2000, which is only Five years after Windows NT 4's "enhanced omain structure".
The trend is that new features and new technologies are constantly being invented and introduced. While there are quite a few companies that have a proper open and flexible design in their Active Directory structures, there are a lot more organizations that see Active Directory as the answer to all their prayers and just keep adding things to it and to the schema. To read more about the technical aspects of the AD schema, please refer to http://msdn2.microsoft.com/en-us/library/ms675085.aspx.
Software companies nowadays are pushing "Active Directory compatible" features more and more, and problems can arise when these packages need complete domain administrator rights in order to function (or modify the Active Directories' inner workings), which they usually do not advertise up-front.
The need for proper planning and design of the AD is extremely high in order to ensure that your DR strategies will work and are easy to implement. A properly designed AD is extremely resilient and still very flexible.
Whenever you intend to add new services, make sure that you test and re-test the things that are necessary for the service to function properly. As the IT department, you are responsible to keep the systems going and ensure business continuity.
Active Directory elements
When designing an Active Directory, you need to be completely clear of what each element or part actually means and how it fits into the overall design. The old saying goes: You can't see the forest because of the trees, and you can apply this to Active Directory as well. It is all about trees and forests and leaves and branches.
The Active Directory forest
The forest, in terms of Active Directory, basically means every domain, organizational unit, and any other object stored within its database. The forest is the absolute top level of your Active Directory infrastructure. Of course, you can have more than one forest in a company, which actually represent security boundaries, and can therefore improve security between different business units or companies belonging to a single organization. The point behind the forest is that you have all your domains and domain tree within your organization contained within it. It is designed so that you can have transitive trust-links between all of the trees within one forest.
To read more about the technical layout of AD, please read Domains and Forests Technical Reference at: http://technet2.microsoft.com/windowsserver/en/library/16a2bdb3-d0a3-4435-95fd-50116e300c571033.mspx.
To visualize a forest with its parts, please see the following image.
The Active Directory tree
A tree in Active Directory refers to a domain and all of its objects that adhere to a single DNS name. For example, a tree of nailcorp.com would contain all other domains that end with "nailcorp.com". So, americas.nailcorp.com, europe.nailcorp.com, and asia.nailcorp.com all belong to the Active Directory tree of nailcorp.com. You cannot separate these unless you create a whole new forest for a sub-domain.
Organizational Units and Leaf Objects
In Active Directory, Organizational Units (OU), which are also called Containers, and Leaf Objects, which are non-containing objects such as computer accounts and user accounts, are directly related and even though you could have objects that do not belong to an OU, it isn't recommended and isn't really feasible.
Organizational Units are comparable to folders in a filing cabinet, and objects are the files. You can move files between different folders, and classifications or properties are applied to the files within a folder. For example, if you move a file into a folder classified "Top Secret", the file will automatically fall under that classification. The same applies to objects within an OU, all properties or rules that apply to the OU apply to the objects within it. OUs, however, are mostly useful from an administrative point of view, not from an user's point of view. If you think of how your files are organized, for example, on your computer, they are most likely to be organized into different folders. You can go ahead and set different folder settings, such as permissions, and it will affect all of the files within that folder, but anything outside that folder won't have its permission affected. It is exactly the same principle with OUs. Any OU that will be created within an OU will contain all of the policy settings of the parent unless you change them. An object can also only belong to a single OU, just as a single file can only be contained within a single folder.
Leaf objects in Active Directory can be users, contacts, and computers. Or in short, any object that cannot contain other objects. They are called leaf objects because they are like leaves on a tree. And, as you can guess, they are the "lowest" class of objects within Active Directory. But if you now look at the forest-tree-branch-leaf concept, it is starting to make sense.
You can access the OUs and other objects through the Microsoft Management Console (MMC) or through the Users and Computers tool in the Administrative Tools. This second option actually just invokes the MMC with the correct view and is a lot quicker, as seen in the following screenshot:
Active Directory Sites
The Sites and Services MMC snap-in is a utility that a lot of Windows administrators, particularly in smaller organizations, completely overlook. This part of Active Directory, however, is one of the most crucial parts to understand and implement correctly.
If you have several locations in your organization, you need to know about Active Directory Sites. Sites give you a very unique and well-designed approach to separate specific locations within your Active Directory. As the principle of an Active Directory domain is global-meaning that it is meant to be the same anywhere-it could present a problem for users who move from office to office, or for offices with network connections that are slow. Active Directory sites allow you to specify the IP address spaces or subnets used within your organization and, therefore, bring the structure of your network into Active Directory. The usefulness of having properly organized and maintained Sites becomes more evident when you consider that any machine within an address space will use that Sites' DC to authenticate. This is a great feature of AD and reduces unnecessary traffic. However, it requires having Sites and subnets properly updated and maintained. This is also particularly useful for defining different replication schedules for different locations within the same domain, and also to support users who travel. Once they log on through the other location, they are assigned an IP address from that network. The Windows locator service will then look up which DC is the nearest one, and the user won't log on all the way to their usual DC (to read more about how the locator service works please refer to http://support.microsoft.com/kb/314861). This saves bandwidth and speeds up the authentication process.
Bandwidth nowadays is cheap, especially in developed countries such as the USA or most parts of Western Europe. But just because it is cheap in some parts, does not mean it is cheap in other parts of your organization. If you are primarily located within developed countries, but your then company decides to open 10 or 20 small sales offices within not-so-developed countries, where bandwidth is expensive, then you really need to start using AD sites. Of course, the problem then is that because you haven't used AD sites before, you need to make the appropriate changes to your infrastructure to accommodate them, and train staff appropriately in order to be able to implement, support, and manage them.
In this example, the argument might be brought up that each of these small branch offices has a local DC that also functions as a File and Print server where the local employees collaborate. This is great, but what about replication to and from your Hub site? Which is the data centre that hosts a critical part of your Active Directory backend? If changes to your AD are fairly frequent, for example, adding and removing users on a regular basis, then the Active Directory will replicate—if the Site links are properly configured—without compression every 15 minutes. Of course, depending on the size of your organization, this can be quite a strain on the link you have from that office. If the people at that office receive email and browse the Web over the same link, network performance will degrade significantly for users and cause unnecessary inconvenience.
To see what Sites look like in the Active Directory Sites and Services console, see the following screenshot:
Group Policy Objects
Group Policy Objects in Active Directory are a set of defined rules for settings about the user environment or the operating environment for a particular PC. They are treated as standalone objects because they can be linked to different OUs. This gives you the flexibility of creating one set of rules and applying it to different OUs in different OU structures, making settings deployment much easier and administratively quick.
The policy settings are quite extensive and if you want to get your hands dirty, you can create your own policy templates, giving you even more control over the machines and application settings located in your domain.
There are templates available for many settings, ready to use. The templates for these settings are called ADM templates and there are quite a few already included in the Windows 2003 installation. Some applications, such as Microsoft Office 2007, also provide ADM templates that can be loaded and modified (see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=92d8519a-e143-4aee-8f7a-e4bbaeba13e7 for Office 2007 ADM templates). Using ADM templates, you do not need to write anything by yourself, and so it is a quicker way apply to GPO settings. The following screenshot shows Office 2007 ADM templates loaded in the Group Policy Editor.
Domain Design: Single Forest, Single Domain, and Star Shaped
A domain is not a security boundary within a forest. By default, all domains have transitive trust relationships within a forest and are therefore visible to each other. On top of that, all Global Catalogs contain the Security database and a rogue administrator can potentially gain access to different domains or even the entire forest. Please see http://www.microsoft.com/technet/security/bulletin/MS02-001.mspx for more details on such vulnerability. Even though this particular vulnerability no longer exists within Windows 2003, something causing similar effects can be a possibility.
This is the most common design version for small-and medium-size businesses, that have offices within one country or that are geographically close. It involves a single hub site and several small sites. A hub site is defined as a big data center where the majority of your infrastructure is housed. So if you have the headquarters and development for nailcorp.com taking place in Los Angeles where 40 servers are housed in a datacenter and 900 people work, then that would be a hub site. In short, a hub site is a location where a large part of your crucial infrastructure operates.
From the hub site, all changes are replicated out to smaller sites, which can be small branch offices, small development locations, or pretty much any office that warrants its own domain controller. This puts control firmly into the one major hub site and all the branch sites just replicate with that. The advantage of this set-up is that you can push out a forced replication to all branch sites at once (provided your bandwidth supports this) and do not have to wait for any delayed replication schedules due to time zones and so on. The drawback is that if you do have a problem, due to human error, for example, and this gets replicated, everyone gets it at once. If, for example, an administrator at NailCorp deletes or renames by accident a service account that is used by a certain service throughout the organization, and he does not notice it, then after the next replication the service stops working. If the replication was star shaped and went to everywhere at the same time, the service stops everywhere at the same time. If the service is something that does not get recognized immediately, such as an antivirus policy update or some automatic update service from a third-party application, this failure will not get noticed immediately and the service will stop and won't restart because it will be a logon failure. In this scenario, NailCorp could go on for days without anyone noticing.
As you can see in the following figure, in this design NailCorp would have a single hub site and three branch sites. Each site would have its own IP address range and would have, within Active Directory, its own site with DCs located inside it.
In this case, we only have a single forest and a single domain with different sites, but even in these sites all objects belong to the same forest and hence the same domain.
Domain Design: Single Forest, Single Domain, Empty Root, Star Shaped
Even though this architecture is no longer recommended, there are still quite a lot of companies that either use it or implement it. This is almost the same design as the previous one, except that it includes an empty root domain. Basically, it implies that the root of your forest is empty, meaning that there will be no computer accounts and no user accounts other than the Enterprise Administrators located in this domain. Within AD, a domain is not a security boundary. A forest, however is, so a multi-forest architecture would provide more security. An empty root domain has good and not-so-good points. The point is that this is a fairly safe design, which still adds layers of security. The other domain under the root domain - the child domain-will contain all of the user and computer accounts. This setup is beneficial from a security perspective in that the Enterprise and Schema Administrators groups are isolated from the other users and administrators. With this design, a few administrators can be selected to control the Enterprise and Schema Administrator groups, and all the other administrators reside in the child domains, configured to be Domain Administrators.
This will add a proper layer of security to the whole structure and will allow an easier structural change, should:
- New companies be acquired and need transitional access, or
- A separate AD be required for special access etc.
There has been some controversy about the necessity of an empty root domain. When Windows 2000 came out, the empty root was all the rage and everyone was doing it.
Domain Design: Multi-Domain Forest
This design is used a lot in larger corporations and companies that do a lot of Quality Assurance testing for software, or software development. It has a forest and multiple trees under this. This is also very good if your company has expanded a lot through acquisitions and you need to ensure that the acquired companies can access cross-domain files.
This design approach needs to be designed from the beginning because you cannot create a new forest on top of an existing one. Windows 2003, however, makes moving domain information and migrating between two Active Directories easier, with the tools that it provides.
Domain Design: Multi-Forest
This design, while administratively more complex, provides the best security. It also raises support costs and makes collaboration a little more difficult, but it definitely has its benefits. This design will have standalone forests for all of the business units or departments. This also means that by default they cannot see or access each other. Administrators then create trust relationships between the different domains that are within the forests. This will give the granularity needed. To visually understand this, please see the following image:
LRS—Lag Replication Site
These sites are also often called RLS (Replication Lag Site), DRS (Delayed Replication Site), and just plain lag site. Officially, there really isn't a "correct" name as Microsoft and AD experts have referred to this concept in all four ways.
A lag site is a site in your AD that will contain at least one DC. This site is configured so that the replication only happens at a delayed schedule compared to all the other sites. This can be anything from one day to one week.
The purpose of lag sites is primarily to restore deleted objects quickly without having to go through the process of authoritative restores or even start working with tapes. If something gets inadvertently deleted, all that is needed is a replication in the opposite direction, from the lag site to the production DCs, and the deleted data is recovered. It is a clean, fast, and efficient way to recovery.
The other feature that is a natural by-product of a lag site, and used by quite a few organizations, is that in case of a disaster, it becomes easier, cleaner, and faster to recover a part of or your complete infrastructure. As lag sites are not used for authentication by users and DNS registration is disabled, they are considered stealth sites because they are not usable by any service or user.
Active Directory, as we have established, is a very complex infrastructure. There are a multitude of things that can go wrong at any given time, and human error, while the most common cause, is also the worst of the things that can happen if the changes are replicated out. Best practices generally include separating one or even two domain controllers per domain in your datacenter or somewhere else. (Create it in a new site in your Active Directory and make the link cost the highest possible. That means that it will only replicate the data with the main Active Directory once a week and the rest of the time just sit there. You can even design it so that there is no active replication going on by putting a firewall in front of the site and denying the traffic.)
Of course, you will get replication errors, but at least you have a working Active Directory in any event. If your infrastructure fails, all you need to do is complete an authoritative restore from the lag site, and activate the network link, meaning dropping the firewall if you have one, and promote or seize the roles of the domain controllers in the lag site. You will generally have a working infrastructure and since the lag site has an authoritative restore, all other DCs will replicate from it.
There are different approaches to lag sites. If you want to keep your Active Directory even more redundant and safer, you should definitely consider establishing a lag site.
In this article, we went through some of the key elements in Active Directory. A few design models were dissected, and this should give you a good starting point for your own design. In the next part, we will cover designing your Active Directory and keeping it up-to-date.