Работа с контроллерами доменов, доступными только для чтения (часть 2)

В своей предыдущей статье я объяснил основные причины решения компании Microsoft вернуть функцию контроллеров домена – только чтение в Windows Server 2008. В этой статье мы продолжаем рассмотрение некоторых практических аспектов работы с контроллерами доменов – только чтение (Read Only Domain Controllers – RODC).

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

Мандаты пользовательской учетной записи

Я хочу начать с прояснения того, что сказал в конце предыдущей части. Я сказал, что никакая информация учетной записи пользователя не храниться на контроллерах домена – только чтение. Когда я перечитывал свою предыдущую часть статьи, я понял, что подобрал слова очень неточно.

В действительности информация учетной записи пользователя храниться на контроллерах домена – только чтение. Однако на них не хранятся пароли пользователей. Пароли не реплицируются на RODC. Если кто-то украдет контроллер домена из офиса филиала, он не сможет воспользоваться информацией, хранящейся в базе данных Active Directory для взлома пользовательского пароля.

Атрибуты пользователей

По умолчанию пароли являются единственными пользовательскими атрибутами, которые не реплицируются на RODC. Однако у вас есть возможность настроить Windows вручную так, чтобы другие пользовательские атрибуты не копировались на эти контроллеры домена.

Так зачем использовать такую функцию? Если вы используете Active Directory лишь в качестве механизма проверки подлинности, то вам не потребуется использовать данную функцию. Однако следует учитывать, что существуют организации, которые используют Active Directory не только для аутентификации.

Для примера того, о чем я говорю, я расскажу вам о месте, в котором раньше работал. Это была большая производственная среда со своим персоналом разработчиков. Разработчики компании создавали собственные приложения практически для всех своих производственных процессов. Практически все эти приложения работали на основе баз данных, но ни одна из баз данных не была связана с другой.

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

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

Например, я знаю одну организацию, которая создала приложение отдела кадров, используемое внутри компании. Хотя основная часть данных храниться на сервере SQL Server, такие вещи как имена сотрудников, названия, телефонные номера и т.п. хранятся в Active Directory в виде атрибутов учетных записей пользователей. Это позволяет повторно использовать общую информацию в нескольких местах и не требует связи между именами пользователей и более конфиденциальными данными. Базы данных сервера SQL Server содержат такие вещи как номер социального страхования и размер зарплаты, но не содержат имен сотрудников. Единственной общей информацией, которая содержится в обеих базах, является номер сотрудника.

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

Однако следует учитывать один момент. Хотя некоторые организации используют атрибуты учетных записей пользователей в приложениях, обычно приложения используют разделы каталогов приложений. Если вы не знакомы с таким каталогами разделов приложений, скажу, что это специальные разделы Active Directory, которые создаются специально для использования приложениями. Контроллеры домена RODC полностью поддерживают одностороннюю репликацию данных, хранящихся в разделах каталогов приложений.

Контроллеры домена – только чтение можно настроить в качестве DNS серверов, доступных только для чтения. По сути, это означает, что если вы расположите DNS сервер на RODC, то взломщик не сможет причинить ущерб DNS записям.

Проблемы администрирования

Уверен, что к данному моменту у вас накопилась масса вопросов об администрировании контроллеров домена – только чтение. Я попытался сделать все, чтобы предугадать эти вопросы и ответить на них.

Как пользователи проходят проверку подлинности, если отсутствуют данные паролей?

Это довольной сложный момент. Как вы, вероятно, знаете, учетные записи пользователей и компьютеров имеют свои пароли. По умолчанию единственным паролем, который храниться на RODC, будет пароль его собственной учетной записи компьютера, а также пароли для специальных учетных записей под названием «krbtgt», используемых механизмом Kerberos.

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

Как работает администрирование?

Очень часто в офисах филиалов контроллеры домена настроены на работу в качестве серверов приложений. Если в филиале отсутствуют специальные ИТ сотрудники, вы можете назначить кого-либо администратором контроллера домена – только чтение без необходимости предоставлять ему права администратора домена. Таким образом, у них будет контроль локального администратора над серверами, но при этом они не смогут причинить вреда службе Active Directory. Это позволяет им устанавливать обновления приложений и выполнять любые необходимые задачи обслуживания. Назначение кого-либо в качестве администратора RODC подобно предоставлению прав локального администратора сервера-участника или отдельного сервера.

Заключение

Надеюсь у вас теперь есть базовое понимание того, как контроллеры домена – только чтение используются в реальном мире. В третьей части этого цикла статей я опишу процесс установки контроллера домена RODC.