Active Directory allows administrators to use group policies(GPO) to ensure consistency in setting up the user's working environment, deploy software on multiple computers (through group policies or install OS, application and server software updates on all computers on the network. Active Directory stores data and environment settings in a centralized database. Networks Active Directory can be of varying sizes: from several hundred to several million objects.

A domain is a separate area of ​​security in computer network. The Active Directory directory service can span one or more domains. On a standalone workstation, the domain is the computer itself. From a physical point of view, a domain can include computers located in different locations.

A domain tree (tree) consists of several domains that share a common schema and configuration and thus form a common namespace. Domains in the same tree are also linked by trust relationships. The Active Directory directory service is a set consisting of one or more trees.

A forest is a collection of one or more trees that do not form a contiguous namespace. All trees in the forest have the same schema, configuration, and global catalog. All trees in the forest are connected by a trust relationship through a transitive trust relationship using the Kerberos protocol. A forest, unlike a tree, should not have a name to distinguish it. A forest exists as a collection of cross-reference objects and Kerberos trusts known to the trees that make up the forest. The forest trees form a trust hierarchy under the Kerberos protocol; the name of the tree at the root of the trust tree can be used to refer to the specified forest.

35. ad domain controller

The Windows servers on which the directory service instance operates are domain controllers. They are carriers of a fully functional copy of the catalogs. They perform the following task:

1) Access and management of information stored in the directory.t

2) Synchronization of copies of directories.

3) Centralized replication of users. and system files.

4) User authentication.

A multi-peer replication model is used. It doesn't matter which controller makes changes to the directories. However, there is a certain class of operations that should be performed by only one domain controller - single-executor or single-master operations. When more than one controller is involved in these operations, the possibility of a computer. A single-executor operation is also called computer domain roles. An example of such roles are schema masters, which monitor directory changes.

Domain owner - monitors changes in the domain structure, guarantees the integrity of the namespace and the uniqueness of its components.

The relative identifier (RID) master generates unique identifiers. By default, all specialized roles are assigned to new domains in the new forest.

Because the Microsoft Windows Since Server 2003 and Microsoft Exchange Server 2007 depend on Active Directory for directory services, you must determine how to integrate Exchange 2007 into your Active Directory structure. Active Directory includes the following logical elements, the combination of which defines the Active Directory topology:

• One or more domains
• One or more Active Directory sites

Active Directory forests

Forest represents the outermost boundary of the directory service. The forest operates in the context of end-to-end security so that all resources within the forest explicitly trust each other regardless of their location in the forest. Each forest uses a common directory structure and directory service configuration. A forest can consist of one or more domains. There are two types of forest topologies: single forest and multiple forests.

Single forest topology

In a single-forest topology, Exchange is installed in a single Active Directory forest that spans the entire organization. All Accounts users and groups, as well as all Exchange configuration data, reside in the same forest.

If your organization uses a single Active Directory forest, Exchange 2007 can be installed in that forest. We recommend using the single-forest Exchange design because it offers the maximum range of email system capabilities and because it provides the most simple model administration. Because all resources are contained in a single forest, one GAL contains all users from the entire forest. This case is shown in the following figure.

The single scaffold option offers the following advantages:

• The richest set of email system features.
• Simple administration model.
• Take advantage of your existing Active Directory structure.
• GAL synchronization is not required.

The main disadvantage associated with a single forest is that administrators must determine how to consolidate or share responsibility for managing Active Directory and Exchange objects.

Multi-forest topology

Although a single forest topology is recommended because it provides the greatest range of messaging capabilities, there are various reasons why you might want to implement multiple forests. These reasons may include, for example:

• Having multiple departments that require messaging service isolation.
• The presence of several departments with different requirements for the scheme.
• A merger, acquisition or division that has occurred.

In any case, the only way to establish strict boundaries between organizational units is to create a separate Active Directory forest for each organizational unit. When using this Active Directory configuration, the preferred way to implement Exchange is to create an Exchange resource forest. For getting additional information For information about Exchange resource forests, see “Resource Forest Topology” later in this topic.

But there are scenarios in which a resource forest may not be possible (for example, during mergers or acquisitions, or when multiple forests already have their own Exchange instances running). In these cases, a cross-forest topology can be implemented.

Cross forest topology

In a cross-forest topology, a company uses multiple Active Directory forests, each containing an Exchange organization. Unlike a resource forest topology, user accounts are not separated from their mailboxes. Instead, the user account and the corresponding mailbox are in the same forest.

The main benefit of implementing a cross-forest topology is the ability to isolate data and security boundaries between Exchange organizations. But this topology has the following disadvantages:

• The richest set of messaging features is not available.
• When you move mailboxes from one forest to another, delegated permissions are not preserved if there is no contact in the target forest to delegate, or if you move a mailbox delegate at the same time.
• Although you can synchronize free/busy information across forests so you can use it to schedule meetings, Microsoft Office Outlook function cannot be used Open another user's folder to view a user's calendar data from another forest.
• Because the group from another forest is represented as a contact, you cannot view the group members. Until a letter is sent to the forest containing the group represented by the contact, the group's membership is not expanded.
• Synchronization of directory objects across forests is required, as is replication of free/busy information. The most commonly used directory synchronization solutions are Microsoft Identity Integration Server (MIIS) 2003 SP2 or Identity Integration Feature Pack for Microsoft Windows Server Active Directory SP2: The Exchange 2007 Availability service can be used to exchange free/busy information and calendar information between Exchange organizations in different forests.

Resource forest topology

In some cases, you may need to create a separate, dedicated Active Directory forest to run Exchange. For example, there may be a situation where you want to preserve an existing Active Directory forest. Or you may want to separate the administration of Active Directory objects from Exchange objects. Therefore, you may need to create a separate Active Directory forest dedicated to running Exchange. This separate dedicated forest is called forest of resources Exchange. In the resource forest model, Exchange is installed in an Active Directory forest that is separate from the Active Directory forest that contains users, computers, and application servers. This option is typically used by companies that need security boundaries between Active Directory administration and Exchange administration.

An Exchange resource forest is dedicated to running Exchange and hosting mailboxes. User accounts are contained in one or more forests called account forests. Account forests are separate from the Exchange resource forest. Between the forest of accounts and the forest Exchange resources creates a one-way trust that allows the Exchange forest to trust the account forest so that users in the account forest can access mailboxes in the Exchange resource forest. Because an Exchange organization cannot span Active Directory forest boundaries, each mailbox created in the Exchange resource forest must have a corresponding user object in the Exchange resource forest. User objects in the Exchange resource forest are never used for user logon and are disabled to prevent their use. Users usually do not even know about the existence of a duplicate account. Because the account in the Exchange resource forest is disabled and is not used for logon, the real user account in the account forest must be given the logon right to the mailbox. Access is granted by including the security identifier (SID) of the user object from the account forest in the attribute msExchMasterAccountSID disabled user object in the Exchange resource forest.

You may not need directory synchronization if you are using an Exchange resource forest. From an Exchange and Outlook perspective, all objects listed in the directory service come from one place, in this case the directory service that hosts the Exchange forest. However, if you have data associated with GALs in your account forests, synchronization may be required to get the data into the Exchange resource forest for use in GALs. Additionally, you might want to configure the process so that when you create accounts in the account forest in the Exchange resource forest, a disabled account with a mailbox is created.

An enabled user in the resource forest is associated with a mailbox that is attached to a disabled user in the resource forest. This configuration gives users access to mailboxes located in other forests. This scenario configures a trust relationship between the resource forest and the account forest. You may also want to configure the provisioning process so that each time an administrator creates a user in the account forest, a disabled user with a mailbox is created in the Exchange resource forest.

Because all Exchange resources are in the same forest, one GAL will contain all users in the forest. The main benefit of the Exchange dedicated forest scenario is the security boundary between Active Directory and Exchange administration.

There are a number of disadvantages associated with this topology, including the following:

• Implementing a resource forest provides separation of Exchange and Active Directory administration, but the cost associated with deploying a resource forest may outweigh the need for such separation.
• For Microsoft Windows hosts that will run Exchange, you will need to install additional domain controllers and global catalog servers, which will increase the cost.
• An initialization process is required to reflect Active Directory changes in Exchange. When you create an object in one forest, you must be sure that the corresponding objects are created in the other forest. For example, if you create a user in one forest, make sure that a placeholder is created for that user in another forest in the other forest. The corresponding objects can be created manually, or the process can be automated.

A variant of the resource forest scenario is multiple forests, one of which hosts Exchange. When using multiple Active Directory forests, Exchange deployment depends on the degree of autonomy that you plan to maintain between forests. For companies with departments that require security boundaries (forests) of directory objects but can share Exchange objects, you might consider deploying Exchange in one of the forests and using that forest to host mailboxes from other forests in the company. Because all Exchange resources are in the same forest, one GAL will contain all users from all forests.

This scenario has the following main advantages:

• Using an existing Active Directory structure.
• Using existing domain controllers and global catalog servers.
• Ensuring strict safety boundaries between forests.

The disadvantages of this scenario include the following features:

• The need for an initialization process that reflects Active Directory changes in Exchange. For example, you could create a script that, when a new Active Directory user is created in Forest A, creates a disabled object in Forest B with permissions that grant access to a mailbox.
• The need for forest administrators to determine how to consolidate or share responsibility for managing Active Directory and Exchange objects.

Active Directory Domains

A domain is a collection of security principals and jointly administered other entities. Domains are flexible structures. The choice of what will be included in the domain remains open and left to the discretion of the administrator. For example, a domain may represent a group of users and computers physically located in one location, or it may represent all users and all computers across many locations in a large geographic region. By consolidating administration and infrastructure, domains tend to be spread over larger geographic regions to reduce support costs. But as directory services grow in size, the target directory must be able to access relevant resources as efficiently as possible.

Active Directory Sites

Active Directory sites are a logical collection of securely linked computers in Active Directory. Within an Active Directory site, you can separate client computers to use specific sets or groups of directory resources. An Active Directory site is one or more well-connected TCP/IP subnets that allow administrators to configure Active Directory access and required replication. These subnets may or may not correspond to the physical topology.

The following figure shows several of the most typical relationships between Active Directory logical definitions and physical locations.

Active Directory Deployment Scenarios

There are four main scenarios for integrating Exchange with Active Directory:

• The only forest
• Forest of resources
• Cross forest
• Mergers and acquisitions

The following table summarizes the benefits of each scenario.

Active Directory Scenario	Description	Why is this script used?
The only forest	Users and their mailboxes are in the same forest.	The richest set of mail system functions Simplified administration Using an existing Active Directory structure No need to synchronize with other forests
Forest of resources	One of the forests is dedicated to running Exchange and hosting Exchange mailboxes. User accounts associated with mailboxes are contained in one or more separate forests.	Security boundary between Active Directory and Exchange administration Simplified Exchange Deployment in a Multi-Forest Environment Restricting network infrastructure management and user accounts
Cross forest	Exchange runs in separate forests, but the email feature is available in other forests.	Multiple departments that require data and service isolation Multiple departments with different schema requirements Merger, acquisition or division
Mergers and acquisitions	Mergers and acquisitions often involve the coexistence of Exchange organizations prior to the merger. Planning issues are similar to the multiple forest scenario with additional migration considerations.	Mergers and acquisitions present a special case of multi-forest deployments that require additional attention to migration issues

Active Directory - Extensible and scalable Active Directory directory service allows you to effectively manage network resources.
Active Directory is a hierarchically organized repository of data about network objects, providing convenient means for searching and using this data. The computer that runs Active Directory is called a domain controller. Almost all administrative tasks are related to Active Directory.
Active Directory technology is based on standard Internet protocols and helps to clearly define the structure of the network; read more about how to deploy an Active Directory domain from scratch here..

Active Directory and DNS

Active Directory uses the domain name system.

Active Directory Administration

Using the Active Directory service, computer accounts are created, connected to the domain, and computers, domain controllers, and organizational units (OUs) are managed.

Administration and support tools are provided to manage Active Directory. The tools listed below are also implemented as snap-ins in the MMC console (Microsoft Management Console):

• Active Directory - users and computers (Active Directory Users and Computers) allows you to manage users, groups, computers and organizational units (OU);
• Active Directory - domains and trusts (Active Directory Domains and Trusts) is used to work with domains, domain trees and domain forests;
• Active Directory Sites and Services allows you to manage sites and subnets;
• The Resultant Set of Policy is used to view the current policy of a user or system and to schedule changes to the policy.
• In Microsoft Windows 2003 Server, you can access these snap-ins directly from the Administrative Tools menu.

Another administrative tool, the Active Directory Schema snap-in, allows you to manage and modify the directory schema.

Utilities command line Active Directory

To manage Active Directory objects, there are command line tools that allow you to perform a wide range of administrative tasks:

• DSADD - adds computers, contacts, groups, OUs and users to Active Directory.
• DSGET - displays properties of computers, contacts, groups, OUs, users, sites, subnets and servers registered in Active Directory.
• DSMOD - changes the properties of computers, contacts, groups, OPs, users and servers registered in Active Directory.
• DSMOVE - Moves a single object to a new location within a domain or renames the object without moving it.
• DSQXJERY - searches for computers, contacts, groups, OPs, users, sites, subnets and servers in Active Directory according to specified criteria.
• DSRM - removes an object from Active Directory.
• NTDSUTIL - allows you to view information about a site, domain or server, manage operations masters and maintain the Active Directory database.

An Active Directory forest defines a collection of one or more domains that share the same schema, configuration, and global catalog. In addition, all domains participate in two-way transitive trust relationships. Let us pay attention to the terms that are used in the definition of forest.

