Active Directory comprehensive guide, from installation and configuration to security auditing. Part 7: Understanding the AD infrastructure

The main unit in which the main processes take place to manage users, computers, equipment, processes and others is the domain. The core of the domain is the domain controller, which, in fact, is responsible for managing the listed elements. Therefore, when exploring Active Directory, the focus is on the objects that the domain controller manages. The most commonly used objects:

users
computers
group
peripherals
network services

Each object is uniquely identified by its name and attributes.

These objects can be grouped into organizational units (OUs) according to any number of logical or business needs. Group Policy Objects (GPOs) can then be linked to an organizational unit to centrally configure various users or computers in an organization.

It seems that without much explanation it is clear what the type of objects is “users”, “computers” and so on. And it is with them that most of the work happens. But Active Directory is not limited only to domain objects, depending on the needs, the system administrator can operate with several domains, or create several domain controllers for one domain. Domains can be in a wide variety of relationships with each other: from complete isolation to complete trust with all intermediate options. To set up relationships, a forest, tree, and other elements are used that a system administrator working with a single domain does not focus on, even if there are thousands of computers and users in his domain. For this reason, we will start with an introduction to domain objects and then move on to the overall structure of Active Directory, describing the relationship between multiple domains and domain controllers. In the future, some of these issues will be explored in separate chapters.

Active Directory domain objects

Before delving into the abstract concepts of “forest”, “tree”, “domain”, let's dwell on more specific ones: “users”, “computers”, “groups”. They are all domain objects.

There are the following types of objects:

We will limit ourselves to studying and working with the following types of objects:

User
Computer
Group
Container
Organizational Units (OUs)

How Organizational units and Containers differ

In the next window “Active Directory Users and Computers” you can see items such as Container and Organizational Units.

In fact, they are similar: both of these types are used to order objects. They can be thought of as folders that contain other folders and objects. Their main difference is that once a server becomes a domain controller, multiple default containers are created. These containers are unique by default and cannot be renamed, deleted, created, or linked to a Group Policy Object (GPO).

In turn, Organizational Units can be renamed, created, linked to a Group Policy Object (GPO) by domain administrators.

Note: Group Policy Objects (GPOs) will be discussed below.

Not every default container is needed for the day-to-day work of a sysadmin. Because of this, some containers are hidden by default. One of the reasons these containers are hidden is to keep AD users and computer snap-ins from looking confusing. To show these default hidden containers, enable the Advanced Features option on the View menu.

Full list of containers:

Please note that other utilities show all containers by default. For example, this is a screenshot of the Active Directory Administrative Center.

And this is a screenshot of an overview of the default containers from Windows Admin Center.

Therefore, if you use any of these tools, then you do not need to activate the display of hidden containers by default.

Default containers

Available default containers (note that “Computers” and “Users” are not object types here, but container names!):

Computers is the default container for computer accounts.
Domain Controllers is the default container for domain controllers.
ForeignSecurityPrincipals is the default container for security identifiers (SIDs).
Keys is the default container for key objects.
LostandFound is the default container for orphaned objects.
Managed Service Accounts is the default container for managed service accounts.
Users is the default container for user accounts.

Organizational Units

As already mentioned, you can think of Organizational Units as folders that contain objects of various types, for example, there may be users and computers. In addition, nested organizational units are allowed, that is, within one organizational unit there may be another, and so on.

One of the most important functions of an organizational unit is the ability to apply a Group Policy Object(s) to it. As you might guess, GPOs contain various sets of rules and permissions (policies) that will be applied to all objects located within the organizational unit to which the GPO is applied.

An example of a complex structure of organizational units, which is based on the division of branches by country, then by regions of the country, while a structure of typical units has been created for each region.

In this example, users, computers and other objects are not only structured in an organized way, but for any organizational unit, at any level, a separate policy can be applied.

Organizational units should be designed to reflect your organization's need for delegation of authority and Group Policy enforcement. A multinational company may have top-level divisions in North America, Europe, Asia, South America, Africa so that they can delegate administrative privileges based on continent. Other organizations may have top-level departments for HR, accounting, sales, and so on, if that makes more sense to them. Other organizations have minimal policy needs and use a flat layout with only employee users and employee computers. There is no one size fits all solution and no single correct answer. Organizational units should meet the needs of your company and the convenience of managing computers and users through Group Policy Objects.

We'll come back to GPOs later, but for now we'll continue our acquaintance with the types of Active Directory objects.

