Руководство по репликации Active Directory

До внедрения Windows 2000 Server и Active Directory во многих корпоративных сетях для поддержания серверной инфраструктуры и управления идентификацией и правами доступа использовалась ОС

Windows NT. До выпуска Windows NT® 4.0 она была цельным предложением на рынке сетевых операционных систем, однако у нее был ряд недостатков, затрудняющих ее развертывание на большом предприятии.

Прежде всего, в Windows NT для именования сетевых ресурсов использовалось одноуровневое пространство имен. В результате не существовало удовлетворительного способа разделить ресурсы на меньшие подмножества или настроить хоть какое-то групповое администрирование. Например, нельзя было создать отдельный контейнер для ресурсов отдела маркетинга или назначить локального администратора с правом изменения паролей только для пользователей этого отдела. Безопасность в Windows NT в основном строилась по принципу «все или ничего». Если нужно было делегировать часть административных заданий инженеру технической поддержки настольных компьютеров, часто не оставалось ничего другого, кроме как давать ему намного больше полномочий, чем можно было бы при другой модели безопасности.

Кроме того, вся информация Windows NT сохранялась в базе данных диспетчера учетных записей безопасности (SAM), объем которой не мог превышать 40 МБ. Если база данных SAM вырастала больше рекомендованного максимума (примерно 25000-40000 объектов, в зависимости от настройки), приходилось делить сеть на несколько отдельных доменов, что усложняло администрирование сети и предоставление пользователям доступа к ресурсам. Каждый домен NT содержал один и только один основной контроллер домена с копией базы данных SAM, доступной на запись и чтение. Кроме него для защиты от сбоев в домене можно было создать один или несколько резервных контроллеров домена. Резервные контроллеры содержали копию базы, открытую только, на чтение и модифицировать данные они не могли. Поэтому им нельзя было, например, менять пароли пользователей, поскольку это требует доступа на запись.

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

Появление новой модели

В 2000 году Microsoft выпустил Windows® 2000, являющийся значительным шагом вперед по сравнению с предыдущими NOS. Новая служба сетевой ОС, Active Directory®, настолько отличалась от Windows NT, насколько это можно себе представить. Вместо того, чтобы опираться на одноуровневое пространство имен, Active Directory была построена на стандарте X.500, предполагающем создание иерархических организационных структур. Ресурсы можно было объединять в многочисленные организационные подразделения внутри одного домена и делегировать администрирование каждым подразделением на уровне задач.

Другим заметным отходом от Windows NT стала новая модель репликации — репликация с несколькими хозяевами. Вместо единственного пишущего основного контроллера домена и связанных с ним резервных контроллеров домена в Active Directory каждый контроллер домена может записывать в базу данных Active Directory.

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

Механизмы репликации Active Directory

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

Поскольку Active Directory может масштабироваться до сотен тысяч и даже миллионов объектов, необходимо разбивать базу данных Active Directory на части. Эти части называются контекстами именования (NC). Каждый контроллер домена хранит как минимум три контекста именования в своей локальной копии базы данных Active Directory.

Контекст именования «Схема» Этот контекст именования реплицируется на все остальные контроллеры доменов в лесе. В нем содержится информация о схеме Active Directory, которая определяет классы объектов Active Directory и их атрибуты.

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

Контекст именования «Домен» Этот контекст именования реплицируется всем остальным контроллерам доменов в пределах одного домена Active Directory. В этом контексте именования находятся наиболее часто запрашиваемые данные Active Directory: реальные пользователи, группы, компьютеры и другие объекты, находящиеся внутри домена Active Directory.

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

Поскольку с любого контроллера домена Active Directory можно вносить изменения, репликация Active Directory должна отслеживать два типа операций записи. Один тип — это порождающие записи, когда какие-то изменения вносятся в некоторый контроллер домена напрямую. Например, можно подключиться к DC1 и поменять пароль пользователя. Это изменение считается порождающей записью в DC1. Кроме того, Active Directory должна отслеживать реплицированные записи — это, как можно предположить, те изменения, которые реплицированы с другого контроллера домена. Изменение, которое было порождающей записью для DC1, будет считаться реплицированной записью на DC2, DC3 и всех прочих контроллерах домена в домене.

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

