Before we dive into creating or configuring any services, we will look at some definitions and concepts to set a baseline and foundation of knowledge for you to build from. We will start this chapter by defining Active Directory (AD), which forms the basis of Windows Server identity, access management, and information protection services.

AD is part of Microsoft’s identity, access, and information protection solutions. It runs as an installed service as part of Windows Server and was introduced in Windows 2000.

As its name suggests, AD is a directory service and an identity provider (IDP) whose primary function is to manage access to domain resources through authentication and authorization. It is used to control, centrally organize, locate, and secure access to these resources on a network.

At a simple level, you can think of it as an identity store and digital address book for resources on a network. It comprises a list of identities and their access rights to resources in the directory.

AD is not a single function service or solution; it is a collective or umbrella term for a portfolio of directory-based and identity-driven services, including domain services, federation services, certificate services, and rights management services. It provides capabilities such as single sign-on (SSO).

From a technical perspective, it is an X.500 compatible directory service and can be accessed using the Lightweight Directory Access Protocol (LDAP). It is based on a hierarchical, multi-master distributed database model that comprises partitions and an extensible schema.

This section introduced AD as the Microsoft solution for the foundation of identity, access, and information protection for on-premises and hybrid environments. In the next section, we will understand and define Active Directory Domain Services (AD DS).

AD DS is organized as a distributed and searchable hierarchical directory that controls access to network resources and allows settings and configurations to be applied through policies.

AD DS is a server role installed on Windows Server and is included with the operating system (OS); no software needs to be downloaded. A server with an installed AD DS role is referred to as a domain controller (DC).

AD DS provides access to resources by authenticating and authorizing domain object resources.

Accessing domain resources is based on a two-stage concept that consists of authenticating and then authorizing; in a nutshell, it involves identifying who you are and determining what you can do:

• Authentication, also referred to as AuthN, is the identity component; it is the process of establishing the identity of a person (or service) and proving they are who they say they are. This can be done by validating access credentials against stored or known identifying information.
• Authorization, also referred to as AuthZ, is the access component; it is the process of establishing what level of access the authenticated person (or service) has to the resource, what they can access, and what actions they may take.

The concept of authenticating and authorizing is shown in the following diagram:

Figure 1.1 – Understanding authentication and authorization

The terms Active Directory and Domain Services (abbreviated to their short forms of AD and DS) are often used interchangeably to mean the same thing. When people refer to AD, they often mean just the DS component, mainly since it is the most common and foundational identity and access management service component to be implemented.

For this book and the exam, we will refer to AD in the context of the DS component only; we will refer to it simply as AD DS for brevity. For additional learning content on the other services that are part of AD, please refer to the Further reading section at the end of this chapter.

AD DS contains a list of objects, such as user accounts, along with their attributes, such as passwords and their assigned access rights to resources. This list can be queried to validate the identity and access rights to a resource in the domain that is created as an object in the information store database. This is shown in the following diagram:

Figure 1.2 – Domain resource access

AD DS functions by classifying everything stored in its information store (database) as an object. Objects can be user accounts, computer accounts, groups (security principals), printers, network appliances, applications, or services. These objects are hierarchical, meaning that objects can contain other nested objects; these types of objects are called containers. We will look at these terms in more detail later in this chapter.

Each object stored in the database has a set of attributes that match the object’s context; this is defined in a schema. The directories information data store is a database structure with a schema that is extensible and can store attributes that suit the business requirement. Being a directory service means every object can be searched, queried, access controlled, managed, and configured in a centralized and policy-driven manner.

The foundation of identity and access management (IAM) is that access to objects is controlled through role-based access control (RBAC) and the principle and practice of least privilege. This means providing the proper scope of control. Just enough access is given to perform a required task without unnecessarily providing elevated access rights that may give a broader scope than required and privileged lateral access if an account were to be compromised. The control mechanism is a group policy and provides group scoping for identities.

AD DS comprises a logical structure that often maps to the organization’s operating model and a physical structure that should map to the network topology.

The following can be considered as the logical components:

• Domain
• Domain tree
• Forest
• OU
• Partition
• Schema
• Container

The following can be considered as the physical components:

• Data store
• Global catalog
• Domain controller
• Read-only domain controller
• Site
• Subnet

These components will be covered in more detail later in this chapter.

This section introduced us to DS, one of AD’s services, which provides a centralized mechanism for authenticating and authorizing resources in a domain.

In summary, AD DS is built around a directory service that is a replicated information store (database) for all domain objects. It primarily provides authentication and authorization for accessing domain objects and configuration and management access.

In this section, we will look closer at the individual components of AD DS.

Objects

Objects refer to any element in the AD DS directory; examples of objects include printers, computers, users, groups, subnets, and so on. Objects have attributes that describe them; each will have required attributes and optional attributes. A name and an object identifier (OID) are two examples of required attributes.

In this section, we will look at the different classes of AD DS objects.

Container objects

These are built-in objects for logically grouping and holding other objects; think of these as hierarchical folder structures containing objects belonging to the same category or class.

When AD DS is installed, a set of default object containers are created; these will be visually represented as hierarchal folders. The following screenshot shows the default containers; some are hidden by default:

Figure 1.3 – Containers for objects

These default containers inherit a default set of permissions that are assigned to allow proper service administration and operations. These containers cannot be deleted, and you should not change the assigned permissions or delegate control of these; instead, you should create containers to meet your needs.

The essential containers to be aware of are as follows:

• The Domain container acts as the root container for the container hierarchy.
• The Builtin container provides a container that holds several default groups and default service admin accounts that are created when AD DS is installed.
• The Computers container provides a container that holds all computer account objects; it is the default location for all created computer accounts.
• The Users container provides a container that holds all user and group objects; it is also the default location for all created users and groups, some of which are automatically placed in this container location when AD DS is installed.
• The Domain Controllers OU container provides a container that holds the computer accounts for all DCs; it is the default location for all created DCs.

These default containers are automatically created when you install AD DS. They cannot be deleted, and assigned permissions and access control should not be modified. Still, custom containers can be created to meet your needs.

You can only apply policies to OU containers; to apply policies and delegate control over users or computers, you should create your own OU containers and move objects to those containers so that the policies and permissions can be applied.