Users, computers, groups

If you go to the Users and Computers containers, you will see three types of objects:

User
Computer
Group

User and computer accounts are used to access network services. In networks based on Windows Server, both users and computer accounts are in AD. In such a centralized environment, groups are also used to facilitate the process of assigning rights and permissions.

Accounts (users and computers objects)

Technically, the user's domain account is part of AD and as such is authenticated by the same entity (i.e. AD). A domain user account is allowed access to both local and network services based on the access granted to the account or group to which the account belongs.

Examples of creating domain user accounts are given in the previous part.

Unlike domain accounts, local accounts are part of the computers on which the account was created, and therefore Windows SAM is responsible for authenticating them. The local account is authorized to access local services based on the access granted to the account. In addition, a local account can access shared resources on the P2P network if it has permission to do so.

You cannot create a local account on a domain controller (on a Windows Server that is assigned the role of domain controller).

In AD, a computer account identifies a computer in a domain. Before joining a computer to a domain, its hostname must be unique on the network. After a computer joins a domain, it continues to use its computer name to communicate with other computers and servers on the network. Computer accounts are managed through the Active Directory Users and Computers snap-in:

When a user tries to log on an AD-joined computer using their AD credentials, a combined and hashed username and password combination is sent to the domain controller for both the user account and the computer account that is logged on. Yes, computers log on the system too. This is important because if something happens to a computer account in AD, for example, someone resets the account or deletes it, you may receive an error message stating that no trust relationship exists between the computer and the domain. Even though user credentials are valid, the computer is no longer trusted to log on to the domain.

Groups

In AD, a group is a collection of AD objects. Rather than assigning permissions and rights to each AD object individually, groups are used for more structured administration. Note that a group is also an object, which means that it can also be moved to an OU (however, Group Policy Objects (GPOs) cannot be applied directly to groups).

Groups are managed through the Active Directory Users and Computers snap-in. There are two types of groups in AD:

Security Groups are explicitly used to assign permissions to shared resources on the network.
Distribution Groups are especially used to distribute email lists across an organization's network:

Groups are used to facilitate the administration of AD objects. Consequently, as soon as the server becomes a domain controller, a significant number of default groups are created.

Groups can also be created by the domain administrator.

Regardless of whether it is a security group or a universal group, you need to keep in mind the scope of the group as a parameter for extending the group in the forest, domain tree, or child domain (more on that later). There are three types of groups in AD with different scopes:

The domain local group includes accounts, domain local groups, global groups, and universal groups from the parent's domain local group domain.
The global group includes accounts and global groups from the parent's global group domain.
The universal group includes accounts, global groups, and universal groups from any domain in the forest where a universal group belongs:

AD groups are objects that can also be combined into groups. You should be aware of the rule that adding groups to other groups minimizes the number of individually assignable permissions to users or groups. That is, the strictest are selected from the entire set of permissions.

Active Directory structure

How domain, forest, domain tree, and child domain are related

A domain is a logical grouping of users, computers, peripherals, and network services. From a network architecture perspective, domains are typically centralized network environments in which a domain controller manages authentication. On Windows Server-based networks, the domain is served by the AD DS role.

You may recall that during the stage of promoting the server to the level of a domain controller, we selected the option to Add a new forest.

A forest, relatively speaking, is a shell that delimits domains. Domains in different forests are completely delimited from each other (unless otherwise configured through a trust). In practice, usually one forest contains one domain – this is the simplest and most common configuration.

In addition to single domains, a forest can contain domain trees. These domains automatically trust each other, but can use a different namespace, for example, one domain can use the name ad-dom.loc, and the other mydomain.com.

A domain can have a child domain, which, accordingly, is included in the same forest. Child domains differ from domain trees in that they use the same namespace, for example, if the parent domain has the name ad-dom.loc, then the child must have a name like *.ad-dom.loc, for example, train.ad-dom.loc.

In practice, sysadmins rarely use trees and child domains, because in modern Active Directory this is not necessary – everything that is needed can be configured within the same domain through organizational units.

However, let's take a closer look at the elements of the domain structure.

What is domain and what is forest

The forest is the border of security. Objects in separate forests cannot communicate with each other unless the administrators of each separate forest create trusts between them. For example, the enterprise administrator account for domain1.com, which is usually the most privileged account in the forest, will not have any permissions in the second forest named domain2.com, even if those forests exist on the same local network. If you need permissions, then this is configured through trust.

