none
Branch RODC проблема репликации RRS feed

  • Вопрос

  • Здравствуйте уважаемые коллеги,

    В нашей компании имеется не большой удаленный офис с не оч.хорошим ВПН,

    по этому было принято решение развернуть в нем RODC (DCK -его имя) на 2012R2,

    С развертыванием проблем не возникло, включил DCК  он при этом успешно реплицировался, и все показалось таким радужным,

    Но грабли начались сразу же, 2я и последующие репликации не прошли, при попытке закотить солнце в ручную получил ошибку -

     

    Домен контролер пингуется, Отключил Брандмауер, - ошибка повторилась

    так же выявлены симптомы:

    1. При авторизации на контроллере домена процесс очень длительный

    2. PortQryUI  зависает на этапе

    portqry.exe -n dc1 -e 135 -p TCP exits with return code 0x00000000.
    =============================================
     Starting portqry.exe -n dc1 -e 389 -p BOTH ...

    Хотя проходит аналогичная проверка по UDP - portqry -n dc1 -e 389 -p UDP

    ======== End of LDAP query response ========
    UDP port 389 is LISTENING

    Проверка по головам (от Бранча к головному), других портов выявила-

    Starting portqry.exe -n dc1 -e 389 -p TCP ...  ЗАДИМАЛСЯ И НЕ ОТВЕТИЛ

    TCP port 636 (ldaps service): LISTENING

    Starting portqry.exe -n dc1 -e 3268 -p TCP ...   ЗАДИМАЛСЯ И НЕ ОТВЕТИЛ

    TCP port 88 (kerberos service): LISTENING

    UDP port 88 (kerberos service): LISTENING or FILTERED
    portqry.exe -n dc1 -e 88 -p UDP exits with return code 0x00000002.

    TCP port 53 (domain service): LISTENING
    portqry.exe -n dc1 -e 53 -p TCP exits with return code 0x00000000.

    UDP port 53 is LISTENING
    portqry.exe -n dc1 -e 53 -p UDP exits with return code 0x00000000.

    TCP port 445 (microsoft-ds service): LISTENING
    portqry.exe -n dc1 -e 445 -p TCP exits with return code 0x00000000.

    UDP port 445 (microsoft-ds service): NOT LISTENING
    portqry.exe -n dc1 -e 445 -p UDP exits with return code 0x00000001.

    TCP port 135 (epmap service): LISTENING

    UDP port 137 (netbios-ns service): LISTENING or FILTERED
    Server's response: MAC address 00155d010113
    UDP port: LISTENING
    portqry.exe -n dc1 -e 137 -p UDP exits with return code 0x00000000.

    UDP port 138 (netbios-dgm service): LISTENING or FILTERED
    portqry.exe -n dc1 -e 138 -p UDP exits with return code 0x00000002.

    3. DCK отвечает главному контроллеру по всем портам

    4. с рабочей станции в локальной сети главного офиса DC1 на все запросы отвечает

    TCP port 389 (ldap service): LISTENING

    TCP port 3268 (msft-gc service): LISTENING

    Логично предположить что порты закрыты для запросов из НЕ ЛОКАЛЬНОЙ сети,

    НО (еще раз повторюсь) все проверки проводились при отключенном Брандмауере

    Подскажите пожалуйста,

    куда копать проблему 

    19 ноября 2014 г. 10:52

Ответы

  • Извините за задержку,

    тест проходит -

         C:\>rpcping /s dc1 /t ncacn_ip_tcp
         Completed 1 calls in 31 ms
         32 T/S or  31.000 ms/T

    Есть еще симптом, проверка DNS проходит, но с большой задержкой (~30сек),  

    C:\>dnscmd dc1 /EnumZones

    Enumerated zone list:
            Zone count = 6
    • Помечено в качестве ответа ZVitaly 21 ноября 2014 г. 7:35
    21 ноября 2014 г. 7:34

Все ответы

  • А вот так http://technet.microsoft.com/en-us/library/hh875578.aspx?
    19 ноября 2014 г. 11:20
  • Извините за задержку,

    тест проходит -

         C:\>rpcping /s dc1 /t ncacn_ip_tcp
         Completed 1 calls in 31 ms
         32 T/S or  31.000 ms/T

    Есть еще симптом, проверка DNS проходит, но с большой задержкой (~30сек),  

    C:\>dnscmd dc1 /EnumZones

    Enumerated zone list:
            Zone count = 6
    • Помечено в качестве ответа ZVitaly 21 ноября 2014 г. 7:35
    21 ноября 2014 г. 7:34
  • И снова здравствуйте уважаемые коллеги,

    Проблема остается, для изучения вопроса поднял тестовый домен с аналогичными условиями,

    наблюдается следующий симптом -

    утилита portquery из локальной сети показывает что проблемный порт открыт -

       TCP port 389 (ldap service): LISTENING

        ....

        ======== End of LDAP query response ========
        portqry.exe -n 192.168.1.203 -e 389 -p TCP exits with return code 0x00000000.

    Из удаленной сети -

        TCP port 389 (ldap service): FILTERED
        portqry.exe -n 192.168.1.203 -e 389 -p TCP exits with return code 0x00000002.

    В фаервол добавил правило на входящий трафик на порт 389 со всеми мыслимыми разрешениями и правило разрешающее весь исходящий трафик (на случай если режутся ответы)

    Не помогло, также как и отключение файервола ваабще.

    Логично предположить что запросы режутся где то на уровне AD

    В остнастке - Active Directory Sites and Sevices есть раздел Subnets, добавление в него удаленной сети проблему не решило.

    В общем - грусть, тоска и мировая скорбь :(

    Уважаемые коллеги,

    кто знает как добавить доверенную сеть, чтобы АД ее считало своей?


    • Изменено ZVitaly 27 ноября 2014 г. 10:44
    27 ноября 2014 г. 10:43
  • AD в принципе имеет возможность резать запросы только после установления соединения. Так что, проблема  - в брандмауэрах: на сервере с AD или на маршрутизаторах между сетями.

    Слава России!

    27 ноября 2014 г. 11:47