The domain controllers container is an organizational unit (OU) container and is the only OU created by default when AD DS is installed. It is recommended that DCs not be moved out of their default location of the Domain Controllers OU container and not delegate control to non-service administrators.

Organizational unit

The OU functions as a container object and is used to collectively organize users, groups, and computers, providing a framework for targeting administrative control and policies on objects in the container.

An example of where OUs could be helpful is where you need to apply common administrative control to a group of resources that are part of the same workload (such as all Azure Virtual Desktop objects), environment (such as dev, test, prod, and so on), business unit, or region.

It is important to note that you can only link group policy objects (GPOs) to OU containers and not regular containers.

OUs can be created via the following methods:

• AD Users and Computers
• AD Admin Center
• PowerShell with the AD module
• Windows Admin Center (WAC), which is rapidly becoming the most widely adopted tool in hybrid environments

An OU structure can be hierarchal and map to organizational structures such as department, business group, or geography. These can be mapped to functions, projects, or resources such as workstations, servers, and so on.

OUs should group all those objects that need the same administration and policy settings and move them into an OU that can be controlled with Group Policy. If there are objects in an OU that you don’t want to have the policy applied to, then you can create a new OU and move the objects out to that OU so that the policy does not apply.

Hierarchal grouping is supported; you can nest OUs within OUs (just like any hierarchal folder structure). However, you should carefully plan the object grouping and hierarchy so that it isn’t too complex. Typically, five levels or less is optimum, and 10 is the recommended maximum to ease the admin burden and reduce complexity. You may also be constrained by a domain object resource that will only work with an OU structure of a supported method/configuration.

User objects

When a user account (an identity) is created in the directory, it’s classed as an object. It is one of the core and foundation object classes in the directory, along with computer objects. Hence, we will look at an AD DS management tool known as Active Directory Users and Computers later in this chapter.

For a user to be able to authenticate to domain resources, they must use a user account that AD DS provides. AD DS stores user accounts in its database with object-specific identity information and attributes such as the login username and password; these are used for the user to sign in to access domain resources.

In addition, other attributes include any organization-specific information that needs to be stored, such as job title, department, office, email, phone number, and more.

Regarding access management, the groups the user is a member of are listed. These group memberships are used to determine the level of access to resources in the domain; this is the concept of who you are and what access you have.

The recommended practice is that access rights are not given to user objects directly but to group objects. Users are members of groups, so they inherit their access permissions from their group memberships; this simplifies administration and makes troubleshooting access issues much easier and quicker.

Every user account object has a critical and primary attribute known as the User Principal Name (UPN). This is in an internet communication standard format typically recognized and expressed as an email address format – name@domain. However, it is essential to understand that it is not an email address. We recognize that a user’s email address could match their UPN and vice versa, but it’s not an explicit rule.

The user’s UPN is derived from a combination of the user’s login name and the domain name. The @ symbol is a form of join or delimiter between these two names; for example, the user Steve Miles in the milesbetter.solutions AD domain may have a UPN of smiles@milesbetter.solutions, where smiles is the user login attribute for the user account of Steve Miles.

Two other terms are the UPN prefix and UPN suffix; the UPN prefix is the part of the name before the @ symbol, while the suffix is the part of the name after the @ symbol. The UPN prefix and suffix components are shown in the following screenshot:

Figure 1.4 – UPN format

As in the previous user account example, the smiles login name attribute is then termed the UPN prefix, whereas the UPN suffix would be milesbetter. solutions, which refers to the domain part of the name.

Service objects

Service accounts are non-user-based account object classes used for applications and services that run in the background and require no user interaction. However, they still need to be authenticated to the directory service.

Managed Service Accounts (MSAs) are AD DS object classes that provide this service account capability; they benefit from lowering admin effort for Service Principal Name (SPN) management and service account password management.

There are two types of MSAs, as follows:

• Standard Managed Service Accounts (sMSAs) are local to a computer, service, or application and cannot be shared across other resources in the network. This limits their efficiency and adds an administrative burden. Needing to implement multiple local sMSAs increases the threat, security, and configuration drift surface area and exposure.

Further information about sMSAs can be found at https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-standalone-managed.

• Group Managed Service Accounts (gMSAs) have domain scopes and capabilities and can be used across multiple computers, services, and applications; NLB clusters and IIS are examples.

gMSAs require you to create a key distribution services (KDS) root key on a DC to create gMSA accounts.

The following are some AD PowerShell cmdlets that can be used to manage gMSAs:

• Get-ADServiceAccount
• Install-ADServiceAccount
• New-ADServiceAccount
• Remove-ADServiceAccount
• Set-ADServiceAccount
• Test-ADServiceAccount
• Uninstall-ADServiceAccount

Further information about gMSAs can be found at https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-group-managed.

Computer objects

Just as users have an account in the directory service so that we can search for and locate these users, we need the same mechanism to search for and locate computers in the domain. A computer object provides an account for a computer; it represents a computer resource on the network and allows it to uniquely identify itself and authenticate. Once a computer has a computer account, it can be managed as a domain resource and configured using Group Policy.

User account objects and computer account objects are the two foundation building block object classes in AD DS.

Group objects

Group object classes in the directory form the basis for access management.

Once you have been authenticated through your user account, your group object membership defines what you are authorized to access in the domain. The permissions assigned to the group define what actions you can carry out on that network resource.

Permissions shouldn’t be set at the user account level; this is an admin burden, inefficient, prone to configuration drift, and becomes a governance and security posture issue.

All permissions should be assigned to a group, and users should be made members of the appropriate groups to give them the required permissions. This makes it easier to govern and control policies such as joiners, leaver policies, or where people change roles and now require different access levels. Rather than change individual resource permissions directly for what they can now do/not do based on their new role definition, we can add or remove them to the appropriate groups based on their new role’s permissions requirements. This is much more efficient, less error-prone, and provides much better control and governance.

Adding user accounts to groups is an RBAC approach. The principle of least privilege should be adopted, meaning you only need just enough access to perform the tasks/activities required without the need for elevated permissions. This should be the cornerstone of protecting against lateral attacks following an account compromise.

In summary, by adopting the practice of creating groups, assigning permissions to groups, and then making user accounts members of those groups, we can efficiently manage access to resources for multiple users that all need the same access type.