If you have multiple unrelated business units or need separate security boundaries, you need multiple forests.

A new forest is created when a security boundary is needed. For example, you might have a perimeter network (DMZ) that you want to manage with AD, but you don't want your internal AD to be available on the perimeter network for security reasons. In this case, you need to create a new forest for this safe zone. You might also want a split like this if you have multiple organizations that don't trust each other – for example, a shell corporation that includes individual businesses that operate independently. In this case, you need each entity to have its own forest.

The domain is the control boundary. Domains are part of the forest. The first domain in the forest is known as the forest root domain. In many small to medium sized organizations (and even some large ones), you will only find one domain in one forest. The forest root domain defines the default namespace for the forest. For example, if the first domain in a new forest is called domain1.com, then this is the root domain of the forest. If you have a business need for a child domain, such as a branch office in Chicago, you can name the child domain chi. The FQDN (Fully Qualified Domain Name) of the child domain will be chi.domain1.com. You can see that the child domain name has been appended to the forest root domain name. There can be multiple domains in the same forest and there can be non-overlapping namespaces.

In most cases, sysadmins do their best to have a single AD domain. This simplifies management, and modern versions of AD make it very easy to delegate management based on organizational units (OUs), which reduces the need for child domains.

FSMO (Flexible single master operation) roles

When the AD DS role is installed and the server becomes a domain controller, AD DS automatically assigns five operations master roles.

FSMO (Flexible single-master operations) are types of operations performed by Active Directory domain controllers requiring the mandatory uniqueness of the server performing these operations.

Depending on the type of operation, FSMO uniqueness is implied within either the domain forest or the domain.

In fact, there are 5 Flexible Single Master Operations (FSMO) roles. They are also referred to as operations master roles. These two terms are used interchangeably.

The first two are forest-wide operations master roles:

Schema Master – Responsible for making changes to the Active Directory schema. This role is required to prevent conflicting changes from two servers. There is only one schema master in the forest. It is responsible for updating the Active Directory schema. Tasks that require this, such as preparing AD for a new version of Windows Server running as a domain controller, or installing Exchange, require a schema change. These changes must be performed by the schema wizard.
Domain Naming Master – Responsible for forest composition, accepts and deletes domains. There is only one domain naming wizard in each forest. The Domain Naming Wizard ensures that when a new domain is added to the forest, it is unique. If the server playing this role is down, you won't be able to make changes to the AD namespace, including things like adding new child domains.

Whereas the remaining three represent the roles of the single master operation at the scale of the tree (if there is only one domain, then in fact at the scale of the domain):

There are two types of domain controllers: read-only and read-write. The read-only version contains a read-only copy of the ADDS database. As the name suggests, read-write domain controllers can optionally write to the ADDS database. The Schema Master and Domain Naming Master manage the AD schema and run on a read-write domain controller that makes sure there is only one unique domain in the forest. On the other hand, the Relative ID Master takes care of assigning Security Identifiers (SIDs) to domain controllers, the Primary Domain Controller Emulator (PDC Emulator) takes care of updating passwords, and the Infrastructure Master keeps track of changes made to other objects in the domain.

An example of getting forest information for the current user:

Get-ADForest

Retrieving forest information for a remote computer:

Get-ADForest -Server ds.hackware.ru -Credential Administrator

As you can see, the domain, root domain and forest are named the same: ds.hackware.ru. Notice the meaning of the SchemaMaster and DomainNamingMaster fields which are the forest-wide operations master roles.

Retrieving domain information for the current user:

Get-ADDomain

Retrieving domain information for a remote computer:

Get-ADDomain -Server ds.hackware.ru -Credential Administrator

In this output, the (same) domain is named ds, and the forest is still named ds.hackware.ru. Here, notice the meaning of RIDMaster, PDCEmulator, and InfrastructureMaster, which are tree (domain) scale operations master roles.

It's important to remember that the servers that run these roles are not set in stone. Moving these roles is usually trivial, so while some DCs do a little more than others, if they go down for short periods of time, things will usually work fine. If they don't work for a long time, then it's easy to transparently transfer roles.

Domain Controllers and Global Catalogs

If the structure of Active Directory contains several domains, the global catalog is used to solve the problem of finding objects: a domain controller that contains all objects in the forest, but with a limited set of attributes (incomplete replica). The catalog is stored on specified global catalog servers and serves cross-domain requests.