Обсудим для начала элемент метаданных репликации, называемый номером последовательного обновления (USN). Каждый контроллер домена поддерживает USN, который ему специфичен. Как только данный контроллер домена вносит изменения в Active Directory, к значению USN прибавляется 1. Если у DC был USN, равный 1000 в 11:00 утра, и 1005 в 11:30 утра, значит, на этом DC был сделано 5 изменений базы данных Active Directory. C точки зрения USN неважно, какими именно были изменения. И при модификации, и при удалении, и при создании, и при любых комбинациях действий над 5 объектами значение USN контроллера домена увеличится ровно на 5. Более того, USN существуют только в пределах определенного контроллера домена, между USN разных контроллеров домена нет никакой связи, и сравнивать их значения нельзя. Один контроллер в домене может внести изменения в 11:30 и присвоить USN значение 1051. Второй контроллер того же домена может внести изменения в тот же самый момент, что и первый, но присвоить USN значение 5084. Эти два контроллера домена будут иметь совершенно разные USN для изменений, происшедших почти одновременно. Однако на репликацию изменений это никак не повлияет, потому что сравнение номеров последовательного обновления для разных контроллеров домена не имеет смысла.

Однако USN может увеличиваться и по другим причинам. Выше говорилось, что изменения в базе данных Active Directory состоят из порождающих и реплицированных записей. Номер последовательного обновления контроллера домена увеличивается обоими типами операций на запись, то есть всякий раз, когда изменения реплицируются с другого контроллера домена. Очевидно, что каждому контроллеру домена нужно как-то следить за тем, какие изменения уже реплицировались, иначе при каждой репликации отправлялась бы вся база данных Active Directory. Чтобы этого не произошло, каждый контроллер домена Active Directory поддерживает величину, называющуюся вектором верхних пределов (HWMV) для всех остальных контроллеров домена, с которыми происходит обмен данными при репликации. Каждый контроллер домена связывает этот вектор верхних пределов с глобальным уникальным идентификатором (GUID) удаленного контроллера домена, чтобы предотвратить путаницу в случае, если этот контроллер домена переименуют или удалят из каталога.

Начнем с простого примера. Пусть есть два контроллера, настроенных в домене contoso.com, dc1.contoso.com и dc2 contoso.com. Поскольку в домене contoso.com только два контроллера домена, репликация будет происходить только между DC1 и DC2. (В этом упрощенном примере не раскрыт полный механизм репликации, в дальнейшем к нему будут добавлены дополнительные детали).

Пусть USN у DC1 равен 3000, у DC2 4500 и оба контроллера домена на начало примера обновлены.

Шаг 1: DC1 и DC2 обновлены друг относительно друга. У DC1 есть вектор верхнего предела для DC2 со значением 4500, у DC2 вектор верхнего предела для DC1 со значением 3000, как показано на рис. 1.

Рис. 1 Текущее состояние двух контроллеров домена

Шаг 2: Администратор создает новый объект на DC1, USN DC1 увеличивается до 3001, как показано на рис. 2. Заметьте, что HWMV DC1 на DC2 не изменился, потому что DC1 еще не сообщил DC2 о том, что у него есть ожидающие репликации изменения.

Рис. 2 Добавлен новый объект

Шаг 3: DC1 сообщает DC2 об изменении. Затем DC2 начинает репликацию с DC1, чтобы запросить все доступные изменения. Как часть запроса, DC2 отправляет DC1 вектор верхнего предела, который хранился для DC1, как показано на рис. 3.

Рис. 3 Оповещения об изменениях

Шаг 4: DC1 отправляет на DC2 изменение, соответствующее USN 3001, то есть тот объект, который был создан на DC1 в шаге 2. DC2 обновляет свой USN до 4501 и свой HWMV для DC1 до 3001, как показано на рис. 4.

Рис. 4 Изменения и обновления

Пока все идет нормально. Но есть проблема. У DC2 есть изменения, которые нужно реплицировать. Если единственными ориентирами являлись бы номера USN и векторы верхнего предела, в этот момент DC2 связался бы с DC1 чтобы реплицировать назад на DC1 то же изменение, которое DC1 только что реплицировал на DC2. В результате образовался бы бесконечный цикл репликации, который постепенно занимал бы все большую и большую долю пропускной способности. Чтобы бороться с этим, нужно поставить на место еще несколько кусочков головоломки, первый из которых — вектор синхронизации (вектор UTD или просто UTDV).