Group types

There are two types of groups: security groups and distribution groups. Let’s look at these in more detail:

• Security groups are used as security-enabled logical containers to collectively group users to assign access permission to resources. This is a much more efficient way to assign a set of permissions to resources than assigning them individually to each user. For example, to control access to a network resource, we would create any number of groups, each with different levels of access permissions. Then, users can be added to the appropriate group(s), depending on what level of access they should have. We should ensure we follow the least privilege approach when assigning users to groups – that is, if they only need read access, then don’t make them members of a group with full-control permissions.

Two default security groups are created automatically when AD DS is installed; these groups are located in the Builtin and Users containers.

• Distribution groups are used as non-security enabled logical containers, that is, no permissions can be assigned to these groups, and are used for grouping users for providing some other form of non-security related administration, and to target a subset of users, often a business unit, team, or project focus. Most commonly used for email applications, for sending emails to target all group members.

Group scopes

Groups also have a scope. This defines where they can exist/be effective, the types of members that can be added, and the capabilities and permissions that the group supports.

Four types of group scopes are supported in Windows Server: local groups, domain-local groups, global groups, and universal groups. Let’s look at these in more detail:

• Local groups are effective only on the local machines they are created on and cannot be created on DCs; for clarity, these are not domain objects and exist only on local machines. The following are characteristics of local groups:
  • Abilities and permissions: Can be assigned to local (non-domain) resources only
  • Members: Any user account of the forest
• Domain-local groups only apply locally to the domain created within and exist on the AD DS DCs for that domain. They are the primary means of managing access rights and responsibilities to resources within the local domain. The following are characteristics of domain-local groups:
  • Abilities and permissions: Can only be assigned to domain-local resources
  • Members: Any user account of the forest
• Global groups are used to collectively group user accounts that share similar functions; this could be based on geographic location or business unit. The following are characteristics of global groups:
  • Abilities and permissions: Can be assigned to any forest resource
  • Members: Local domain only
• Universal groups are used in multi-domain environments and combine the functions of the domain-local and global groups. The following are characteristics of universal groups:
  • Abilities and permissions: Can be assigned to any forest resource
  • Members: Any user account of the AD DS forest

You set the group type and scope at the time of creation and choose based on your needs and requirements for each group; this must be given adequate planning.

This section looked at AD DS objects. The next section will look at the AD DS domain and domain tree topology.

Domains

As inferred by the name Domain Services, a domain is the core foundation component and the building block of AD DS. A domain is a logical container of objects in the directory for management purposes. AD DS directory objects could be user accounts, computer accounts, groups, printers, and so on; all objects within that domain are bound by and share the same admin and security policies.

The domain is an administrative and replication boundary for AD objects; security boundaries are only implemented at the forest level. We will explore this in the Forests section.

A domain has one or more DCs. This is a Windows Server role responsible for authenticating requests to access resources in the domain, such as authenticating and authorizing a login request to a computer or accessing a storage file share. The DCs hold a copy of the AD DS database that is writeable; we will look at the concept of RODC and its use cases later.

Domains have a hierarchal topology, referred to as a domain tree. It consists of domains in a parent/child relationship that share a parent root domain; they also share a contiguous namespace in DNS.

The AD DS domain and domain tree are shown in the following diagram:

Figure 1.5 – Domain topology

AD DS uses a multi-master replication model, meaning that any DC can make changes to objects in the directory stored in the AD database. When changes to the domain are made on a DC, such as adding, removing, or changing an object, these changes are replicated to all other DCs in the domain. In a multi-domain case, only a subset of changes is replicated to all domains.

When the AD DS role is installed on Windows Server, a deployment option is provided for creating a new domain in an existing forest or a new domain in a new forest. The first domain in a new forest becomes what is known as the forest root domain; this is analogous to saying whether you would like to create a city in an existing state or whether you would like to create a new state and make this the first and parent/founding/capital city in that state – that is, the first domain in the new forest becomes the capital city, also known as the forest root domain.

This section looked at the AD DS domain and domain tree topology. The next section will look at the AD DS forest topology.

Forests

A forest is a top-level logical container definition. It is a collection of one or more domains that share a common parent root domain, schema, and global catalog that has a contiguous namespace; it is considered a security and administrative boundary.

To implement a security boundary for objects, they must be placed in different forests; all objects in a forest share the same security controls. It is a common misunderstanding that placing objects in different domains will isolate them between domains. It is essential to note this is not the case; only placing them in different forests can provide this isolation. The following diagram shows a visual representation of a forest:

Figure 1.6 – Forest topology

The forest topology (structure or layout) means that a forest can contain one domain or multiple domains across multiple domain trees, much like a country can contain many states, which are collections of independent and autonomous cities. Each state would contain a state capital city; we refer to this as the forest root domain.

In this section, we looked closely at various AD DS components. In the next section, we will look at the function of AD DS trusts.

Trusts

Trusts are implemented to access resources when multiple domains and forests exist within an environment. Depending on the type of trust, these trusts can be one way or two way.

A trusted domain object is stored in the system container in AD DS and provides information on the trust types that have been created.

The most common trust types that can be implemented are as follows:

• Parent and child trust: This is created when a new domain is added to an existing tree. It is a transitive, two-way trust.
• Tree-root trust: This is created when a new tree is added to an existing forest. It is a transitive, two-way trust.
• Forest trust: This is a trust between forests and allows two forests to share resources. It is a transitive one-way or two-way trust.
• Shortcut trust: This is a trust created manually when authentication time between domains in different parts of the forest needs to be reduced. It is a nontransitive one-way or two-way trust.
• External trust: This is a trust that allows access to resources from a domain in another forest or an NT 4.0 domain. It is a nontransitive one-way or two-way trust.
• Realm trust: This is a trust between AD DS and a directory service other than AD DS that implements a Kerberos version 5 protocol realm. It is a transitive or nontransitive one-way or two-way trust.

These trust relationships are shown in the following diagram:

Figure 1.7 – Trusts

All automatically created two-way trusts in the forest are transitive. If domain B is trusted by domain A, and domain D is trusted by domain C, then domain A trusts domain C and D. This is a complex way of saying all the domains trust all the other domains in the forest.

