Windows Active Directory Family---Distributed Active Directory Deployment overview

An overview of the AD DS components:

What is an AD DS domain?

The AD DS domain is a tool that combines the logic of users, computers, and group objects together for centralized management and security. All of these objects are stored in the adds database, and a copy of the data is held on every domain controller in the domain. Therefore, the adds database has fault tolerance, and clients within the domain can access domain information on any one domain controller. Adds provides a searchable hierarchical directory, and a framework for application configuration and security settings for objects in the enterprise. You can use adds and GPOs to apply configuration and security settings to user and computer accounts.

What is the AD DS domain tree?

The adds domain tree is a collection of one or more adds domains in a contiguous namespace. For example, if the first domain in the forest is adatum.com, you can create another domain in this namespace as a subdomain, such as atl.adatum.com.

Sometimes including multiple domains in a forest is more appropriate for your enterprise environment. When you add a domain to an existing forest, you can join the domain as a subdomain to an existing domain, which joins the new domain into the domain tree. You can also use the created domain as a new domain tree in the forest. For example, Adatum company already has a adatum.com adds forest, followed by the acquisition of a company Fabrikam, then now need to create a tree in the adatum.com forest called fabrikam.com. Although this new domain is a new domain tree and generates a new namespace, it is still integrated in the existing forest.

What is an AD DS forest?

A adds forest is a collection of one or more adds trees. Each adds tree may contain one or more adds domains, and the adds forest is the outermost boundary of adds security and management.

What is a trust relationship?

Trust relationships Direct validation pipelines in different domains. Some trust relationships are generated automatically during the installation of a domain, and some trust relationships are created manually for different reasons. Domains in the trust relationship framework can share resources and provide a structure to support validation between domains.

What is a global catalog?

A global catalog is a central directory that holds information about each object in the forest and is unique within each adds forest. Unlike a separate domain partition, a separate domain partition holds the set of properties for all objects in a domain, which are writable, while the global catalog holds a read-only list that contains some of the properties of each object in the forest. In a multidomain environment, the global catalog can easily navigate to objects in different domains, such as the Exchange server using the global catalog to locate all mail senders in the forest.

Overview of the boundaries of domains and forests in the adds structure:

In adds deployment, domains and forests have different types of boundaries, and understanding of different types of boundaries is the basis for managing a complex ad environment.

Adds domain boundary:

The domain provides the following boundaries:

2. The replication boundary for the domain partition. All adds objects in a single domain are saved in the domain partition of the adds database for each domain controller. The replication process ensures that all initial updates are replicated to all other domain controllers in the same domain, and that data in the domain partition is not replicated to domain controllers in other forests.

4. Manage boundaries. By default, a adds domain contains multiple groups, such as the Domain Admins group, where members have full administrative privileges on the entire domain, and you can give administrative privileges to user accounts and groups within the domain. In addition to the Enterprise Admins group in the root domain of the forest, other administrative accounts do not have any administrative privileges in other domains in the forest or in other forests, and they cannot manage resources that are not local to the domain.

6. Group Policy applies boundaries. Group Policy can be linked at the following levels: local, site, domain, OU. In addition to the site-level Group Policy, the other Group Policy scopes are domain-level. Group Policy in a domain does not inherit from one domain to another, even if a domain is a subdomain of another domain and does not have the same functionality as Group Policy inheritance.

8. Audit boundaries. Audits are centrally managed through GPOs, and the maximum scope for audit settings is the entire domain. You can use the same audit settings in different domains, but these settings must be managed separately in each domain.

10. Password and account policy boundaries. By default, password and account policies are defined at the domain level and are applied to all domain accounts. However, we can configure granular password policies to apply these policies to certain special users in the domain. Password and account policies cannot be applied at the level above a single domain.

12. The DNS zone replication boundary for the domain. When you configure DNS zones in a adds environment, there is an option to configure the ad integration zone. If you select an ad-integrated zone, DNS records are stored and replicated in the adds database instead of being saved in a local text file for each DNS server. The administrator can then choose whether to copy the DNS information "to all domain controllers in the domain (regardless of whether they are DNS servers)", "Replicate to all domain controllers that have DNS roles installed in the domain", "Replicate to all DNS-installed domain controllers in the forest". By default, when you deploy the first domain controller and use this server as a DNS server, 2 separate replication Partitions "DomainDNSZones" and "ForestDNSZones" are created automatically. The "DomainDNSZones" partition contains the DNS records for the specified domain and will only replicate between other DNS-installed domain controllers in the domain.

