Book Image

Active Directory Administration Cookbook

By : Sander Berkouwer
Book Image

Active Directory Administration Cookbook

By: Sander Berkouwer

Overview of this book

Active Directory is an administration system for Windows administrators to automate network, security and access management tasks in the Windows infrastructure. This book starts off with a detailed focus on forests, domains, trusts, schemas and partitions. Next, you'll learn how to manage domain controllers, organizational units and the default containers. Going forward, you'll explore managing Active Directory sites as well as identifying and solving replication problems. The next set of chapters covers the different components of Active Directory and discusses the management of users, groups and computers. You'll also work through recipes that help you manage your Active Directory domains, manage user and group objects and computer accounts, expiring group memberships and group Managed Service Accounts (gMSAs) with PowerShell. You'll understand how to work with Group Policy and how to get the most out of it. The last set of chapters covers federation, security and monitoring. You will also learn about Azure Active Directory and how to integrate on-premises Active Directory with Azure AD. You'll discover how Azure AD Connect synchronization works, which will help you manage Azure AD. By the end of the book, you have learned about Active Directory and Azure AD in detail.
Table of Contents (16 chapters)

Choosing between a new domain or forest

In organizations, sometimes, an expansion or business change requires changes in Active Directory too. In Active Directory terms, the change might require creating a new Active Directory domain or a new Active Directory forest. In this recipe, we'll look at the reasoning between these two choices, taking the entire life cycle of Active Directory into consideration.

Why would you have a new domain?

A new Active Directory domain—as either a subdomain of an existing domain, or a new domain tree in an existing forest—provides a boundary.

The boundary of domains in Active Directory relates to the following:

  • DNS name: An additional domain tree offers the possibility to add a DNS domain name to the organization to, for instance, correctly label a new business venture. An alternative might be to add an additional UPN suffix.
  • Domain DNS zones replication: Throughout an Active Directory forest, all domain controllers replicate to exchange information on objects, schema, and configuration. Between domains, a distinction can be made to limit the replication of information on Active Directory-integrated DNS zones. That way, this information is only replicated within the domain.
  • Password and account lock-out policies: Fine-grained password and account lock-out policies can only be applied within an Active Directory domain. The information can be viewed by any account in the domain. If you want to shield this information or create completely separate policies, an additional domain is the route to go.
  • Group Policy: Group Policy Objects (GPOs) only replicate within a domain. The only exception is the GPOs that are linked to Active Directory sites; these are copied between domains instead, since Active Directory sites are created at the forest level.

However, the boundary of domains in Active Directory does not include the following:

  • An Active Directory schema
  • The scope of the enterprise administrators group

Essentially, a new Active Directory domain is an administrative boundary, which you can create for an organization to allow for delegated management.

What are the downsides of a new domain?

Microsoft's advice is to keep Active Directory as simple as possible. When you create additional domains, the organization ends up with the following:

  • At least two additional domain controllers
  • Active Directory trusts between the current domain(s) and the new domain
  • An increase in administrative burden

Why would you create a new forest?

A new Active Directory forest is basically a completely new Active Directory environment. When you create it, it does not have a relationship with an existing Active Directory environment, unless you choose to create Active Directory trusts afterward.

Since the new Active Directory forest is separate, a boundary is created for the following reasons:

  • Schema and configuration partitions: The schema and configuration partitions hold information on the way that objects can be created, what attributes are required for these objects, what attributes are optional for these objects, and the domains within the forest. Since many applications require Active Directory schema extensions, introducing a legacy or cutting-edge application might result in schema conflicts. In these types of scenarios, creating an additional Active Directory forest is the best way forward. An alternative might be to add an Active Directory Lightweight Directory Services (AD-LDS) instance to the environment.
  • Global catalog replication: Domain controllers with the additional global catalog role hold partial information on the most requested attributes for objects in Active Directory. With multiple global catalogs, the information is replicated throughout the forest. To shield this information, an additional Active Directory forest can be created.
  • Forest DNS zones replication: To overcome the default boundary for Active Directory-integrated DNS zones, the Forest DNS zone replication scope, an additional Active Directory forest can be created.

When requirements apply in terms of schema or replication, creating an Active Directory forest is the right choice. One thing that might be good here is to state that the forest is a security boundary as well as an administrative boundary.

Additionally, since the forest is a separate environment, by default, it can also be separated afterward. In acquisition and divestiture scenarios that can be overseen for the life cycle of Active Directory, an Active Directory forest is also the right choice.

What are the downsides of a new forest?

A separate Active Directory environment, of course, requires double the administrative effort of Active Directory admins. Additionally, since the environments are separate, creating an address list in Microsoft Exchange Server or sharing common applications, services, and/or systems is hard.

Now we can look at the recipes covered in this chapter.