However, in contrast, trusts between forests are not transitive, which means that if there are trusts between forests A and B and forests B and C, then C is not implicitly trusted by forest A.

Note that when a trust is set up between forests or domains, a function known as SID filtering is enabled by default. The purpose is to remove all foreign security identifiers (SIDs) from a user’s access token when using a trust in the trusting domain to access resources. Although it should be disabled to allow access to resources via the trust, you can disable this on the outgoing trust of the trusting domain.

When it comes to SID filtering and resource access across trusts, it is important to understand the trust direction and its relationship to the direction of access and which way the trust relationship is set up – that is, outgoing or incoming. This can be unclear; the core concept is that the direction of trust will be the opposite of the direction of access. This is shown in the following diagram:

Figure 1.8 – Trust direction

This means that if you want to access resources in another forest, there must be an outgoing trust; conversely, an incoming trust allows outgoing access.

One final concept to note is that of the trust authentication types. External and forest trusts provide two modes of authentication: forest-wide authentication and selective authentication.

Further information about trusts can be found at https://docs.microsoft.com/en-us/azure/active-directory-domain-services/concepts-forest-trust.

In this section, we looked at AD DS trusts. Now, let’s look at the AD DS data store.

Data store

A directory information store holds the AD database, which uses the Extensible Storage Engine (ESE) based on the Jet database engine.

The database is made up of two files – the database file itself (named NTDS.DIT and located in C:\Windows\NTDS directory by default) and the transaction log file (named EDB.LOG and also located in C\:Windows\NTDS directory by default). These files are stored on each DC. The group policy files for the group policy objects are stored in the SYSVOL folder.

The AD DS database file (NTDS.DIT) contains four partitions (or naming contexts) that contain all the domain-related information. Different data is stored in each partition, and each partition is replicated between DCs with a dependent replication scope and schedule.

These partitions are shown in the following diagram:

Figure 1.9 – AD DS database partitions

Let’s look at these four directory partitions in more detail:

• The schema partition is where the AD DS schema is stored; this defines what can be stored in the AD database
• The configuration partition is where the configuration information for the forest and domain trees is stored, such as site and replication information
• The domain partition is where object information for the domain is stored – that is, information about the user and computer objects
• The application partition is where applications can store data in AD; multiple application partitions may exist

In this section, we looked at the AD DS data store, which contains the AD DS database. We also looked at the partitions for the AD database. In the next section, we will look at the AD DS schema.

Schema

The schema is a partition of the AD database; it provides the definitions for the object classes (categories) that can be stored in the directory and the object-describing attributes. The object classes and object attributes are schema objects; in other technology areas, they would be referred to as metadata – that is, data describing the data.

The schema can be edited and allows you to create, modify, and disable object categories and attributes of objects. The schema is forest-wide, so any change is replicated to every domain in the forest. Understand the impact before committing any changes to the schema. In addition, be aware that deletions are not supported in the schema.

The default built-in group schema administrators control access to the schema; you must be a member of this group to make changes to the schema.

In this section, we looked at the AD schema. In the next section, we will look at AD DS DCs.

Domain controllers

A DC is a server with the AD DS role installed; it holds a writeable copy of the AD database and functions through the multi-master replication model for this information store. It also provides a store for GPOs. It ensures that the configuration settings are applied to domain-managed objects.

The DC is also a Kerberos Key Distribution Center (KDC). Kerberos is the mechanism for all authentication and authorization within AD; a Kerberos key identifies an object (authentication – that is, who you are) and outlines what resources an object can access (authorization – that is, what you can do and access).

DCS must be highly available to process logon requests; they are required to authenticate requests for access to domain resources and apply policies for managing and configuring objects in the directory stored in the AD database.

All computers and users that wish to access objects in an AD DS domain must be authenticated by a DC, so their placement, operation, and availability are crucial.

Read-only domain controller

In Windows Server 2008, the read-only domain controller (RODC) concept was introduced as a deployment option. An RODC server holds a copy of the AD database and supports one-way, incoming replication. No direct changes can be made to the directory (such as LDAP writes); the only changes that can occur are those that are made via replication. A change should be made on a DC, allowing replication to push those changes to the RODC.

The RODC role was intended as a branch office for other locations that may not have adequate security to protect against Kerberos system components being compromised, such as the KDC, which is a database of keys, and the Ticket Granting Service (TGS), which is used to obtain Kerberos session keys. Unlike DCs, which share a Kerberos key, RODCs each have a unique key, minimizing the risk of exposing remote sites that may be isolated from secured and controlled corporate networks.

RODCs have two other use cases. The first is where locations, such as branch offices, don’t have a lot of bandwidth for replication traffic. The other scenario is to support the principle of least privilege so that the local server admin account does not need to have domain admin access to function.

This section looked at DCs and their role in AD DS. Now, let’s look at the global catalog and its purpose.

Global catalog

The global catalog (GC) runs as a service on DCs and provides an index that allows you to look up information for every object listed in the AD forest (such as group memberships).

The GC holds a list of every object in the directory, but not every attribute for those objects; the schema defines what attributes of the objects are stored in the GC. The schema can be modified to allow those object attributes you want to appear in the GC so that they can be looked up in the GC.

When a user logs in, a GC must be contactable to look up a user’s universal group membership; however, when universal group caching is enabled, contacting a DC with a copy of the GC is less critical.

As part of the DC deployment, the first DC created in a forest holds a copy of the GC by default; this is for hybrid environments. GC placement should be designed for availability in each site, and perform local site searches to optimize network traffic. A DC that does not have a copy of the GC will have to send traffic over a WAN link to a site with a copy of the GC. GC placement is an important design decision; we will cover sites later in this chapter.

In this section, we looked at the purpose of the AD DS Global Catalog service. In the next section, we will look at the function of the operations master roles.

Operations master roles

Although AD DS runs on a multi-master model, some single master operation roles are known as Flexible Single Master Operations ((FSMO), pronounced fizmo) roles and run on DCs.

As the name implies, these are single instance roles. They are not replicated, so this does, to some extent, introduce a single point of failure. If a DC holding that role goes offline, then any operations that rely on being able to contact that role will not be available. This should be considered while managing expectations in any design.

The five FSMO roles are categorized as forest and domain operations scopes. These are as follows:

• Schema master (forest operations scope)
• Domain naming master (forest operations scope)
• RID master (domain operations scope)
• Infrastructure master (domain operations scope)
• PDC emulator master (domain operations scope)

Not all FSMO roles are created equal – some should be available for daily operations, while others are not required all the time. They each have different functions they perform, and some roles being available are more critical than others – that is, the schema master role could be offline. Only when you want to make schema changes would this impact you.

In this section, we looked at the function of AD DS operations master roles. Now, let’s look at AD DS sites and subnets.

Sites and subnets

A site is an AD object representing a collection of IP subnets connected over low latency connections and supporting local Remote Procedure Calls (RPCs). You can think of a site as a physical location that maps to your network WAN topology.

A subnet object represents each subnet where a DC is located; a subnet object will be part of a site object and can only be created as a one-to-one mapping – that is, a subnet can only be part of a single site.

The site topology is shown in the following diagram:

Figure 1.10 – Site topology

By default, there will be a single first site called Default-First-Site-Name (which can be renamed), containing all the subnets where a DC is located. However, in terms of network traffic for replication, user authentication, directory searches, and so on, this is often not an efficient implementation of sites and site design.

A site structure should map to the WAN topology of an organization, and you should create as many sites as needed to replicate this topology. This is to optimize replication so authentication can stay local to the site.

A DC determines its site by looking at the subnet object that matches the subnet that it is part of. After that, it uses the site associated with that subnet to determine the site it belongs to. This means it will control what site a DC belongs to; you must ensure that the DC is located in the subnet associated with that site or that the site contains that subnet.

Site links

Site links are the replication paths between sites; you determine which links the replication traffic goes over. When there is no DC in a client’s local network, site links are used to direct client traffic to a site with a DC; you should consider the reasoning for not having a DC at each location to gain access to domain resources.

It is always recommended to put a DC close to clients who need access to a DC to authenticate resources, perform directory searches, and so on. You shouldn’t have traffic pass over a WAN link but, instead, stay on the local network.

For this purpose, you should always create site design maps for your network topology. In a hybrid environment, this will often require you to go beyond the default and out-of-the-box setup of the single first site design; the default site link used to connect sites is called DEFAULTIPSITELINK.

This section concludes the first of the three skills areas of this chapter – understanding the concepts and components of AD DS. We looked at what AD is and looked at each component. In the next section, we will look at the second of this chapter’s three skills areas: creating AD DS.

This section will cover some planning aspects and information about the components that will be created as part of a deployment. We will also cover deploying DCs on-premises and deploying Azure as Infrastructure as a Service (IaaS) resources and other considerations.

Planning for availability and performance

Before diving straight into deploying, let’s cover some planning steps.

The availability of the AD DS database is provided by the built-in native capability of the multi-master replication model, where the data is replicated across multiple DCs; there is no master-slave.

Deploying at least two DCs is a recommended best practice to provide the necessary services and AD database availability through this native replication capability.

This can be a double-edged sword in that it has pros and cons; multiple DCs can be made available to process authentication and authorization for access to domain resources, especially in the case of many multiple concurrent requests, such as login storms to a virtual desktop infrastructure, or a line of business (LoB) app or service. However, the downside is that this data replication can cause network congestion when data is transferred across the network. We can address this through sites and links, which help control this replication traffic. With that said, to address most enterprises’ availability and performance needs, you should have at least two DCs per geographical region. Here, each geographical region represents a site that improves performance and reduces replication and auth traffic over a WAN link to remote DCs; instead, this traffic can stay local to the region’s network.

Planning for data protection

In this section, you will learn how to protect your AD DS data store, which holds your database. We will also look at how to restore AD DS.

When we talk about data protection in general terms, the industry focuses on backing up data, which is an important task to discuss. However, the focus should always be on the desired outcome rather than the action – that is, we must focus on restoring data rather than backing it up. We always hear about backup strategies, but I encourage you to consider your restore strategy.

With AD DS, two levels of data protection are provided and, more importantly, data recovery; these are the AD recycle bin and being able to restore from a traditional backup copy of the data (this must have the included system state). Let’s look at each of those methods in more detail.

Recycle bin restore

The recycle bin is the first level of object restore and allows you to quickly and efficiently restore objects that may have been accidentally deleted. It only allows you to restore any deleted objects in the directory. It can’t roll back any changes made to an object by recovering to an earlier time; this can only be achieved with a traditional data backup method.

The recycle bin’s primary benefit is its Recovery Time Objective (RTO) – the time it takes to bring a deleted object back into operation. This can be achieved by requiring no downtime on the server, which would be required from the more traditional restore from the backup data approach.

For simplicity and speed, which are needed in a data recovery crisis, this restore can be performed from within the UI of the server itself. No backup software or hardware components need to be installed, and no license needs to be configured or paid for. However, the feature must be enabled, so it is important to do this before putting any DC into operation.

Once enabled, you will see it referenced as the Deleted Objects container in the AD Administrative Center (ADAC). Objects have a lifetime of 180 days by default, though this can be changed. The original location or alternate location can be set as the restore location.

Backup copy restore

The traditional Windows Server backup method is the next level of object restore; however, it has a much longer RTO due to the temporary offline nature of the traditional restore method when using a backup copy of the data to restore from. The system state must be explicitly included for the backups jobs to restore AD DS using the traditional Windows Server backup method.

The NTDSUtil, replmon, and repadmin command-line tools can also be used in the data protection operations to run validations, restore, seize FSMO roles, and so on.

Windows Server has a safe mode boot for DCs; this is called Directory Services Restore Mode (DSRM), allowing you to restore the directory database. Two types of restoration can be carried out: an authoritative restore and a non-authoritative restore. Let’s briefly look at each.

Authoritative restore

This type of restore replaces objects in the directory with a copy of the objects stored in the backup.

An authoritative restore means you wish to set the restored objects so that they persist in the directory and replace all the other copies of the objects through replication. That is, all the other DC copies will be updated and made consistent with the copy of the database stored in the restored DC.

Non-authoritative restore

This type of restore also replaces objects in the directory with a copy of the objects stored in the backup. However, the objects are not persisted, and the DC requests a pull replication from other DCs to ensure it has the latest copies of the database, including any changes that were made since the backup occurred; the restored objects are not restored to other DCs.

