For example, Active Directory will define a user by name, location, and department. With the added granularity of these attributes, IT teams are better equipped to track and manage important network objects. Beyond these categories, certain objects are designated as security principal objects , which can be assigned permissions or special authentication rules. IT teams use a unique SID security identifier to identify each security principal.
In Active Directory terms, a domain is an area of a network organized by a single authentication database. In other words, an Active Directory domain is essentially a logical grouping of objects on a network.
Domains are created so IT teams can establish administrative boundaries between different network entities. Active Directory domains are controlled by a tool called the domain controller. AD domains are usually identified via a domain name system DNS. One of your first considerations when setting up AD will be whether to use a single domain vs. In large networks, there might be dozens or even hundreds of Active Directory domains.
To organize them in a manageable way, domains are put together into groups called Active Directory domain trees. Enterprise networks with hundreds of users and thousands of network entities might have dozens and dozens of Active Directory trees. In such cases, IT teams will organize AD trees into groups called forests. Active Directory forests are the highest level of security boundary for network objects in the Active Directory tree and forest structure.
Within this Active Directory hierarchy, an AD forest is considered the most important logical container in an Active Directory configuration. This is because it contains all other users, domains, computers, group policies, and any other network objects of importance.
Although Active Directory may contain multiple domains and trees, most single Active Directory configurations only house a single domain forest. In multiple forest ecosystems, information and data exchange can only occur within the confines of a single Active Directory forest. This can be a challenge to manage, so IT admins should know creating more than one forest can make Active Directory monitoring practices significantly more complex. With an additional forest, IT teams can leverage an isolated copy of their AD system to test and tweak the configuration of their new software before rolling it out on a live network, minimizing the risk of the software affecting day-to-day operations.
Depending on the nature of the transaction, it can sometimes be easier to create an entirely new forest for the newly bought business, as opposed to migrating every user and resource over into your existing domains and trees. In such circumstances, an IT team can attempt to port the trees of the new division over to the existing forest, but this can quickly become complex.
Instead, leave the acquired network alone, and link the two Active Directory forests together by establishing a transitive trust authority. Although this solution has to be carried out manually, it can be effective. A transitive trust authority will extend the accessibility of resources, so the two forests can effectively merge on a logical level. This saves time and IT resources, which will likely already be stretched thin during a merger. IT teams can still manage the two Active Directory forests separately and let the trust link handle any mutual accessibility.
Windows NT environments were built as single master networks, meaning they used a single primary domain controller. With this setup, the primary domain controller was responsible for replicating any and all changes made to the backup domain controllers. If the primary domain controller was unavailable or experiencing downtime for some reason, no changes would be made to the domain database, which meant data was at risk of being lost or unaccounted for. This made Windows environments significantly less reliable, since IT teams had to take many manual steps to continually ensure changes could be made to a domain database or else risk losing valuable information.
To mitigate these risks, IT teams needed a software to deploy more than one domain controller. The solution came with the introduction of Active Directory, which, unlike Windows NT environments, was designed to be a scalable, distributed, replicated database.
This means AD operates with multiple domain controllers. Because every domain controller in an Active Directory ecosystem automatically creates a replica of the information it stores within its own domain, the entire AD system is more reliable than previous systems. Accordingly, Active Directory replication is best understood as a guarantee that any information or data processed by any of the domain controllers is consistent, updated, and synchronized.
The most common method to enable the domain and forest functional levels is to use the graphical user interface GUI administration tools that are documented in the TechNet article about Windows Server Active Directory functional levels. This article discusses Windows Server However, the steps are the same in the newer the operating system versions. Additionally, the functional level can be manually configured or can be configured by using Windows PowerShell scripts. For more information about how to manually configure the functional level, see the "View and set the functional level" section.
For more information about how to use Windows PowerShell script to configure the functional level, view Raise the Forest Functional Level. When you change the functional level attributes manually, the best practice is to make attribute changes on the Flexible Single Master Operations FSMO domain controller that is normally targeted by the Microsoft administrative tools.
When you increase the msDS-Behavior-Version attribute from the 0 value to the 1 value by usingAdsiedit. Some aspect of the modification is not permitted. The attributes on the partitions container and on the domain head are correctly increased. If an error message is report by the Ldp. To verify that the level increase was successful, refresh the attribute list, and then check the current setting. This error message may also occur after you have performed the level increase on the authoritative FSMO if the change has not yet replicated to the local domain controller.
After you connect to a domain controller, the RootDSE information for the domain controller appears. This information includes information on the forest, domain, and domain controllers. The following is an example of a Windows Server based domain controller. In the following example, assume that the domain mode is Windows Server and that the forest mode is Windows Server. The domain controller functionality represents the highest possible functional level for this domain controller.
You must change the domain mode to native mode before you raise the domain level if one of the following conditions is true:. If you do not change the domain mode to native mode before you raise the domain level, the operation is not completed successfully, and you receive the following error messages:.
When this process is used to raise the domain functional level to 2 Windows Server , the domain mode is automatically changed to native mode. The transition from mixed mode to native mode changes the scope of the Schema Administrators security group and the Enterprise Administrators security group to universal groups. When these groups have been changed to universal groups, the following message is logged in the System log:. When the Windows Server administrative tools are used to invoke the domain functional level, both the ntmixedmode attribute and the msdsBehaviorVersion attribute are modified in the correct order.
However, this does not always occur. In the following scenario, the native mode is implicitly set to a value of 0 without changing the scope for the Schema Administrators security group and the Enterprise Administrators security group to universal:.
Windows Server supports only mixed mode and native mode. Additionally, it only applies these modes to the domain functionality. The following sections list the Windows Server domain modes because these modes affect how Windows NT 4. There are many considerations when raising the operating system level of the domain controller.
These considerations are caused by the storage and replication limitations of the linked attributes in Windows Server modes. Domains that are upgraded from Windows NT 4. Windows Server domains maintain their current domain functional level when Windows Server domain controllers are upgraded to the Windows Server operating system. You can raise the domain functional level to either Windows Server native or Windows Server Windows Server Active Directory permits a special forest and domain functional level that is named Windows Server interim.
This functional level is provided for upgrades of existing Windows NT 4. Windows Server domain controllers are not supported in this mode. Windows Server interim applies to the following scenarios:. Windows Server interim provides two important enhancements while still permitting replication to Windows NT 4.
Because of the efficiencies in group replication that is activated in the interim level, the interim level is the recommended level for all Windows NT 4. See the "Best Practices" section of this article for more details. Windows Server interim can be activated in three different ways. The first two methods are highly recommended. The third option is less highly recommended because membership in security groups uses a single multi-valued attribute, which may result in replication issues.
The ways in which Windows Server interim can be activated are:. Before you upgrade the Windows NT 4. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Feedback will be sent to Microsoft: By pressing the submit button, your feedback will be used to improve Microsoft products and services. Privacy policy. In the organizational domain forest model, several autonomous groups each own a domain within a forest. Each group controls domain-level service administration, which enables them to manage certain aspects of service management autonomously while the forest owner controls forest-level service management.
The organizational domain forest model enables the delegation of authority for domain-level service management. The following table lists the types of service management that can be controlled at the domain level. Other types of service management, such as schema or replication topology management, are the responsibility of the forest owner. In an organizational domain forest model, domain owners are responsible for domain-level service management tasks.
Domain owners have authority over the entire domain as well as access to all other domains in the forest. For this reason, domain owners must be trusted individuals selected by the forest owner.