• Domain- a domain provides a way to organize and protect objects, such as users and computers, that are part of the same namespace..com are domains. Computers in each domain share the same domain configuration and may be subject to policies and restrictions set by the domain administrator. Using domains makes it easier to maintain enterprise-wide security.
• Scheme- The Active Directory schema is shared by all domains within the forest. A schema is configuration information that controls the structure and contents of a directory.
• Configuration- configuration defines the logical structure of the forest, for example, the number and configuration of sites within the forest.
• Global catalog- the global catalog can be perceived as a directory for the forest. The global catalog contains information about all forest objects, including information about the location of objects. In addition, the global directory contains universal group membership information.
• Confidence- Trust provides the ability for different domains to work together. Without trust, domains operate as separate entities, meaning users in domain A will not be able to access resources in domain B. If a trust relationship is established between domains such that domain B trusts domain A, then users in domain A will be able to access resources in the domain B, if they have the appropriate permissions.

There are three main types of trust relationships.

• Transitive- Transitive trust relationships are created automatically between domains of the same forest. They allow users in any domain to potentially access resources in any other domain in that forest, as long as the users have the appropriate access rights.
• Shortcut is a trust between domains in the same forest that already have a transitive trust. This trust provides faster authentication and verification of resource access between non-adjacent forest domains.
• External- External trusts allow domains from different forests to share resources. These trusts are not transitive, meaning they only apply to the domains for which they were created.

Having clarified the meaning of basic terms, let's consider the example of a forest. The following is a single forest that contains two domain trees.

The figure shows four domains aw.net, west.aw.net, east.aw.net and person.net. The domains aw.net, west.aw.net and east.aw.net are in the same domain tree because they share the same namespace (aw.net).

The person.net domain is in a different tree because it is not part of the aw.net namespace. Note that within the east.aw.net domain (which is not signed) OU symbols are shown. OU is organizational units(organizational units), which will be discussed in the next article.

The arrows in the figure represent transitive trust relationships that are automatically created when initial setup domains within the forest. Please note that the child domains (east and west) of the aw.net domain are not directly related to the person.net domain. Despite this, they trust the person.net domain.

The reason for trust is that child domains trust the aw.net domain. Because the aw.net domain trusts the person.net domain, aw.net's child domains also trust the person.net domain. Knowing this, you can think of Active Directory domains as little children. They unconditionally believe everything their parents say. If a parent says that another domain can be trusted, then that's exactly what it is.

But the difference between children and child domains is that child domains always agree and do not question the parent.

How it will help Active Directory specialists?

Here is a small list of “goodies” that you can get by deploying Active Directory:

• a single user registration database, which is stored centrally on one or more servers; thus, when a new employee appears in the office, you will only need to create an account for him on the server and indicate which workstations he can access;
• Since all domain resources are indexed, this makes it possible to easily and quick search for users; for example, if you need to find a color printer in a department;
• the combination of applying NTFS permissions, group policies and delegation of control will allow you to fine-tune and distribute rights between domain members;
• roaming user profiles make it possible to store important information and configuration settings on the server; in fact, if a user with a roaming profile in a domain sits down to work at another computer and enters his username and password, he will see his desktop with the settings he is familiar with;
• using group policies you can change settings operating systems users, from allowing the user to set desktop wallpaper to security settings, as well as distributing over the network software, for example, Volume Shadow Copy client, etc.;
• Many programs (proxy servers, database servers, etc.) not only produced by Microsoft today have learned to use domain authentication, so you do not have to create another user database, but can use an existing one;
• Using Remote Installation Services makes it easier to install systems on workstations, but, in turn, only works if the directory service is implemented.

And it's far from full list possibilities, but more on that later. Now I will try to tell you the logic of construction Active Directory, but again it’s worth finding out what our boys are made of Active Directory- these are Domains, Trees, Forests, Organizational Units, User and Computer Groups.

Domains - This is the basic logical unit of construction. Compared to workgroups AD domains are security groups that have a single registration base, while workgroups are just a logical association of machines. AD uses DNS (Domain Name Server) for naming and search services, not WINS ( Windows Internet Name Service - Internet name service), as it was in earlier versions of NT. Thus, the names of computers in the domain look like, for example, buh.work.com, where buh is the name of the computer in the work.com domain (although this is not always the case).

Workgroups use NetBIOS names. To host a domain structure AD it is possible to use a DNS server without Microsoft. But it must be compatible with BIND 8.1.2 or higher and support SRV() records as well as the Dynamic Registration Protocol (RFC 2136). Each domain has at least one domain controller on which it is located central base data.