In this section, we looked at AD DS data protection. Now, let’s learn how to deploy AD DS DCs.

Deploying domain controllers

In this first section of this top-level topic, we will collectively look at deploying AD DS DCs in several scenarios, including deploying to on-premises platforms and deploying to the Microsoft Azure public cloud platform using IaaS virtual machines (VMs). However, note that deploying domain controllers for Azure AD DS won’t be covered here; this will be covered in Chapter 2, Implementing and Managing Azure Active Directory Domain Services.

Deploying a DC on Windows Server using Server Manager GUI

A DC is a server with the AD DS role installed on it. This can be installed and configured in many ways, such as via PowerShell, Server Manager, or WAC. As we continue our hybrid journey, we will see that WAC, in many cases, will often be the preferred and most optimal deployment and management tool for many hybrid scenarios.

A critical part of AD DS is DNS; AD DS requires a DNS server. The DNS server role is typically installed on the DC as part of the deployment configuration and will use AD-integrated DNS for a seamless experience.

Regarding availability, to ensure users can still log on, servers and other resources can authenticate to a DC if a DC can’t be reached. A minimum of two should be deployed for each domain in the forest. DCs should be placed as close to where the resources that require authentication are located, and ideally, in each physical location that requires local authentication to take place to reduce authentication traffic that would have to occur over a Wide Area Network (WAN) connection. We covered this in more detail in the Sites and Site links sections.

When using Server Manager to install the AD DS role, the process will start by installing some AD DS components and tools on the server. Once completed, you will be prompted to complete the post-deployment configuration, which will step you through promoting this server to a DC.

The configuration wizard will prompt you with several deployment configuration selections; we will look at these in this section so that you understand these when it comes to the hands-on exercise.

For the deployment configuration, you can select Add a domain controller to an existing domain, Add a new domain to an existing forest, or Add a new forest. If this is a new deployment of AD DS rather than deploying DCs to an existing AD DS instance, then you need to use the third option – add a new forest.

When you implement AD DS and deploy a domain and promote a server to be a DC that won’t be deployed into an existing AD forest, then, by default, a new forest will be created as the top-level container in the topology or hierarchy for the new AD DS instance. The first domain that’s created will be created as the forest root domain:

Figure 1.11 – Deployment operation options

Here, you specify a domain name for the root domain name; all subsequent child domains created within the forest will share the same contiguous DNS namespace. To define a domain with a new DNS namespace within the same forest, you would need to use the Add a new domain to an existing forest option, creating a new domain tree. This is shown in the following diagram:

Figure 1.12 – Domain tree

Once the deployment configuration step is complete, you will be presented with the Domain Controller Options screen. From here, you can set the forest’s functional level. Note that this is where you get to set the DC’s capabilities.

Note that at the bottom of this screen, there is a hyperlink for More about domain controller options. This will take you to the Microsoft documentation. If you haven’t done so already, it is recommended that you follow this link and study the information in the documentation before proceeding so that you are aware of all the information we do not have space to cover in this book:

Figure 1.13 – Domain controller options

As shown in the preceding screenshot, you can choose whether the DC should be a DNS server. Note that the Global Catalog (GC) option is automatically assigned as the first DC in a new domain and that the Read-only domain controller (RODC) option is grayed out; again, this is because this is the first DC in the domain. When you choose the Add a domain controller to an existing domain option on the previous Deployment Configuration screen, these options can be selected; we will look at installing an RODC later.

On the following screens, you have the option to create DNS delegation records and verify and change the generated NetBIOS name if necessary.

Under the Paths section of the configuration wizard, you can specify different locations for the AD DS database, log files, and SYSVOL:

Figure 1.14 – Install paths

You should specify the location that meets your needs; the component’s paths can impact the performance of AD DS. This is more critical when installing AD DS on IaaS VM DCs, which we will look at later in this chapter, due to disk caching.

Deploying a DC on Windows Server Core

There is no GUI on Windows Server Core. So, to install AD DS, you need an alternative method such as Windows PowerShell with the AD module; alternatively, you can use the Remote Server Administration Tools (RSAT), Windows Admin Center, Server Manager, and PowerShell remoting tools from a remote machine that can connect to the server’s core machine.

Deploying a DC from media

This is only for deploying additional DCs to an existing AD DS environment. This deployment approach creates a backup of AD DS and then transfers it to removable media such as a USB drive. You start by deploying AD DS on the server that will be the DC via the Server Manager GUI and select the Install from media option. This is very similar to a non-authoritative recovery – that is, the AD DS database and its objects will only be as current as the date when the backup was taken. So, to get the latest changes to the directory since the backup, pull replication must occur. This will ensure that the new DC is consistent with all the other DCs and has the same copy of the directory objects.

Deploying a DC in Azure as IaaS

As we learned earlier in this chapter, as well as deploying DCs to on-premises platforms, we can also deploy DCs to the Microsoft Azure public cloud platform as IaaS VMs. However, note that deploying AD DS is not covered here and will be covered in Chapter 2, Implementing and Managing Azure Active Directory Domain Services.

When deploying a DC in Azure or the AD DS role in an IaaS VM, there are some considerations you need to be aware of:

• Networks: To add DCs to an existing AD DS environment, you should consider network connectivity. Here, you must have a line of sight to those existing DCs. This will require your networks that have DCs placed on them to be extended into Azure. This is typically done over a VPN or, in some scenarios, ExpressRoute.
• Sites/Subnets: These should be created to reflect the address space(s) defined in your Azure VNet.
• DNS: Azure AD DNS cannot be used for AD DS; you should use the DNS role within Windows Server or Azure private DNS zones.
• VMs: Due to the burstable CPU capability in the B Series VMs, they are an excellent fit to be used for DCs.
• Disks: Since implementing AD DS will install a database on the VM; we should follow some guidance on that scenario – that is, we shouldn’t install on any disks that have caching enabled – especially write caching. To meet this guidance, you should not place the NTDS.DIT and SYSVOL files in the default path offered to you during the configuration wizard; instead, you should attach a data disk to the VM (which has to write caching off by default) and change the path to store these files in the data drive.

Deploying an RODC

To deploy an RODC, we can use a pre-staged account to perform the AD DS install tasks. This will ensure that a user does not need to be a member of the domain’s admin group or enterprise admins group.

