Одной из наиболее важных и сложных систем является служба каталогов Active Directory (AD), которая на многих предприятиях используется для авторизации и аутентификации пользователей. На что же следует обращать внимание в связи с сохранением данных? Какие меры предосторожности позволяют администратору спать спокойно? Мы постараемся дать ответы на эти вопросы и предложить некоторые практические идеи для повседневного применения, которые базируются на подручных средствах.
Сохранение Active Directory не должно зависеть от помпезных пакетов управления резервным копированием данных — при желании ее можно осуществить бесплатно и с сохранением наглядности.
СОХРАНЕНИЕ И УДАЛЕНИЕ ДАННЫХ В ACTIVE DIRECTORY
В зависимости от инфраструктуры ИТ среда Active Directory состоит из двух или более контроллеров доменов (Domain Controller). Active Directory можно использовать и с одним контроллером домена, однако из соображений обеспечения отказоустойчивости предпочтительнее избыточная комбинация. Какие-либо ограничения сверху отсутствуют. Дизайн произволен, хотя и определяется некоторыми правилами, не влияющими на функции восстановления информации. Среды Active Directory с 50 и более контроллерами доменов, распределенными по всему миру или по отдельному региону, сегодня встречаются нередко. Точное их количество зависит от требований филиала, доступной пропускной способности и числа пользователей, которые аутентифицируются в Active Directory. Система тиражирования обеспечивает распределение базы данных по всем контроллерам доменов, а также следит за тем, чтобы любой из них обладал каталогом с актуальной информацией.
Каждый пользователь, который вместе со своей учетной записью является членом домена Active Directory, после регистрации взаимодействует только с одним контроллером в своем домене. Определение этого контроллера происходит на основе топологии филиала и подсети.
За изменения в Active Directory, когда, к примеру, администратор настраивает одну из учетных записей или пользователь меняет пароль самостоятельно, отвечает соответствующий контроллер домена. При этом у изменяемого объекта увеличивается порядковый номер обновления (Update Sequence Number, USN), что сигнализирует о необходимости осуществить тиражирование на другой контроллер домена. Таким образом можно предотвратить конфликты в случае изменений и обеспечить целостность службы каталогов в любой момент времени.
РАБОТА С «МЕРТВЫМИ» ОБЪЕКТАМИ
То же касается и удаления данных, но процесс происходит в два этапа. Учетная запись сначала маркируется для удаления впоследствии. В этом случае говорят о «надгробии» (Tombstone). Объект становится «надгробием», когда атрибут IsDeleted принимает значение True, а большая часть всех остальных атрибутов теряется. Кроме того, он переименовывается в <СтароеИмяОбъекта> ADEL:
В таком урезанном виде учетная запись хранится в базе данных на протяжении 60 дней — это срок «жизни надгробия». Начиная с Windows Server 2003 SP1 данный промежуток времени составляет 180 дней — но лишь при установке доменов с SP1. По прошествии указанного периода выполняется второй этап: «надгробие» окончательно удаляется в процессе уборки (Garbage Collection). В продолжении всего срока «жизни надгробия», который одинаков для всей компании, удаленные учетные записи можно реанимировать — при условии, что имеется резервная копия или соответствующие инструменты, описанные ниже.
ЕЖЕДНЕВНОЕ СОХРАНЕНИЕ СОСТОЯНИЯ СИСТЕМЫ
Каждая программа резервного копирования, совместимая с Windows, должна справляться с сохранением состояния системы. При этом на контроллере домена автоматически происходит сохранение Active Directory. Поскольку защищаются всегда все серверы, в том числе и контроллеры доменов, после этого ничего плохого уже не случится. Однако в силу ряда причин обычное резервное копирование данных на контроллере домена имеет смысл дополнить выполнением еще одной операции и записать состояние системы в виде файла: с одной стороны, так обеспечивается быстрое восстановление, с другой — локальное сохранение не зависит от внешних носителей. К тому же тем самым достигается независимость от используемого решения резервного копирования.
НЕЗАВИСИМОСТЬ ОТ ИСПОЛЬЗУЕМОГО РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ
Представленное ниже решение восстановления базируется на подручных средствах, поэтому инсталляция специфического программного обеспечения на контроллере домена становится ненужной. При помощи интегрированной в Windows утилиты резервного копирования (ntbackup.exe) и планировщика задач сохранение системного состояния на локальных носителях данных контроллера домена можно проводить по ночам. Утилита для резервного копирования (см. Рисунок 1) предоставляет планировщику все необходимое. Она доступна не только через графический интерфейс, но и может быть вызвана через командную строку. Следующая команда запускает процесс сохранения системного состояния из командной строки: ntbackup backup systemstate /j «Имя копии» /F
C:BackupfolderBackupfile.bkf /l:f. Параметр /j обозначает имя копии (Jobname). После F следуют путь и имя файла, а /l:f инициирует сохранение с подробным журнальным файлом (Logging=Full). При включении команды в командный файл с определенной функциональностью и привлечении планировщика задач можно проводить локальные резервные копирования, к примеру, ежедневно создавать резервные копии и обновлять их каждую неделю (см. Рисунок 2).
ЛЕЧЕНИЕ ПАРАНОЙИ БЕЗ БОЛЬШИХ ЗАТРАТ
Стоит признать, что создание дополнительных резервных копий на каждом контроллере домена — причем в продолжение всей недели, — наводит на мысль об одержимости. Но, с другой стороны, это не так уж и сложно, а дополнительная подстраховка не помешает. Однако очень важно помнить, что описанный метод ни в коем случае не может заменить признанный метод резервного копирования, ведь при пожаре или в случае отказа жесткого диска все данные будут утеряны. При сохранении системного состояния не следует забывать о том, что содержащаяся там информация привязана к аппаратному обеспечению, и при восстановлении на другом оборудовании могут возникнуть определенные сложности.
ВНИМАТЕЛЬНОСТЬ ПРИ СОХРАНЕНИИ
Неважно, каким образом осуществляется сохранение состояния системы на контроллере домена — на жесткий диск, ленту, при помощи подручных средств или программного обеспечения для резервного копирования третьих производителей, — при архивировании необходимо следить за тем, чтобы сохраняемые данные были не старее уже упомянутого срока «жизни надгробия», поскольку восстановление за пределами этого промежутка времени исключено.
В остальном же контроллер домена всегда должен быть «на линии». Сохранение, к примеру, с применением образов по этой причине имеет мало смысла, так как происходит помимо логических механизмов, к примеру, тиражирования и обработки USN в Active Directory, и с высокой вероятностью может повлечь за собой несогласованность базы данных [1].
ЧТО МОЖЕТ СЛУЧИТЬСЯ С ACTIVE DIRECTORY
При каких обстоятельствах может возникнуть необходимость в восстановлении Active Directory? В первую очередь следует упомянуть об отказе контроллера домена (Domain Controller, DC) — это простейший случай. Если в домене есть другие контроллеры, достаточно подключить новый DC, тогда обращение к системе резервного копирования оказывается излишним. Единственное затруднение составляет сохраненная в базе данных ссылка на имя уже несуществующего контроллера домена. DCPROMO вызывает отказ, когда в базе данных имеется DC с используемым именем. Эту проблему можно решить двумя способами: для достижения скорейшего результата лучше всего включить контроллер домена в Active Directory под другим именем. Старое имя и впредь остается в базе данных, однако это не важно, поскольку DC не функционирует. Избавиться от этой записи можно позже. Если же имя контроллера домена должно оставаться неизменным, его необходимо предварительно удалить.
Сложнее, когда проблема затронула все контроллеры домена, т. е. весь домен. Причины могут быть разные: ошибка в базе данных, вирусная эпидемия, атака на контроллеры домена с целью вызвать «отказ в обслуживании» или даже пожар в серверном помещении. В таком случае для восстановления домена необходимо обратиться к резервной копии состояния системы. Восстановление домена или контроллера домена в зависимости от структуры AD может оказаться довольно сложной задачей. Важно выяснить, какие домены пострадали, был ли затронут корневой домен и существуют ли субдомены. В зависимости от контроллеров доменов могут иметь значение роли FSMO. Имел ли контроллер домена одну из этих ролей? Можно ли на период восстановления отказаться от этой роли или она жизненно необходима для домена? Выполнял ли DC дополнительные функции, к примеру, функции глобального каталога или DNS? Все перечисленные факторы предусматривают разную реакцию.
Полная последовательность действий при восстановлении доменов и контроллеров доменов описывается в документации Microsoft «Планирование восстановления леса каталогов Active Directory» (Planning for Active Directory Forest Recovery [3]). Нет необходимости держать наготове все средства, позволяющие реагировать на отказ домена или контроллера домена, некоторые случаи происходят очень редко. Однако следует знать хотя бы приблизительно, что делать в случае опасности и где подробно описан соответствующий метод. Так же важно иметь твердую уверенность в том, что резервная копия текущего состояния системы всегда под рукой.
Гораздо чаще необходимость в восстановлении возникает в результате случайного удаления учетных записей из-за неправильного обслуживания или сценариев с ошибками. Чаще всего последствия можно ощутить довольно быстро, что тоже требует оперативного реагирования.
К примеру, для восстановления случайно удаленной учетной записи пользователя объект необходимо создать заново при помощи системы восстановления без авторизации и с авторизацией ntdsutii.exe — двухступенчатого метода для восстановления удаленных объектов учетных записей. Это касается всех перечисленных типов объектов — пользователей, компьютеров или групп. Процесс состоит из двух этапов, потому что удаленная учетная запись, как уже говорилось, маркируется в качестве удаленной и база данных исходит из того, что это текущее состояние объекта. Если контроллер домена запускается в режиме восстановления Active Directory и реанимирует состояние системы, после тиражирования объект все равно удаляется другими DC, поскольку текущий номер USN все еще задается контроллером домена, на котором выполнялся процесс удаления. Поэтому после восстановления без авторизации необходимо проведение восстановления с авторизацией, в результате которого увеличивается номер USN, и статус «удалена» удаленной учетной записи отменяется. Эта процедура противоположна описанному в первой части процессу создания «надгробия» — со значительными ограничениями, как еще будет показано.
Если контроллер домена загружается в режиме восстановления Active Directory, а ntdsutil терпеливо ожидает ввода команды, в ней необходимо четко указать, что конкретно требуется восстановить. В это же время администратор должен задать путь к потерянному объекту в форме уникального имени (Distinguished Name, DN). DN обозначает имя объекта в структуре каталога, включая иерархию папок, где расположен объект каталога. Вот пример. Учетная запись пользователя Ганса Муштера из домена SecLab.local, расположенного в структурном подразделении «Менеджеры», обладает следующим уникальным именем: ”CN=Ганс Муштер, OU=Менеджер, DC=SecLab, DC=локальный“.
В плоских структурах DN может быть известным, однако в крупных структурах Active Directory нередко никто не знает, в каком структурном подразделении находилась потерянная учетная запись до удаления. Тогда на помощь придет команда dsquery.exe, посредством которой ежедневно можно создавать текстовый файл со всеми DN (см. Рисунок 3). Эту команду имеет смысл включить в пакет DCBackup.cmd. Список уникальных имен позволяет определить, в каком организационном подразделении располагался удаленный объект учетной записи. Не менее полезна возможность введения в ntdsu-til.exe вместе с уникальным именем всей цепочки символов из текстового файла через буфер обмена, что предотвращает ошибочный ввод данных в ntdsutil.exe (см. Рисунок 4). После выполнения команды ntdsutil.exe может вывести сообщение о неразрешенных ссылках, так называемых «обратных ссылках» (см. Рисунок 5), применяемых, среди прочего, для назначения учетным записям пользователей членства в группах. Они не сохраняются в объекте пользователя, а записываются в виде ссылок в атрибуте memberOf. Если объект пользователя или компьютера становится «надгробием», то в процессе очистки на всех контроллерах доменов удаляются все обратные ссылки. Таким образом, их нельзя реконструировать при помощи ntdsutil.exe, поскольку речь идет только о тех ссылках, которые больше не являются составной частью «надгробия». В случае восстановленного объекта пользователя это означает, что учетная запись больше не входит ни в одну из групп. То же самое касается атрибута directReports (карта реестра «Организация» в «Свойствах пользователя»), он тоже представляет собой обратную ссылку.
Очень интересные документы по этой теме предлагает Netpro [4]. Для нас важно то, что благодаря последней версии ntdsutil.exe обратные ссылки не ведут к отрицательным последствиям, поскольку помимо предупреждений инструмент генерирует и файлы импорта LDIF. При помощи ldifde.exe их можно использовать после того, как контроллер домена снова станет доступен, чтобы восстановить отсутствующие обратные ссылки [5] (см. Рисунок 6). В системе, состоящей из нескольких доменов, ntdsutil.exe необходимо запускать на сервере глобального каталога, поскольку только контроллеры доменов глобальных каталогов обладают всеми ссылками на другие домены. В противном случае членство в доменах пользователей в файлах LDIF может быть учтено, а членство в соседних доменах — нет.
ВОССТАНОВЛЕНИЕ НАПРЯМУЮ
Наряду с авторизованным восстановлением объектов при помощи ntdsutil.exe существует еще одна возможность — напрямую обратиться к «контейнеру удаленных объектов» раздела и реанимировать хранящийся там объект типа «надгробие». Этот метод наиболее удобен, если речь идет об отдельной учетной записи, к которой необходимо срочно получить доступ — к примеру, в результате случайного удаления.
Для такого случая существует инструмент ldp.exe, который можно найти на компакт-диске Windows Server среди средств поддержки. Однако использовать его следует с осторожностью. Как и adsiedit.msc, он предоставляет прямой доступ к Active Directory и позволяет манипулировать атрибутами. При неправильном обращении и наличии соответствующих прав службе каталогов можно нанести значительный ущерб.
Работать с инструментом не так просто, поскольку путь к «надгробию» лежит через активацию элементов управления и подключения к службе каталогов, требует ввода целого ряда дополнительных данных в диалоговых окнах и открывает множество соответствующих масок (см. Рисунки 7 и 8). Пошаговое руководство, иллюстрированное примерами, можно найти в базе знаний Microsoft.
На тех предприятиях, где разрешается копировать программное обеспечение из Internet на контроллер домена, можно воспользоваться инструментом adrestore.exe компании Sysinternals, который предлагает удобный вариант мгновенного восстановления «надгробия». Это ПО предлагается бесплатно для загрузки на странице Microsoft по адресу http://www.microsoft.com/technet/sysinternals/Utilities/AdRestore.mspx. Его можно установить на контроллере домена сразу после распаковки, не прибегая к длительной инсталляции. Инструмент обходится без DLL, поэтому не придется беспокоиться о нежелательном засорении реестра или случайно оставленной где-то информации. Для контроллера домена это очень важный аспект. Управление интуитивно понятно. При запуске без параметров перечисляются все имеющиеся на DC «надгробия». Параметр -r позволяет начать процесс восстановления и для каждого объекта требует подтверждения (см. Рисунок 9). При помощи инструментов ldp.exe и adrestore.exe удастся возвратить к жизни организационные блоки (Organisational Unit, OU) и целые ветви Active Directory. Внимательному читателю захочется узнать, зачем, собственно, нужны все эти проблемы с перезагрузкой контроллера домена в автономном режиме и восстановлением с аутентификацией, если все делается гораздо проще, как только что и было показано. Ответ заключается в том, что восстановление вручную и напрямую не предотвращает, например, потерю данных о членстве в группах из-за обратных ссылок. При восстановлении с помощью ntdsutil.exe есть по крайней мере возможность возвращения в систему обратных ссылок при помощи файлов LDIF. В каждом отдельном случае необходимо решить, что будет сложнее: добавлять группы вручную или запустить контроллер домена в автономном режиме и выполнить ntdsutil.exe.
Групповые директивы — обязательная составная часть Active Directory. Сохранение производится при помощи параметра системного состояния. Однако групповые директивы на контроллере домена сохраняются не только в базе данных, но частично и в файловой системе, что требует иного метода действий при восстановлении. Внутреннее сохранение групповых директив происходит раздельно в двух местах: в контейнере групповых директив (Group Policy Container, GPC) и в шаблоне групповых директив (Group Policy Template, GPT). Контейнер находится в базе данных Active Directory и содержит параметры и настройки групповых директив. Тиражирование происходит при помощи механизмов Active Directory, управление которыми осуществляется с помощью программы контроля целостности знаний (Knowledge Consistency Checker, KCC). Оригинал расположен в папке SYSVOLPolicies и служит, среди прочего, для сохранения административных документов с параметрами реестра.
За тиражирование отвечают службы репликации файлов (File Repliсation Services, FRS). Изменения в объекте групповых директив благодаря внутренним процессам остаются синхронизированными в обоих местах. При реставрации групповых директив это может происходить посредством восстановления системного состояния, поскольку папка SYSVOL содержится в нем. Однако в большинстве случаев это непрактичное решение, поскольку никому не хочется восстанавливать все системное состояние, когда речь идет о единственной групповой директиве. Нет необходимости и в указании групповых директив как авторизованных, поскольку они, как и другие объекты, не подлежат управлению посредством порядковых номеров обновлений (Update Sequence Numbers, USN), благодаря чему «надгробий» не появляется.
Удобную возможность для сохранения и восстановления групповых директив предлагает консоль управления групповыми директивами (Group Policy Management Console). Доступная изначально только в качестве загружаемого расширения, она стала обязательной составной частью представителей семейства Windows 2003 Server и значительно облегчает сохранение и восстановление групповых директив. Еще одно преимущество заключается в том, что обслуживание может производиться при помощи как графического интерфейса, так и прилагаемой библиотеки сценариев. Среди прочего имеется возможность сохранения всех групповых директив из командной строки каталога.
Таким образом, обеспечиваются наилучшие условия для расширения работающего по ночам сценария Dcbackup.cmd (см. Рисунок 10). В следующем примере показано, как проводится сохранение всех правил в файловой системе: “c:Program FilesGPMCScriptsBackupAllGPOs.wsf“ c:Backup /comment: “Daily schedule“.
Вставленную в сценарий команду можно произвольно дополнять и подстраивать под соответствующую среду. Однако необходимо позаботиться о периодическом удалении целевого каталога, поскольку новые копии добавляются в соответствующую папку, а уже имеющиеся будут оставаться в ней до бесконечности. Восстановление групповых директив может происходить и через графический интерфейс. Посредством контекстного меню узла Group Policy Objects и команды Manage Backups на экран выводится диалоговое окно управления резервными копиями (см. Рисунки 11 и 12). После указания папки для хранения все сохраненные директивы доступны для выбора и могут восстанавливаться по отдельности. В результате групповые директивы можно перенести из тестовой среды в производственную и наоборот без повторного создания групповой директивы и задания настроек. Библиотека сценариев располагается в программном каталоге GPMC, содержит множество сценариев и представляет собой полезное дополнение к графическому интерфейсу.
Ничто не может быть хуже мнимого надежного сохранения данных. Поэтому каждый метод резервного копирования необходимо время от времени тестировать в ограниченной тестовой среде путем «пробного прогона». Лишь таким образом можно устранить и локализовать неполноту решения, что в случае потери данных мешает быстрому восстановлению исходного состояния. Кроме того, этот метод помогает персоналу поддерживать должную квалификацию на случай аварийного восстановления данных. Для этого не требуется дорогое аппаратное обеспечение, которое используется лишь раз в полгода. Тестовая среда теперь может быть создана при помощи технологий виртуализации серверов, к примеру, MS Virtual Server 2005.
Все перечисленные выше методы и инструменты бесплатны и предлагают абсолютно надежное резервное копирование данных службы каталогов Active Directory, целью которого всегда является сохранение состояния системы. Для восстановления данных из Active Directory имеются продукты третьих производителей, расширяющие соответствующие возможности. Благодаря коммерческим продуктам управление обратными ссылками также остается прозрачным для администратора. Как было показано, это достигается простыми средствами и предлагает массу преимуществ. Возможно, изложенный нами подход будет способствовать расширению концепции резервного копирования.
Клаус Биршенк — консультант по технологиям в компании T-Systems Enterprise.
© AWi Verlag
Ресурсы Internet
Упоминаемые в тексте
[1] How to detect and recover from a USN rollback in Windows Server 2003: http://support.microsoft.com/kb/875495/en-us.
[2] How to remove data in Active Directory after an unsuccessful domain controller demotion: http://support.microsoft.com/kb/216498/EN-US/.
[3] Planning for Active Directory Forest Recovery: http://www.microsoft.com/downloads/details.aspx?FamilyID=afe436fa-8e8a-443a-9027-c522dee35d85&DisplayLang=en.
[4] The Definitive Guide to Active Directory Disaster Recovery: http://www.netpro.com -> Support -> Technical Articles.
[5] How to restore deleted user accounts and their group memberships in Active Directory: http://support.microsoft.com/kb/840001/.
Дополнительные источники информации:
How to perform a disaster recovery restore of AD on a computer with a different hardware configuration: http://support.microsoft.com/kb/263532/en-us.
Authoritative restore of groups can result inconsistent membership information across domain controllers: http://support.microsoft.com/kb/280079/en-us.
Useful shelf life of a system-state backup of Active Directory: http://support.microsoft.com/kb/216993/en-us.
How To Use Ntdsutil to Manage Active Directory Files from the Command Line in Windows Server 2003: http://support.microsoft.com/kb/816120/en-us.
Using LDIFDE to import and export directory objects to Active Directory: http://support.microsoft.com/kb/237677/en-us