Adds Forest boundary

The adds forest provides the following boundaries:

1. Security boundaries. The forest is a security boundary because accounts outside the forest do not have any administrative rights in the forest by default.

2. The replication boundary of the schema partition. The schema partition contains the rules and syntax for the adds database. It is replicated to all domain controllers in the forest.

3. Configures the replication boundary for the partition. The configuration partition contains the layout details of the adds domain, which includes: domain, domain controller, replication partner, site and subnet information, DHCP authorization, or dynamic access control configuration. The configuration partition also contains information about the applications that are integrated with the ad database, such as Exchange applications. The configuration partition is also replicated to all domain controllers in the forest.

4. The replication boundary for the global catalog. A global catalog is a read-only list that contains every object in the entire forest. To ensure that it is within a manageable size range, the global catalog contains only part of the object's properties. The global catalog is replicated to all domain controllers in the forest that are global directories.

5. The replication boundary for the forest DNS zone. The "ForestDNSZones" partition is replicated to all domain controllers with DNS roles in the forest, and this zone contains records that play an important role in forest-wide DNS name resolution.

Why are multiple domains deployed?

Many enterprises have satisfied their needs with a single domain, but some enterprises need to deploy multiple domains to meet their needs, which may include:

1. Requirements for domain replication. In some cases, the company has several large branches that communicate through a slow or unreliable wan so that there is not enough bandwidth to support replication of domain partitions, so you may need to install a separate adds domain at each branch office to address this problem.

2. The requirements for the DNS namespace. Some companies require multiple DNS namespaces in the forest. This usually happens when a company acquires another company, and the domain name of the acquired company must be retained. Although you can solve this problem by allowing users to use multiple user principal names in a single domain, many enterprises choose to deploy multiple domains to solve this problem.

3. The need for distributed management. Organizations may need to use distributed management models because of some security or political needs, and by deploying a separate domain to enable autonomous management of the organization, domain administrators have full control over their domain resources.

Note: Deploying a detached domain provides self-managed functionality, but this does not mean that it is managed independently. The only way to ensure independent management is to deploy a detached forest.

4. The security requirements of the forest management group. Some organizations may choose to deploy a dedicated or empty root domain, which does not store any accounts other than the default built-in forest root domain. The root domain of the adds forest will have 2 default group schema Admins and Enterprise Admins, these 2 groups will not appear in other domains in the forest, because these 2 groups have very large permissions in the forest, you may want to limit their use by storing the 2 groups in the root domain.

5. Requirements for resource domains. Some organizations deploy resource domains to deploy specialized applications. With this deployment, all user accounts are placed in a single domain, and application server and application management accounts are deployed in a separate domain. This ensures that the application administrator has full domain administrative rights in the resource domain and does not need to open any permissions in the domain where the regular user account is stored.

Why deploy multiple forests?

Organizations may sometimes need to include multiple forests when designing adds. There are several reasons why a forest cannot meet the requirements:

1. Independent security requirements. If an enterprise requires independent management of its two different parts, the enterprise must deploy a multi-forest structure.

2. Incompatible schemas. Some enterprises may require multiple forests because they require incompatible schemas or incompatible schema change processing, and the schema is shared across all domains in the forest.

3. Cross-border demand. Some countries have strict rules and regulations on the ownership and management of domestic enterprises. The establishment of a separate adds forest can provide independent management according to regulatory requirements.

4. External security requirements. Some organizations have multiple servers deployed in the boundary network, which may require adds to authenticate user accounts or use adds to enforce certain policies on the servers in the boundary network. To ensure that external adds are as secure as possible, organizations typically deploy a adds forest on the boundary network.

5. Business mergers and acquisitions or separation requirements. The most common reason for using multiple forests in businesses is business mergers and acquisitions. When an enterprise acquires another enterprise, the enterprise needs to evaluate whether the two should be merged into a adds forest. Merging forests simplifies management and collaboration, but if there are two different groups in the enterprise that still need to be managed independently, and there is little need for collaboration between them, there is no need to combine two forests in this case. Especially if an enterprise plans to sell one of its business divisions, it would be more appropriate to keep two separate forests.
   

This article is from the "Dry Sea Sponge" blog, please be sure to keep this source http://thefallenheaven.blog.51cto.com/450907/1579916

Windows Active Directory Family---Distributed Active Directory Deployment overview