Настройка доверительных отношений между доменами Active Directory

Для возможности аутентификации с использованием учетных записей из нескольких доменов, необходимо, чтобы были доверительные отношения между последними. При создании домена в структуре леса, доверие выстраивается автоматически. Но если мы хотим объединить два домена разных организаций или которые раньше работали независимо друг от друга, то необходимо настроить доверительные отношения.

Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами primary.local (192.168.0.15) и secondary.local (192.168.0.16). Саму настройку разделим на 2 этапа — конфигурирование DNS и создания доверий. В качестве операционной системы по данной инструкции можно настроить Windows Server 2008 / 2012 / 2016 / 2019.

Определяемся с типом доверительных отношений

Доверительные отношению могут быть разных типов. Перед тем, как их настроить, нужно понять, какие нам требуются.

Одностороннее или двустороннее

Определяют направление доверия одного домена к другому.

В односторонних отношениях, только один домен доверяет другому. В результате, на компьютерах одного из доменов можно будет авторизоваться с использованием пользователей другого. При создании такого доверия нужно указать также направление (входящее или исходящее) — оно определяет чьи пользователи смогут проходить аутентификацию на чьем домене.

В двусторонних отношениях домены доверяют друг другу. Таким образом, аутентификация выполняется на всех компьютерах под пользователями любого из доменов.

Внешнее или доверие леса

Внешнее или нетранзитивное отношение устанавливается между двумя доменами напрямую вне леса.

Доверие леса или транзитивное отношение связывает леса и все их домены.

Настройка DNS

Для построения доверия необходимо, чтобы контроллеры домена видели друг друга. Все запросы на поиск узлов в AD выполняются через службы доменных имен. Таким образом, в нашем примере, мы должны сконфигурировать условную пересылку на DNS обоих доменов. Также важно, чтобы между контроллерами была сетевая доступность — по сети они должны видеть друг друга.

На DNS домена primary.local

Открываем Диспетчер серверов — кликаем по Средства — DNS:

В открывшемся окне выбираем нужный сервер, если их несколько — раскрываем его — кликаем правой кнопкой мыши по Серверы условной пересылки — Создать сервер условной пересылки:

В «DNS-домен» пишем второй домен (в нашем случае, secondary.local), затем задаем его IP-адрес, ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицировать ее следующим образом — выбираем Все DNS-серверы в этом домене:

Открываем командную строку и вводим команду:

Мы должны получить ответ на подобие:

Server: localhost
Address: 127.0.0.1

Non-authoritative answer:
Name: secondary.local
Address: 192.168.0.16

На DNS домена secondary.local

Действия, которые делаем на втором сервере DNS, во многом, аналогичны.

Открываем Диспетчер серверов — Средства — DNS:

Раскрываем сервер — Серверы условной пересылки — Создать сервер условной пересылки:

На данном шаге небольшие изменения. В «DNS-домен» пишем первый домен (primary.local), затем задаем его IP-адрес (192.168.0.15), ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицивовать ее следующим образом — выбираем Все DNS-серверы в этом домене:

В командной строке второго сервера проверяем настройку:

Мы должны получить ответ на подобие:

Server: localhost
Address: 127.0.0.1

Non-authoritative answer:
Name: primary.local
Address: 192.168.0.15

Настройка доверительных отношений

После настройки DNS можно переходить к созданию доверительных отношений.

В домене primary.local открываем Диспетчер серверов — кликаем по Средства — Active Directory — домены и доверие:

В открывшемся окне кликаем правой кнопкой по нашему домену — Свойства:

Переходим на вкладку Отношения доверия — кликаем по Создать отношение доверия. :

Нажимаем Далее — вводим имя для второго домена (secondary.local) и кликаем Далее:

Выбираем Доверие леса (если нам не нужно внешнее доверие) — Далее:

В окне «Направление отношения доверия» выбираем Двустороннее:

. и нажимаем Далее.

В следующем окне выбираем, на каком из доменов мы применяем настройку — если у нас есть права администратора для обоих доменов, то выбираем Для данного и указанного доменов:

* если мы являемся администратором одного из доменов, а вторым доменом управляет другой специалист, то выбираем Только для данного домена. Подобные действия должен выполнить второй администратор в своем домене.

На следующем этапе система свяжется со вторым контроллером домена, и если он доступен, запросит логин и пароль от пользователя с правами установки доверительных отношений во втором домене. Вводим данные пользователя и нажимаем Далее.

Далее нужно выбрать «Уровень проверки подлинности исходящего доверия» — если оба домена принадлежат нашей организации, предпочтительнее выбрать Проверка подлинности в лесу, чтобы предоставить доступ ко всем ресурсам:

После последуют два окна — «Выбор доверия завершен» — Далее — «Создание доверия завершено» — Далее.

