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

Active Directory — одна из самых
критических служб в сети Windows. Чтоб свести к минимуму время
простоя и понижение производительности, очень принципиально иметь действенные
планы аварийного восстановления при проблемах в Active Directory.
Это может показаться естественным, но

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

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

Чтоб осознать, почему так трудно проходит
восстановление данных, поначалу следует осознать последующее: как Active
Directory хранит и реплицирует объекты, и в чем заключается механизм
полномочного и неполномочного восстановления.

Хранение объектов

Active Directory — особая база данных
объектов, реализующая модель данных X.500/LDAP. Хранилище данных
(называемое информационным деревом каталога — DIT) основано на
механизме расширяемого хранилища (ESE), механизме базы данных на
базе индексно-последовательного доступа (ISAM). Концептуально
Active Directory хранит DIT в 2-ух таблицах: таблице данных (которая
содержит реальные объекты и атрибуты Active Directory) и таблице
связей (которая хранит данные о связях меж объектами).

Каждый объект Active Directory хранится в
отдельной строке таблицы данных, один атрибут в столбце. Таблица
данных содержит все элементы всех реплик, хранящихся на контроллере
домена (DC). На обыкновенном контроллере домена таблица данных содержит
элементы из контекстов именования (NC) домена, конфигурации и схемы.
В глобальном каталоге таблица данных содержит элементы для каждого
объекта в лесу.

Для уникальной идентификации каждой строчки
таблицы данных Active Directory употребляет идентификатор
различающегося имени (distinguished name tag, DNT) — 32-разрядное
целое число. DNT, использующийся для внутреннего указания на
объекты, меньше других идентификаторов, таких, как различающееся имя
(DN) и идентификатор objectGUID (16-байтовая двоичная структура).
Но, в отличие от идентификатора objectGUID, DNT является локальным
идентификатором и отличается на различных контроллерах
домена.

Как Active
Directory связывает объекты

Active Directory управляет 2-мя видами отношений
меж объектами в информационном дереве каталога: дела
родитель-потомок (также именуемые отношениями контейнера) и
дела ссылки (также именуемые отношениями связи). Для
реализации отношений родитель-потомок 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) и
сути, именуемой фантомным объектом.

Фантомные объекты

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

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

Фантомы позволяют контроллерам домена управлять
ссылками на объект, расположенный в другом домене леса, но атрибуты
ссылки вперед также могут указывать на объект, расположенный вне
леса, к примеру, в доверенном домене. В данном случае Active Directory
делает объект, именуемый участником наружной безопасности (FSP) в
контейнере CN=ForeignSecurityPrincipals в NC домена. FSP содержит
идентификатор безопасности (SID) наружного объекта и атрибуты,
идентифицирующие объект во наружном домене, но не существует
процесса, поддерживающего актуальность данных FSP. При
восстановлении данных мы рассматриваем FSP как хоть какой другой объект
Active Directory.

Удаление объектов

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

Когда Active Directory удаляет объект, он не
удаляется из информационного дерева каталога на физическом уровне. Заместо этого
он отмечает объект как удаленный методом установки значения «истина»
для атрибута isDeleted, что делает объект невидимым для обыденных
операций в каталоге. Active Directory удаляет все атрибуты, не
созданные для сохранения, как определяется схемой и меняет
относительное различающееся имя (RDN) объекта на aDEL:. Потом перемещает объект в
контейнер 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 .

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.