Заметки сисадмина » Active Directory: учимся на горьких ошибках

Заметки сисадмина о интересных вещах из мира IT, инструкции и рецензии. Настраиваем Компьютеры/Сервера/1С/SIP-телефонию в Москве

Active Directory: учимся на горьких ошибках

2007-04-22 · Posted in Active Directory, Windows Server 2003

Active Directory: учимся на горьких ошибках

Дэн Уолбрак

Все началось с того, что в начале этого года в нашей лаборатории университета Gulf Coast Community на контроллере домена Windows 2000 отказал жесткий диск. Дальнейшие события развивались по наихудшему сценарию: когда мы попытались восстановить данные с зеркального диска, выяснилось, что он тоже не работает. В результате потери всей университетской службы Active Directory пользователи были лишены доступа к целому ряду приложений.

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

Итак, нужно быть готовым ко всем возможным отказам, даже маловероятным. Это означает, что необходимо пересмотреть план резервирования Active Directory и убедиться в том, что в вашей стратегии восстановления после сбоев предусмотрена возможность выхода из строя всех контроллеров доменов. Чтобы восстановить нашу службу справочника Active Directory, мы предприняли несколько шагов (причем некоторые из них оказались ошибочными). Но обо всем по порядку.

Восстановление

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

Первой задачей было повторно создать домен путем введения и проверки информации о пользователях и группах отдела. Пользователи и группы Active Directory обладают такими свойствами, как имена, пароли, профили, принадлежность к рабочим станциям и рабочим группам. Все эти данные должны быть введены, скопированы или созданы в зависимости от требований к установке. В университете Gulf Coast Community мы, чтобы контролировать ПК, используем сочетание профилей и рабочих станций для конкретных студентов. Например, в свойстве Classroom 209 профиля Student 209 указано, что студенту разрешено пользоваться рабочими станциями только этой аудитории. Определенным пользователям разрешено работать с определенными приложениями. Кроме того, существуют пользователи с правами администратора. Введя вручную в Active Directory записи о всех 200 пользователях, мы пришли к выводу, что процесс создания пользователей и групп надо автоматизировать.

Мы опробовали несколько взятых из Интернет сценариев создания пользователей и групп Active Directory. Большая часть из них не включала все нужные нам свойства или не работала так, как было заявлено. Последующие поиски привели к тому, что мы обнаружили такие инструменты создания сценариев, как WSH (Windows Scripting Host), Visual Basic Scripting Engine и ADSI (Active Directory Scripting Interface).

В листинге 1 показан сценарий, разработанный нами в лаборатории Gulf Coast Community. Он достаточно ясен, за исключением некоторых элементов. CSV-файл (Comma-Separated Value — файл значений, разделяемых запятой) здесь называется “export.txt”, хотя его формат — CSV. Наличие 15 или около того команд сценария, предназначенных для запрета пользователю менять пароль, осложняется применением механизма безопасности ACE (Access Control Entry), который требует от вас получения разрешения на любое вносимое изменение. Поэтому, до того как сценарий может определить свойство, оно должно быть обработано ACE.

Сценарий также разрешает пользователям принадлежать нескольким группам (до пяти). Для включения в состав различных групп вместо одного цикла применяются отдельные команды. Сценарий разрешает задействовать до трех рабочих станций регистрации. Обратите внимание на две команды, которые находятся перед командой Wend, — это Set Group = nothing и Set adsUser = Nothing. Они перезагружают группу и пользователя до следующей обработки цикла.

Настройка вашего сценария

Вам потребуется настроить некоторые элементы сценария под себя. Например, вместо tech.gulfcoast.edu укажите имя своего домена. В сценарии все пароли установлены в значение “gccc”, в вашем случае при первом входе в систему каждый пользователь должен создать пароль и регулярно менять его.

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

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

После того как был создан и протестирован весь сценарий, настало время создать файл ввода. Мы хотели отработать процесс, который мог дублироваться и выполняться по расписанию с нужной частотой. Сначала мы прибегли к функции экспорта, имеющейся во встроенном модуле AD MMC (Microsoft Management Console). Хотя мы создали несколько различных файлов, ни один из них не содержал необходимых нам данных — например, списка всех рабочих станций для определенного пользователя. Поэтому мы обратили свое внимание на две утилиты командной строки, входящие в состав Windows 2000 Server, — LDIFDE (LDAP Data Interchange Format Data Exchange) и CSVDE (CSV Data Exchange).

LDIFDE — это утилита для экспорта и импорта объектов Active Directory с использованием LDIF-форматированных файлов. Она включает в себя переключатели командной строки, управляющие операциями экспорта и импорта. Несмотря на то что утилита LDIFDE применяется для переноса данных, умело поработав с ключами входных параметров, мы смогли использовать ее для резервирования (синтаксис командной строки утилиты LDIFDE можно узнать, запустив ее с ключем “–?”).

Используя фильтры для выбора пользователей и групп, а затем указывая или исключая некоторые атрибуты, можно создать почти законченный резервный файл. В нашем случае созданный нами с помощью LDIFDE файл все же потребовал просмотра и внесения небольших изменений (листинг 3).

Утилита CSVDE умеет импортировать и экспортировать данные из Active Directory в файлы CSV-формата. Она работает аналогично LDIFDE. Некоторые приложения, например Microsoft Excel, умеют читать и сохранять файлы в формате CSV, представляющем собой одну или множество строк текста со значениями, разделенными запятыми. Первая строка содержит имена всех атрибутов в том же порядке, что и данные во всех последующих строках. Нам больше понравился формат LDIFDE, в котором все поля обозначены.

Если не повезет…

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

Leave a Reply