Заметки порты

Порт	Протокол	Назначение
88	UDP	Kerberos. Этот порт прослушивает процесс lsass.exe (Local Security Authority Service).
135	TCP	RPC
139	TCP	Служба сеансов NetBIOS
389	TCP/UDP	Локатор контроллеров домена
445	TCP	SMB
1025	TCP	Используется процессом lsass.exe. Дополнительная информация здесь.
-	ICMP	ICMP используется для получения различной информации, поэтому пакеты данного протокола должны свободно проходить в направлении контроллеров домена.

Как-то у вас очень коряво обозначены сетевые соединения (что на схеме, что в таблице сетевого доступа). У каждого соединения есть источник/инициатор соединения (source) и целевая cторона (target или destination), принимающая эти соединения. На схеме это обозначается стрелочкой (двусторонней в случае двунаправленного доступа), а в таблице доступа дополнительными колонками source/target. Это важно для понимания направления сетевых подключений и корректной настройки межсетевых экранов.

По поводу набора протоколов/портов у меня тоже есть немалые замечания.
По направлению от клиентов (рабочих станций и рядовых серверов) к контроллеру домена нужно открывать:

1) Port 88 TCP/UDP — для Kerberos. По умолчанию Kerberos, конечно, инициируется по UDP 88, но при некоторых условиях может переходить и на TCP 88. Лучше заранее это учесть в правилах сетевого доступа.

2) Port 389 TCP/UDP — для LDAP (UDP 389 — LDAP ping, TCP 389 — LDAP connection).
Если у вас настроен LDAP SSL, то дополнительно нужно ещё открывать 636 TCP.

3) Port 3268 TCP — если у вас на контроллере поднят и используется Global Catalog (если у вас в организации всего один AD-домен и нет Exchange-серверов, то Global Catalog может и не быть).
Если у вас настроен доступ к Global Catalog с использованием SSL, то нужно дополнительно открывать ещё и 3269 TCP.

4) Port 53 TCP/UDP — для DNS, если у вас DNS поднят на контроллере домена. Клиенты используют запросы к DNS-серверу по UDP 53 (DNS Lookup), поэтому от клиентов до DNS-сервера достаточно будет UDP 53. TCP 53 используется для общения между DNS-серверами, для трансфера DNS-зон и прочих AXFR-запросов.

5) Port 445 TCP — для SMB (windows file sharing). Иногда для работы SMB кроме TCP 445 рекомендуют ещё открывать UDP 445, но я лично не встречал в этом потребности, всегда было достаточно TCP 445.

6) Port 123 UDP — для NTP (для синхронизации времени с контроллером).

7) Port 135 TCP — для RPC endpoint mapper.

8) Port range: 1024-65535 TCP (для Win2003), 49152-65535 TCP (для Win2008/2008-R2) — широкий динамический диапазон TCP-портов для назначения их клиентским RPC-подключениям к сервисам Netlogon, LSA (NTDS), NTFRS.

В действительности клиенты по RPC подключаются к нескольким различным AD-сервисам на контроллере домена, а именно: Netlogon, LSA (NTDS), плюс для репликации файлов между Win2000/2003-контроллерами ещё используется сервис NTFRS (тоже по RPC). Для подключения клиентов к сервисам, работающим по RPC, используются динамически выдаваемые TCP-порты из широкого диапазона TCP-портов (в Win2003 порты выше 1024 до 65535, в Win2008/2008-R2 порты выше 49152 до 65535). При этом клиент сначала подключается к контроллеру домена по TCP 135, RPC endpoint mapper назначает клиенту конкретные порты из широкого диапазона, по которым ему следует подключаться к конкретным RPC-сервисам данного контроллера. А дальше клиент уже подключается к службам Netlogon и LSA (NTDS) по указанным ему TCP-портам. Разным клиентам для одних и тех же RPC-сервисов контроллер может выдать разные порты (из указанного широкого диапазона), т.е. одному клиенту сказал подключаться к Netlogon на порт TCP 1025, другому назначил для того же RPC-сервиса порт TCP 1026 и т.д. По умолчанию заранее неизвестно, какой именно порт и кому назначит RPC endpoint mapper. И это усложняет настройку правил сетевого доступа на файрволе.

