Active Directory Forest and Domain Design
Active Directory Forest
Forest is a complete instance of Active Directory. Each forest acts as a top-level container in that it houses all domain containers for that particular Active Directory instance. A forest can contain one or more domain container objects, all of which share a common logical structure, global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. The first domain in the forest is called the forest root domain. The name of that domain refers to the forest, such as techtutsonline.local. By default, information in Active Directory is shared only within the forest. In this way, the forest is a security boundary for the information that is contained in that instance of Active Directory.
Active Directory Domain
Domain is container object. Domain is a collection of administratively defined objects that share a common directory database, security policies, and trust relationships with other domains. In this way, each domain is an administrative boundary for objects. A single domain can span multiple physical locations or sites and can contain millions of objects.
Active Directory Domain Tree
Domain tree is collections of domains that are grouped together in hierarchical structures. When you add a domain to a tree, it becomes a child of the tree root domain. The domain to which a child domain is attached is called the parent domain.
A child domain might in turn have its own child domain. The name of a child domain is combined with the name of its parent domain to form its own unique Domain Name System (DNS) name such as chd.techtutsonline.local. In this manner, a tree has a contiguous namespace.
Active Directory Site
Site is a leaf and container object. The site container is the topmost object in the hierarchy of objects that are used to manage and implement Active Directory replication. The site container stores the hierarchy of objects that are used by the Knowledge Consistency Checker (KCC) to effect the replication topology. Some of the objects located in the site container include NTDS Site Settings objects, subnet objects, connection objects, server objects, and site objects (one site object for each site in the forest). The hierarchy is displayed as the contents of the Site container, which is a child of the Configuration container.
Organizational unit (OU) is a container object. You use OU to arrange other objects in a manner that supports your administrative purposes. By arranging objects in organizational units, you make it easier to locate and manage them. You can also delegate the authority to manage an organizational unit. Organizational units can be nested in other organizational units.
You can arrange objects that have similar administrative and security requirements into organizational units. Organizational units provide multiple levels of administrative authority, so that you can apply Group Policy settings and delegate administrative control. This delegation simplifies the task of managing these objects and enables you to structure Active Directory to fit your organization’s requirements.
AD DS Forest Design Criteria
AD DS design requires both technical expertise and organizational acceptance. Forest design should be your first architectural element when designing AD DS. A forest is a single instance of AD DS, and is the topmost container in AD DS. It is scalable beyond 5,000 domain controllers, 5,000 sites, and millions of users, according to Microsoft’s Branch Office Deployment Guide. Even the largest organizations should be able to contain all of the necessary objects within a single forest. You will find that other considerations will come into play when developing your design. Legislative, political, or organizational reasons may force you to move to a multiple-forest design, but make sure there is a valid reason to do so.
Although a forest is almost insanely easy to build, it is far, far more complex to design. Several options are available, and you need to know what roles forests and domains play within your organization.
A forest shares a single schema, which can be defined as the rules of what can go into a directory service. AD DS is made up of objects, which are instances of an object class that have been defined by combining attributes to form what can be allowed within the directory. These rules also define where objects can be created and used within the directory service. Because all of the objects within the forest have to follow the same rules, there can be only one schema per forest.
Because of the important nature of the schema, you should not take its existence lightly. Although you may not have to think about it on a daily basis, you will need to make sure that you do not allow just anyone to have access to the schema. If changes are enacted within the schema, the results could be disastrous. Your organization may be one of the lucky ones that never have to modify their schema, but very few organizations are so fortunate. Many organizations will modify their default schema so that it will support directory-enabled applications. A common situation is the need to implement Microsoft Exchange. Microsoft Exchange requires the Schema to be modified.
Keep your Schema Admins group empty until you are required to make a change to the Active Directory schema. By default, the Administrator account is defined as a Schema Admin. This is the account that you used to install AD DS when you first configured your forest. This account is also listed as an Enterprise Admin.
If you remove this account from the Schema Admins group, an Enterprise Admin can add it back into the group when needed.
The rules have changed since Windows NT 4. Under NT, the domain was the security boundary. If you were a member of the Domain Admins group, you had full control of your domain and you were isolated from Domain Admins from other domains. Now with AD DS, the forest is the security boundary—not the domain. Any Domain Admin on any domain controller throughout the forest can bring down the entire AD forest—either on purpose or by mistake. There are, unfortunately, some simple ways to do this:
- Impersonate any user in the forest (in any domain).
- Read, change, or delete any Windows-secured resource or configuration setting on any machine (especially domain controllers) in the forest. FSMO roles are an even higher risk because the FSMO roles are, by nature, a single point of failure.
- Modify service accounts that run in the system context.
- Run code in the system context.
- Hide domain administrator–equivalent accounts for later use.
- Cause changes to replicate to other domain controllers. This is not a problem with database corruption, but it is for a denial-of-service (DoS) attack, which would be easy with a simple script that added users endlessly.
- Take ownership of files, folders, objects, attributes, and, thereby, breach privacy.
These are just a few of the many ways to bring down the AD forest. Granted, being a member of the Domain Admins group from the forest root makes it easier to carry out some of these attacks, but having Domain Admin membership anywhere within the forest could be a potential risk if the user who is granted that level of control is not trustworthy.
When you are creating your AD design, you must account for who will become a forest owner. A forest owner is any account that has full-control access to every domain within the forest. Any Domain Administrator in the root domain of the forest (the first domain created in the forest) is automatically made a member of the Enterprise Admins and Schema Admins groups. Take users and administrators out of this group immediately. You can then create a set of standards and procedures detailing when an account can be added to these groups to perform the administrative duty.
AD DS forests provide a complete replication boundary. Every domain controller within the forest will participate in the replication topology, sharing information among them so that each domain controller can respond correctly when a client requests it. Two AD partitions —the configuration partition and the schema partition (or naming contexts) — will replicate on a forestwide basis. Every domain controller within the forest will share identical data for these two partitions. The schema partition holds all of the rules pertaining to how objects can be created within the forest. If any of the domain controllers within your forest had a different set of attributes or object class rules, the objects that were created by that domain controller would not work with the other domain controllers.
The configuration partition specifies how the domain controllers communicate and how the domain is designed. Other systems, such as Microsoft Exchange, use the configuration partition to hold data about the systems that provide the email service. Having this information replicated to all domain controllers within the forest gives you the ability to hold the configuration data in one location, AD DS, and allows other systems to look to the domain controllers to find out how they are supposed to run. This also means that you only have to configure one replication topology when synchronizing changes instead of having AD DS–specific data replicating through domain controllers and Exchange data replicating through Exchange servers.
Note that data will not replicate between domain controllers in different forests. Even if you have domain controllers from two forests at the same physical location, they will not share configuration and schema partition data; only those from the same forest will. These servers may reside in the same physical location, but they are in different logical forests and domains.
The domain partition or domain naming context is replicated only to other domain controllers within the same domain. Although this does improve performance by restricting the amount of replication throughout the organization, it causes issues when users are trying to locate objects within other domains. To alleviate some of the problems associated with partitioning the forest into separate domains, Microsoft introduced the concept of a global catalog.
A Common Global Catalog
A forest provides a common global catalog (GC) within the forest. A global catalog is a domain controller that hosts objects from every domain naming context within the forest. At first you might think that could be a lot of data for a domain controller to host. If the GC server were to hold all of the attributes from every domain within the forest, you’d be correct. However, to keep network traffic at a minimum, only a few attributes for each object are copied into the GC. The GC is like a giant cache of directory objects and attributes that keep you from needing to query beyond a single domain controller. For example, you could easily take a laptop from domain to domain, country to country inside the same forest and authenticate immediately, because your user object (and every user object in the forest) is cached in the GC, which replicates forestwide.
Kerberos Authentication and Trust Relationships
Under the Windows NT 4 model, every domain was its own security boundary. To allow users to access resources within another NT domain, you had to create a trust relationship between the two domains. When you created a trust relationship, only one domain was allowed to trust users from the other domain. If you wanted to allow both sets of users to access each other’s resources, you had to create two trust relationships. To make matters worse, there was no sharing of trust. In other words, the trust relationships were not transitive. If DomainA had a trust relationship with DomainB,
and DomainB had a trust relationship with DomainC, DomainA was still restricted from accessing DomainC until an explicit trust was set up between DomainA and DomainC. Further, these trust relationships were only one-way trusts, so you needed to create two trusts just so that two domains could trust one another. Needless to say, planning and maintaining the correct trust relationships in a large NT infrastructure caused a loss of sleep for many administrators.
AD DS has changed the trust-relationship game. Within a forest, all of the domains are interconnected through two-way transitive trusts. This allows all the users within the forest to access resources from any domain within the forest so long as they have been granted permissions to access the resource. All of this is accomplished using the fewest trust relationships possible. Take a look at diagram below. This is a typical forest that has two trees, and domains within each tree. In an AD DS forest, you will need only the trust relationships, defined as arrows shown in the graphic.
If you were to implement the same number of domains within a Windows NT 4 environment, you would need 20 trusts. In order for the trust relationships to work within our forest, the Kerberos authentication service (the default trust authentication service used by Windows) is used. With Kerberos, each of the domains and all of the security principals within each domain are identified and given access to the resources through a process known as delegation.
Political and Administration Boundaries
These two topics, political and administration boundaries, are tied together because there is usually an underlying political reason for creating separate forests. As I mentioned earlier, the forest is the security boundary. Administrative accounts from the root domain of the forest have the ability to become the forest owners and, as such, can control all of the objects within the forest. Although there are other reasons why you may want to create separate forests, doing so to appease a faction within your organization might be the deciding factor. Some divisions simply do not like allowing other administrators access their data, and they may have a corporate sponsor who has enough power to override your design. The only way that you can isolate those divisions’ data is to create a separate forest and assign select users from those divisions as the forest owners.
The drawbacks to giving them their own forest are that you will have additional administrative overhead and you will need to make sure that the users are properly trained to use AD DS. When you have two forests, you have two completely separate administrative structures. If you can get by with a single forest, do so. You will reduce the total administrative costs.
Single-Forest Pros and Cons
|Single-Forest Pros||Single-Forest Cons|
|Easier to administer||Less secure for multiple business units with unknown/untrusted administrators|
|Easier to troubleshoot||Forests cannot be merged or split.|
|A single security boundary||Domains cannot join other forests.|
|Single schema||Schema differences are sometimes needed between business units.|
|Easier to support||Cannot agree on change control within a domain.|
|Users cannot search GCs of other forest without additional software.|
Multiple-Forest Pros and Cons
|Multiple-Forest Pros||Multiple-Forest Cons|
|More secure||More administration|
|May have different schema in each forest (e.g. one business unit uses Exchange and another doesn’t want its schema extended with the Exchange attributes)||Difficult to remember what schema extensions have been added and from which application they were added.|
|More control over outside trusts||No complete transitive trusts|
|Trusts between forests in W2003 and W2008 are transitive and Kerberos-secured.||Trusts between two forests are one-way, nontransitive NTLMv2 in Windows 2000.|
|Certain Exchange 2000 mailbox features are not available when users exist in a different forest than does their user object.|
Designing with Change-Control Policies in Mind
Realize that extending the schema later (to implement or upgrade to Exchange, for instance) affects the entire forest, every object, and the domain controller. Have a change-control policy in place that emphasizes proper operational processes. I know this is boring and a pain to implement, but it is sorely needed. Everything you do should be verified in a lab first, monitored, rolled out to a pilot group, verified, and then deployed in a systematic approach. Anticipate change, reorganizations, politics, and so forth. Before deciding to make any type of change, make sure you verify the necessity of the change that will be implemented. If you are simply adding an attribute to an object class, make sure none of the existing attributes will support your needs.
A well-defined change-control policy will reduce the problems associated with making changes to your infrastructure.
Forest Functionality Mode
Windows 2000 introduced mixed- and native-mode functionality. When Window NT 4 backup domain controllers were used in conjunction with Windows 2000 domain controllers in the same domain, the domain had to use mixed-mode functionality. This limited what functions were available to Active Directory because every domain controller had to work under the Windows NT 4 domain rules.
Windows Server 2003 brought additional functionality to Active Directory, and in doing so expanded into forest functionality and domain functionality. Choosing to move your domain or forest to a higher functional level gave you the added benefit of additional AD functionality.
Windows 2008 Server introduces changes at the domain functional level only. No significant changes are achieved at the forest functional level beyond what was provided with Windows 2003 forest functional level.
It is a best practice in any upgrade, migration, or installation to get to Windows 2000 native mode, Windows Server 2003 forest functional, or Windows 2008 forest functional mode as soon as you can. When you switch your domains from Windows Server 2000 mixed mode to native mode, you lose the ability to support Windows NT 4 backup domain controllers. From that point on, the backup domain controllers will not be allowed to participate in replication. When switching from native mode to Windows Server 2003 forest functional level, you loose the ability to add the Windows 2000 domain controllers into the domain. This also applies to Windows Server 2008. If you switch from native mode or Windows Server 2003 functional level to Windows Server 2008 forest functional level, Windows 2000 or 2003 domain controllers cannot participate in your AD DS forest. In return, because all of the domain controllers are at their highest level, you can take advantage of all of the advanced feature sets of Windows Server 2008.
To switch your forest from Windows 2000 to Windows Server 2003 forest functional level, you must be a member of the Enterprise Admins group. When going to Windows Server 2003 forest functional level, you gain the following features:
- Domain rename: This ability is accessed through the netdom command-line utility or the rendom resource-kit utility.
- Link value replication: This is the ability, for example, for a group to replicate a single member when a change is made instead of the entire group being replicated each time (which is what Windows 2000 does). This also removes the 5,000-member limit on groups.
- The ability to convert a user in AD to INetOrgPerson on the fly: You also gain the ability to put a user password on the INetOrgPerson Lightweight Directory Access Protocol (LDAP) object.
- Schema redefine: This is not deletion, though it is the next best thing.
- Dynamic auxiliary classes: Use this when you need to have a departmental schema extension that doesn’t affect the rest of the forest. For example, use it when a department needs to put employee IDs into Active Directory and you, as the forest owner, don’t want to extend the schema for this small department’s needs.
- Basic and query group types: The basic group types, Security and Distribution, are available with all versions of Active Directory. Query groups types become available when the forest level is raised to Windows Server 2003 functional level. Query-based groups allow you to create an email distribution list that dynamically updates its members based on an LDAP query.
- Improved Knowledge Consistency Checker (KCC): This feature is a big deal. In Windows 2000, you were told to turn off the KCC for implementations where you had about 100 DCs in a domain. Now the KCC can scale to more than 4,000 DCs in a domain, although you’d probably never want to have a domain that big.
- Additional attributes automatically added to the global catalog: Because forest-level trusts are now available, the global catalog has a few additional attributes that it tracks so that clients can utilize the trusts efficiently.
- Inter-Site Topology Generator (ISTG) enhancements: You can allow for complex site designs that have more than 100 sites and the ability to stop replicating automatically with an “offline” domain controller.
- Constrained delegation: This allows you to control the service-principle names of the service accounts that another service account has delegated to you.
- Application groups: This is a method of controlling the accounts that have access to an application.
- Cross-forest trusts: These are perfect for Exchange clients that exist in one forest but have their Exchange mailbox in another forest. They eliminate the need to log in again. Windows 2000 has NTLMv2 cross-forest trusts. Windows Server 2003 uses Kerberos trusts.
- The ability to update logon time stamp as a fast-synching replicated attribute: When a user logs on, the logon time stamp is updated within the domain controller to which the user authenticates, and that attribute is replicated as an urgent update to all of the other domain controllers.
AD DS Domain Design Criteria
So far we have looked at what goes into a forest design. The criteria I introduced for forests will flow over into domain design. You are still going to base your design decisions on one major design criterion: administrative control. Keep this in mind as you work through the rest of this section. All of your decisions will have administrative control as the primary concern, and then group policies and security policies will help you refine your design.
I am going to say it again, and you are probably going to tire of hearing this, but administrative control will become the primary domain-design criterion. As you remember from earlier in this section, the forest is the security boundary. Because you cannot guarantee that a domain will not be affected by an account from outside the domain, the forest becomes the security boundary within AD DS. Thus, the domain becomes the autonomous administrative boundary. This means that administrators for a
domain have control over the resources within their domain, but no other domain; additionally, the resources they control can also be controlled by members of the forest root high-level group Enterprise Admins.
However, before planning multiple domains, you should think about the ramifications of doing so. Always start simple—single forest, single domain—and work from there. You will encounter plenty of political battles as you design your domain structure, so plan well. Create a design that you think will work, and, just as with the forest structure, let others review it so that you can refine it to fit their needs.
Defining Domain Requirements
Effectively, a domain can host millions of objects. Theoretically, you are restricted only by the hardware limitations of your domain controllers. With that said, you will find that other factors will force you to limit the size of your domain to make your AD infrastructure efficient. If all the accounts that you have created within your domain are within a large, well-connected network where you have plenty of available bandwidth for all your network traffic to flow, you could probably get by with a single domain. Problems crop up when you start working with locations that are separated by WAN links that may not have enough available bandwidth to support the replication traffic.
As we mentioned earlier, the domain is the administrative boundary for AD DS. Because the Enterprise Admins group has the ability to affect any domain within the forest, administrators will not have complete isolated control of their domain. The same can be said about the replication boundary. The schema and configuration-naming contexts are replicated throughout the forest. Application mode partitions can also be replicated throughout the forest. The domain-naming context, on the other hand, replicates only between domain controllers within a single domain. In this section, we will look at how this can affect your domain design.
- Account Policy: An account policy is enforced at the domain level and will not affect other domains within the forest. Account policies are not inherited from domain to domain, so a parent domain’s policy will not affect any child domain.
- Password Policy: Password restrictions can be set to control exactly how passwords are used within the domain. If you open the Password Policy node, you will see the options like Enforce Password History, Maximum Password Age, Minimum Password Age, Minimum Password Length, Password Must Meet Complexity Requirements etc.
- Account Lockout Policy: The Account Lockout Policy contains the options that control when a user’s account will be locked out, or disabled from use, if too many password attempts fail. This is used to make sure that a user’s account is not easily compromised if an attacker is trying to determine the user’s password.
- Kerberos Policies: Kerberos policies are implemented by the domain’s Key Distribution Center (KDC). These policies are configured and applied at the domain level, and can only be changed by members of the Domain Admins group.
Multiple Domains Pros and Cons
|Account policy boundaries in place||Additional administrative overhead|
|Centralized GPOs, account policies, and administrative delegation||Separate GPOs, account policies, and administrative control at each domain|
|Active Directory database size reduced||Increase in global catalog size|
|Reduced domain-naming context replication traffic||Increase in global catalog replication|
|Less file replication service traffic||Moving user accounts to other domains is more difficult than moving them within a domain|
Between domains within a forest, you will find trust relationships that define how the users within the domains can access resources within other domains in the same forest. By default, when a domain is created, a trust relationship is built between the new domain and its parent. In a single tree, the trust relationships are parent-child trusts. When a new domain tree is created, a tree-root trust is created between the forest root and the root of the new tree. You cannot control this behavior. The Active Directory promotion tool (dcpromo) is responsible for creating the trust relationships and configuring how they will work. A third type of trust, the shortcut trust, is created manually by an administrator. When the trust relationships are in place, each domain will allow requests to flow up the tree in an attempt to secure Kerberos access to a resource.
- Parent-child Trust: A parent-child trust is the most basic of the trust types because all the domains share the same namespace. Each trust relationship is configured to allow two-way access to resources and is also transitive, so that users within every domain can access resources anywhere in the tree structure if they have been given permissions to do so.
- Tree-root Trust: Tree-root trusts share the same behavior as the parent-child trust, but they are used to allow communication between two namespaces. Because of their two-way transitive nature, users from any domain within the forest are allowed to access resources anywhere within the forest, assuming that the administrator has given them the permissions to do so.
- Shortcut Trust: The shortcut trust is available to reduce the network traffic that is incurred when a user attempts to gain access to a resource within the forest. By default, when a user attempts to connect to an object and that object resides within another domain, the user’s account has to be authorized to access the object. This process has been nicknamed “walking the tree” because the trust path through which the user needs to be authorized could take the user to multiple domains within the forest. A domain controller from each domain within the trust path will be contacted to determine if the user is allowed to access the object in question.
In the diagram below you will see that a user Sandeep, whose account is located in the domain south.del.airvoice.com want to access the printer located in the hr.chd.techtutsonline.com domain. The domain controllers for hr.chd.techtutsonline.com, chd.techtutsonline.com, techtutsonline.com, airvoice.com, del.airvoice.com and south.del.airvoice.com will need to be contacted in order for Sandeep’s account to receive the appropriate Kerberos authentication and authorization to the printer.
There are a couple of options you can implement that will reduce the amount of Kerberos traffic as Sandeep attempts to access the printer. The first is to place domain controllers from each of the domains within the trust path into the same site as Sandeep’s account. This will alleviate the need to send the traffic across WAN links. However, you will incur additional costs because you will need more hardware, and you may also increase administrative overhead at that site as a result of the introduction of the domain controller hardware at that location. This scenario has a serious drawback. If you have users who frequently access resources from another domain, yet those users are located in different sites, you may be forced to locate domain controllers at each of the sites to optimize your traffic.
As an alternative, you can create a shortcut trust between the two domains. In doing so, you are essentially cutting a path from one domain to another, thereby allowing the two domains’ Kerberos subsystems to work together instead of having to pass the data through intermediary domains.
The above diagram shows the shortcut trust created between hr.chd.techtutsonline.com and south.del.airvoice.com. There is an advantage to creating a shortcut trust: you have the ability to dictate how the trust will be used. As long as you have the appropriate credentials, you can create the shortcut trust between the two domains so that it is a two-way trust; in other words, both domains can then use the trust path. You can also create the trust as a one-way trust, which will allow only users from one domain to access resources in the other, but not vice versa.
Domain Controller Placement
Domain controllers host the Active Directory database. In order for users to log on to the domain, they need to be able to connect to a domain controller. The rule of thumb is to locate a domain controller near any user so the user can log on even if WAN connections is down. There are instances when you will not want to place a domain controller at a specific location. In the following section, we look at the options for placing domain controllers within your infrastructure and, in some cases, the reasons why you would not.
- Physical Access to Domain Controllers: It is rare to meet a developer who doesn’t believe he needs to be a member of the Domain Admins group. As a matter of fact, many developers have rogue domain controllers under their desks to use for testing. This is a bad practice because any Domain Admin can bring down the entire forest. A simple power-off on the domain controller immediately causes replication problems in Windows 2000 Server, although Windows Server 2003 and 2008 have mechanisms for just such an occurrence. The solution is to use a separate forest for any developer who either develops on Active Directory or needs elevated privileges. Yes, this increases administrative costs, but it will help secure your forest.
- Site Awareness: Active Directory aware clients (such as Windows Server 2003 and 2008, Windows XP/7/8/10), are able to determine whether a domain controller is within the same site as the client. If a domain controller is not located in the same site, the client will connect to a domain controller that is located in a nearby site. If you have several users within a site, it may be in your best bet to include a domain controller within the site. Of course, you want to make sure you can physically secure the domain controller.
- Global Catalog Placement: Global catalog (GC) servers are domain controllers that take on the additional load of hosting objects from every domain within the forest. You should be familiar with the placement of GC servers within your network. The same basic rule applies to a GC server as it does to a domain controller: one should be placed within every site. GC servers provide functionality to users as well as to applications within the domain. GC servers are responsible for collecting information about the objects that exist in the domain partition of other domains in the forest.
Domain Functional Levels
As the engineers behind Active Directory build new and better features, administrators are given more efficient and easier tools with which to work. At the same time, the new features in one operating system are not always supported in legacy operating systems. Windows NT 4 had some serious limitations when it came to secure and efficient administration. Windows 2000 addressed many of the limitations and presented Active Directory as the next generation of directory services.
To help with the interoperability issues between the differing directory services, Microsoft created functional levels that essentially put restrictions in place on the newer versions of Active Directory so that they play by the rules of the earlier operating systems. These functional levels come in various flavors: Windows 2000 mixed mode, Windows 2000 native mode, Windows Server 2003, Windows Server 2003 Interim, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2.
- Windows 2000 mixed mode: If you need at least one each of Windows NT 4 and Windows 2000 domain controllers within your domain, you will need to maintain a mixed-mode environment. In mixed mode, the domain controllers work under the NT 4 rules for backward compatibility. This is the most restrictive mode, and you do not get all of the functionality of Active Directory. However, you can still use your Windows NT 4 Backup Domain Controllers (BDCs) to authenticate users until you have a chance to upgrade all of the BDCs. Note that the functional levels apply only to domain controllers. You can still have Windows NT 4 and Windows 2000 member servers and clients within domains of any functional level.
- Windows 2000 native mode: When you decide that you are ready to move to native mode, you manually set off the update through the appropriate Active Directory snap-ins. How do you know if you are ready? You are ready if you no longer need to have NT 4 BDCs as part of Active Directory. This could mean application needs, political needs, or timidity about moving from NT 4. Basically, if an NT 4 BDC has to be a part of an Active Directory domain, you are not ready to go to Windows 2000 native mode. Moving to Active Directory native mode is a one-time, permanent move. Once you are there, replication to Windows NT BDCs no longer occurs, you cannot add any new BDCs to the network and even you can not revert back to Windows 2000 mixed mode.
- Windows Server 2003: This is the utopia for Windows Server 2003 domain controllers. Once you have raised the domain to this level, the domain controllers no longer need to share their databases with any of the Windows NT–based or Windows 2000–based domain controllers. As with native mode, once you have set the functional level to Windows Server 2003, there is no going back and you cannot install a Windows 2000–based domain controller into your Active Directory infrastructure.
- Windows Server 2003 Interim: The Interim functional level assumes that you are migrating directly from Windows NT 4 to Windows Server 2003 without ever introducing Windows 2000–based domain controllers into the mix. You can still implement a Windows 2000–based workstation or server into the infrastructure; they will work perfectly. The major advantage to moving directly from Windows NT 4 to Windows Server 2003 is that the Windows Server 2003 Interim functional level allows you to take advantage of linked value replication (LVR) when replicating the membership of groups. This means that every member of a group is seen as a separate attribute. If you do not choose the Windows Server 2003 Interim level during the upgrade of the PDC to the forest root, or you do not have the forest root domain at the Windows Server 2003 Interim level when you upgrade PDCs to their own domain within the forest, group membership values will be replicated as a single attribute. LVR also removes the 5,000-member limit on groups.
- Windows Server 2008: Following are the features that are changed with Windows Server 2008:
- Distributed File System (DFS) replication of SYSVOL. Because DFS is the mechanism used for replication, only deltas (changes) to the SYSVOL are replicated.
- Advanced Encryption Services (AES) support for Kerberos authentication.
- Last-interactive-logon information. Information is retained about the last successful interactive logon, the workstation that was used, and even the number of failed logon attempts for each user.
- Fine-grained password policies. Password policies and account-lockout policies can now be configured for users and global security groups in a domain. In Windows 2000 and 2003 Active Directory domains, there was one password policy and one account-lockout policy that was configured for the entire domain. If there was a need for different settings for any reason, another domain would have to be introduced.
- Windows Server 2008 R2: All default Active Directory features, all features from the Windows Server 2008 domain functional level, plus the following features:
- Authentication mechanism assurance, which packages information about the type of logon method (smart card or user name/password) that is used to authenticate domain users inside each user’s Kerberos token. When this feature is enabled in a network environment that has deployed a federated identity management infrastructure, such as Active Directory Federation Services (AD FS), the information in the token can then be extracted whenever a user attempts to access any claims-aware application that has been developed to determine authorization based on a user’s logon method.
- Automatic SPN management for services running on a particular computer under the context of a Managed Service Account when the name or DNS host name of the machine account changes.
- Windows Server 2012: The KDC support for claims, compound authentication, and Kerberos armoring KDC administrative template policy has two settings (Always provide claims and Fail unarmored authentication requests) that require Windows Server 2012 domain functional level.
- Windows Server 2012 R2: Windows Server 2012 R2 provides the following features
- DC-side protections for Protected Users. Protected Users authenticating to a Windows Server 2012 R2 domain can no longerauthenticate with NTLM authentication.
- New forest-based Active Directory policies which can be applied to accounts in Windows Server 2012 R2 domains to control which hosts an account can sign-on from and apply access control conditions for authentication to services running as an account.
- New forest-based Active Directory object, which can create a relationship between user, managed service and computer, accounts to be used to classify accounts for authentication policies or for authentication isolation.
Depending on the version of Active Directory you are running, you will have different methods of changing the functional level of the domain. You will be able to change to Windows 2008 and higher mode only if you have upgraded all of domain controllers to Windows Server 2008. You can raise the domain functional level as shown in diagram below:
Notice that I am currently using Windows Server 2008 R2 functional level and I cannot raise the functional level to Windows Server 2012 because I have not yet upgraded all of my Domain Controllers to Windows Server 2012.