Recall that the server that responds to authentication or authorization requests is a domain controller (DC). In most cases, the domain controller will keep a copy of the global catalog. A global catalog (GC) is a partial collection of objects across all domains in a forest. It is directly searchable, which means that cross-domain queries can usually be made to the GC without having to go to the DC in the target domain.

Domain controller availability issues

Multiple domain controllers can simultaneously respond to authentication requests from different users and computers. If one fails, the rest will continue to offer authentication services. Now there is no such thing as a “primary” or “secondary” server. But for the domain to function properly, these domain controllers must also be DNS servers that also contain a copy of the Active Directory integrated DNS zones for your domain.

Data between servers is synchronized using replication. By default, domain controllers belonging to the same domain at the same site will replicate their data to each other at 15 second intervals. This ensures that everything is relatively up to date. There are some “urgent” events that trigger immediate replication. Examples of urgent events include account locked out due to too many failed login attempts, changing the domain password or lockout policy, changing the LSA secret, changing the password for the domain controller computer account, or transferring the RID Master role to a new DC. Any of these events will trigger an immediate replication event.

A password change falls somewhere between urgent and non-urgent events. If the user's password is changed to DC01 and the user tries to log into a computer that authenticates to DC02 before replication takes place, you would expect it to fail, right? Fortunately, this is not the case. Suppose there is also a third DC named DC03 that acts as a PDC (Primary Domain Controller) emulator. When a user's password is updated on DC01, the change is immediately replicated to DC03. If your attempt to authenticate to DC02 fails, then DC02 forwards this authentication attempt to DC03, which checks if everything is valid, and if so, then login is allowed.

Site

The site should represent a physical or logical boundary on your network. For example, branches. Sites are used to intelligently select replication partners for domain controllers in various locations. Without site definitions, all domain controllers will be treated as if they were in the same physical location and replicated in a mesh topology. In practice, most organizations are logically configured according to the hub-and-spoke principle, that is, a centralized server or several interconnected servers to which client machines are connected. Therefore, sites and services should be configured to reflect this.

Other applications also use the Sites and Services. The Distributed File System (DFS) uses it to refer to the namespace and select a replication partner. Exchange and Outlook use it to find the “closest” global catalog to query. Domain-joined computers use it to determine the “closest” domain controller(s) for authentication. Without it, your replication and authentication traffic will look like the Wild West and take inefficient routes.

Group Policy Objects

What is Group Policy and Group Policy Objects

Group Policy is a tool available to administrators using a Windows 2000 or later Active Directory domain. It allows you to centrally manage settings on client computers and domain-joined servers, and provides a rudimentary way to distribute software.

The settings are grouped into objects called Group Policy Objects (GPOs). GPOs link with an organizational units (OUs) in Active Directory and can be applied to users and computers. GPOs cannot be applied directly to groups, although you can use security filtering or item-level targeting to filter policy enforcement based on group membership.

What Organizational unit policies can do

Anything.

Seriously, you can do whatever you want with users or computers in your domain. There are hundreds of predefined settings for things like folder redirection, password complexity, power options, drive mapping, drive encryption, Windows update, and so on. All the settings that you can make for one computer or user, you can easily extend to tens or hundreds of computers using organizational units.

Anything that you cannot configure using the predefined parameters, you can control using scripts, including PowerShell.

Importance of Group Policy Objects for Active Directory

Group Policy Objects are a powerful tool that allows you to manage Active Directory very flexibly and effectively.

Algorithm of a typical control mechanism:

Organizational units are created to which computers and users are added, as well as other types of objects
These or those GPOs are linked with organizational units, as a result of which the selected settings begin to apply immediately to all elements of the organizational unit.
User rights and permissions can also be configured using groups (for example, if you add a user to the Domain Admins group, that user will receive domain administrator privileges).

Group Policy is very important, and a separate chapter will be devoted to it, in which the process of editing GPOs and their linking with organizational units will be discussed.

After a detailed acquaintance with group policies, we will delve into the management of users, computers and other types of objects using group policies and groups.

Also in this part, we have only scratched the surface of trust between domains and domain controllers – and a separate chapter will be devoted to this topic.

Recommended for you:

Alex October 28, 2021 Active Directory, Active Directory Users and Computers, child domain, containers, dsa.msc, forest, Global Catalogs, Group Policy Objects (GPOs), Organizational Units (OUs), replication, tree domain Work Environment No Comments »

Ethical hacking and penetration testing

InfoSec, IT, Kali Linux, BlackArch

Leave a Reply Cancel reply