A new site and subnet should be created to control this traffic replication to the RODCs. The replication schedule can be set on the default site link.

Upgrading the OS of an existing DC

The underlying OS of a DC from Windows Server 2012 R2 to Windows Server 2022 can be upgraded as if it did not have the AD DS role installed. There are no differences, known issues, or limitations placed on it because it performs as a DC.

This section concludes the second of this chapter’s three skills areas: creating AD DS, where we looked at planning and deployment information. In the next section, we will look at the last of this chapter’s three skills areas: managing AD DS.

This section will introduce managing AD DS and the tools that are used. We will look at Active Directory Administrative Center, Remote Server Administration Tools, Windows Admin Center, and PowerShell, along with the AD module and other additional management tools.

Active Directory Administrative Center (ADAC) is a PowerShell-based GUI available in Windows Server (not in Windows Server Core).

The following tasks can be carried out with this tool:

• Manage multiple domains through a single tool instance
• Search the directory for objects
• Create and manage directory objects, such as users, groups, computers, and OUs
• Manage Dynamic Access Control
• Create and manage fine-grained password policies
• AD recycle bin operations

This tool replaces the functionality previously provided through the Microsoft Management Console (MMC) snap-in tool known as Active Directory Users and Computers.

Further information about ADAC can be found at https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/active-directory-administrative-center.

Now, let’s look at the management tools that can be used for the Azure AD DS managed domain.

RSAT

RSAT allows you to manage servers remotely via a GUI; a set of AD DS tools is included. This was the primary tool console until the introduction of WAC, which we will look at in the next section.

The consoles for these tools are available on Windows 10/11 and Windows Server. With Windows 10/11, these tools are now included within the OS rather than a separate download, which was added through the Optional features setting.

Further information about RSAT can be found at https://docs.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/remote-server-administration-tools.

WAC

This browser-based admin tool can be downloaded and installed locally on Windows 10/11 and Windows Server. It can also be accessed directly via the Azure portal, so no download or local install is required, much like CloudShell has to install PowerShell locally.

For a local install of WAC, you must ensure your network allows the required ports; the default is port 6516 for standalone mode in Windows 10. The gateway mode in Windows Server is TCP 443. Both can be changed.

Further information about WAC can be found at https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/overview.

PowerShell with the AD module

This is an alternative to using a GUI to manage AD DS. You can use PowerShell commands via an AD module that provides a collection of cmdlets.

If you wish to use the module on a local install of PowerShell on a client/desktop OS such as Windows 10/11, then the module is part of RSAT, which you will need to download and install.

Further information about the AD module can be found at https://docs.microsoft.com/en-us/powershell/module/activedirectory/?view=windowsserver2022-ps.

MMC snap-in tools

MMC is a GUI console that contains a collection of tools called snap-ins. The following snap-in tools are available for managing AD DS, most of which are self-explanatory:

• Active Directory Users and Computers allows you to carry out everyday tasks to manage objects such as users, groups, and computers; this is replaced by ADAC and provides additional capabilities
• Active Directory Sites and Services allows you to create and manage sites, subnets, replication, and associated services
• Active Directory Domains and Trusts allow you to create and manage domain and forest trusts
• Active Directory Schema snap-in allows you to view and modify the schema

Further information about MMC can be found at https://docs.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/what-is-microsoft-management-console.

This section looked at a variety of AD DS management tools. In the next section, we will look at some of AD DS’s monitoring and troubleshooting tools.

Monitoring and troubleshooting tools

In this section, we will look at some of AD DS’s monitoring and troubleshooting tools.

Performance monitoring tools

Windows Server contains the following built-in native tools for monitoring performance and analyzing service operations:

• Performance monitor – Directory Replication Agent (DRA) counters
• Resource Monitor
• Task Manager
• Event Viewer

These tools can help you analyze and identify any overutilization and depletion of these system resources. They will help you find the root cause and the source of any system performance issues caused by a bottleneck. A system can only suffer from one bottleneck at a time; this could lie in the CPU, memory, disk, or networking. You should address each in turn and then move on to the next.

Repadmin

This tool helps you view the service’s health and diagnose replication problems between DCs. It allows you to view the replication topology, manually create a replication topology, and force replication. It is available when the AD DS role is installed on a server and is also included as part of the AD DS tools in the RSAT tools.

Further information and syntax about Repadmin can be found at https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963(v=ws.11).

dcdiag

This tool will analyze the state of the health of AD DS DCs. It is available when the AD DS role is installed on a server and is also included as part of the AD DS tools in the RSAT tools.

Further information and syntax about dcdiag can be found at https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731968(v=ws.11).

netdom

This tool allows you to manage AD DS trusts; it can also join a computer to a domain, manage computer accounts, query for domain information such as which DCs hold the FSMO roles, and more. It is available when the AD DS role is installed on a server and is also included as part of the AD DS tools in the RSAT tools.

Further information and syntax about netdom can be found at https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc772217(v=ws.11).

In this section, we looked at some of AD DS’s monitoring and troubleshooting tools. In the next section, we will complete a hands-on exercise to reinforce some of the concepts covered in this chapter.

To support your learning with practical skills, let’s learn how to create some of the services we looked at in this chapter. You will learn how to install AD DS on Windows Server.

Getting started

To start this hands-on exercise, you will need access to a physical or virtual machine running Windows Server 2012 Standard/Datacenter or later.

For this exercise, we could use a nested virtualization environment in Azure, meaning no on-premises hardware is required. However, to help you with your learning and demo purposes, we will complete this exercise using IaaS VMs in an Azure environment where we have the correct level of access to create the required resources.

You can create a free Azure account at https://azure.microsoft.com/free. This free Azure account provides the following:

• 12 months of free services
• $200 credit to explore Azure for 30 days
• 25+ services that are always free

If you will be using Azure IaaS VMs for DCs, then recommended practice is that each VM should have a data disk attached to store the AD DS database, log files, and SYSVOL. Alternatively, you could install them on the default paths provided for learning purposes. However, this should not be done in a production scenario.

Let’s move on to the exercise.

Exercise – installing AD DS on Windows Server

This section will teach you how to install AD DS on Windows Server.