В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.

Тоже самое в окне «Подтверждение входящего доверия».

Нажимаем Готово — доверительные отношения созданы.

How to configure a firewall for Active Directory domains and trusts

This article describes how to configure a firewall for Active Directory domains and trusts.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 Standard, Windows Server 2012 Standard
Original KB number: В 179442

Not all the ports that are listed in the tables here are required in all scenarios. For example, if the firewall separates members and DCs, you don’t have to open the FRS or DFSR ports. Also, if you know that no clients use LDAP with SSL/TLS, you don’t have to open ports 636 and 3269.

More information

The two domain controllers are both in the same forest, or the two domain controllers are both in a separate forest. Also, the trusts in the forest are Windows Server 2003 trusts or later version trusts.

Client Port(s)	Server Port	Service
1024-65535/TCP	135/TCP	RPC Endpoint Mapper
1024-65535/TCP	1024-65535/TCP	RPC for LSA, SAM, NetLogon (*)
1024-65535/TCP/UDP	389/TCP/UDP	LDAP
1024-65535/TCP	636/TCP	LDAP SSL
1024-65535/TCP	3268/TCP	LDAP GC
1024-65535/TCP	3269/TCP	LDAP GC SSL
53,1024-65535/TCP/UDP	53/TCP/UDP	DNS
1024-65535/TCP/UDP	88/TCP/UDP	Kerberos
1024-65535/TCP	445/TCP	SMB
1024-65535/TCP	1024-65535/TCP	FRS RPC (*)

NETBIOS ports as listed for Windows NT are also required for Windows 2000 and Windows Server 2003 when trusts to domains are configured that support only NETBIOS-based communication. Examples are Windows NT-based operating systems or third-party Domain Controllers that are based on Samba.

For more information about how to define RPC server ports that are used by the LSA RPC services, see:

Windows Server 2008 and later versions

Windows Server 2008 newer versions of Windows Server have increased the dynamic client port range for outgoing connections. The new default start port is 49152, and the default end port is 65535. Therefore, you must increase the RPC port range in your firewalls. This change was made to comply with Internet Assigned Numbers Authority (IANA) recommendations. This differs from a mixed-mode domain that consists of Windows Server 2003 domain controllers, Windows 2000 server-based domain controllers, or legacy clients, where the default dynamic port range is 1025 through 5000.

For more information about the dynamic port range change in Windows Server 2012 and Windows Server 2012 R2, see:

• The default dynamic port range for TCP/IP has changed.
• Dynamic Ports in Windows Server.

Client Port(s)	Server Port	Service
49152 -65535/UDP	123/UDP	W32Time
49152 -65535/TCP	135/TCP	RPC Endpoint Mapper
49152 -65535/TCP	464/TCP/UDP	Kerberos password change
49152 -65535/TCP	49152-65535/TCP	RPC for LSA, SAM, NetLogon (*)
49152 -65535/TCP/UDP	389/TCP/UDP	LDAP
49152 -65535/TCP	636/TCP	LDAP SSL
49152 -65535/TCP	3268/TCP	LDAP GC
49152 -65535/TCP	3269/TCP	LDAP GC SSL
53, 49152 -65535/TCP/UDP	53/TCP/UDP	DNS
49152 -65535/TCP	49152 -65535/TCP	FRS RPC (*)
49152 -65535/TCP/UDP	88/TCP/UDP	Kerberos
49152 -65535/TCP/UDP	445/TCP	SMB (**)
49152 -65535/TCP	49152-65535/TCP	DFSR RPC (*)

NETBIOS ports as listed for Windows NT are also required for Windows 2000 and Server 2003 when trusts to domains are configured that support only NETBIOS-based communication. Examples are Windows NT-based operating systems or third-party Domain Controllers that are based on Samba.

(*) For information about how to define RPC server ports that are used by the LSA RPC services, see:

(**) For the operation of the trust this port is not required, it is used for trust creation only.

External trust 123/UDP is only needed if you have manually configured the Windows Time Service to Sync with a server across the external trust.

Active Directory

In Windows 2000 and Windows XP, the Internet Control Message Protocol (ICMP) must be allowed through the firewall from the clients to the domain controllers so that the Active Directory Group Policy client can function correctly through a firewall. ICMP is used to determine whether the link is a slow link or a fast link.

In Windows Server 2008 and later versions, the Network Location Awareness Service provides the bandwidth estimate based on traffic with other stations on the network. There is no traffic generated for the estimate.

The Windows Redirector also uses ICMP Ping messages to verify that a server IP is resolved by the DNS service before a connection is made, and when a server is located by using DFS. If you want to minimize ICMP traffic, you can use the following sample firewall rule:

Unlike the TCP protocol layer and the UDP protocol layer, ICMP does not have a port number. This is because ICMP is directly hosted by the IP layer.

