none
Настройка RODC в отдельном офисе RRS feed

  • Вопрос

  • Здравствуйте.

    Имеется головной офис и офис филиала.

    В головном два полноценных DC, в филиале - RODC.

    На RODC установлен ДНС-сервер, настроено кэширование паролей пользователей, компьютеров и серверов. Пользователи логинятся на нем (set logonserver выдает ответ \\RODC). Но при обрыве соединения между центральным и филиальным офисом пользователи не могут получить доступ на сетевые ресурсы с ошибкой "Разрешение на доступ к \\ip\share отсутствует". При опросе domain.local ДНС-сервер не дает ответа, т.к. ищет записи на ДНС контроллеров домена в офисе, которые в данный момент недоступны.

    Подскажите, пожалуйста, что я мог пропустить в настройке RODC в моем случае? Спасибо.


    26 декабря 2016 г. 4:51

Ответы

  • Вон как у вас там всё интересно устроено, оказывается! Может, ещё что-нибудь интересное есть.

    С пользователями, которые находятся в старом домене всё очень просто: при обрыве связи с полноценным КД нового домена они доступ не получат, потому что через RODC доверительные отношения не работают: пароли для доверенных доменов на него не реплицируется.

    Далее. Компьютеры из старого леса (как я понимаю, старый и новый домены у вас в разных лесах, так?) ничего не знают про сайты из нового леса, потому ищут контроллеры домена на уровне всего домена - где RODC не регистрируется.

    А чтобы разобраться с пользователями из нового домена на компьютерах из этого же домена, нужно видеть глазами, что у вас там настроено (выдача ipconfig /all с клиента - настройка серверов DNS, выдача dnscmd /zoneinfo новый.домен на сервере DNS старого домена - настройка условной пересылки, адрес IP RODC в новом домене)

    Если какие-то из таких пользователей не получают доступ, то, прежде всего, следует проверить, какие контроллеры домена они находят в своём сайте.  Проверить это можно командой:

      nltest /dnsgetdc:имя.домена /site:имя_сайта

    (nltest входит в состав средств управления ролью AD DS в RSAT). Если там нет этого вашего RODC, то надо разбираться, куда он девается.


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

    5 января 2017 г. 15:10
  • RODC должен был зарегистрировать свои записи для обнаружения себя на нормальном контроллере домена. Но регистрирует он записи только на уровне сайта: в поддоменах _tcp.имя_сайта._sites.dc._msdcs, _tcp.имя_сайта._sites._gc._msdcs и _tcp.имя_сайта._sites. На глобальном уровне (в поддоменах _tcp.dc._msdcs, _tcp._gc._msdcs, _tcp и др.) он записи не регистрирует. Поэтому через DNS клиенты смогут найти RODC только в пределах своего сайта.

    Отсюда вывод: проверьте имя сайта, к которому принадлежит RODC. А то это вполне распространённая ошибка: установить КД для филиала в центральном офисе и забыть поменять его принадлежность к сайту после перевозки на место. Ну и регистрацию записей SRV на уровне сайта тоже на всякий случай стоит проверить.


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


    28 декабря 2016 г. 7:41
  • Зависит чисто от ваших требований по безопасности. Если риск несанкционированного доступа к контроллеру или его хищения (что приводит к получению всех паролей пользователей AD) исключён или не является значимым - то допускается.

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

    7 января 2017 г. 21:32

Все ответы

  • Не увидел один важный момент про настройки: Global Catalog на RODC есть?

    И ещё, до кучи: поcмотрите, действительно ли реплицированы пароли этих пользователей на RODC (в свойствах учётной записи RODC в AD Users & Computers, вкладка Password Replication Policy, кнопка Advanced).


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

    26 декабря 2016 г. 9:50
  • Да - GC галочка стоит. Пароли реплицированы.

    Не совсем понятен такой момент: когда теряется связь между филиалом и головным офисом, ДНС в филиале не разрешает имя домена, т.к. записи домена на ДНС-сервере соотносятся только с RWDC. Как клиенты в таком случае находят домен? 




    28 декабря 2016 г. 3:40
  • RODC должен был зарегистрировать свои записи для обнаружения себя на нормальном контроллере домена. Но регистрирует он записи только на уровне сайта: в поддоменах _tcp.имя_сайта._sites.dc._msdcs, _tcp.имя_сайта._sites._gc._msdcs и _tcp.имя_сайта._sites. На глобальном уровне (в поддоменах _tcp.dc._msdcs, _tcp._gc._msdcs, _tcp и др.) он записи не регистрирует. Поэтому через DNS клиенты смогут найти RODC только в пределах своего сайта.

    Отсюда вывод: проверьте имя сайта, к которому принадлежит RODC. А то это вполне распространённая ошибка: установить КД для филиала в центральном офисе и забыть поменять его принадлежность к сайту после перевозки на место. Ну и регистрацию записей SRV на уровне сайта тоже на всякий случай стоит проверить.


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


    28 декабря 2016 г. 7:41
  • Все указанные записи присутствуют на ДНС-сервере. RODC находится в сайте филиала.

    Есть такой нюанс. Учетные записи пользователей и компьютеров филиала в свое время были мигрированы в основной домен. Часть компьютеров, пользователей и серверов филиала еще находятся в старом домене. DHCP указывает всем клиентам на ДНС сервер старого домена, на котором указан сервер условной пересылки (Conditional Forwarders) на ДНС-сервер RODC. Может ли из-за этого при обрыве связи с головным офисом клиенты теряют домен?

    5 января 2017 г. 2:32
  • Вон как у вас там всё интересно устроено, оказывается! Может, ещё что-нибудь интересное есть.

    С пользователями, которые находятся в старом домене всё очень просто: при обрыве связи с полноценным КД нового домена они доступ не получат, потому что через RODC доверительные отношения не работают: пароли для доверенных доменов на него не реплицируется.

    Далее. Компьютеры из старого леса (как я понимаю, старый и новый домены у вас в разных лесах, так?) ничего не знают про сайты из нового леса, потому ищут контроллеры домена на уровне всего домена - где RODC не регистрируется.

    А чтобы разобраться с пользователями из нового домена на компьютерах из этого же домена, нужно видеть глазами, что у вас там настроено (выдача ipconfig /all с клиента - настройка серверов DNS, выдача dnscmd /zoneinfo новый.домен на сервере DNS старого домена - настройка условной пересылки, адрес IP RODC в новом домене)

    Если какие-то из таких пользователей не получают доступ, то, прежде всего, следует проверить, какие контроллеры домена они находят в своём сайте.  Проверить это можно командой:

      nltest /dnsgetdc:имя.домена /site:имя_сайта

    (nltest входит в состав средств управления ролью AD DS в RSAT). Если там нет этого вашего RODC, то надо разбираться, куда он девается.


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

    5 января 2017 г. 15:10
  • Спасибо за ответы.

    Скажите, допустимо ли использование в филиале, находящегося в главном домене (домене центрального офиса), полноценного контроллера домена?

    7 января 2017 г. 19:26
  • Зависит чисто от ваших требований по безопасности. Если риск несанкционированного доступа к контроллеру или его хищения (что приводит к получению всех паролей пользователей AD) исключён или не является значимым - то допускается.

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

    7 января 2017 г. 21:32