Поиск на сайте: Расширенный поиск


Новые программы oszone.net Читать ленту новостей RSS
Iceсream Screen Recorder – это программа для захвата видео с аудио и микрофоном и создания скриншотов с помощью ряда доп...
SlimDrivers — бесплатная программа для обнаружения присутствующих на компьютере драйверов, определение их версий, поиска...
Многофункциональный, кроссплатформенный текстовый редактор с функциями подсветки синтаксиса, авто-подстановкой выражений...
Программа позволяет быстро обнаруживать на раннем этапе возможные отказы в работе сети или веб-сайта. PRTG Network Monit...
Программа для создания презентаций и интерактивных обучающих видеоуроков. Camtasia Studio может осуществлять захват изоб...
OSzone.net Microsoft Windows Server 2003 Администрирование Аварийное восстановление пользователей и групп службы каталогов Active Directory RSS

Аварийное восстановление пользователей и групп службы каталогов Active Directory

Текущий рейтинг: 3.94 (проголосовало 16)
 Посетителей: 25843 | Просмотров: 40801 (сегодня 1)  Шрифт: - +

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 Di­rectory не нужно будет выполнять сортировку по всем группам системы, чтобы обновить различающееся имя в каждом атрибуте участника. Так Active Directory поддерживает ссылочную целостность в информационном дереве каталога. На рис. 1 показано сильно упрощенное представление взаимоотношений таблицы данных и таблицы связей.

Рис 1  Взаимоотношение таблицы данных и таблицы связей

Таблица данных       DNT PDNT Класс объекта Cn Таблица связей       Атрибут DNT Ссылка вперед (на следующий элемент)  
14529 14401 Подразделение Инженеры
14530 14529 Группа Главные инженеры
14531 14529 Пользователь Molly Clark
14532 14529 Пользователь Alexander Tumanov
14533 14529 Пользователь Makoto Yamagishi
Член 14530 14531  
Член 14530 14532  
Член 14530 14533  

На этих таблицах показано, что три объекта пользователей — Molly Clark, Alexander Tumanov и Makoto Yamagishi — являются членами группы старших инженеров.

Эти ссылки называют ссылками на следующий элемент (ссылка вперед). Тем же образом Active Directory поддерживает атрибуты ссылки на предыдущий элемент (ссылка назад). Так обеспечивается связь между связанным объектом и объектом, который на него ссылается, то есть связан со следующим элементом. Атрибут memberOf для пользователей и групп — пример атрибута связи с предыдущим объектом. Объект attribute­Schema, который описывает атрибут ссылки на предыдущий объект, имеет значение linkID на единицу большее, чем целочисленное значение linkID соответствующего атрибута ссылки на следующий элемент. Например, атрибут членства схемы Windows Server® 2003 R2 имеет значение linkID, равное 2; атрибут memberOf, который служит ссылкой на предыдущий элемент, имеет значение linkID, равное 3. В качестве дополнительных сведений на Рис. 2 показан список стандартных атрибутов ссылки схемы Windows Server 2003 R2.

Рис 2  Атрибуты ссылки в схеме Windows Server 2003 R2

Ссылка вперед (на следующий элемент) linkID Атрибут ссылки назад (на предыдущий элемент) Связаны
член 2 memberOf 3
менеджер 42 directReports 43
владелец 44 ownerBL 45
siteObject 46 siteObjectBL 47
nonSecurityMember 50 nonSecurityMemberBL 51
queryPolicyObject 68 queryPolicyBL 69
privilegeHolder 70 isPrivilegeHolder 71
managedBy 72 managedObjects 73
hasPartialReplicaNCs 74    
hasMasterNCs 76 masteredBy 77
syncMembership 78    
serverReference 94 serverReferenceBL 95
bridgeheadTransportList 98 bridgeheadServerListBL 99
netbootServer 100 netbootSCPBL 101
frsComputerReference 102 frsComputerReferenceBL 103
fRSMemberReference 104 fRSMemberReferenceBL 105
fRSPrimaryMember 106    
siteLinkList 142    
siteList 144    
msCOM-PartitionLink 1040 msCOM-PartitionSetLink 1041
msDS-NC-Replica-Locations 1044    
msFRS-Hub-Member 1046    
msCOM-UserPartitionSetLink 1048 msCOM-UserLink 1049
msDS-SDReferenceDomain 2000    
msDS-HasInstantiatedNCs 2002    
msDS-NonMembers 2014 msDS-NonMembersBL 2015
msDS-MembersForAzRole 2016 msDS-MembersForAzRoleBL 2017
msDS-OperationsForAzTask 2018 msDS-OperationsForAzTaskBL 2019
msDS-TasksForAzTask 2020 msDS-TasksForAzTaskBL 2021
msDS-OperationsForAzRole 2022 msDS-OperationsForAzRoleBL 2023
msDS-TasksForAzRole 2024 msDS-TasksForAzRoleBL 2025
msDS-HasDomainNCs 2026    
msSFU30PosixMember 2030 msSFU30PosixMemberOf 2031
msDS-hasMasterNCs 2036 msDs-masteredBy 2037
msDS-ObjectReference 2038 msDS-ObjectReferenceBL 2039
msDFSR-ComputerReference 2050 msDFSR-ComputerReferenceBL 2051
msDFSR-MemberReference 2052 msDFSR-MemberReferenceBL 2053

Атрибуты ссылки на предыдущий элемент всегда имеют несколько значений и обрабатываются 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=Ser­vices,CN=Con­fig­ura­tion,DC=. Процессы «сборки мусора» на каждом DC удаляют объекты-захоронения, которые старше, чем настроенное для них время жизни. По умолчанию время жизни объектов-захоронений составляет 60 дней для Win­dows® 2000, Windows Server 2003, и Win­dows Server 2003 R2. Оно равно 180 дням для Win­dows 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 “”

Здесь — имя создаваемого файла резервной копии, который должен иметь расширение bkf .

Автор: Джил Киркпатрик (Gil Kirkpatrick)  •  Иcточник: TechNet Magazine  •  Опубликована: 11.04.2007
Нашли ошибку в тексте? Сообщите о ней автору: выделите мышкой и нажмите CTRL + ENTER
Теги:  


Оценить статью:
Вверх
Комментарии посетителей RSS

Чтобы оставить комментарий, зарегистрируйтесь или войдите с учетной записью социальной сети.