By default, Windows Server 2003 and Windows 2000 Server DNS servers use ephemeral client-side ports when they query other DNS servers. However, this behavior may be changed by a specific registry setting. Or, you can establish a trust through the Point-to-Point Tunneling Protocol (PPTP) compulsory tunnel. This limits the number of ports that the firewall has to open. For PPTP, the following ports must be enabled.

Client Ports	Server Port	Protocol
1024-65535/TCP	1723/TCP	PPTP

In addition, you would have to enable IP PROTOCOL 47 (GRE).

When you add permissions to a resource on a trusting domain for users in a trusted domain, there are some differences between the Windows 2000 and Windows NT 4.0 behavior. If the computer cannot display a list of the remote domain’s users, consider the following behavior:

• Windows NT 4.0 tries to resolve manually typed names by contacting the PDC for the remote user’s domain (UDP 138). If that communication fails, a Windows NT 4.0-based computer contacts its own PDC, and then asks for resolution of the name.
• Windows 2000 and Windows Server 2003 also try to contact the remote user’s PDC for resolution over UDP 138. However, they do not rely on using their own PDC. Make sure that all Windows 2000-based member servers and Windows Server 2003-based member servers that will be granting access to resources have UDP 138 connectivity to the remote PDC.

Reference

Service overview and network port requirements for Windows is a valuable resource outlining the required network ports, protocols, and services that are used by Microsoft client and server operating systems, server-based programs, and their subcomponents in the Microsoft Windows Server system. Administrators and support professionals may use the article as a roadmap to determine which ports and protocols Microsoft operating systems and programs require for network connectivity in a segmented network.

You should not use the port information in Service overview and network port requirements for Windows to configure Windows Firewall. For information about how to configure Windows Firewall, see Windows Firewall with Advanced Security.

Описание Active Directory

Оснастка Active Directory Domains and Trusts

В оснастке Active Directory Domains and Trusts (Домены и доверительные отношения Active Directory ) вы можете просматривать, создавать, модифицировать и проверять доверительные отношения для вашего леса. Доверительные отношения позволяют пользователям одного домена аутентифицироваться в доверяющем домене. Если пользовательская учетная запись может быть аутентифицирована, то вы можете предоставлять доступ к ресурсам этого доверяющего домена.

Ниже приводится список различных типов доверительных отношений в Windows Server 2003.

• Domain root trust (Доверительные отношения между корнями доменов).Доверительные отношения между корнями двух различных доменов одного леса. На рис. 10.5 показан этот тип доверительных отношений между двумя деревьями: company.dom и domain2.dom.
• Parent-child trust (Доверительные отношения между родительским и дочерним доменами).Отношения в рамках одного пространства доменных имен. На рис. 10.5 имеется домен sales под корнем company.dom. Их доверительные отношения — это отношения между родительским и дочерним доменами. В лесу Active Directory доверительные отношения являются двусторонними и транзитивными. Транзитивность на рис. 10.5 означает, что для доступа к ресурсам домена finance.company.dom из домена sales.company.dom не требуется специально конфигурировать соответствующие доверительные отношения, поскольку оба этих домена являются дочерними доменами родительского домена company.com. Доверительные отношения между finance.company.dom и sales.company.dom определяются как путь доверия через все домены в одном дереве доменов.

• Shortcut trust (Сокращенные доверительные отношения).Для транзитивности доверительных отношений в домене и лесу соответствующее доверительное отношение должно проверяться через все дерево доменов. Вы можете создавать доверительное отношение, которое позволяет снизить количество времени, требующееся для проверки пути доверия. Создавая вручную доверительное отношение в оснастке Active Directory Domains and Trusts, вы действительно сокращаете время, которое требуется для аутентификации доступа к ресурсам.
• Forest trust (Доверительные отношения между лесами).Новый вид доверительных отношений, появившийся в Windows Server 2003; это позволяет одному лесу тран-зитивно доверять всем доменам другого леса. Например, предположим, у нас имеется домен company.dom из предыдущего примера и внутри этого домена имеется дочерний домен sales.company.dom. Если сконфигурировать доверительные отношения на уровне лесов с другим лесом, external.dom, то sales.company.dom получает транзитивные доверительные отношения через корень своего леса с другим доверяемым лесом. Вы можете конфигурировать эти доверительные отношения как транзитивные двусторонние или односторонние отношения.
• Realm trust (Доверительные отношения с областью действия).Добавляя доверительные отношения с областью действия Kerberos, вы можете устанавливать такие доверительные отношения с областями, отличными от Windows Kerberos version Как и в случае других внешних доверительных отношений, это могут быть транзитивные или нетранзитивные двусторонние или односторонние отношения.

В следующем примере происходит добавление доверительного отношения к существующему домену.