Вектор синхронизации — это еще одна часть метаданных репликации. Он используется для предотвращения распространения, то есть его назначение состоит в том, чтобы предотвратить исчерпание полосы пропускания повторной репликацией одного и того же изменения. Каждый контроллер домена поддерживает таблицу вектора синхронизации для каждого другого контроллера домена, в которой хранится реплика рассматриваемого контекста именования. Для каждого контекста именования «Домен» каждый контроллер домена в домене поддерживает вектор синхронизации для каждого контроллера домена в домене; контексты именования «Конфигурация» и «Схема» поддерживаются каждым контроллером домена в лесе. Таблица вектора синхронизации не только следит за максимальным USN, который каждый контроллер домена получает от своих партнеров по репликации, но и за максимальным USN, получаемым от каждого контроллера домена, замещающего данный контекст именования. Чтобы это стало возможным, каждое изменение при репликации включает следующую информацию:

• Номер GUID контроллера домена, который реплицирует изменение. Это может быть изменение, которое реплицируется как порождающая запись или как реплицированная запись.
• USN контроллера домена, который реплицирует изменение. Оно тоже может быть от порождающей или реплицированной записи.
• Номер GUID контроллера домена, который реплицирует изменение. Если этот номер GUID равен номеру GUID контроллера домена, пославшему репликацию, то это порождающая запись. Иначе в дело вступает таблица вектора синхронизации.
• USN контроллера домена, являющегося источником изменения. Опять же, если этот номер GUID равен номеру GUID контроллера домена, пославшему репликацию, то это порождающая запись. Иначе, это из таблицы вектора синхронизации.

Чтобы лучше проиллюстрировать процесс, усложним пример и добавим третий контроллер домена, DC3. В этом случае DC1, DC2 и DC3 являются партнерами репликации друг для друга. DC1 реплицируется с DC2 и DC3, DC2 с DC1 и DC3, и DC3 с DC1 и DC2:

Шаг 1: DC1, DC2 и DC3 все обновлены друг относительно друга.

Шаг 2: DC3 производит одну порождающую запись, изменяя пароль учетной записи пользователя икузнецов. DC3 сообщает DC1 и DC2 о доступном изменении. DC1 и DC2 запрашивают порождающую запись с DC3, а потом обновляют свои HWMV и таблицы векторов синхронизации для DC3, как показано на рис.5.

Рис. 5 Обновление таблиц HWMV и векторов синхронизации

Шаг 3: На этом шаге начинает работать вектор синхронизации. DC2 сообщает DC1, что у него есть изменения. DC1 связывается с DC2, запрашивая новые изменения. При этом DC2 передается следующая информация:

• Верхний предел DC1 для DC2, в данном случае 4501.
• Таблица вектора синхронизации контроллера домена DC1 (показано на рис.6), указывающая максимальный порождающий USN, который получили все контроллеры домена, включая DC3.

Рис. 6  Таблица вектора синхронизации.

Все контроллеры домена, реплицирующие этот контекст именования UTDV

<Номер GUID контроллера DC2>	4501
<Номер GUID контроллера DC3>	7002

Основываясь на значении HWMV 4501, DC2 решает, что он не реплицировал изменения примера на DC1 (см. рис.7).

Рис. 7  Изменение, которое нужно реплицировать

Свойство Значение Номер GUID локального контроллера домена Локальный USN Номер GUID исходного контроллера домена Оригинальный USN

Свойство пароль икузнецов	%#FH%2rfg2	<Номер GUID контроллера DC2>	4501	<Номер GUID контроллера DC3>	7002

Однако на основании данных таблицы вектора синхронизации, которую передал перед началом репликации DC1, DC2 выясняет, что DC1 не нуждается в этом изменении, поскольку он уже получил его от DC3. В этот момент DC1 только обновляет свой HWMV для DC2, отображая увеличенный USN, как показано на рис. 8. Однако для того, чтобы сохранить пропускную способность, сами данные по сети не передаются.

Рис. 8 Гашение распространения

Шаг 4: Такое же гашение распространения происходит, когда о наличии изменений DC2 оповещает DC3, и когда DC1 также оповещает DC2 и DC3. Все три контроллера домена обновят свои соответствующие вхождения HWMV для всех партнеров репликации, как показано на рис. 8, однако сами данные не будут передаваться по сети, потому что они уже передались каждому контроллеру домена на шаге 2.

Разрешение конфликтов в среде с несколькими хозяевами

До сих пор наши примеры описывали идеальный мир, где только один администратор вносил изменения на контроллер домена в каждый момент времени и никто никому на ноги не наступал. Однако в реальном мире такое случается редко. Поскольку обновления объектов Active Directory могут поступить от любого контроллера в домене, что будет, если два администратора сделают несовместимые изменения с двух разных контроллеров домена? Существуют три типа конфликтов, которые происходят в Active Directory, для каждого из которых есть свой метод разрешения.

