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

Введение

В моей предыдущей статье я объяснил основную причину решения Microsoft предложить контроллеры домена только для чтения в Windows Server 2008. Эта статья продолжает серию, исследуя некоторые практические аспекты работы с контроллерами домена только для чтения.

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

Учетные данные пользователя

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

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

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

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

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

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

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

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

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

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

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

Аналогичным образом, контроллеры домена только для чтения также можно настроить для работы в качестве DNS-серверов только для чтения. По сути, это означает, что если вы размещаете DNS-сервер на контроллере домена только для чтения, злоумышленник не сможет вмешиваться в записи DNS.

Административные вопросы

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

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

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

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

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

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

Вывод

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