Introduction
This blog post is part two of the Cyb3r-S3c's Microsoft's Active Directory Domain Services (AD DS) series. In the previous blog post, I covered the fundamental components of Active Directory (AD). In this video, we'll be exploring Forests and Domains, two key concepts that form the foundation of AD. We'll also touch on Trust Relationships and Organizational Units (OUs), both of which are important in managing and administering AD environments. Gaining a good understanding of AD will be valuable for anyone working in IT, regardless of their specialty. With this knowledge, you'll be better equipped to effectively manage, administer, and secure complex network environments. If you're interested in cybersecurity, please regularly check back on Cyb3r-S3c and check out my YouTube channel, Cyb3r_0verWatch, for more informative content.
A Hike into the Forest
When you think of a forest you think a large swath of land with a lot of trees. Forests in AD are similar in that they are logical hierarchical structures that consist of one or more AD trees, which are collections of domains. All domains in a forest share a common schema and global catalog, and they are connected by trust relationships. A common root domain is established when the first domain is created in a forest, and it serves as the parent for all subsequent domains.
Forest Roles
The forest root domain is the first domain that is created in the forest and contains objects that don't exist in other domains in the forest, such as the forest schema, configuration, and domain naming contexts. The forest root domain also contains the forest-wide operations master roles like:
Schema master role: This is a crucial role responsible for managing and enforcing updates to the directory schema across the entire forest. It ensures that any changes to the schema are correctly propagated to all domain controllers in the forest to maintain consistency and integrity of the directory data The Schema Master role is initially assigned to the first domain controller created in the root domain of the forest, but it can be transferred to other domain controllers located anywhere within the forest.
Domain naming master role: This is a crucial role in the AD forest, responsible for managing the addition or removal of domains in the forest. It controls the creation and deletion of domains in the forest, as well as managing the configuration of domain-wide settings. The domain naming master role can be held by only one domain controller at a time and is essential to maintain the integrity and consistency of the domain namespace.
Enterprise Admins group: This group is a security group in Active Directory Domain Services that has administrative access to all domains in the forest. Members of this group are authorized to manage the entire forest, including all domains and domain controllers. This group is typically used for tasks that require high-level permissions, such as creating or deleting domains, managing trust relationships between forests, and configuring forest-wide Group Policy settings.
Schema Admins group: This is a security group that has administrative access to manage the directory schema for the entire forest. Members of this group can modify the schema by adding, deleting, or changing definitions of objects or attributes.
A forest can consist of as few as one domain with a single domain controller or it can contain multiple domains across multiple domain trees. The size and complexity of the forest depend on the needs of the organization. Regardless of the size, all domains within a forest share a common directory schema and a global catalog, which facilitates communication and information sharing between domains. Trust relationships can be established between domains in the same or different forests to enable resource sharing and collaboration between users and groups.
An AD forest serves as:
A security boundary that restricts access to resources within the forest by default to users from outside the forest. All domains in the forest have automatic trust relationships with each other, enabling easy access to resources for all users, regardless of their domain membership.
A replication boundary for the configuration and schema partitions in the AD database. This means that if organizations plan to deploy applications with incompatible schemas, they must create additional forests. The forest is also the replication boundary for the global catalog, which facilitates the search for objects across all domains in the forest.
Entering the Domain of AD
In real estate a domain is private property, meaning not everyone is permitted on the property. In AD a domain is similar, as it's a logical administrative container (or logical property) for organizing and managing various objects, including users, computers, and groups (who are authorized). The AD database contains all objects specific to the domain, and each domain controller maintains a copy of the database. The domain provides a security boundary for authentication and authorization, with each domain having its own security policies, trust relationships with other domains in the forest, and domain controllers that authenticate users and manage domain-wide policies. A single domain is able to contain nearly two billion objects.
A domain contain both functional boundaries and units:
Replication boundary: A DC will replicate any changes made to any object in the domain. The replication will update all DC's in the domain. AD uses a multi-master replication model that allows every domain controller to make changes to objects in the domain. If multiple domains exist in the forest, only subsets of the changes replicate to other domains.
Administrative unit: Administrator account and a Domain Admins group can be found in an domain. For administrative functionality every computer joined to the domain will have the Domain Admins group in the Local Administrators group. By default, the Administrator account is a member of the Domain Admins group. Members of the Domain Admins group have full control over every object in the domain, making the domain a critical administrative unit for managing user accounts, computer accounts, groups, and other objects.
Authentication and authorization boundary: Only DC's can authenticate and authorize users and computers joined to the domain. DC's maintain copies of the AD database containing domain objects. This allows administrators to manage access to resources and enforce security policies within the domain.
Delegation unit: To assist in the administrative workload and to allow for a more detailed approach to administration, Administrators can delegate control of specific domain objects or tasks to other users or groups in the domain.
Domain Roles
Domains contain various objects, including:
User accounts: Information such as credentials, profile data, and group membership are stored.
Computer accounts: Every domain-joined computer has an account in AD, which allows the domain controller to authenticate and authorize the computer to access network resources.
Groups: AD DS uses groups to organize users or computers and to simplify the management of permissions and Group Policy Objects in the domain. Group membership can be used to grant or deny access to resources or privileges based on the security settings assigned to the group.
A Primer on Trust Relationships
As complex as AD environments can become, trusts are imperative for enabling access to resources. When you only have a single-domain deployment to deal with it's easy to grant access to resources within the domain to users and groups from the same domain. The challenge comes when there are multiple domains or forests that are implemented. It's important to put in place the necessary trusts to enable similar access to resources. Trusts enable domains to create a relationship that allows users, groups, and computers in one domain to access resources in another domain. By default two-way transitive trust relationships are automatically created between AD domains in a multi-domain AD forest. This creates a path of trust between all the AD domains in the forest. This means that if domain A trusts domain B, and domain B trusts domain C, then domain A automatically trusts domain C. The transitive nature of these trusts means that trust relationships can be established between multiple domains in a forest without the need for each domain to have an individual trust with every other domain. This allows users, groups, and computers to access resources across domains. If you are evaluating business needs and it's determine that more restrictive security policies need to be enforced, you can also create selective trusts to limit access.
The following table provides an overview of the main types of trust relationships in AD DS:
OU's: What's in the Secret Sauce of AD Management?
An Organizational Unit (OU) is a container object in AD that serves two main purposes:
Combining AD objects for easier management: OUs are used to group similar objects, such as users, computers, and groups, together in a logical structure. By organizing objects in this way, you can apply Group Policy Objects (GPOs) to the entire group of objects within the OU. GPOs are policies that administrators create to manage and configure settings for computers or users. When GPOs are linked to an OU, the settings get applied to all the objects within the OU. GPOs can be linked to OUs, domains, or sites.
Delegating administrative control: Besides the Domain Admins group, OUs can be used to delegate management permissions to a user or a group within AD. By doing this, you can allow specific users or groups to manage the objects within the OU without giving them full administrative control over the entire domain.
You can use OUs to represent the tiered, logical layout within your organization. You can create:
Department OUs
OUs based on geographic regions
A combination of both departmental and geographic regions.
OUs facilitate management of user, group, and computer accounts according to organizational models. OUs can be created using the following tools:
ADAC
ADUC
Windows Admin Center
PowerShell with the AD module
They May Be Generic, But They're More than Your Average Container
When you deploy AD it comes prepackaged with several built-in containers, or generic containers, such as Users and Computers. These containers store system objects or act as default parent objects to new objects. Generic containers, it's important to note are not the same as OUs. While OUs provide robust management capabilities, containers management capabilities are limited . You will not be able to apply a GPO directly to a generic container.
After AD DS role is installed there are several default objects created, including the Domain Controllers OU and generic container objects like Users and Computers.
Domain: In AD it's the highest level of the domain hierarchy, serving as the root object that determines the perimeter for administrative authority and security policies.
Built-In container: This is a container in AD DS that stores a set of default security groups. These security groups are used to grant or deny permissions and access to resources across the domain. Some of the default security groups include Administrators, Backup Operators, Domain Admins, Domain Users, Enterprise Admins, Guests, and Print Operators.
Computer container: Newly created computer accounts by default get placed in this generic container.
Foreign Security Principals container: This container stores trusted objects from domains outside the local AD domain. This occurs when the external domains gets added to a group in the local AD domain.
Managed Service Accounts container: Managed service accounts are stored in the Managed Service Accounts container,. This allows AD to automatically manage password.
Users container: A generic container that stores new user accounts and groups created in the domain by default. It also contains the administrator and guest accounts for the domain, as well as some default groups.
Domain Controllers container: It is the only OU that is automatically created during a new installation of AD. DC computer accounts are stored in this container by default.
If you select the Advanced Features option in ADUC, you can review several additional containers in AD that are normally hidden by default and cannot have GPOs linked. Object descriptions of the objects are noted below:
Designing Up: Unleashing the Power of Hierarchical Design
Designing the AD architecture for an environment is not a small task. The AD OU hierarchy should be based on the organization's administrative needs, such as geographic, functional, resource, or user classifications, for effective and flexible administration. Nested OUs is a great way to better organize your resources, like having OUs for offices, IT administrators, and departments. It is recommended to keep the OU depth manageable to ensure effective administration. Limit the OU's to no more than 10 levels, as most organizations tend to cap it at five levels or fewer. It is also good to recognize that some applications may impose OU depth restrictions for areas of the hierarchy in use.
Conclusion
In closing, this blog post "Active Directory Fundamentals (Part Two: Forests and Domains)" provides an informative introduction to Microsoft's Active Directory Domain Services (AD DS), focusing on two key concepts: Forests and Domains. The video also touches on Trust Relationships and Organizational Units (OUs), both of which are important in managing and administering AD environments. Understanding AD is valuable for anyone working in IT, regardless of their specialty, and with this knowledge one can better manage, administer, and secure complex network environments. Thank you for reading "Active Directory Fundamentals (Part Two: Forests and Domains)" part two of four in the Active Directory Fundamentals series on Cyb3r-S3c. If you find this content informative and you are interested in cybersecurity, please regularly check back on the Cyb3r-S3c website. For more free content, please like and subscribe to the Cyb3r-0verwatch channel. Until next time keep learning, the only way to improve is to keep learning.
/Signing Off
Pragmat1c_0n3
Comments