Конфликтующие изменения свойств . Такой конфликт происходит, когда два администратора обновляют один объект, так что возникает конфликт: один администратор устанавливает описание пользователя «Маркетинг», а другой администратор с другого контроллера домена — «Маркетинг и продажи».

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

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

Говоря о первых двух типах конфликтов, рассмотрим еще две составляющих метаданных репликации, использующихся в основном для разрешения конфликтов. Каждому атрибуту объекта назначается величина versionID, устанавливаемая в единицу при создании объекта. Величина versionID увеличивается на 1 каждый раз, когда контроллер домена модифицирует атрибут. Таким образом, если атрибут «описание» некоторого пользователя меняется со значения по умолчанию (пусто или <не установлено>) на «Отдел маркетинга», versionID этого атрибута станет равен 2. Если позже описание поменяется на «Отдел продаж и маркетинга», versionID будет равен 3, и так далее. versionID включается в каждый элемент репликации вместе с другими, уже рассмотренными здесь метаданными.

С помощью versionID можно еще больше сократить трафик, требующийся репликации. Например, если администратор DC2 несколько раз менял один атрибут (возможно, он или она несколько раз опечаталась), так что порождающие записи DC2 соответствуют значениям versionIDs 2, 3, 4, and 5, DC2 реплицирует только ту запись, которая соответствует последнему versionID, равному 5. Поскольку более ранние изменения все равно переписаны, то, не отправляя их, можно уменьшить нагрузку на сеть.

Каждое изменение Active Directory включает еще одну составляющую метаданных, используемую для разрешения конфликтов — временную метку, указывающую на время обновления.

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

Как же используются эти атрибуты для разрешения конфликтов? Давайте рассмотрим каждый тип конфликта по порядку.

Разрешение конфликта при изменении свойств

Рассмотрим в качестве примера объект пользователя икузнецов в домене contoso.com. Администратор DC1 меняет описание икузнецова на «Маркетинг». Почти одновременно с ним, администратор DC3 меняет то же описание пользователя на «Продажи и маркетинг». Информация об атрибуте «описание» для икузнецов на DC1 и DC3 в этот момент показана на рис. 9.

Рис. 9  Почти одновременные изменения

Сервер Свойство Значение VersionID Временная метка. Номер GUID локального контроллера домена Локальный USN Номер GUID исходного контроллера домена Оригинальный USN

DC1	Свойство «описание» икузнецов	маркетинг;	2	2007-06-07 14:03:25	<Номер GUID контроллера DC1>	3003	<Номер GUID контроллера DC1>	3003
DC3	Свойство «описание» икузнецов	Сбыт и маркетинг	2	2007-06-07 14:04:57	<Номер GUID контроллера DC3>	7003	<Номер GUID контроллера DC3>	7003

Если DC2 получит оба изменения одновременно, ему придется определять, какое из них «победило». Порядок разрешения конфликта таков:

1. Модификация с большим значением versionID считается «победительницей»; «проигравшая» модификация переписывается. В данном случае versionID для обеих записей равен 2, так что используем следующий критерий.
2. Если у двух записей одинаковый versionID, изменение с более поздней временной меткой будет принято как выигравшее, проигравшее изменение будет переписано. В данном случае временная метка порождающей записи DC3 позже, поэтому описание икузнецова будет установлено в «Продажи и маркетинг». В тех редких случаях, когда и versionID, и временная метка одинаковы, нужен третий и определяющий критерий:
3. Если versionID и временная метка совпадают у обеих записей, выигрывает то изменение, которое пришло от контроллер домена с меньшим номером GUID; запись с большим номером GUID перепишется. Если у DC1 номер GUID равен 1234567890, а у DC3's равен 2345678901, то запись от DC1 выигрывает при одинаковых versionID и временной метке.

Возможно, вы задумались: «А не стоило ли сделать временную метку первым критерием выигрыша?» Это не такое шаблонное решение, как можно подумать. Если бы первичным критерием при разрешении конфликтов Active Directory являлись временные метки, то злонамеренный администратор мог бы распространить свои изменения на всю сеть, просто переставив часы на одном из контроллеров домена так, чтобы временная метка этого контроллера домена всегда выигрывала конфликт.

Разрешение конфликта создания объектов

