Сервер RPC недоступен при попытке повысить уровень контроллера домена. Открытый брандмауэр
Итак, я уже несколько дней ломаю голову над этой проблемой.
Это краткая схема нашей инфраструктуры:
- Наш основной контроллер домена работает в гипервизоре, в нашем Дата центр. Существует два стека межсетевых экранов (Fortigate FG200D и pfSense) перед запуском в нашу сеть MPLS.
- Новый контроллер домена запускается в режиме без операционной системы, в одном наших сайтов, подключенных к MPLS, а также два уровня брандмауэры (Fortigate FG100D и pfSense).
Оба сервера работают под управлением Windows 2012 R2 и обновлены до последней версии. Существующий контроллер домена будет называться DC-AD , а новый - RNS .
Я также отключил оба брандмауэра Windows и сделал разрешить все в наших брандмауэрах между двумя DC (по крайней мере, DC (DC-AD) и i-would-like-to-be-DC (RNS)).
Вот результаты сканирования nmap:
- От RNS к DC-AD:
- От DC-A к RNS:
Я перепробовал все, что мог придумать, или все, что смог найти в Интернете, но большинство проблем связано с заблокированными портами в брандмауэре .
Это не все необходимые порты AD.
- TCP и UDP 389
- TCP 636
- TCP 3268
- TCP 3269
- TCP и UDP 88
- TCP и UDP 53
- TCP и UDP 445
- TCP 25
- TCP 135
- TCP Dynamic
- TCP 5722
- UDP 123
- TCP и UDP 464
- UDP Dynamic
- UDP 138
- TCP 9389
Я получил этот список здесь ; есть таблица, объясняющая, для чего AD использует каждый порт.
В другой статье, которую я нашел , предлагалось эти порты только для dcpromo:
- TCP 3269
- TCP 3268
- TCP 389
- UDP 389
- TCP 636
- UDP 636
- UDP 500
- UDP 4500
- TCP 135
- Случайный TCP 1024–65535, 49152–65535²
Итак, после запуска PortQueryUI я обнаружил, что несколько портов нужно отфильтровать, несмотря на то, что у меня были разрешены все правила между этими двумя хостами.
Я пошел дальше и использовал tcpdump-d и обнаружил, что у одного брандмауэра неправильное правило, из-за которого некоторые порты фильтруются.
После исправления этого правила dcpromo нормально работал.
Большое спасибо всем, кто мне помог!