The following steps must be carried out on the local OS of a machine you have admin access to. We will install the AD DS role directly on the server we wish to be our first DC in our new domain, in a new forest; we will not use remoting.

The Server Manager Add Roles wizard and the AD DS Configuration wizard are used to install and configure AD DS.

Follow these steps:

Note

The dcpromo.exe AD DS Installation Wizard has been deprecated as a deployment method starting with Windows Server 2012.

1. Log in to your server. Then, from Manage in Server Manager, click Add Roles and Features:

Figure 1.15 – Server Manager

2. On the Before you begin page, click Next.
3. On the Select installation type page, leave Role-based or feature-based installation set and click Next.
4. On the Select a destination server page, leave Select a server from the server pool set and ensure the server where you want to install AD DS is selected. Then, click Next.
5. From the list of available roles on the Select server roles page, select the box for the Active Directory Domain Services role:

Figure 1.16 – The Select server roles screen

6. From the Add Roles and Features Wizard pop-up screen, click Add Features:

Figure 1.17 – The Add Roles and Feature Wizard pop-up screen

7. Back on the Select server roles page, click Next.
8. On the Features page, leave all the defaults as-is, review the features selected as a reference, and click Next.
9. On the AD DS page, review the information and click Next.
10. If required, select Restart the destination server automatically on the Confirmation page. Then, review the selections installed as a reference and click Install.
11. On the Results page, observe and monitor the installation progress; click Close when you see a message stating the Installation succeeded on [YourServerName]:

Figure 1.18 – The Installation progress screen

12. From Server Manager, click on Notifications, then Promote this server to a domain controller:

Figure 1.19 – The Promote this server to a domain controller notification screen

13. On the AD DS Configuration Wizard pop-up screen, note the deployment operation options on the Deployment Configuration screen. Select Add a new forest for this exercise:

Figure 1.20 – The Deployment Configuration screen

14. Enter a domain name under the Root domain name and click Next:

For further reference, click the More about deployment configurations hyperlink at the bottom of the page:

Figure 1.21 – The Deployment Configuration screen

15. On the Domain Controller Options page, note that the Domain Name System (DNS) server and Global Catalog (GC) options are selected by default but that the Read only domain controller (RODC) option is not available; leave all the defaults as-is and enter the DSRM password and confirm. Then, click Install.

For further reference, click the More about domain controller options hyperlink at the bottom of the page:

Figure 1.22 – The Domain Controller Options screen

16. On the DNS Options page, ignore the message that states that delegation for this DNS server cannot be created and click Next.
17. Wait while the NETBIOS domain name is auto-populated on the Additional Options page. Then, click Next:

Figure 1.23 – The Additional Options screen

18. From the Paths page, specify the location for the AD DS database, log files, and SYSVOL. For this exercise, leave the defaults as-is. Then, click Next.

For further reference, click the More about Active Directory paths hyperlink at the bottom of the page:

Figure 1.24 – The Paths screen

19. From the Review Options page, review the selections and click Next.
20. The Prerequisites Check page confirms the status of all prerequisite checks. A green tick should appear with a message stating All prerequisite checks passed successfully. Click ‘Install’ to begin the installation. Then, click Install:

Figure 1.25 – The Prerequisites Check screen

21. From the Installation page, observe and monitor the installation progress; your server will automatically restart:

Figure 1.26 – Installation progress screen

22. From the login screen of the server, you will need to use the domain account for your user, not the local account; this will be in UPN format – that is, UserName@domain.name:

Figure 1.27 – Server login screen

23. From Server Manager, you will see that the AD DS role has been installed, as well as the DNS:

Figure 1.28 – Server Manager

24. From Server Manager, click Tools, then Active Directory Administrative Center:

Figure 1.29 – AD Administrative Center

Congratulations! You have completed this exercise and installed AD DS on Windows Server.

In this exercise, you installed AD DS on Windows Server and accessed it via the ADAC. This helped you reinforce this chapter’s theory, along with some practical skills.

Now, let’s summarize this chapter.

This chapter has provided coverage for the AZ-800 Administering Windows Server Hybrid Core Infrastructure exam learning objective: Deploy and manage AD DS in on-premises and cloud environments.

We learned about AD concepts, its services, such as AD DS and its components. We looked at the creation and management of AD DS instances in on-premises environments. A hands-on exercise then finished the chapter to provide you with additional practical skills.

This chapter aimed to take your knowledge beyond the exam objectives; we added new skills and learning with the content provided. This further develops your knowledge and skills for on-premises network infrastructure services and enables you to be prepared for a real-world, day-to-day hybrid environment-focused role.

In the next chapter, you will learn about some of the concepts and components of Azure AD DS and learn how to create and manage an Azure AD.

This section provides links to additional exam information and study references:

• Microsoft Certified: Windows Server Hybrid Administrator Associate: https://docs.microsoft.com/en-us/learn/certifications/windows-server-hybrid-administrator/
• Exam AZ-800: Administering Windows Server Hybrid Core Infrastructure: https://docs.microsoft.com/en-us/learn/certifications/exams/az-800
• Exam AZ-800: skills outline: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWKI0r
• Microsoft Learn: Deploy and manage identity infrastructure: https://docs.microsoft.com/en-us/learn/paths/deploy-manage-identity-infrastructure/

Challenge yourself regarding what you have learned in this chapter:

1. What is Active Directory?
2. List three services that form part of Active Directory.
3. What is Active Directory Domain Services?
4. Explain the difference between AD and Azure AD.
5. What is Hybrid Identity?
6. What is the difference between Authentication and Authorization?
7. List seven logical components of AD DS.
8. List six physical components of AD DS.
9. What are AD DS objects?
10. What is an OU?
11. What is a service object, and how does it differ from a user object?
12. What is the difference between Standard and Group Managed Service Accounts?
13. What is a UPN?
14. Explain the group types and scopes.
15. Explain domains and forests.
16. List the trust types.
17. Explain trust directions.
18. What is a domain controller?
19. What are the five FSMO roles?
20. How can replication traffic be minimized?
21. List three considerations for deploying AD DS in Azure with IaaS VMs.
22. What are the two levels of AD DS data protection?
23. Name five AD DS management tools.
24. What is the dcdiag tool used for?
25. What is the netdom tool used for?