В случае создания двух объектов с одинаковыми именами Active Directory использует перечисленные выше три критерия чтобы определить, какой объект «выиграет». Правда, в отличие от предыдущей ситуации, «проигравший» объект не перезаписывается. Вместо этого проигравший объект переименовывается с использованием символов CNF (конфликтный объект), за которым следует двоеточие и номер GUID «проигравшего» объекта.. Это позволяет администратору позже принять более обоснованное решение о том, какой объект оставить, а какой удалить.

Разрешение перемещения объекта в удаленный контейнер

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

В этом случае разрешение довольно просто: Active Directory перемещает «осиротевший» объект в специальный контейнер Active Directory, разработанный специально для таких случаев. Он является потомком корня каждого домена Active Directory. В домене contoso.com контейнер LostAndFound находится вдоль следующего пути LDAP: LDAP://cn=LostAndFound,dc=contoso,dc=com. Если вы не видите контейнера LostAndFound, когда вы открываете оснастку «Active Directory – пользователи и компьютеры», просто выберите «Вид|Дополнительно».

Защита от отката USN

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

Одна из причин, вызывающая откат USN, находится в способе удаления объектов в среде с несколькими хозяевами. Когда на контроллере домена удаляется объект, он не убирается из системы тут же, а помечается как удаленный. В этом состоянии он может реплицироваться другие контроллеры домена, тем самым сообщая о своем удалении. Объект, помеченный на удаление, имеет атрибут isDeleted, равный «ИСТИНА». Для того, чтобы уменьшить количество объектов, помеченных на удаление, большинство значений объекта (описание, личная информация и членство объекта в группах) удаляется. (дальнейшие сведения об этом процессе приведены в статье Длил Киркпатрик (Gil Kirkpatrick) «Реанимация объектов-захоронений Active Directory» (Reanimating Active Directory Tombstone Objects), доступную на веб-странице technetmagazine.com/issues/2007/09).

Откат USN происходит потому, что помеченные на удаление объекты не остаются в системе навечно. По умолчанию, они полностью стираются из базы данных через 60 или 180 дней (в зависимости от версии Windows Server ®, в которой впервые создавалась среда Active Directory. Эти 60 или 180 дней называются «временем жизни захоронения». Все контроллеры доменов должны реплицироваться хотя бы раз в течение этого времени, иначе они становятся хуже, чем бесполезными — они создают возможность отката USN. Откат USN происходит, когда контроллер домена настолько долго не обновлялся, что он пропустил один или нескольких объектов-захоронений, в результате он не способен построить полностью обновленную структуру базы данных. Чтобы защититься от этого, каждый контроллер домена, который отсутствовал в сети дольше, чем время жизни удаленных объектов, нельзя возвращать к обслуживанию сети. Вместо этого сервер нужно собрать заново, удалив старые метаданные этого сервера из Active Directory, используя шаги, описанные в статье 216498 (support.microsoft.com/kb/216498) базы знаний Майкрософт.

Вторая причина отката USN — восстановление контроллера домена неправильным способом, в основном используя клонирование дисков или снятие их образов. Когда это происходит, восстановленная база данных Active Directory не может сразу понять, что она «перенеслась в прошлое», потому что использованный метод восстановления не учитывал Active Directory. В Windows 2000 и Windows 2003 распознать откат USN было сложно, но Windows Server 2003 SP1 (и ожидаемый Windows Server 2008) имеют внутренние механизмы контроля, определяющие, правильно ли был восстановлен контроллер домена. В этих ОС новых версий контроллер домена будет записывать события с идентификаторами 1115, 2095, 2103, и 2110 в журнал событий службы каталогов. Текст этих сообщений, так же как и необходимые шаги по восстановлению после отката USN, можно прочитать в статье 875495 базы знаний (support.microsoft.com/kb/875495) по Windows Server 2003. (Сведения о том, как справляться с откатом USN в Windows 2000, находятся в статье 885875 базы знаний, доступной на support.microsoft.com/kb/885875.)

Обновление модели нескольких хозяев в Windows Server 2008

В готовящемся выпуске Windows Server 2008 будут произведены некоторые изменения в модели нескольких хозяев путем введения контроллеров домена только для чтения (RODC). Контроллеры домена только для чтения разработаны преимущественно для развертывания в офисах филиалов, или для тех случаев, когда выделенного информационно-технического персонала в определенном месте нет, и надо принимать дополнительные шаги для поддержания целостности контроллера домена. Не углубляясь в подробности, рассмотрим ключевые моменты контроллеров домена только для чтения, которые не должны показаться незнакомыми.

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

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

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