Работа с контроллерами домена Read-Only (RODC) (часть 1)

Введение

В Windows Server 2008, Microsoft решила вернуть функцию, которую мы не видели со времен Windows NT: это технология контроллеров домена, доступных только для чтения. В этой статье я расскажу про технологию Read Only Domain Controllers и ее преимущества. Я ранее не раз упоминал об этой технологии в своих статьях, например в статье про использование утилиты adprep в Windows 2008.

Хорошим примером циклического характера развития IT технологий является новая функция Windows Server 2008, которая называется Read Only Domain Controller, или RODC. Ведь эта технология впервые появилась уже давно, однако протяжении последних 10 лет практически не применялась.

Windows NT была первой серверной ОС от Microsoft. Как и современные операционные системы Windows Server, Windows NT полностью поддерживала технологию доменов. Одним отличием был тот факт, что только один контроллер домена в каждом домене был доступен для записи. Этот контроллер домена, называемый Primary Domain Controller или PDC, был единственным контроллером домена, в который администратор мог вносить изменения. Основной контроллер домена затем передавал обновления на другие контроллеры домена в домене. Эти контроллеры домена назывались резервными контроллерами домена (backup domain controllers или BDC), и информация на них обновлялась только при обновлении основного контроллера домена, для клиентов домена они были доступны только на чтение.

И хотя эта доменная модель была полностью работоспособной, у нее были и существенные недостатки. В частности, проблемы с основным контроллером домена могли парализовать работу всего домена целиком. Как вы знаете, Microsoft внесла значительные изменения в доменную модель, которую они внедрили в свою новую серверную ОС Windows 2000 Server. В Windows 2000 Server появились две новые технологии для контроллеров доменов, и оба этих нововведения используются и по сей день: это Active Directory и модель с несколькими основными контроллерами (multi master модель).

И хотя роль PDC все еще сохранялась, остальные контроллеры домена в мульти-мастерной конфигурации были доступными на запись. Это означало, что администратор может внести изменения на любом контроллере домена, и эти изменения в виде обновлений в конечном итоге будут распространены на все другие контроллеры домена в сети.

Затем мульти-мастерная модель была сохранена и в Windows Server 2003 и в Windows Server 2008. Однако, в Windows Server 2008 появилась возможность создавать контроллеры домена только для чтения (Read Only Domain Controllers). RODC – это контроллер домена, информация в котором не может быть изменена непосредственно даже администраторами. Единственный способ обновления этих контроллеров домена — применить изменения на PDC, а затем эти изменения должны быть распространены (реплицированы) на RODC. Ничего не напоминает?

Как вы видите, RODC, являются не чем иным, как пережитком времен Windows NT. Безусловно, Microsoft не вернула бы технологию RODC, если бы не усмотрела бы в их применении существенных преимуществ.

Прежде чем приступить к объяснению того, почему Microsoft решила вновь вернуться к RODC, позвольте мне пояснить, почему использование RODC не является обязательным условием работы с доменами Active Directory в 2008 Server. Если вы хотите, чтобы каждый контроллер домена в вашем лесу был доступен для записи, вы, безусловно, может сделать это.

Я хочу вкратце упомянуть, что несмотря на то, что RODC, очень похожи на резервные контроллеры домена (BDC) в NT, они претерпели ряд изменений. Есть несколько вещей, которые являются новинками в технологии RODC, и я хочу о них рассказать.

Итак, почему Microsoft решила вернуть RODC? Это связано с проблемами поддержки филиальной сети (подразделений и филиалов). Офисы филиалов традиционно достаточно трудно сопровождать и поддерживать из-за их удаленности и особенностей связи между головным офисом и филиалом.

Традиционно применялось несколько различных способов управления филиалами, но каждый из них имел свои собственные преимущества и недостатки. Одним из наиболее распространенных способов организации филиальной сети является установка всех серверов в главном офисе, и предоставление доступа к ним пользователей филиала через глобальную сеть (WAN).

Конечно, наиболее очевидным недостатком такого метода является то, что если канал WAN нестабилен или отвалился, то пользователи, которые находятся в филиале, не в состоянии нормально работать, т.к. они полностью отрезаны от всех ресурсов центрального офиса. Даже если сетевое соединение с головным офисом стабильно, зачастую производительность WAN соединения может быть невысока из-за нагрузки на канал или непосредственно скорости соединения

Другим распространенным вариантом при работе с удаленными филиалами является подход, предусматривающий установку по крайней мере одного контроллера домена в филиал. Часто, этот контроллер домена также выступает в качестве сервера DNS и сервера глобального каталога. Таким образом, даже если WAN подключение разрывается, то пользователи в филиале, по крайней мере, имеют возможность войти в сеть. В зависимости от характера работы организации, в филиальном подразделении могут устанавливать и другие сервера.

Хотя это решение, как правило, работает довольно неплохо, и у него есть ряд недостатков. Основным недостатком является стоимость. Размещение серверов в филиалах требует от предприятия вкладывать деньги в серверное оборудование и лицензии на программное обеспечение. Существенно увеличиваются также затраты на поддержку. Организация должна определить, нужен ли в филиале штат собственных ИТ-специалистов, или в случае неполадок, она готова ждать пока ИТ-персонал из центрального офиса доберется в филиал.

Еще один нюансом при установке собственных серверов в филиале, является вопрос безопасности. В моем опыте нередки случаи, при которых сервера, которые расположены за пределами центрально датацентра, оставались банально без присмотра. Часто сервера просто закрывают в шкафу на ключ!

Как я упоминал ранее, WAN соединения часто бывают медленным и ненадежным. В этом кроется еще одна проблема с размещением серверов в филиале. Трафик репликации контроллеров домена может существенно загрузить такое соединение

Вот это как раз тот случай, когда можно использовать RODC. Размещение RODC в филиал не избавляет совсем от трафика репликации Active Directory, но существенно снижает нагрузку на bridgehead сервера, т.к. они получают только входящий трафик репликации.

RODC могут также способствовать повышению безопасности, ведь персонал в офисе филиала не сможет внести изменения в базу данных Active Directory. Кроме того, никакой информации обо всех пользователях домена и их учетках, не передаются на RODC. Это означает, что если кто-то украл сервер RODC, он не сможет воспользоваться информацией, полученной в результате взлома паролей пользователей.