Trees - These are multi-domain structures. The root of this structure is the main domain for which you create child domains. In fact, Active Directory uses a hierarchical structure similar to the domain structure in DNS.

If we have a domain work.com (first-level domain) and create two child domains for it first.work.com and second.work.com (here first and second are second-level domains, and not a computer in the domain, as in the case , described above), we end up with a domain tree.

Trees as a logical structure are used when you need to divide company branches, for example, by geography, or for some other organizational reasons.

AD helps to automatically create trust relationships between each domain and its child domains.

Thus, the creation of the first.work.com domain leads to the automatic establishment of a two-way trust relationship between the parent work.com and the child first.work.com (similarly for second.work.com). Therefore, permissions can be applied from the parent domain to the child, and vice versa. It is not difficult to assume that trust relationships will exist for child domains as well.

Another property of trust relationships is transitivity. We get that a trust relationship is created for the net.first.work.com domain with the work.com domain.

Forest - Just like trees, they are multi-domain structures. But forest is a union of trees that have different root domains.

Suppose you decide to have multiple domains named work.com and home.net and create child domains for them, but because the tld (top level domain) is not under your control, in this case you can organize a forest by selecting one of the first-level root domains. The beauty of creating a forest in this case is the two-way trust relationship between these two domains and their child domains.

However, when working with forests and trees, you must remember the following:

• you cannot add an existing domain to the tree
• You cannot include an existing tree in the forest
• Once domains are placed in a forest, they cannot be moved to another forest
• you cannot delete a domain that has child domains

Organizational units - In principle, they can be called subdomains. allow you to group user accounts, user groups, computers, shared resources, printers and other OUs (Organizational Units) in a domain. The practical benefit of their use is the possibility of delegating rights to administer these units.

Simply put, you can appoint an administrator in a domain who can manage the OU, but does not have rights to administer the entire domain.

An important feature of OUs, unlike groups, is the ability to apply group policies to them. “Why can’t you split the original domain into multiple domains instead of using an OU?” - you ask.

Many experts advise having one domain if possible. The reason for this is the decentralization of administration when creating an additional domain, since the administrators of each such domain receive unlimited control (let me remind you that when delegating rights to OU administrators, you can limit their functionality).

In addition to this, to create a new domain (even a child one) you will need another controller. If you have two separate departments connected by a slow communication channel, problems with replication may arise. In this case, it would be more appropriate to have two domains.

There is also one more nuance of using group policies: policies that define password settings and account lockouts can only be applied to domains. For OUs, these policy settings are ignored.

Websites - This is a way to physically separate a directory service. By definition, a site is a group of computers connected by fast data transfer channels.

If you have several branches in different parts of the country, connected by low-speed communication lines, then for each branch you can create your own website. This is done to increase the reliability of directory replication.

This division of AD does not affect the principles logical construction, therefore, just as a site can contain several domains, and vice versa, a domain can contain several sites. But there is a catch to this directory service topology. As a rule, the Internet is used to communicate with branches - a very insecure environment. Many companies use security measures such as firewalls. The directory service uses about one and a half dozen ports and services in its work, the opening of which for AD traffic to pass through the firewall will actually expose it “outside”. The solution to the problem is to use tunneling technology, as well as the presence of a domain controller in each site to speed up the processing of AD client requests.

The logic of nesting of directory service components is presented. It can be seen that the forest contains two domain trees, in which the root domain of the tree, in turn, can contain OUs and groups of objects, and also have child domains (in this case, one for each). Child domains can also contain object groups and OUs and have child domains (not shown in the figure). And so on. Let me remind you that OUs can contain OUs, objects and groups of objects, and groups can contain other groups.

User and computer groups - are used for administrative purposes and have the same meaning as when used on local machines on the network. Unlike OUs, group policies cannot be applied to groups, but management can be delegated for them. Within the Active Directory scheme, there are two types of groups: security groups (used to differentiate access rights to network objects) and distribution groups (used mainly for distributing mail messages, for example, in Microsoft server Exchange Server).

They are divided by scope:

• universal groups may include users within the forest as well as other universal groups or global groups of any domain in the forest
• global domain groups may include domain users and other global groups of the same domain
• domain local groups used to differentiate access rights, can include domain users, as well as universal groups and global groups of any domain in the forest
• local computer groups– groups that contain SAM (security account manager) of the local machine. Their scope is limited only to a given machine, but they can include local groups of the domain in which the computer is located, as well as universal and global groups of their own domain or another that they trust. For example, you can include a user from the domain local Users group in the Administrators group of the local machine, thereby giving him administrator rights, but only for this computer