Поскольку по умолчанию порты для RPC-подключений клиенту выдаются динамически случайным образом из очень широкого диапазона, то открывать такой огромный жиапазон сразу на файрволе — это совсем не вариант. Поэтому для открытия портов для данных RPC-сервисов на межсетевом экране нужно:
а) Либо, чтобы firewall (например, на стороне самого контроллера домена) слушал общение клиента с RPC endpoint mapper'ом и автоматически понимал, какие TCP-порты тот назначил для RPC-подключений конкретному клиенту, чтобы динамически менять правила и разрешать эти назначенные порты для подключений конкретного клиента.
б) Либо на стороне контроллеров домена заранее биндить все RPC-сервисы на конкретные TCP-порты (без динамического диапазона). А потом в статических правилах на файрволе добавлять разрешения на подключения клиентских машин к контроллерам домена на эти конкретные жёстко заранее назначенные TCP-порты.

Конкретный TCP-порт для каждого RPC-сервиса назначается в параметрах системного реестра на контроллерах домена, например, так (значения можно дать любые незанятые):

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
«TCP/IP Port» = 50001

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
«DCTcpipPort» = 50002

HKLM\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters
«RPC TCP/IP Port Assignment» = 50003

После этого RPC endpoint mapper будет выдавать всем клиентам без исключения именно эти значения TCP-портов для подключения к соответствующим своим RPC-сервисам. Соответственно в правилах на файрволе нужно будет разрешить TCP-подключения от клиентов к контроллерам домена именно на эти фиксированные порты (50001 и 50002), а если есть межсетевые экраны между контроллерами домена, то в оба направления разрешить подключения между контроллерами на фиксированные порты 50001, 50002 и 50003.

9) Port 3389 TCP — для подключений по протоколу RDP (можно открывать не со всей сети, а только с отдельных администраторских машин).

10) ICMP Echo Request/Reply — для обмена пингами, для диагностики, для поиска ближайшего контроллера перед применением групповых политик.

Вот этого джентльменского набора портов/протоколов будет достаточно для настройки в правилах межсетевого экрана разрешений на клиентские сетевые подключения к контроллерам домена. При наличии на контроллерах домена дополнительных сервисов (DHCP, DFS, SMTP и др.) в эти правила могут добавиться какие-то дополнительные наборы TCP/UDP-портов.

Если у вас в сети нет машин с Win9x/NT4, то клиентские подключения к контроллерам на TCP/UPD-порты 137, 138, 139 — не нужны. Забудьте о NBT (NetBIOS over TCP/IP) и прочее убогое наследие NetBIOS, сейчас вместо него везде достаточно только SMB (TCP 445).

все верно, только забыли маленькую весч: печать с терминальных серверов:
1) через RDP (перенаправленные принтеры/easyprint) — глючно и/или тормознуто — но порты открывать не надо
2) screw driver (и прочие продукты) — это уже не MS + кому интересно — посмотрите на стоимость
3) печать на машины к которым подключены принтеры (обычная печать) — нужно открывание smb портов, что нивелирует безопасность
4) печать на принт-серверы — нужно открывание порта + не все принтеры работают
5) удешевление варианта 4 — печать на машины к которым подключены принтеры (через lpd) — нужно открывание порта + не все принтеры работают
6) аналогично 5, только через дополнительный эмулятор PS принтера, чтобы работало с большим количеством принтеров — костыли, но, бывает, единственный рабочий вариант.
7) идеал — все принтеры с поддержкой сети/с принтсерверами — нужно открывание 1го порта

Все вышеперечисленное написано с учетом реального опыта и работающих (поддерживаемых) систем. К сожалению, если есть ЗООпарк принтеров (+где есть win-принтеры и нет денег на их замену/приобретение screwdriver) с- пасает 6й вариант.