Аварийное восстановление пользователей и групп службы каталогов Active Directory
Active Directory — одна из самых критичных служб в сети Windows. Чтобы свести к минимуму время простоя и снижение производительности, очень важно иметь эффективные планы аварийного восстановления при неполадках в Active Directory. Это может показаться очевидным, но просто поразительно, сколько администраторов не имеют плана восстановления при возникновении одной из наиболее вероятных проблем с Active Directory®: случайного удаления данных.
Случайное удаление объектов — одна из наиболее распространенных причин сбоя службы. Когда я провожу семинары или конференции, я часто спрашиваю, сталкивался ли кто-нибудь с неполадками в Active Directory из-за случайного удаления данных. И каждый раз почти все поднимают руку.
Чтобы понять, почему так сложно проходит восстановление данных, сначала следует понять следующее: как Active Directory хранит и реплицирует объекты, и в чем заключается механизм полномочного и неполномочного восстановления.
Хранение объектов
Active Directory — специальная база данных объектов, реализующая модель данных X.500/LDAP. Хранилище данных (называемое информационным деревом каталога — DIT) основано на механизме расширяемого хранилища (ESE), механизме базы данных на основе индексно-последовательного доступа (ISAM). Концептуально Active Directory хранит DIT в двух таблицах: таблице данных (которая содержит реальные объекты и атрибуты Active Directory) и таблице связей (которая хранит данные о связях между объектами).
Каждый объект Active Directory хранится в отдельной строке таблицы данных, один атрибут в столбце. Таблица данных содержит все элементы всех реплик, хранящихся на контроллере домена (DC). На обычном контроллере домена таблица данных содержит элементы из контекстов именования (NC) домена, конфигурации и схемы. В глобальном каталоге таблица данных содержит элементы для каждого объекта в лесу.
Для уникальной идентификации каждой строки таблицы данных Active Directory использует идентификатор различающегося имени (distinguished name tag, DNT) — 32-разрядное целое число. DNT, использующийся для внутреннего указания на объекты, меньше других идентификаторов, таких, как различающееся имя (DN) и идентификатор objectGUID (16-байтовая двоичная структура). Но, в отличие от идентификатора objectGUID, DNT является локальным идентификатором и отличается на разных контроллерах домена.
Как Active Directory связывает объекты
Active Directory управляет двумя видами отношений между объектами в информационном дереве каталога: отношения родитель-потомок (также называемые взаимоотношениями контейнера) и отношения ссылки (также называемые отношениями связи). Для реализации отношений родитель-потомок Active Directory содержит в таблице данных дополнительный столбец для идентификатора различающегося родительского имени (). Этот столбец всегда содержит DNT родителя объекта.
Каждый атрибут в Active Directory определяется объектом attributeSchema в контейнере схемы Active Directory. Некоторые атрибуты в Active Directory определяются как атрибуты ссылки и задаются четным ненулевым числом в атрибуте linkID объекта attributeSchema. Атрибуты ссылки устанавливают отношения между объектами в каталоге и могут иметь одно или несколько значений. Атрибут членства объекта группы — пример атрибута ссылки с несколькими значениями, устанавливающий связь между объектом-группой и объектом-участником.
Хотя кажется, что атрибут членства группы содержит различающиеся имена участников (как, например, показано в оснастке «Пользователи и компьютеры Active Directory»), на самом деле Active Directory хранит их другим способом. При добавлении различающегося имени объекта участника к атрибуту членства группы Active Directory сохраняет идентификатор различающегося имени объекта, а не само различающееся имя. Поскольку идентификатор различающегося имени не меняется даже при переименовании объекта, можно переименовать объект пользователя, и Active Directory не нужно будет выполнять сортировку по всем группам системы, чтобы обновить различающееся имя в каждом атрибуте участника. Так Active Directory поддерживает ссылочную целостность в информационном дереве каталога. На рис. 1 показано сильно упрощенное представление взаимоотношений таблицы данных и таблицы связей. На этих таблицах показано, что три объекта пользователей — Molly Clark, Alexander Tumanov и Makoto Yamagishi — являются членами группы старших инженеров.
Эти ссылки называют ссылками на следующий элемент (ссылка вперед). Тем же образом Active Directory поддерживает атрибуты ссылки на предыдущий элемент (ссылка назад). Так обеспечивается связь между связанным объектом и объектом, который на него ссылается, то есть связан со следующим элементом. Атрибут memberOf для пользователей и групп — пример атрибута связи с предыдущим объектом. Объект attributeSchema, который описывает атрибут ссылки на предыдущий объект, имеет значение linkID на единицу большее, чем целочисленное значение linkID соответствующего атрибута ссылки на следующий элемент. Например, атрибут членства схемы Windows Server® 2003 R2 имеет значение linkID, равное 2; атрибут memberOf, который служит ссылкой на предыдущий элемент, имеет значение linkID, равное 3. В качестве дополнительных сведений на Рис. 2 показан список стандартных атрибутов ссылки схемы Windows Server 2003 R2.
Атрибуты ссылки на предыдущий элемент всегда имеют несколько значений и обрабатываются Active Directory автоматически. На самом деле нельзя напрямую изменять атрибут ссылки на предыдущий элемент. Хотя кажется, что можно изменить атрибут memberOf пользователя или группы с помощью оснастки MMC «Active Directory – пользователи и компьютеры», на самом деле оснастка меняет атрибут членства соответствующей группы, и Active Directory «за кулисами» обновляет атрибут memberOf. Поэтому не требуются полномочия для объекта пользователя, чтобы добавить пользователя в группу; вы только меняете атрибут членства объекта группы. Поскольку каждый контроллер домена локально управляет атрибутами ссылки на предыдущий элемент, изменения ссылок назад никогда не реплицируются. Реплицируются только изменения атрибута ссылки на следующий элемент, такие, как атрибуты членства в группе.
На обычном контроллере домена таблица данных содержит элементы объектов домена, а также объекты контейнеров из конфигурации и схемы. Но некоторые типы групп могут содержать ссылки на объекты, расположенные в другом домене. Как Active Directory хранит идентификатор различающегося имени для объекта, отсутствующего в таблице данных? Ответ касается владельца роли хозяина инфраструктуры FSMO (Flexible Single Master Operations) и сущности, называемой фантомным объектом.
Фантомные объекты
При добавлении участника одного домена в группу, расположенную в другом домене, Active Directory автоматически создает специальный объект в таблице данных, называемый фантомом, и содержащий objectGUID, objectSid и различающееся имя нового участника. Таким образом создается идентификатор различающегося имени, который может храниться в атрибуте членства в группе. Если контроллер домена — глобальный каталог, нет необходимости создавать фантом, поскольку каталог уже содержит элемент в таблице данных для каждого объекта леса.
Контроллер домена, который поддерживает роль инфраструктуры FSMO, периодически проверяет элементы в своей таблице данных по отношению к глобальному каталогу, и если выясняется, что объект перемещен, переименован или удален, обновляет фантомные объекты в таблице данных, а также реплицирует изменения на другие контроллеры домена. А благодаря преимуществу счетчика ссылок хозяин инфраструктуры также может удалять фантомы, на которые больше не ссылаются никакие атрибуты ссылки на следующий элемент домена.
Фантомы позволяют контроллерам домена управлять ссылками на объект, расположенный в другом домене леса, но атрибуты ссылки вперед также могут указывать на объект, расположенный вне леса, например, в доверенном домене. В этом случае Active Directory создает объект, называемый участником внешней безопасности (FSP) в контейнере CN=ForeignSecurityPrincipals в NC домена. FSP содержит идентификатор безопасности (SID) внешнего объекта и атрибуты, идентифицирующие объект во внешнем домене, но не существует процесса, поддерживающего актуальность данных FSP. При восстановлении данных мы рассматриваем FSP как любой другой объект Active Directory.
Удаление объектов
Здесь я прежде всего сосредоточусь на восстановлении пользователей и их членства в группах. В то же время аналогичный подход применим к восстановлению других связанных атрибутов.
Когда Active Directory удаляет объект, он не удаляется из информационного дерева каталога физически. Вместо этого он помечает объект как удаленный путем установки значения «истина» для атрибута isDeleted, что делает объект невидимым для обычных операций в каталоге. Active Directory удаляет все атрибуты, не предназначенные для сохранения, как определяется схемой и меняет относительное различающееся имя (RDN) объекта на \0aDEL:. Затем перемещает объект в контейнер CN=Deleted Objects для контекста именования. (Существуют некоторые классы объектов в контексте именования Конфигурация, которые Active Directory не может переместить в контейнер Deleted Objects.) Active Directory удаляет любые ссылки вперед на другие объекты, содержащие удаленные объекты, что снижает значение счетчика ссылок в таблице связей. Если существуют другие объекты, содержащие ссылки вперед на новые удаленные объекты, Active Directory также удаляет эти ссылки.
Получившийся объект носит название захоронения. Active Directory реплицирует это захоронение на другие контроллеры домена, где происходят аналогичные изменения. Учтите, что Active Directory не реплицирует изменения, произошедшие со ссылками вперед на удаленный объект. Каждый контроллер домена выполняет подобное действие локально, поэтому нет необходимости его реплицировать. Это имеет последствия для восстановления членства в группе, как будет рассмотрено в этой статье далее.
Active Directory обрабатывает объекты в информационном дереве каталога как определено атрибутом объекта tombstoneLifetime CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=. Процессы «сборки мусора» на каждом DC удаляют объекты-захоронения, которые старше, чем настроенное для них время жизни. По умолчанию время жизни объектов-захоронений составляет 60 дней для Windows® 2000, Windows Server 2003, и Windows Server 2003 R2. Оно равно 180 дням для Windows Server 2003 SP1.
Время жизни захоронений играет большую роль в процессе восстановления. Невозможно восстановить из более ранней резервной копии, чем время жизни объекта-захоронения. Поскольку объекты, удаленные и затем убранные из домена при сборке мусора, больше не обладают захоронениями, операции удаления никогда не будут заново реплицированы на восстановленном контроллере домена. Удаленные объекты затем будут оставаться на восстановленном контроллере домена как устаревшие объекты, и восстановленный контроллер никогда правильно не интегрируется с другими контроллерами домена.
Репликация объектов
Когда контроллер домена выполняет любую операцию обновления, например, при добавлении объекта или изменения атрибута, контроллер присваивает операции уникальный 64-разрядный номер, называемый номером последовательного обновления (USN). Active Directory помечает с помощью USN обновляемые объекты и атрибуты, чтобы определить, следует ли их реплицировать.
Active Directory реплицирует объекты по принципу «атрибут за атрибутом». Поэтому при изменении атрибута объекта Active Directory будет реплицировать атрибут, а не объект целиком. Для этого Active Directory отслеживает изменения каждого атрибута при помощи метаданных репликации. Метаданные репликации атрибута включают:
• Локальный USN, который идентифицирует операцию изменения на локальном DC. • InvocationID контроллера домена, на котором возникли изменения (особенно атрибут invocationID контроллера, соответствующего объекту nTDSSettings), который показывает отдельное появление информационного дерева каталога на контроллере домена. • USN исходной операции, если она существует на исходном контроллере домена. • Отметка времени, которая отражает системное время DC при выполнении изменения. • 32-разрядный номер версии, последовательно возрастающий при каждом изменении.
Когда контроллер домена назначения запрашивает изменения у исходного контроллера, он отправляет USN последнего успешно реплицированного изменения исходному контроллеру вместе с вектором синхронизации, который включает исходный USN, контроллер домена назначения, видимый каждому контроллеру домена, имеющему реплику реплицируемого контекста именования. Исходный контроллер домена использует эти данные, чтобы отправлять только те обновления, которые еще не видел контроллер домена назначения.
По мере обработки контроллером домена назначения входящих изменений атрибутов он проверяет номер версии каждого атрибута. Если номер версии поступающего атрибута больше номера, который хранится в контроллере, будет сохранено поступившее значение. Если номер версии поступающего атрибута равен существующему номеру, контроллер сравнивает отметку времени и использует атрибут с последней отметкой. Если отметки временисовпадают, контроллер домена назначения выбирает значение с наибольшим invocationID. Так обеспечивается синхронизация для каждого контроллера домена значение каждого реплицируемого атрибута.
Репликация связанных значений
В Windows 2000 Active Directory реплицирует атрибуты с множественными значениями так же, как и атрибуты с одним значением. Это вызывает проблемы для больших динамических групп объектов, имеющих атрибуты членства с несколькими значениями, которые могут часто меняться на разных контроллерах доменов. Если администратор добавил пользователя в группу на одном контроллере домена, а другой администратор добавил на другом контроллере другого пользователя в окне задержки репликации, Active Directory выберет последнее добавление, а предыдущее добавление будет полностью утрачено. Корпорация Майкрософт решила эту проблему в Windows Server 2003 с помощью процесса, называемого «репликация связанных значений» (LVR).
На функциональном уровне леса или внутреннего леса Windows Server 2003 Active Directory отдельно реплицирует индивидуальные значения атрибутов ссылок вперед с множественными значениями, при этом каждое значение имеет свои метаданные репликации. Это эффективно решает проблему, выявленную в Windows 2000, когда практически одновременные обновления членства в группах на различных контроллерах домена могут вызывать потерю данных.
В то же время существует один момент, который следует учитывать. При повышении функционального уровня леса не происходит одновременного исправления существующих атрибутов с множественными значениями новыми метаданными репликации. Новые метаданные будут присутствовать только для тех значений, которые были добавлены после повышения функционального уровня леса. Это оказывает заметное влияние на восстановление членства в группах, как вы сейчас увидите.
Резервное копирование
В состав Windows включена служебная программа начального уровня NTBACKUP, которую можно использовать для создания резервной копии состояния системы контроллера домена. Состояние системы контроллера домена включает его реестр, папку SYSVOL, файлы информационного дерева каталога Active Directory и критические системные файлы. Большинство сторонних программ резервного копирования также способны создавать резервные копии и восстанавливать состояние контроллера домена.
Для резервного копирования состояния в файл на диске используйте следующую команду:
NTBACKUP backup systemstate /F ”<filename>”
Здесь — имя создаваемого файла резервной копии, который должен иметь расширение bkf .
Выполнение неполномочного восстановления
Восстановление удаленных объектов Active Directory из резервной копии идет в две стадии. Сначала контроллер домена перезагружается в режиме восстановления службы каталога, затем выполняется восстановление информационного дерева каталога Active Directory целиком с помощью служебной программы Windows NTBACKUP или аналогичной сторонней программы. При этом информационное дерево каталога полностью переписывается.
Существует два способа загрузки контроллера в режиме восстановления службы каталога. Если есть доступ к системной консоли контроллера, завершите работу и перезагрузите контроллер, затем нажмите F8 при появлении запроса на вывод меню загрузки Windows. Выберите в меню режим восстановления службы каталога и введите пароль для этого режима.
При удаленном управлении сервером меню загрузки Windows недоступно. Вместо этого можно изменить параметры загрузки системы, выбрав пункт «Настройка» в разделе «Мой компьютер», щелкнув вкладку «Дополнительно» и нажав кнопку «Параметры ниже надписи «Загрузка и восстановление». Нажмите кнопку «Правка» в разделе «Загрузка операционной системы» для внесения изменений в файл boot.ini, добавьте аргумент /SAFEBOOT:DSREPAIR к концу строки, как показано на рис. 3. (Дополнительные сведения об аргументах файла boot.ini см. .)
Рис. 3 Настройка параметров загрузки для режима восстановления службы каталога
После перезагрузки сервера включится режим восстановления службы каталога. Помните, что нужно удалить аргумент /SAFEBOOT из файла boot.ini, если нужно перезагрузить контроллер домена в обычном режиме.
После входа в систему с паролем режима восстановления службы каталога восстановите состояние системы из резервной копии с помощью служебной программы NTBACKUP, но без каких-либо параметров. (Можно выполнить восстановление, набрав NTBACKUP в командной строке.) При появлении мастера выберите «Восстановление файлов и параметров» и нажмите кнопку «Далее». Выберите файл с резервной копией и проверьте состояние окна Состояние системы, как показано на рис. 4.
Рис. 4 Использование Мастера архивации и восстановления для восстановление состояния системы
Если на этой стадии нужно загрузить контроллер домена в обычном режиме, процесс репликации Active Directory синхронизирует восстановленный контроллер с остальными контроллерами домена, и все восстановленные данные будут заменены на текущие. Разумеется, это не входило в ваши задачи. Вместо этого вам нужен способ принудительной репликации восстановленных данных на другие контроллеры домена.
Выполнение полномочного восстановления
NTDSUTIL также увеличивает номер версии каждого атрибута на 100 000 за каждый день промежутка между созданием архива и его восстановлением. Если не имеется атрибутов, которые меняются более 100 000 раз в день (очень маловероятно), номер версии восстановленных атрибутов будет значительно больше номера версии, хранящейся на других контроллерах домена. Полномочное восстановление реплицирует их на другие контроллеры. Другие объекты, которые были восстановлены из резервной копии неполномочно, будут обязательно заменены актуальными данными с других контроллеров домена.
После завершения неполномочного восстановления, но до перезагрузки используйте программу NTDSUTIL для выполнения полномочного восстановления объектов, которые хотите вернуть к первоначальному состоянию. Несмотря на название, полномочное восстановление объектов их не «восстанавливает», при этом Active Directory просто реплицирует объекты на другие контроллеры. Для этого NTDSUTIL присваивает следующий доступный USN локальному USN атрибутов объекта. Это приводит к тому, что объект будет отправлен для репликации партнерам при следующем сеансе синхронизации. Для восстановления единичного объекта убедитесь, что контроллер домена загружен в режиме восстановления службы каталога, и выполните следующие действия:
1. Откройте окно командной строки и наберите:
ntdsutil
2. При появлении приглашения ntdsutil наберите:
authoritative restore
3. При появлении запроса на полномочное восстановление наберите:
restore object ”<DN of object to be restored>”
Например, если нужно восстановить учетную запись Molly Clark в подразделении Eng домена DRNET, следует набрать:
Если нужно полномочно восстановить все поддерево каталога, например подразделение, наберите вместо этого:
restore subtree ”OU=Eng,DC=DRNET,DC=com”
В NTDSUTIL также имеется команда восстановления базы данных, которая полномочно восстанавливает весь домен, а также контексты именования конфигурации и схемы. Восстановление всего домена сопряжено с риском, и я не рекомендую использовать эту возможность. Если возникла необходимость восстановления всего домена, следует восстановить один контроллер домена и заново повысить роль остальных контроллеров домена, как описано на странице "",
4. При появлении запроса подтвердите, что полномочное восстановление должно повысить номера версии соответствующих объектов и их атрибутов.
5. Выйдите из программы ntdsutil (необходимо дважды набрать quit).
6. Перезагрузите контроллер домена в обычном режиме Active Directory.
При следующем сеансе репликации контроллера домена с партнерами восстановленный пользователь будет реплицирован. Но восстановление объекта пользователя — только половина проблемы. Если представить себе связи объекта, например, между группой и ее членами, ситуация усложняется. В следующих разделах описывается некоторые фундаментальные проблемы, с которыми можно столкнуться при восстановлении.
Прежде всего рассмотрим, что происходит при удалении объекта, имеющего ссылки назад. Например, вы удаляете объект, который входит в состав одной или нескольких групп. Каждый контроллер домена, имеющий копию объекта пользователя, преобразует его в захоронение и удалит все ссылки в таблице связей, тем самым удаляя объект пользователя из всех групп домена. (Помните, что удаление пользователя из членов группы не реплицируется, каждый DC обновляет членство в группах локально. Номер версии и локальный USN атрибута члена группы остается неизмененным.) Спустя короткое время фантомные объекты будут удалены из таблиц ссылок в других доменах, снова без обновления метаданных репликации атрибута членства в группе.
При неполномочном восстановлении информационного дерева каталога на контроллере домена пользователя объект пользователь восстанавливается вместе с членством в группах по всему домену, поэтому восстановленный контроллер будет самосогласованным. После использования программы NTDSUTIL для полномочного восстановления пользователя объект пользователя реплицируется на все другие контроллеры домена.
Но поскольку метаданные репликации текущих групп домена не меняются, атрибуты членов групп восстановленного контроллера домена будут несогласованными с другими контроллерами домена. И не существует способа привести их в единое состояние. Таким образом, членство пользователей не будет восстановлено на других контроллерах домена.
Ситуация: Членство в группах домена не восстановлено
Полномочное восстановление объекта пользователя не восстанавливает членство пользователя в группах. Собственно, почему? Потому, что отношения членства сохраняются и реплицируются при помощи атрибута члена объектов групп (ссылки вперед), а не атрибута memberOf пользователя (ссылки назад). Проблема состоит в том, чтобы найти членство пользователей в старой группе и, узнав это, правильно их восстановить.
Корпорация Майкрософт постоянно вносит улучшения в процесс восстановления членства в группах, поэтому используемая методика зависит от версии Active Directory. Следующие разделы прежде всего применимы для Windows 2000 Active Directory.
Определить членство пользователя в старых группах достаточно просто: посмотрите атрибут ссылки назад на восстановленном контроллере домена — в данном случае это атрибут memberOf объекта пользователя. Атрибут memberOf будет содержать все сведения о членстве в локальных и глобальных группах домена пользователя. Для составления списка членства пользователя в группах можно использовать оснастку «Active Directory – пользователи и компьютеры» (ADUC), или программу LDIFDE, которая включена в состав Windows Server.
Следующая команда LDIFDE выведет список групп домена DRNET, членом которых состоит Molly Clark, сохранив результат в файле output.ldf:
Помните, что для использования программы LDAP необходимо загрузить контроллер домена в обычном режиме и затем запретить входящую репликацию, иначе восстановленные данные будут переписаны. Простейший способ запретить входящую репликацию — использовать команду REPADMIN:
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
Здесь — имя восстанавливаемого контроллера домена. Не забудьте после окончания заново включить репликацию с помощью параметра -DISABLE_INBOUND_REPL.
Если восстанавливаются только некоторые пользователи, можно просто вручную добавить пользователя в группы с помощью ADUC. Для восстановления большого числа пользователей существуют средства, позволяющие автоматизировать некоторые процессы. Служебная программа Microsoft GROUPADD (доступна через службу поддержки Microsoft) может использовать созданный файл LDIF для просмотра членства пользователя в старых группах и, в свою очередь, для создания файла LDIF, который восстанавливает это членство. Например, можно использовать команду GROUPADD для обработки файла LDIF, ранее созданного для пользователя Molly Clark:
C:\> groupadd /after_restore output.ldf
Эта команда создаст новый файл LDIF для каждого домена, в группы которого входит Molly Clark с именем groupadd_.ldf (где — полное доменное имя (FQDN) домена, в котором будут обновлены группы). Импортировать ранее созданный файл LDIF можно при помощи следующей команды:
С выходом Windows Server 2003 корпорация Microsoft улучшила NTDSUTIL, добавив преимущества дополнительных метаданных, присутствующих в атрибуте членства для поддержки репликации связанных значений (LVR). Если восстанавливаемый объект пользователя являлся членом любых групп домена, а членство пользователя хранилось с метаданными LVR, служебная программа NTDSUTIL увеличивает номер версии соответствующего значения атрибута пользователя, что приводит к репликации восстановленного членства.
Служебная программа NTDSUTIL в составе Windows Server 2003 SP1 объединена с функциями GROUPADD и автоматически будет создавать файлы LDIF при полномочном восстановлении объекта пользователя. На рис. 5 показана новая версия NTDSUTIL, а на рис. 6 - содержимое автоматически созданного файла LDIF.
Рис. 5 Новая служебная программа NTDSUTIL со встроенными функциями GROUPADD
При восстановлении целого подразделения, содержащего ряд пользователей и групп, добавлять в эти группы пользователей вручную довольно утомительно. Другой способ возвращения членства для восстановленных групп — полномочное восстановление самих групп.
В то же время при полномочном восстановлении групп существуют две проблемы. Первая проблема очевидна: при восстановлении группы членство в ней будет отражать момент создания резервной копии. Это означает, что к группе необходимо заново применить любые изменения, произошедшие после создания архива. Вторая проблема не такая явная и связана с тем, как происходит репликация в Active Directory. После полномочного восстановления пользователей и групп нет гарантии, что репликация пойдет в нужном порядке. Если объект пользователя реплицируется позднее, он не будет добавлен в группу.
Простейшее решение этой проблемы — выполнить полномочное восстановление группы позже. После выполнения первого полномочного восстановления перезагрузитесь в обычном режиме и убедитесь, что репликация прошла правильно. Затем перезагрузитесь в режиме восстановления службы каталога и запустите программу NTDSUTIL, чтобы выполнить полномочное восстановление групп, членом которых является пользователь. При этом гарантируется, что при загрузке в обычном режиме объекты пользователей будут реплицированы до того, как объекты групп сошлются на их реплику.
Ситуация: Членство в группах других доменов не восстановлено
Проблема «членом каких групп является пользователь» на самом деле более сложная, чем я описал. Восстанавливаемый пользователь может быть членом локального домена и универсальных групп других доменов. Членство в этих группах не будет восстановлено при неполномочном восстановлении. Как узнать, в каких группах других доменов состоит пользователь? Ответ лежит в глобальном каталоге. Наряду с собственными данными о домене глобальный каталог содержит доступную только для чтения копию данных из других доменов леса.
Чтобы воспользоваться данными о лесе из глобального каталога, следует выполнить неполномочное восстановление в глобальном каталоге, что означает необходимость иметь архив глобального каталога. Теперь при запуске LDIFDE для определения членства пользователя в группах можно узнать о членстве пользователя в универсальных группах других доменов.
При просмотре членства в группах восстанавливаемого пользователя подключитесь к порту глобального каталога 3268 вместо стандартного 389 и выберите в качестве начала поиска корневой домен леса. LDIFDE покажет членство в группах восстанавливаемого пользователя, включая членство в универсальных группах всех доменов леса. Это делается следующим образом:
Если запустить программу GROUPADD или новую программу NTDSUTIL в глобальном каталоге, создается один файл LDIF для домена пользователя и один файл LDIF для каждого домена, в который восстанавливаемый пользователь был членом универсальной группы. При импорте этих файлов LDIF вы восстановите членство пользователя во всех группах. Или почти всех, как покажет рассмотрение следующей проблемы.
Ситуация: Восстановление членства в локальных группах других доменов
В среде Windows Active Directory существует три вида групп. Глобальные группы могут состоять только из членов своего домена, но которые могут использоваться как члены локальных групп того же домена или других доменов леса. Атрибут членства в глобальных группах не появляется в глобальном каталоге, но это не представляет проблемы, поскольку глобальные группы содержат только членов своего домена. Универсальные группы могут состоять из членов любого домена, которые могут выступать как члены других универсальных групп леса и локальных групп своего домена и других доменов леса. Атрибут членства в универсальных группах реплицируются в глобальные каталоги. Локальные группы домена могут состоять из членов любого домена леса, но которые не могут выступать как члены групп других доменов. Важнее то, что атрибут членства в локальных группах домена, как и в глобальных группах, не появляется в глобальном каталоге. В результате не существует простого способа восстановления членства пользователя в локальных группах других доменов.
До выхода Windows Server 2003 SP1 единственным способом восстановления членства в локальных группах других доменов было восстановление контроллера в каждом домене, ручной поиск в домене данных о любых локальных группах домена, содержащих восстановленного пользователя и затем добавление пользователя в найденные группы. В больших многодоменных средах этот способ требует непозволительно много времени.
В этом случае может помочь версия программы NTDSUTIL из Windows Server 2003 с пакетом обновления 1 (SP1). При запуске NTDSUTIL на контроллере домена создается текстовый файл, содержащий различающееся имя и идентификатор GUID восстановленных объектов пользователей. Затем для каждого внешнего домена можно неполномочно восстановить один контроллер домена, скопировать на него текстовый файл и запустить NTDSUTIL для создания нового файла LDIF для этого домена. Файл добавит восстановленного пользователя в локальные группы домена, членом которых он был ранее.
Для этого выполните следующие действия над контроллером домена в каждом внешнем домене:
• Загрузите контроллер внешнего домена в режиме восстановления службы каталога. • С помощью программы NTBACKUP восстановите копию информационного дерева каталога, содержащую сведения о членстве в группах восстановленных пользователей. • Скопируйте созданный NTDSUTIL TXT-файл на текущий контроллер домена. • Откройте окно командной строки и наберите ntdsutil. • Наберите authoritative restore (полномочное восстановление). • Наберите create LDIF file(s) from (где имя текстового файла). • Дважды наберите quit для выхода из программы ntdsutil. • Перезагрузите контроллер домена в обычном режиме Active Directory. • Наберите ldifde –i –f (где имя созданного только что файла LDIF).
Вы восстановили членство в группах всех удаленных пользователей.
Шаг за шагом
Восстановление пользователей Active Directory и их членства в группах, особенно в многодоменной среде — сложная задача. Конкретные действия, необходимые для правильного восстановления членства в группах, зависят от версии Windows.
При работе с Windows 2003 SP1 необходимы следующие действия:
• Загрузите глобальный каталог в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей. • С помощью программы NTDSUTIL выполните полномочное восстановление удаленного пользователя. NTDSUTIL создаст текстовый файл, содержащий различающееся имя и идентификатор GUID восстановленного объекта, и один или несколько файлов LDIF для восстановления членства пользователя в группах. • Используйте команду LDIFDE –i –f (где имя файлов LDIF, созданных в шаге 2) для импорта членства в группах текущего и других доменов. • Перезагрузите глобальный каталог в обычном режиме. • В каждом внешнем домене загрузите какой-либо контроллер в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей. • Запустите программу NTDSUTIL с командой create ldif files (создать файлы ldif). • Перезагрузите контроллер домена в обычном режиме. • Используйте команду LDIFDE –i –f (где имя LDIF файла, созданного в шаге 6) для восстановления членства в группах внешнего домена. • На этой стадии можно запустить репликацию командой REPADMIN /syncall.
Если запущена версия Windows Server 2003 без установленного пакета обновления 1 (SP1) или Windows 2000, необходимо выполнить ряд дополнительных действий. Поскольку более старая версия NTDSUTIL не создает файлы LDIF, используйте для их создания программу GROUPADD. Процедура выполняется так:
• Загрузите глобальный каталог в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей. • Отключите сетевую карту или отсоедините кабель для предотвращения входящей репликации. • Перезагрузите глобальный каталог в обычном режиме. • С помощью команды LDIFDE –r "(distinguishedName=)" -t 3268 -l memberOf –p Base -f membership.ldf создайте дамп членства пользователя с различающимся именем . • Для создания файлов LDIF используйте команду GROUPADD /after_restore membership.ldf. • Для импорта членства в группах текущего и других доменов используйте команду LDIFDE –i –f (где имя файла LDIF, созданного программой GROUPADD в шаге 5). • Заново разрешите входящую репликацию с помощью команды REPADMIN /options -DISABLE_INBOUND_REPL. • В каждом внешнем домене загрузите какой-либо контроллер в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей. • Перезагрузите контроллер домена в обычном режиме. • С помощью команды LDIFDE –i –f (где имя файла LDIF , созданного программой GROUPADD в шаге 5) восстановите членство в группах внешнего домена. • На этой стадии можно запустить репликацию командой REPADMIN /syncall.
Единственное, что остается сделать в среде, предшествующей Windows Server 2003 с пакетом обновления 1 (SP1), — восстановить членство в локальных группах внешнего домена восстановленного пользователя. Можно вручную только восстановить членство в локальных группах домена или восстановить контроллер домена из резервной копии и полномочно восстановить локальные группы домена.
Заключение
Несмотря на то, что из Active Directory легко можно случайно удалить пользователей или даже подразделения, правильное восстановление удаленных пользователей и их членства в группах может оказаться неожиданно сложной, длительной и подверженной ошибкам задачей. Для уверенности в том, что вы сможете преодолеть эти трудности максимально быстро, следует понимать механизмы связи объектов, репликации, удаления и полномочного восстановления.
Сможете ли вы правильно выполнить эти действия в вашем окружении с первой попытки? Для уверенности в том, что в следующий раз вы действительно сможете восстановить объект Генеральный директор, приготовьте письменный план восстановления удаленных объектов. И потренируйтесь в выполнении этого плана один-два раза перед тем, как испытывать его на реальных данных. Ваш босс (и ваш генеральный директор) оценят это по достоинству.
