Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Active Directory Administration Cookbook

You're reading from   Active Directory Administration Cookbook Actionable, proven solutions to identity management and authentication on servers and in the cloud

Arrow left icon
Product type Paperback
Published in May 2019
Publisher Packt
ISBN-13 9781789806984
Length 620 pages
Edition 1st Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Sander Berkouwer Sander Berkouwer
Author Profile Icon Sander Berkouwer
Sander Berkouwer
Arrow right icon
View More author details
Toc

Table of Contents (16) Chapters Close

Preface 1. Optimizing Forests, Domains, and Trusts FREE CHAPTER 2. Managing Domain Controllers 3. Managing Active Directory Roles and Features 4. Managing Containers and Organizational Units 5. Managing Active Directory Sites and Troubleshooting Replication 6. Managing Active Directory Users 7. Managing Active Directory Groups 8. Managing Active Directory Computers 9. Getting the Most Out of Group Policy 10. Securing Active Directory 11. Managing Federation 12. Handling Authentication in a Hybrid World (AD FS, PHS, PTA, and 3SO) 13. Handling Synchronization in a Hybrid World (Azure AD Connect) 14. Hardening Azure AD 15. Other Books You May Enjoy

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.

You have been reading a chapter from
Active Directory Administration Cookbook
Published in: May 2019
Publisher: Packt
ISBN-13: 9781789806984
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image