A forest is a collection of domains with a shared configuration and schema, represented by a single logical global catalog, and connected by a spanning tree of transitive trusts. A forest is represented by a forest root domain. The default administrative owner of a forest is the Domain Admins group of the forest root domain.
The Domain Admins group of the forest root controls the membership of the Enterprise Admins and Schema Admins groups, which by default have control over forest-wide configuration settings. Because the forest owner controls domain controllers, the forest owner is a service administrator. A domain is a partition in an Active Directory forest.
The default administrative owner of a domain is the Domain Admins group of the domain. Because the domain owner controls domain controllers, the domain owner is a service administrator. All non-root domain owners in a forest are peers, regardless of their domain's position in the naming hierarchy; the owner of a non-root parent domain has no default administrative control over a child domain.
An organizational unit OU is a container within a domain. Users and groups that have control over objects in OUs are data administrators. The greater the number of organizations that can participate in a forest, the greater are the possible benefits from collaboration and cost savings. For this reason, it is a best practice to minimize the number of forests in an Active Directory deployment. However, there are situations in which delegation requirements make deployment of multiple forests entirely appropriate.
For example, in organizations where administrative control is highly distributed, it can be impractical to expect all organizations to participate in the same infrastructure. In these situations, the cost of managing an additional forest is traded off to satisfy this practical requirement. The following facts about Active Directory structures and their administrators are important when choosing a directory structure for a delegation.
For an application of these facts in a simple structure-picking procedure see, "Selecting a Structure Based on Delegation Requirements", later in this document. To summarize the consequences of the facts about directory structures and directory structure owners, for an organization to join a forest or domain infrastructure, it must choose to trust all service administrators in the forest and in all domains.
In this context, to trust service administrators means to:. Some organizations might accept the risk of security breaches by rogue or coerced service administrators from other parts of the organization. Such organizations might determine that the collaborative and cost-saving benefit of participating in a shared infrastructure outweighs the risk.
However, other organizations might not accept this risk because the consequences of a security breach are too severe. Figure 1 illustrates the decision process for determining if an organization's specific delegation requirements justify delegating control of a separate forest, domain, or OU to that organization. To use the process, perform the following conceptual exercise:. The decision process for delegation of administration is illustrated in Figure 1 and discussed in detail in a series of scenarios following the figure.
An organization that needs service isolation requires that no administrator outside of the organization can interfere with the operation of the directory.
Service isolation is typically driven by operational or legal requirements. To provide service isolation, create a new forest for the organization. A forest consists of a set of domains with a shared schema container and configuration container. These containers are controlled by the forest owner. If an organization requires the ability to independently manipulate the schema or configuration container, it requires its own forest.
This requirement is typically driven by organizational structure or operational requirements. Please note that disabling SID filtering is a security risk. If there is no matching site, authentication request will go to any Domain Controller at Trusted Forest.
This will create multiple problems, and you cannot decide on which Domain Controllers firewall ports need to be opened for Forest Trust.
In my article about Forest Trust , I have discussed this feature elaborately. One of the reasons behind Active Directory's wide adaptation is its ability to control the IT environment through Group Policy.
Using Group Policy, administrators can control thousands of users and systems the way they want. When we configure a GPO, we need to consider two things, what and where. This means, what the policy is all about and where it will be applied, and where it will not be applied. Once we finalize a GPO, we need to plan for its deployment. Here are a few thumb rules :. Do not link it to an OU which is having thousands of users or computers.
First link it with a smaller OU or sub OU having fewer users or computers, to minimize any possible impact. I have published an article called Group Policy : Filtering and Permission , which you can refer to understand how can we fine-tune the target of Group Policy. You can use some script to automate that. So you should follow that approach rather than creating multiple GPOs for the same purpose. So far, we have discussed some best practices related to Active Directory design.
Let's discuss some of the best practices related to DNS. I assume that all zones in your environment are AD Integrated. This will ensure that the records within that zone would only be updated by trusted entities. Changing this settings later would impact record permission and can cause outage, so please make the zone "Secure Only" as soon as it is created.
A zone can be replicated within Domain or throughout an AD Forest. If a given zone is mostly used only by a single domain, there is no need to replicate it to the entire forest, as that would increase replication traffic. It is not necessary to have a separate reverse lookup zone against every forward lookup zone, you can combine few forward lookup zones with a bigger reverse lookup zone.
It is difficult to manage static DNS records, and over the time it will become a huge burden for DNS Administrators to identify and cleanup stale static records. This is by design, and no action is required on that. However, please plan this carefully to ensure that it would not delete live records.
Please check your DHCP lease duration for corresponding scopes, which configuring ageing. However, as a DNS Administrators, you would like to control the traffic and can change this default behavior. It is not necessary that every DNS server should directly talk to root servers for external name resolution. Typically, you can choose few DNS servers in your root domain to do this job.
External DNS Zones. In addition to internal DNS servers, most of the organizations also need to host few zone externally, to make the zone and corresponding records available globally. These service providers host the zones in their environment and provides a management console to organizations, from where DNS Administrator manages those external zones and records.
In this approach, the same zone would be hosted in external DNS servers as well as internal DNS servers, which are completely independent on each other. In the external zone, you create only those records which need to be available globally.
In the internal zone, you create all records which are required externally and internally. That way, you do not need to expose all records externally. Few more best practices related to DNS.
We have almost covered DNS best practices, lets add few more and move on to the next topic. A higher TTL value will ensure that the record would be retained in the resolver cache for a longer time. If you need to change record value urgently, this will create problem as the new value will take more time to reflect, causing DNS client to be diverted to the old value.
Sometime this can also pose security issue. These factors impact Inter Site Replication. Instead, you should create a RBAC policy for your organization.
Backup Tool. Windows Server R2. Backup Method. AD Site Layout. Global Catalog Placement. Contents Exit focus mode. Is this page helpful? Please rate your experience Yes No. Any additional feedback?
Submit and view feedback for This product This page. Not an IT pro? SQL Server. Sign in. United States English. Home R2 Library Forums. Ask a question. Quick access. Search related threads. Remove From My Forums.
0コメント