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

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

Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами 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) и кликаем Далее:

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

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

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

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

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

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

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

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

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

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

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

Настройка брандмауэра для доменов и доверия Active Directory

В этой статье описывается настройка брандмауэра для доменов и доверия Active Directory.

Исходная версия продукта: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 Standard, Windows Server 2012 Standard
Исходный номер КБ: 179442

Не все порты, перечисленные в таблицах, требуются во всех сценариях. Например, если брандмауэр разделяет члены и DCS, вам не нужно открывать порты FRS или DFSR. Кроме того, если вы знаете, что ни один клиент не использует LDAP с SSL/TLS, вам не нужно открывать порты 636 и 3269.

Дополнительные сведения

Оба контроллера домена находятся в одном лесу или оба контроллера домена находятся в отдельном лесу. Кроме того, отношения доверия в лесу являются отношениями доверия Windows Server 2003 или более поздней версии.

Клиентские порты	Порт сервера	Служба
1024-65535/TCP	135/TCP	RPC Endpoint Mapper
1024-65535/TCP	1024-65535/TCP	RPC для 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, указанные для Windows NT также необходимы для Windows 2000 и Windows Server 2003, когда настроены отношения доверия к доменам, которые поддерживают только связь на основе NETBIOS. Примерами являются Windows NT операционные системы или сторонние контроллеры домена, основанные на S s.

Дополнительные сведения о том, как определить порты сервера RPC, используемые службами RPC LSA, см. в:

• Ограничение трафика RPC Active Directory определенным портом.
• Раздел «Контроллеры домена» и «Active Directory» в обзоре службы и требованиях к сетевым портам для Windows.

Windows Server 2008 и более поздние версии

Более новые версии Windows Server 2008 повысили динамический диапазон портов клиентов для исходяющих подключений. Новый порт запуска по умолчанию — 49152, а конечный порт по умолчанию — 65535. Поэтому необходимо увеличить диапазон портов RPC в брандмауэрах. Это изменение было внося в соответствии с рекомендациями IANA. Это отличается от домена смешанного режима, состоящего из контроллеров домена Windows Server 2003, серверных контроллеров домена Windows 2000 или устаревших клиентов, где динамический диапазон портов по умолчанию — от 1025 до 5000.

Дополнительные сведения о динамическом изменении диапазона портов в Windows Server 2012 и Windows Server 2012 R2 см. в:

• Динамический диапазон портов по умолчанию для TCP/IP изменился.
• Динамические порты в Windows Server.

Клиентские порты	Порт сервера	Служба
49152 -65535/UDP	123/UDP	W32Time
49152 -65535/TCP	135/TCP	RPC Endpoint Mapper
49152 -65535/TCP	464/TCP/UDP	Смена пароля Kerberos
49152 -65535/TCP	49152-65535/TCP	RPC для 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	RPC DFSR (*)

Порты NETBIOS, указанные для Windows NT также необходимы для Windows 2000 и Server 2003, если настроены отношения доверия к доменам, которые поддерживают только связь на основе NETBIOS. Примерами являются Windows NT операционные системы или сторонние контроллеры домена, основанные на S s.

(*) Сведения о том, как определить порты сервера RPC, используемые службами RPC LSA, см. в:

• Ограничение трафика RPC Active Directory определенным портом.
• Раздел «Контроллеры домена» и «Active Directory» в обзоре службы и требованиях к сетевым портам для Windows.

(**) Для работы доверия этот порт не требуется, он используется только для создания доверия.

Внешнее доверие 123/UDP необходимо, только если вы вручную настроили службу времени Windows для синхронизации с сервером через внешнее доверие.

Active Directory

В Windows 2000 и Windows XP протокол ICMP должен быть разрешен через брандмауэр от клиентов к контроллерам домена, чтобы клиент групповой политики Active Directory правильно функционировал через брандмауэр. ICMP используется для определения того, является ли ссылка медленной или быстрой.

В Windows Server 2008 и более поздних версиях служба информирования о расположении сети предоставляет оценку пропускной способности на основе трафика с другими станциями в сети. Трафик для оценки не создается.

Перенаправление Windows также использует сообщения ICMP Ping, чтобы убедиться, что IP-адрес сервера разрешен службой DNS перед подключением и когда сервер расположен с помощью DFS. Чтобы свести к минимуму трафик ICMP, можно использовать следующее правило брандмауэра:

В отличие от TCP-протокола и уровня протокола UDP, ICMP не имеет номера порта. Это связано с тем, что ICMP напрямую находится на уровне IP.

По умолчанию DNS-серверы Windows Server 2003 и Windows 2000 Server используют эфемерные клиентские порты при запросе других DNS-серверов. Однако это поведение может быть изменено определенным параметром реестра. Или можно установить доверие через туннель PPTP. Это ограничивает количество портов, которые необходимо открыть брандмауэру. Для PPTP необходимо включить следующие порты.

Порты клиента	Порт сервера	Протокол
1024-65535/TCP	1723/TCP	PPTP

Кроме того, необходимо включить ПРОТОКОЛ IP 47 (GRE).

При добавлении разрешений к ресурсу в доверяемом домене для пользователей в доверенном домене существуют некоторые различия между поведением Windows 2000 и Windows NT 4.0. Если компьютер не может отобразить список пользователей удаленного домена, рассмотрите следующее поведение:

• Windows NT 4.0 пытается разрешить вручную введите имена, обратившись в PDC для домена удаленного пользователя (UDP 138). В случае сбоя связи компьютер Windows NT на основе 4.0 получает собственный PDC-канал, а затем запросит разрешение имени.
• Windows 2000 и Windows Server 2003 также пытаются связаться с PDC удаленного пользователя для разрешения проблемы по UDP 138. Однако они не используют собственные PDC. Убедитесь, что все серверы-члены на основе Windows 2000 и Windows Server 2003, которые будут предоставлять доступ к ресурсам, подключены к удаленному PDC с помощью UDP 138.

Справка

Обзор службы и требования к сетевым портам для Windows — это ценный ресурс, который включает в себя необходимые сетевые порты, протоколы и службы, используемые клиентской и серверной операционными системами Майкрософт, серверными программами и их подкомпонентами в системе Microsoft Windows Server. Администраторы и специалисты службы поддержки могут использовать эту статью в качестве карты для определения портов и протоколов, необходимых операционным системам и программам Майкрософт для сетевого подключения в сегментной сети.

Не следует использовать сведения о портах в обзоре службы и требования к сетевым портам для Windows для настройки брандмауэра Windows. Дополнительные сведения о настройке брандмауэра Windows см. в подсети Брандмауэр Windows с расширенными настройками безопасности.