Главная Windows, Новое Active Directory, Windows Server 2008
  • Восстановление контроллера домена Active Directory в Windows Server 2008 (Часть 2)

    • Рубрика: Windows,Новое
    • Автор: Илья Рудь
    • Дата: Thursday 16 Apr 2009

    Stop

    Два и более контроллеров домена. Продолжаю тему восстановления контроллера домена Active Directory в Windows Server 2008. Контроллеров домена должно быть несколько, это золотое правило, которому необходимо следовать во всех средних и крупных организациях. Принцип восстановления при наличии нескольких контроллеров существенно меняется. Давайте попробуем понять почему. Представим, что вы имеете два контроллера домена с именами DC1 и DC2(это контроллеры одного домена). Оба будут иметь идентичную базу данных Active Directory, и если вы измените ее на одном, она автоматически обновится на другом, это процесс репликации.

  • Главная Windows, Новое Active Directory
    • Версия Схемы Active Directory

      • Рубрика: Windows,Новое
      • Автор: Илья Рудь
      • Дата: Tuesday 14 Apr 2009

      adТрудно недооценить важность «Схемы Active Directory»  для сетей, построенных на базе доменной среды Active Directory. Это основа технологии «AD» и очень важно правильно понимать принципы ее функционирования. Большинство системных администраторов не уделяют схеме должного внимания по причине того, что иметь дело с ней приходится достаточно редко. В данной статье я расскажу, что такое версия схемы, для чего нам необходимо ее знать и самое главное как посмотреть текущую версию. Прежде всего, пару слов о самой схеме, каждый объект, созданный в Active Directory, будь то пользователь или компьютер, имеет определенные параметры, называемые атрибутами. Самым простым примером может служить атрибут «Фамилия» у объекта пользователь. Схема определяет, какие объекты мы можем создавать в Active Directory, и какие атрибуты они будут иметь.

      Active Directory допускает использование в рамках одной организации несколько контроллеров домена, построенных на базе разных версий ОС Windows. А именно – на базе Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Поскольку данные версии выпускались в разные годы, и каждая новая версия несет больший функционал, чем предыдущая, понимание схемы у каждой операционной системы свое. Поэтому при добавлении нового контроллера на базе Windows Server 2008 в организацию, где существующие контроллеры построены на Windows Server 2003, вам приходилось запускать утилиту «Adprep». Тем самым вы обновляли схему вашей организации до того уровня, с которым работает Windows Server 2008.

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

      Возможные версии схемы:

      13 – Windows 2000 Server
      30 – Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
      31 – Windows Server 2003 R2
      44 – Windows Server 2008 RTM

      Даже если все контроллеры в вашей организации работают на Windows Server 2003 R2, а версия схемы показывает «44» не стоит удивляться, это говорит о том, что уже было осуществлено обновление схемы до уровня Windows Server 2008 RTM, но сам контроллер по какой-то причине устанавливать не стали.

      Посмотреть версию схемы можно несколькими способами. Самым простым является способ с использованием утилиты «DSQuery». Для этого в командной строке необходимо ввести команду со следующими параметрами:

      “dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion”

      Естественно в части «dc=domainname,dc=local» вы должны подставить имя собственного домена. (Пример: dc=microsoft,dc=com)

      Результатом ввода команды является получение атрибута «ObjectVersion», который и будет являться номером версии схемы:

      image

      Рис. 1 Получение версии схемы через утилиту «DSQuery».

      Второй способ более длинный и подразумевает использование оснастки «ADSIEdit.msc». Для просмотра версии схемы вам придется подключиться к разделу Active Directory схема.

      "CN=Schema,CN=Configuration,DC=domain,DC=local"

      И найти значение атрибута "objectVersion".

      image

      Рис.2 Получение версии схемы через оснастку «ADSIEdit.msc».

      Зная версию схему, вы всегда можете с уверенностью сказать нужно ли схему обновлять и если нужно то, до какого уровня.

      Следует отметить, что обновления схемы могу производиться программным обеспечением тесно интегрированным с Active Directory. Самый яркий пример Microsoft Exchange Server. И зачастую в организации, планирующей внедрение Exchange Server, необходимо выяснить, была ли осуществлена подготовка схемы? И если была, то какой версией Exchange Server. На текущий момент существуют три версии Exchange, работающие с Active Directory, но вариантов модификации схемы существует шесть.

      Понять была ли изме
      нена Схема Active Directory Exchange сервером можно по атрибуту «rangeUpper», который принимает следующие значения:

      4397    – Exchange Server 2000 RTM
      4406    – Exchange Server 2000 With Service Pack 3
      6870    – Exchange Server 2003 RTM
      6936    – Exchange Server 2003 With Service Pack 3
      10628  – Exchange Server 2007
      11116  – Exchange 2007 With Service Pack 1

      Как можно заметить обновление схемы происходит и при установке набора обновлений SP3 для Exchange Server 2000/2003 и SP1 для Exchange 2007.

      Посмотреть значение атрибута «rangeUpper» можно через утилиту DSQuery:

      "dsquery * CN=ms-Exch-Schema-Version-Pt, cn=schema, cn=configuration, dc=domainname, dc=local -scope base -attr rangeUpper"

      image

      Рис. 3 Получение атрибута «rangeUpper» через утилиту DSQuery.

      Если после ввода данной команды возвращен ответ, говорящий об отсутствии атрибута «rangeUpper» можно сделать вывод о том, что схема изменена не была.

      Процесс обновления схемы является очень важным моментом для каждой организации Active Directory, поэтому следует избегать лишних, неоправданных действий. Понимая сути атрибутов «objectVersion» и «rangeUpper» дает специалисту преимущество при работе с Active Directory в незнакомой организации, а также является вспомогательным инструментом при решении проблем.

      MCT\MCSE

      Рудь Илья

      me@rudilya.ru

    • Главная Windows, Новое Active Directory
      • Восстановление контроллера домена Active Directory в Windows Server 2008 (Часть 1)

        • Рубрика: Windows,Новое
        • Автор: Илья Рудь
        • Дата: Monday 06 Apr 2009

        ad   В предыдущей статье я рассказывал, как правильно восстанавливать удаленные объекты Active Directory. Сейчас хотелось бы поговорить о полном восстановлении контроллера домена Active Directory, ведь зачастую проблемы системных администраторов гораздо более сложные, чем потеря одного объекта. Угрозу стабильности может представлять вирусная активность, испортившая реестр на контроллере, вышедший из строя жесткий диск, на котором хранились системные файлы, полная или частичная потеря папки SYSVOL c групповыми политиками. Этот страшный список можно продолжать.

        Поскольку на дворе 2009 год речь пойдет о контроллерах домена под управлением Windows Server 2008, благо восстановление предыдущей версии ОС описано неоднократно. Начнем.

        Первое, что бы должны хорошо уяснить, знакомой утилиты NTbackup уже нет, на смену ей пришло новое решение ” Система архивации данных Windows Server “. Это именно новое решение, а не обновленный NTbackup. Также с Windows Server 2008 поставляется новая утилита командной строки Wbadmin.exe, она расширяет и дополняет возможности графической “Системы архивации данных Windows Server “.

        Для достижения полного понимания, описывать систему восстановления я буду на примерах типовых организации.

        Организация первая: Один сервер.

        Довольно распространенное явление. Фирма имеет небольшое количество компьютеров, как правило, до 30-40 и в сети присутствует единственный сервер под управлением ос Windows Server 2008. Он же и является контроллером домена Active Directory, вдобавок несет на себе роль файлового сервера и возможно некоторые сетевые приложения. Да у Microsoft есть рекомендации говорящие о том, что любая организация Active Directory должна иметь как минимум два контроллера домена и сам контроллер не должен иметь дополнительных ролей. Но будем смотреть правде в глаза, в малом бизнесе фирм с одним сервером очень и очень много. Как же будет выглядеть система восстановления в такой ситуации?

        Прежде все давайте сразу определимся. Наш сервер должен иметь минимум два раздела на жестком диске, а в идеале два раздела на RAID массиве. Объясню почему, “Система архивации данных Windows Server ” осуществляет резервное копирование только разделов (есть одно исключение, но о нем позже), выбрать резервное копирование одной или нескольких папок мы не можем.

        Поэтому:

        1) Раздел 1 будет содержать – Операционную систему Windows с реестром, файлы загрузки, включая файл Bootmgr, базу данных Active Directory (Ntds.dit), журналы базы данных Active Directory и папку SYSVOL с групповым политиками.

        2) Раздел 2. Второй раздел будет использоваться под хранение резервных копий.

        Примечание: У нас есть возможность создавать резервные копии на:

        а) Раздел жесткого диска (то, что я и предлагаю)

        б) На сетевом ресурсе,

        в) DVD-дисках.

        Microsoft рекомендует хранить резервную копию на внутреннем или внешнем жестком диске.

        Будем считать, что наш сервер был установлен, следуя вышестоящей рекомендации.

        Теперь давайте посмотрим, как застраховаться от непредвиденного “падения” сервера. Используем Windows Complete PC Restore.

        1. Для начала необходимо установить программу “Система архивации данных Windows Server “. К сожалению, в борьбе за минимальный набор устанавливаемых По-умолчанию компонентов система архивации проиграла и изначально не стоит. Я считаю это правильным решением, те, кому она нужна, ее установят, а люди, использующие сторонние решения, сэкономят немного ресурсов. Установка идет по классическому сценарию для Windows 2008 через “Диспетчер Сервера”

        image

        Рис. 1 Установка системы архивации

        2. После установки системы архивации нам необходимо настроить расписание задачи, которая будет делать архивную копию нашего Раздела 1 (Напоминаю на нем находится Windows Server 2008 и Active Directory ). Я предлагаю делать такой архив раз в неделю в воскресенье, дальше вы поймете почему. Для этого запускаем оснастку “Системы архивации данных Windows Server ” и запустить расписание архивации.

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

        image

        Рис.2 Запуск расписания Архивации

        После этого пропустить приветствие и нажать “Далее”. Перед нами встанет выбор, как осуществлять резервное копирование (Весь сервер или настраиваемый). Поскольку в наш архив должен попадать только Раздел 1, мы выбираем “Настраиваемый”.

        image

        Рис.3 Выбор конфигурации архивации.

        После открывается список разделов нашего сервера на котором мы должны снять “галочки” на всех разделах кроме того который содержит нашу систему. (В статье он называется Раздел 1)

        image

        Рис. 3 Выбор разделов.

        Выбрав, что бы будем архивировать, переходим к настройке расписания. Из данного окна тонко настроить расписание задачи мы не сможем, поэтому выбиваем время Ежедневно 21:00. В дальнейшем мы изменим это расписание.

        image

        Рис.4 Расписание.

        image

        Рис. 5 Выбор места хранения резервной копии

        На пятом рисунку показано окно, где вам необходимо выбрать место хранения архива. Я выбираю единственный доступный раздел. После чего запускается процесс форматирования. По окончанию которого вам раздел пропадет из зоны видимости, т.к буква диска него будет удалена. От лишних глаз он будет убран, а вы всегда сможете его найти через оснастку “Управление дисками”

        image

        Рис. 6. В Процессе форматирования.

        После окончания процесса вам придется несколько раз нажать “Далее”. Я не показываю эти окна, поскольку ничего важного на них не выбирается. Просто оставьте все на параметрах По-умолчанию. Настройка резервного копирования завершена. Остается подправить расписание запуска задачи. Для этого открываем “Планировщик Заданий” в Панели управления и находим нашу задачу.

        image

        Рис. 7 Планировщик Заданий

        Теперь заходим в свойства задачи и меняем расписание. Нам нужно сделать запуск задачи “Ежевоскресной”

        image

        Рис. 8 Измененное расписание

        Подведем итог. Теперь каждое воскресенье в 21:00 на отдельный раздел жесткого диска будет делаться резервная копия нашего “Раздела 1” содержащего системные файлы и базу Active Directory. В случае падения вашего сервера вы всегда сможете его восстановить. Это и есть Windows Complete PC Restore. Только не забывайте, время от времени переносить архивы для хранения за пределы вашего сервера и серверной, дабы не остаться в случае пожара или других крупных неприятностей без сервера и архива одновременно.

        Перейдем к этапу восстановления.

        Запустить восстановление сервера, мы можем несколькими путями, самый простой взять установочный диск Windows Server 2008 и загрузиться с него. На этапе приглашения к установке, необходимо выбрать “Восстановление системы”. После чего будет запущена среда “Windows RE” .

        image

        Рис. 9 Запуск процесса восстановления.

        Далее, мастер находит уже установленные ОС на наших дисках и спрашивает, какую из них мы будет восстанавливать. Как видно по рисунку, на этом этапе также можно подгрузить драйвера для ваших жестких дисков, естественно, если в этом есть необходимость.

        image

        Рис.10 Выбор ОС

        image

        Рис.11 Запуск Windows Complete PC Restore.

        Остается запустить “Восстановление архива Windows Complete PC Restore “. После запуска он предложит нам самую свежую копию архива. Если вы не планируете использовать последний архив, выберите “Восстановить другой архив”. У меня такая задача не стоит, и я выбираю последний доступный.

        image

        Рис.12 Этап выбора архива.

        Далее следует пара окон, которые мы оставляем неизменными. По завершению мастера запускается процесс восстановления, продолжительность которого сильно зависит от скорости оборудования и размера нашего раздела.

        image

        Рис.13 Процесс восстановления.

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

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

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

        Это конечно личное дело каждого, но на текущий момент мне кажется правильным следующее:

        1.Если ваш системный раздел содержит только операционною систему и базу Active Directory c системными файлами, то создание ежедневной копии системного раздела является оптимальным.

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

        Архив состояния системы. Тут главное не путать архив раздела и состояние системы. Состояние системы это архив самых важных для операционной системы вещей.

        В нашей ситуации в него попадут:

        • Системный реестр
        • База данных регистрации класса COM+
        • Файлы загрузки
        • База данных доменных служб Active Directory
        • Папка SYSVOL
        • Системные файлы, защищенные с помощью средства защиты ресурсов Windows

        Соответственно используя этот набор вы можете восстановить ваш сервер, если произошло повреждение вышеперечисленного. А также выполнить восстановление базы Active Directory в актуальное состояние. Но при полностью уничтоженном сервере только “Состояния системы” будет явно недостаточно. Как минимум потому, что “Состояния системы” контроллера можно восстановить только через “Режим восстановления службы каталогов”, т.е сервер должен в нем загрузиться.

        При этом хотелось бы заметить, что Архив состояния системы со времен Windows 2003 сильно изменился. Если в Windows 2003 он весил порядка 600-700 мегабайт, то создав его в Windows 2008, вы будете сильно удивлены размером в 9 гигабайт. Это происходит за счет включения в архив дополнительных файлов системы. Разница в размерах между архивом раздела и архивом состояния системы  будет видна, если у вас на системном диске хранятся какие-то дополнительные файлы.

        Осуществить создание состояния системы можно только из командной строки используя утилиту Wbadmin.exe

        Синтаксис будет следующий:

        wbadmin.exe start systemstatebackupbackupTarget:Z:

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

        По-умолчанию невозможно сохранять состояние системы на системный раздел, если по какой-то таинственной причине вам это необходимо, создайте следующий ключ в реестре.

        Путь: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\
        Ключ: Name: AllowSSBToAnyVolume
        Data type: DWORD
        Value data: 1

        image

        Рис.14 Создание состояния системы

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

        Сценарий первый. У нас полностью вышел из строя системный раздел и операционная система не загружается. Для восстановления нам придется пройтись по описанной выше процедуре и вернуть наш раздел с системой в рабочее состояние. Естественно для этого будет использоваться загрузочный дистрибутивный диск Windows Server 2008 и последний воскресный архив. Когда этот этап восстановления окончится, будет необходимо перезагрузиться в особый режим работы контроллера домена под название “Режим восстановления службы каталогов”.

        В этом режиме служба Active Directory Domain Services основлена и мы сможем воспользовавшись архивом со свежим состоянием системы обновить базу AD до актуального. (например пятничного).

        Сценарий второй. Наш сервер работает отлично, но по какой-то трагической случайности, были испорчены несколько веток реестра и вдобавок большая часть объектов Active Directory была удалена. Будем считать это атакой злостного хакера-инсайдера. Вродебы “пробоина” не смертельна и сервер все еще в строю, но нам бы конечно хотелось убрать последствия атаки. В этой ситуации состояния системы будет вполне достаточно. Именно этот сценарий я и рассмотрю подробней. Поскольку вы будете знать как восстанавливается состояние системы, выполнить возврат к жизни по первому сценарию самостоятельно у вас труда не составит.

        Для начала перезагружаем наш контроллер домена в режим восстановления службы каталога (DSRM), при этом помним, что для входа на контроллер домена в этом режиме нам нужно знать пароль администратора DSRM режима. (Вы задавали его при поднятии контроллера домена). Для выбора этого режима при запуске компьютера жмем “F8

        image

        Рис.15 Загрузка в DSRM

        Загрузившись в режиме DSRM, открываем командную строку. Сейчас нам нужно посмотреть список резервных копий и выбрать актуальное состояние системы. Для вывода списка вводим команду:

        wbadmin.exe get versions

        Найдя нужное состояние системы копируем “Идентификатор версии”. В моей ситуации он выглядит как “04/05/2009-13:49“. Идентификатором является дата и время создания архива. (Рис.16)

        image

        Рис.16 Поиск нужного архива состояния системы.

        Теперь мы готовы запустить восстановление состояния системы.

        Выполняем команду: wbadmin start systemstaterecovery -version: 04/05/2009-13:49

        image

        Рис.17 Процесс восстановления состояния системы.

        После запуска команды остается набраться терпения и дождаться окончания процесса. Закончив восстановление необходимо перезагрузиться в обычном режиме и проверить работоспособность сервера. Обратите внимание, что после восстановления системы, дополнительные папки созданные вами на системном диске, остались нетронутые.

        А теперь давайте подведем итоги:

        Мы рассмотрели процесс восстановления контроллера домена Active Directory на базе Windows Server 2008 в ситуации когда этот контроллер единственный в сети.

        Для того чтобы спать спокойно, вам будет необходимо:

        1. Выделить раздел жесткого диска под резервные копии.

        2. Создать расписание создания архива раздела с установленной системой. (Выполнение еженедельно)

        3. Создать пакетный файл с командой “wbadmin.exe start systemstatebackupи запускать его с помощью планировщика ежедневно. (Кроме дня, когда запускается создание архива системного раздела)

        4. Держать под рукой дистрибутивный диск с Windows Server 2008.

        5. Помнить пароль администратора “Режима восстановления службы каталогов”

        И еще самое важное, помните, процесс восстановления должен быть отлажен до совершенства. Естественно на тестовом сервере а не на боевом. В ситуации когда сервер не работает вы должны хладнокровно следовать инструкции, которая уже не однократно была проверена.

        На этом первая часть статьи по восстановлению контроллеров домена заканчивается. Процесс восстановления при нескольких контроллерах домена будет описан во второй части.

        Рудь Илья

        MCSE/MCT

        me@rudilya.ru

      • Главная Windows, Новое Active Directory, Group Policy
        • Использование в работе «GP Preferences»

          • Рубрика: Windows,Новое
          • Автор: Илья Рудь
          • Дата: Wednesday 01 Apr 2009

          sec21 На современном этапе у компании Microsoft есть продукты и технологии, которые становятся козырной картой в игре за внимание пользователей и администраторов. Одним из «джокеров» является технология групповых политик, позволяющая достаточно просто и эффективно управлять тысячами windows-компьютеров. Корпорация Microsoft это прекрасно понимает и с каждой версией новой операционной системы увеличивает количество параметров доступных для конфигурирования через GP. (Давайте сразу договоримся, групповые политики или Group Policy здесь и дальше по тексту просто GP).

          Если в Windows 2003 SP1 мы могли настроить через GP порядка 1800 параметров, то в Windows Vista и Windows Server 2008 это количество выросло до 2500. С использованием групповых политик в среде, построенной на Windows 2003 и Windows XP, можно было сделать много, но не все. Часть задач перекладывалась на скрипты, которые можно было создавать самому и применять вместе с GP.

          Скрипты это конечно здорово, но есть одна проблема, далеко не все умеют их писать. А поскольку «свято место пусто не бывает» на рынке появились компании, которые предлагали свои разработки позволяющие расширить стандартные групповые политики. Одной из таких компаний была «Desktop Standard». Видимо их разработка показалась софтверному гиганту достаточно интересной, поскольку в 2006-м году по старой корпоративной традиции компания была куплена Microsoft . С точки зрения ИТ-администраторов данное поглощение однозначно прошло со знаком «+». То, что стоило отдельных денег, теперь является частью доменной сети под управлением Windows Server 2008 и не требует дополнительного лицензирования.

          В данной статье я буду рассказывать об изменениях в групповых политиках, которые произошли после выхода Windows Server 2008 с акцентом на «GP Preferences». Ну а теперь обо всем по порядку.

          Как было в Windows Server 2003.

          Для начала я предлагаю освежить в памяти групповые политики в классическом виде, т.е так как они выглядят в Windows Server 2003. При создании объекта групповой политики мы могли воздействовать на компьютеры или пользователей несколькими способами:

          1. Сценарии – синий блок на рисунке 1. Сценарии давали возможность выполнить скрипты, написанные на Visual Basic Scripting Edition (VBS-файлы) и JScript (JS-файлы). При этом данные скрипты могли применяться в четырех случаях: при загрузке, при входе пользователя в систему, при выходе пользователя из системы, при выключении компьютера.

          2. Установка программ – красный блок на рисунке 1. Компонент «Установка программ» позволял развертывать программное обеспечение из msi-файлов и в ряде ситуации отойти от ручной установки программ.

          3. Параметры безопасности – оранжевый блок на рисунке 1. Параметры безопасности содержали целый ряд настроек безопасности компьютера. Список достаточно большой, могу привести примеры того что мы могли сделать: настроить NTFS права на файлы и папки, разрешить или запретить выключение питания компьютера, регулировать запуск служб, контролировать принадлежность пользователяк группам безопасности и многое другое.

          4. Административные шаблоны – черный блок на рисунке 1. Непосредственная настройка самой операционной системы и ее компонентов ложилась на административные шаблоны. Фактически они являлись текстовыми файлами, в которых было прописано, какие параметры реестра должны быть применены на клиенте. Сразу после установки мы уже имели пять различных шаблонов, каждый из которых отвечал за свои параметры. Например, шаблон «Inetres.adm» позволял конфигурировать параметры обозревателя Internet Explorer.

          image

          Рис. 1 Объект групповой политики Windows Server 2003

          В итоге все выглядело следующим образом, безопасность и права настраивались через «Параметры безопасности», настройка системы и ее компонентов производилась через административные шаблоны, если этого было недостаточно, оставалась возможность скачать дополнительные шаблоны или создать собственный шаблон. Все, что не удалось сделать этими способами, делалось через скрипты.

          Как стало в Windows 2008.

          В принципе данная логика остается и в Windows Server 2008, за одним исключением, при создании объекта групповой политики в Windows Server 2008 у вас появляется новый блок, в русских версиях ОС он звучит как «Настройка». (Рис.2).

          Собственно говоря, это и есть решение бывшей «Desktop Standard» интегрированное в новой серверной операционной системе. Данный блок «Настройка» предназначен для расширенного администрирования компьютеров без использования скриптов.

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

          image

          Рис.2 Новый блок при создании GP (англ. – GP Preferences)

          Для начала давайте ответим на вопрос: В какие моменты происходит применение групповых политик?

          Первым моментом является загрузка компьютера, второй это вход пользователя на компьютер, третий фоновое обновление (когда человек уже работает, раз в 90-минут происходит обновление и новые параметры вступают в силу, за исключением параметров требующих выхода из системы или перезагрузки) и последний момент при выполнении команды «gpupdate».

          Примечание: 90 минут является значением по-умолчанию для параметра фонового применения GP, значение этого параметр можно менять.

          Применение нового блока (давайте называть его GP Preferences) осуществляется точно также.

          Разница заключается в следующем. Если GP применяется каждый раз в вышеописанных ситуациях и при изменении параметров на клиентском компьютере приводит все в соответствии с политикой, то параметры «GP Preferences» можно настроить на выполнение как постоянно, так и только один раз.

          Простой пример: вы меняете параметр через GP, пока политика применена этот параметр проверяется каждый раз при загрузке и входе. Если вдруг пользователь поменял этот параметр после входа на компьютер, то через 90 минут действия пользователя будут затерты, и параметр будет иметь значение в соответствии с политикой. Если вдруг вы отключите политику, параметр вернется на то значение, которое он имел По-умолчанию.

          А вот при передаче параметра через «GP Preferences» у вас есть выбор либо применять этот параметр каждый раз, т.е будет действовать классическая схема «принуждения» описанная выше, либо применить его один раз. Соответственно при однократном применении пользователь получит результат, но сможет его поменять и измененное значение останется,

          т.к повторного применения не будет. Плюс к этому отключение политики, где настроены «GP Preferences» не приведет к возвращению на параметры По-умолчанию.

          Не стоит забывать, что «GP Preferences» делятся на часть, которая применяется к пользователям и часть, которая применяется к компьютерам. Т.е здесь все, как и у классических политик. Рис.3

          image

          image

          Рис.3 Часть «GP Preferences» применяемая для объектов компьютер (слева) и часть, применяемая для объектов пользователь. (справа)

          Следующей особенностью является ориентация нового блока «GP Preferences» на выполнения действия, то, что изначально делалось только скриптами: создать папку, создать ярлык, открыть общий доступ к папке, создать локального пользователя и тому подобное.

          Попробуем в «GP Preferences» в деле.

          Я предлагаю для лучшего понимания данной темы, решить практическую задачу с использованием «GP Preferences».

          Вводная информация для задачи такая:

          На сервере «Win2008-DC», который является контроллером домена, есть папка с общим доступом «Intro Docs», в этой папки находятся документы, которые должны прочитать сотрудники в первый рабочий день. Нужно, чтобы при первом входе на компьютер, у нового сотрудника на диск «C:» была скопирована данная папка, на рабочий стол пользователя добавлен к ней ярлык. После ознакомления сотрудник должен иметь возможность удалить и папку и ярлык. Вот и все. Может быть данная ситуация не совсем логична с жизненной точки зрения, но для проверки работы «GP Preferences» этого будет достаточно.

          Прежде чем приступить к выполнению задачи, давайте уясним одну вещь. С помощью «GP Preferences» можно управлять следующими операционными системами:

          · Windows XP with SP2

          · Windows Vista

          · Windows Server 2003 with SP1

          · Windows Server 2008

          И на каждой из управляемых систем (кроме Windows Server 2008) нужно установить клиентскую часть «Group Policy preferences clientside extension» или сокращенно CSE. Для всех из данного списка операционных систем доступна своя версия CSE. Скачать CSE можно с сайта Microsoft

          Важно: Пока CSE не установлены на управляемом компьютере параметры «GP Preferences» применяться не будут.

          Итак, переходим к выполнению задачи:

          1. В первую очередь я скачал CSE для Windows Vista и установил на все компьютеры.

          2. После этого на сервере «Win2008-DC» создал папку «Intro Docs» , открыл к ней общий доступ и наполнил документами.

          3. Поскольку «GP Preferences» являются частью объекта групповой политики, нам будет необходимо создать и применить такой объект. В моем тестовом домене создано организационное подразделение «Moscow», в которое вложены два других организационных подразделения. «Computer» – где хранятся объекты компьютеров и «User» с объектами пользователей. (Рис.4)

          image

          Рис.4 Структура организационных подразделений.

          4. Используя оснастку «Управление групповой политикой» я создаю объект групповой политики и связываю его с организационным подразделением Moscow.

          Назову его «TEST GP Pref». Политика создана, остается ее настроить. (Рис.5)

          image

          Рис.5 Создание GPO

          5. Открываем «TEST GP Pref» для редактирования и перед нами встает вопрос: «Какую часть GP Preferences редактировать? Для пользователя или для компьютера». Я считаю, что в нашей ситуации будет правильно редактировать «Конфигурацию пользователя». В зависимости от того что мы выберем наша политика будет действовать по-разному. Если применим настройки в «Конфигурации пользователя», то на первый же компьютер, на который зайдет пользователь, будет скопирована папка «Intro Docs» и создан ярлык. В последующие заходы данного пользователя на этот или другие компьютеры ничего создаваться не будет. Если применим настройки в «Конфигурации компьютера» то при первой загрузке будет создана папка «Intro Docs» и ярлык и абсолютно не важно, будет ли кто на него входить или нет. Я надеюсь, разницу вы поняли.

          image

          Рис.6 Редактирование GPO

          6. Разворачиваем «Конфигурацию пользователя – Настройка – Конфигурация Windows –Файлы». Щелкаем правой кнопкой мыши на пустом месте и выбираем «Создать» – «Файл». Сейчас перед нами стоит задача настроить копирование папки «Intro Docs» на клиента при первом его входе. Для этого в появившемся окне выбираем действие «Создать» (Рис.7) , в поле «Исходные файлы» вводим путь к папке на сервере, по окончанию пути ставим звездочку, это говорит о том, что из папки нужно копировать все файлы. В поле пути конечной папки указываем, в какой папке на клиенте должны появиться эти файлы. Если папка в момент применения политики не существует – она будет создана! Обратите внимание, что я при указании конечной папки использовал переменную %SystemDrive% которая означает что папка должна находиться в корне на системном диске, т.е на диске где стоит Windows. Если вы не помните, какие переменные используются в Windows, достаточно поставить курсор в поле ввода и нажать клавишу «F3» , перед вами появится окно с переменными, где можно будет выбрать нужную. (Рис.8) Указывая переменные вместо жесткого указания пути, (т.е C:\Intro Docs) вы страхуете себя от нештатных ситуаций. (Например, отсутствие раздела с буквой C:)

          image

          Рис.7 Создание действия в «GP Preferences»

          Но это еще не все, нам необходимо убедиться, что данное действие будет осуществлено только единожды для каждого пользователя. Поэтому переходим на закладку «Общие параметры» (Рис.9) и ставим галочку напротив настройки «Применить один раз и не применять повторно» и нажимаем «Ок»

          Что произойдет в результате применения данной настройки?

          При первом входе пользователя на компьютер будет проверено, существует ли на системном диске папка «Intro Docs», если ее нет, она будет создана и после чего в нее будут скопированы файлы с общей папки по адресу «\\Win2008-DC\Intro Docs\». После применения политики и создания файлов и папки, пользователь сможет сделать с ней все что угодно в рамках данных ему прав, повторно папка создаваться не будет.

          image

          Рис.8 Меню с переменными.

          image

          Рис.9 Настройка закладки общие параметры.

          Первую часть задания мы выполнили, теперь необходимо сделать ярлык на эту папку и положить его на рабочий стол этому же пользователю. Для этого там же в ветке «Конфигурации Windows» выбираем «Ярлыки», щелкаем правой кнопкой мыши на пустом месте и выбираем «Создать».

          image

          Рис. 10 Создание ярлыка.

          В поле «Имя» вводим имя нашего ярлыка, в типе объекта оставляем «Объект файловой системы», в «Размещении» – указываем «Рабочий стол». Но если хотите, чтобы ярлык появился в каком-то другом месте, можете поэкспериментировать.

          «Конечный путь» – путь, к которому будет вести наш ярлык. Прописываем здесь %SystemDrive%\Intro Docs, т.е ярлык будет указывать на папку «Intro Docs» на системном диске клиента.

          В поле «Путь к значку файла» можете нажать на троеточие «» и выбрать иконку для вашего ярлыка. После чего нажимаем «Ок»

          Задача выполнена. Остается обновить политику на клиенте и проверить появление ярлыка на рабочем столе и папки Intro Docs на системном диске клиента.

          На что еще следует обратить внимание при создании действия.

          Когда вы создавали файлы, то при выборе действия у вас было 4 варианта.

          «Создать» – «Заменить» – «Обновить» – «Удалить»

          Если по первому и последнему все я думаю понятно. На нашем примере «Создать» создает файлы путем копирования с сервера, а «Удаление» позволило бы очистить папку Intro Docs.

          То действия «Заменить» – «Обновить» не столь очевидны.

          Особый интерес представляет фильтрация применения «GP Preferences».

          Если вы помните, в Windows Server 2003 мы могли фильтровать применение групповой политики несколькими способами, самой распространенной была и остается фильтрация путем применения GP к разным организационным подразделениям. Если же мы хотели фильтровать применение GP в рамках одного организационного подразделения, то могли использовать WMI-фильтры или запрещать применение политики путем фильтров безопасности. Осуществлять фильтрацию, по каким-то признакам клиента можно было только с помощью WMI-фильтров и было это достаточно сложно.

          В Windows 2008 фильтрация «GP Preferences» выглядит поистине сказочно. Кто не верит на слово, предлагаю взглянуть на Рис.11

          image

          В «Нацеливании» (а именно так называется фильтрация «GP Preferences») есть если не все, то очень многое. Добавьте к этому «Нацеливание» по каждому элементу, а на всей политики разом и вы получите «Мечту системного администратора». Подробнее в видео-приложении.

          Вывод.

          Инструмент для работы получился отменный. Когда смотришь на подобные решения, действительно веришь в снижении стоимости обслуживания новых версии операционных систем от Microsoft. Следует заметить что «GP Preferences» можно установить и на контроллер домена под управлением Windows Server 2003, после чего задействовать данную возможность для управления сетью. Позвольте ответить на вопрос: Почему ты до этого об этом молчал?

          На последней встрече с архитекторами Microsoft зашел разговор о «GP Preferences» и я поинтересовался, почему они умалчивают возможность использования «GP Preferences» без покупки Windows Server 2008, на что я получил конкретный ответ: «Да, установить данную вещь на Windows Server 2003 можно и это будет работать. Но, работа «GP Preferences»на Windows Server 2003 компанией Microsoft не поддерживается, мы это выпустили, а вы хотите, используйте, хотите, нет». Вот собственно и причина моего молчания.

          Некоторые моменты в статье я осознанно опустил. Данная статья является экспериментальной. Она состоит из данного документа и видео-приложения.

          Скачать видео-демонстрацию.

          Рудь Илья

          MCSE/MCT

          me@rudilya.ru

        • Главная Windows, Новое Active Directory
          • Восстановление удаленных доменных учетных записей в Windows 2003/2008/2008R2

            • Рубрика: Windows,Новое
            • Автор: Илья Рудь
            • Дата: Friday 27 Mar 2009

            Снимок Темы, посвященные резервному копированию, я всегда начинаю с шутки: «Системные администраторы делятся на две группы, те которые уже делают резервные копии и те которые еще не делают». На самом деле эта шутка «Со слезами на глазах». В бытность работы начинающим системным администратором я потерял по собственной халатности несколько файлов и помню чувство, которое испытал в процессе вызова «на ковер». Никому такое не пожелаешь. Но несколько файлов это все же не так страшно как полная потеря вашей инфраструктуры и остановка фирмы. Сегодня я не буду говорить непосредственно о резервном копировании, вместо этого мы рассмотрим варианты восстановлении самого важного для Windows сетей, (После баз данных) – Active Directory, восстановление её объектов без наличия резервной копии.

            Active Directory используют сотни тысяч компаний по миру, но поверьте, грамотно разбираются в восстановлении AD единицы системных администраторов. То, что я буду рассказывать, уже неоднократно печаталось. Но, я попытался сделать более серьезную работу. Во-первых, постарался донести материал максимально понятно. Во-вторых, объединить в статье информацию о Windows 2003, Windows 2008 и Windows 2008R2 Beta.

            Запаситесь временем, оно вам понадобится. Но та польза, которую вы получите, подробно разобравшись в тексте статьи, с лихвой его окупит.

            Если я удалил из Active Directory нужного пользователя (группу или компьютер)? Что мне делать?

            Такой вопрос я часто слышу на своих курсах. Действительно, что же делать. Давайте подумаем, мы можем создать нового пользователя и назвать его точно также как и удаленного. Поможет ли?

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

            И все это по одной простой причине, каждый объект Active Directory содержит дополнительную информацию, не видимую простому пользователю. Этой информацией является SID объекта. Что же это такое. Для начального понимания предлагаю пример из жизни. Налоговая Инспекция Российской Федерации должна отличать каждого налогоплательщика в стране. Но как быть, если в Стране тысячи Ивановых Иванов Ивановичей, как распознать, кто есть кто. Очень просто выдать каждому по уникальному номеру. Проблема решена. Похоже, решается и проблема уникальности в Active Directory.

            Security Identifier (SID) это идентификатор безопасности, который уникально идентифицирует, учетную запись пользователя, группы или компьютера. (Проще говоря, уникальный номер)

            SID присваивается каждой учетной записи в момент её создания. Система работает с SID’ами учетных записей, а не их именами. В контроле доступа пользователей к защищаемым объектам (файлам, ключам реестра и т.п.) участвуют также только SID’ы.

            Может возникнуть вопрос – Я же вижу имена учетных записей при настройке прав к папке на диске с файловой системой NTFS. Где там SID`ы?

            Отвечу очень просто, вы видите это, потому что работать непосредственно с SID было бы очень неудобно. Компьютер облегчает вам задачу и показывает имена, а не SID`ы.

            Пример SID’ a (S-1-5-21-1986275044-495590890-615916108)

            Попробуйте запомнить два десятка таких 🙂

            Вернемся к главной теме.

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

            На этом моменте мы откинем мысли о повторном создании учетной записи и попытаемся разобраться в том, существуют ли более «гуманные» способы вернуть учетную запись.

            Для того, чтобы ответить на этот вопрос, надо разобраться с тем, что происходит после того как вы нажали «Удалить» и объект пользователя или компьютера исчез из оснастки Active Directory User and Computers. Сразу хочу обрадовать, наш объект не исчез из Active Directory и не удалился бесследно. Он спрятался и ждет, ждет, пока вы одумаетесь и вернете его. Сразу вопрос, сколько же он будет ждать?

            Ответ, это зависит от того на базе каких версий Windows Server построена ваша Active Directory.

            Срок ожидания равен (это параметр правильно называется «tombstoneLifetime»):

            60 дням для лесов, построенных при помощи Windows® 2000 и Windows Server 2003

            180 дней для лесов, построенных при помощи Windows Server 2003 SP1, Windows Server 2008/R2

            Что самое интересное, «tombstoneLifetime» (давайте называть вещи своими именами, теперь мы знаем что значит данный термин) это параметр на который вы можете влиять, т.е давать ему значение по своему усмотрению.

            Посмотреть текущее значение «tombstoneLifetime» и поменять его можно следующим способом.

            Вам понадобится оснастка ADSI Edit.

            image

            Рис. 1. Открываем оснастку и выбираем “Connect to..

            image

            Рис. 2. Подключение.

            В показанном на рисунке 2 окне, выбираем «Select or Type a Distinguished Name» и в пустом поле вводим путь «CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=<корневой домен>». Где <корневой домен> это имя вашего домена.

            Мой домен назывался – testlab.local и строка пути выглядела следующим образом:

            «CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=testlab,DC=local»

            После ввода нажимаем “OK” и если вы все сдали правильно, в оснастке появится новый контекст именования, который нам необходимо развернуть и зайти в свойства введенного пути.

            image

            Рис. 3. Заходим в свойства введенного пути.

            image

            Рис. 4. Изменение атрибута «tombstoneLifetime»

            В открывшемся меню находим атрибут «tombstoneLifetime» , как вы видите на моем контроллере домена под управлением Windows Server 2008 R2 Beta, он равен 180 дням.

            Сделаем второй вывод: Теперь мы не только точно можем узнать, сколько будет храниться в нашей базе данных удаленный объект, но и изменить это время по своему желанию. Ради справедливости следует заметить, что делать это практически нет необходимости. Как только объект устаревает, т.е находится в удаленном состоянии более срока «tombstoneLifetime», он удаляется из базы данных и больше вы не сможете его восстановить. Т.е любые операции по восстановлению только до истечения срока «tombstoneLifetime», позже нельзя. Запомните это.

            В некоторых статьях в интернете и некоторых книгах приводятся способы восстановления объектов Active Directory после истечения срока «tombstoneLifetime», относитесь к этому как к трюкам экстремалов, как к высшему пилотажу. В определенно отведенном месте это имеет место быть, в городских или в вашем случае рабочих условиях неподготовленный человек просто свернет голову, а вы потеряете всю Active Directory.

            Отлично со временем «загробной жизни» наших объектов мы разобрались. Теперь необходимо понять где находятся наши объекты после удаления и до того как они окончательно исчезнут.

            После удаление объекты попадают в контейнер «Deleted Objects». Не пытайтесь увидеть его содержимое через оснастку Active Directory User and Computers. У вас это не получится. От глаз «простых смертных» он надежно спрятан. 🙂

            Для того чтобы все-таки увидеть сам контейнер и те объекты, которые были удалены нам понадобится одна из двух вещей. Либо служебная программа «LDP», схожая с проводником Windows, для работы с Active Directory, либо утилита «Ad Explorer» из комплекта легендарных утилилит Sysinternals. Ни одна, ни вторая не установлена при новой инсталляции Windows Server 2003. В Windows Server 2008 и 2008R2 программа «LDP» входит изначально.

            LDP можно получить установив на свой сервер Windows 2003 Support tools, комплект утилит, свободно скачиваемых с сайта Microsoft.

            Утилита «Ad Explorer» доступна свободного скачивания с Веб-узла Windows Sysinternals.

            Я воспользуюсь «Ad Explorer» так как, на мой взгляд, для данной цели она более дружелюбна.

            image

            Рис. 5. Подключение через утилиту AdExplorer.

            Запустив AdExplorer, вы сразу сталкиваетесь с окном, предлагающим вам ввести имя домена, к которому вы хотите подключиться, а также имя Администратора и его пароль. Вводим, нажимаем «ОК».

            После разворачиваем раздел нашего домена и видим скрытый до этого контейнер «Deleted Objects».

            image

            Рис. 6. Контейнер Deleted Objects

            Разворачиваем контейнер Deleted Objects и не пугаемся количеству объектов хранящихся в нем, в моем примере, я легко нахожу удаленную запись пользователя Bill Gates по иконке и имени. (Рис.7.)

            Теперь перед нами возникает другая проблема, как вернуть учетную запись обратно в оснастку “Active Directory User and Computers” и позволить пользователю полноценно работать, что он, собственно говоря, и делал до удаления. И опять перед вами есть два пути.

            Первый путь является более сложным и предназначен для администраторов хорошо знакомых с алгоритмом удаления/ восстановления объектов Active Directory. Путь пролегает через использование уже знакомой вам утилиты Ldp.exe.

            Суть процесса выглядит следующим образом. При удалении и попадании учетной записи в «Deleted Objects » к имени пользователя добавляется DEL , а также в атрибутах объекта пользователь атрибут «isDeleted» переходит в состояние TRUE, что значит истина, а на языке простых смертных состояние включен. Соответственно что бы учетка вернулась в нормальное состояние, нам необходимо используя Ldp.exe выключить этот атрибут и заменить то, что имеем на нормальное имя. Повторюсь еще раз это более сложный путь, и я его описывать не буду. Для тех, кто выбирает сложные есть Google и встроенная справка.

            image

            Рис.7. Удаленный объект в Deleted Objects

            image

            Рис. 8. Adrestore

            Мы пойдем по второму пути, а именно воспользуемся утилитой командной строки от Sysinternals под названием «AdRestore». Не путайте, пожалуйста, с «AdExplorer» у них похожие названия, но разное назначение. У кого данной утилиты еще нет, скачиваем ее с сайта Microsoft. Распаковываем данную утилиту на диск C:\ и запускаем с командной строки.

            Синтаксис команды достаточно простой, чтобы восстановить пользователя Bill Gates я ввел утилиту с ключом “-r” и явно указал имя пользователя для восстановления. Если вы хотите посмотреть полный список доступных объектов, вводите AdRestore без ключа.

            Итак, объект восстановлен, теперь мы можем его обнаружить в оснастке «Active Directory User and Computers»

            image

            image

            Рис. 9 Пользователь после восстановления.

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

            Теперь я могу сформулировать третий вывод. При удалении учетной записи и помещения ее в контейнер Deleted Objects теряются все атрибуты записи, кроме SID, ObjectGUID, LastKnownParent и SAMAccountName и при возвращении записи, указанным способом они не восстанавливаются. В том числе и пароль пользователя.

            Что такое SID вы уже знаете, ObjectGUID это еще один идентификатор нашего объекта, LastKnownParent это путь контейнеру в котором находился объект до удаления, а SAMAccountName – имя для входа пользователя. Все остальное, увы, так легко не вернется.

            Поэтому вам придется сменить пароль, включить учетную запись и заново ввести все атрибуты.

            В статье Джил Киркпатрика (Gil Kirkpatrick) под названием «Восстановление объектов-захоронений Active Directory» есть краткое описание того, что мы может путем некой манипуляции заставить атрибуты объектов сохраняться при удалении. И естественно при восстановлении они также будут доступны. Я пойду дальше и распишу этот процесс. Сразу скажу, что атрибуты уже удаленных записей это не вернет.

            План наших действий будет такой:

            1. Откроем оснастку ADSI Edit

            2. Выберем «Подключиться к» или «Connect to»

            3. В появившемся окне выбрать подключение к разделу Схема нашей Active Directory

            4. Найти нужный нам атрибут и зайти в его свойства.

            5. В свойствах атрибута найти параметр «searchflags»

            6. Включить третий бит в значении параметра «searchflags»

            Пугаться плана не стоит, сейчас мы подробно разберемся в данном процессе. Я буду выполнять данную операцию на Windows Server 2008R2 Beta, но на младшей версии Windows Server 2003 процесс будет аналогичным.

            image

            Рис.10 Запускаем ADSI Edit и выбираем «Connect to»

            image

            Рис 11. В появившемся окне выбираем подключение в Схеме Active Directory. (Schema)

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

            image

            Рис. 12 Список атрибутов.

            Я приведу пример соотношения имен в свойствах объекта и схеме следующей иллюстрацией, созданной Ильей Сазоновым в его блоге. Если вы хотите посмотреть полную картину соотношений, то советую перейти по следующей ссылке.

            http://msdn.microsoft.com/en-us/library/ms677980(VS.85).aspx

            image

            Рис.13 Имена атрибутов Active Directory в схеме. (Указаны красным цветом)

            Проверять данную процедуру я буду на атрибуте Company (Компания). В данном случае имя атрибута в схеме такое же. Для того чтобы найти в длинном списке нужный нам атрибут, необходимо поставить курсов мыши на любой из атрибутов и начать набирать с клавиатуры:

            CN= company

            Причем набирать необходимо быстро и необязательно полностью, набрав например «CN= com» вы попадете на список атрибутов начинающихся с «com» и легко отыщите нужный.

            image

            Рис.14 Поиск нужного атрибута.

            После нахождения нужного атрибута открываем его двойным щелчком мыши и на закладке «Attribute Editor» ищем параметр «searchflags». У каждого атрибута он свой и представлен десятичным числом. В моем случае «searchflags» равен 16.

            image

            Рис. 15 Параметр «searchflags» для атрибута «Company»

            Если вы вернетесь на пару страниц вверх к списку того, что нужно сделать для сохранения атрибута при удалении, то увидите, что остался один пункт «Включить третий бит в значении параметра «searchflags»»

            Для того чтобы перевести десятичное число 16 в двоичное я воспользуюсь инженерным калькулятором. В двоичном виде я получил «100000». Что значит включить третий БИТ? Значит, третий бит должен быть равен «1»

            Находим третий бит. Считаем справа на лево.

            «1 0 0 0 0 0»

            Первый справа 0-й бит

            Второй справа 1-й бит

            Третий справа 2-й бит

            Четвертый справа 3-йбит. Тот, который нужно включить.

            Меняем его на «1» и получаем в двоичной системе «101000», что и переводим десятичную систему тем же инженерным калькулятором. Получаем «40». И именно эти «40» и ставим в значении «searchflags». Нажимаем «Ок» и закрываем все лишнее. Теперь для проверки правильности действий, вы можете создать новую учетную запись и ввести атрибут «Company». После чего ее удалить и восстановить с помощью утилиты «Adrestore». При правильном выполнении вышеописанной процедуры при восстановлении учетной записи атрибут «Company» не будет потерян.

            Вывод третий. Да, мы можем прописать параметр «searchflags» и при восстановлении объекта Active Directory эти атрибуты теряться не будут. НО, следует помнить, что есть особенные атрибуты описывающий членство нашего пользователя в группах Active Directory. К сожалению, подобным образом защититься от его удаления нельзя. Существует способ восстановления членства в группах, но в данной статье он рассмотрен не будет, т.к требует знакомства еще с рядом понятий.

            А сейчас я бы хотел перейти к новой возможности, которая стала доступна с выходом Windows Server 2008 R2 под названием «Active Directory Recycle Bin»  или Корзина удаленных объектов. Она предназначена для решения как раз наших проблем.
            Для начала немного теории.  Жизненный цикл цикл объекта  «Active Directory»  в любой версии Windows Server выглядит одинаково. (Рис.16) Разница лишь в сроке хранения захороненного объекта. (tombstoneLifetime). По умолчанию в Windows Server 2008 R2 «Active Directory Recycle Bin»   отключена.

            image

            Рис. 16 Жизненный цикл объекта Active Directory.

            При включении «Active Directory Recycle Bin» схема удаления несколько меняется. Главное преимущество которое мы получаем, это возможность восстановить удаленный объект с сохранением все атрибутов без перезагрузки и резервной копии. («типа link-valued» – как пример «Членство в группах» и «типа non-link-valued» – как пример «Компания»)

            image

            Рис. 17 Жизненный цикл объекта Active Directory при включенной «Active Directory Recycle Bin».

            При включенной корзине после удаления объекты также попадают в контейнер «Deleted Objects», но теперь с сохранением всех атрибутов, объекту присваивается статус «logically deleted» и находятся, он в таком состоянии в течение определенного времени, на схеме время показано как «Deleted object lifetime». Пока не истекло это время, вы можете спокойно восстановить объект из корзины без каких либо последствий.

            По прошествии времени «Deleted object lifetime», у объекта меняется статус на «recycled object» и большинство его атрибутов удаляется. После чего он продолжает храниться в течении «Recycled object lifetime» промежутка. По окончании, которого он удаляется из базы.

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

            Необходимо:

            a) Убедить, что все контроллеры домена в лесу работают под управлением Windows Server 2008 R2

            b) Поднять уровень нашего леса до Windows Server 2008 R2

            c) Если лес изначально создавался на базе Windows Server 2003 – осуществить обновление схемы

            Примечание: Для обновления схемы: выполнить adprep /forestprep на контроллере домена с ролью «schema master», выполнить adprep /domainprep /gpprep на контроллере домена с ролью «infrastructure operations master». Если есть контроллер домена только для чтения (RODC) запустить на нем adprep /rodcprep.

            Ну что ж, теперь давайте проверим новый функционал. В моей лабораторной среде только один контроллер домена под управлением Windows Server 2008 R2, так что подготовительные пункты а) и с) я опускаю. Первый по причине отсутствия других контроллеров домена, второй поскольку я поднимал лес на Windows Server 2008 R2 изначально.

            Но поднятие уровня леса мне придется осуществить. На текущий момент мой уровень леса стоит По-умолчанию Windows Server 2008. Можете осуществить поднятие классически через оснастку «Active Directory Domain and Trust», а можно воспользоваться Active Directory PowerShell.

            image

            Рис.18 Поднятие уровня леса (Click Start, click Administrative Tools, right-click Active Directory PowerShell)

            При этом необходимо выполнить:

            Set-ADForestMode –Identity testlab.local -ForestMode Windows2008R2Forest

            Постойте! Скажут те из вас кто хорошо знаком с Active Directory. Ведь для поднятия леса нам необходимо сначала поднять уровень домена? Да, в Windows Server 2003 вам нужно было сделать именно так. В Windows Server 2008 R2 автоматически поднимает уровень доменов, упрощая достижение цели на несколько кликов мышью.

            Все предварительные этапы пройдены и теперь мы готовы включить «Active Directory Recycle Bin». Сделаем это опять же из «Active Directory PowerShell» выполнив командлет:

            Enable-ADOptionalFeature –Identity  ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=testlab,DC=local’   –Scope Forest  –Target ‘testlab.local’

            image

            Рис. 19 Включение «Active Directory Recycle Bin»

            Естественно при выполнении команд не забудьте поменять имя домена, заменив testlab.local на имя вашего домена.

            Теперь задача выполнена и «Active Directory Recycle Bin» работает.

            Что хотелось бы отметить:

            А) Приятного графического способа работы с «Active Directory Recycle Bin» на текущий момент нет. Майкрософт рекомендует два способа работы с корзиной. Первый через утилиту Ldp.exe. Второй через командлеты «Get-ADObject-Filter» и «Restore-ADObject» .

            Б) Лично я использовал для восстановления объектов утилиту “AdRestore”. При включенной корзине все атрибуты и пароль пользователя восстановились вместе с учетной записью.

            В) Время, выделяемое на «Deleted object lifetime» и «Recycled object lifetime» можно менять. Если время «Deleted object lifetime» не задано явно, а по умолчанию оно не задано, то равно продолжительности параметра «tombstoneLifetime», т.е 180-и дням. Остается еще один параметр «Recycled object lifetime» – период времени, когда атрибуты уже уничтожены, но объект еще существует, при определении этого времени используется параметр «tombstoneLifetime». Именно в нем это время и прописывается.

            Итоги:

            Прежде всего, хотелось бы отметить, что Active Directory имеет механизм восстановления учетной записи без перезагрузки контроллера домена в режим «Восстановления Службы Каталогов» и остановки его работы. В Windows Server 2008 R2 это механизм был усовершенствован с помощью «Active Directory Recycle Bin», при этом решена проблема сохранения атрибутов удаленных объектов. Конечно, у вас могу остаться вопросы. А что будет, если пользователь имел Exchange-атрибуты? Что станет с теми учетными записями, которые были удалены до включения корзины? Что еще можно восстановить таким способом? Ответы на них каждый желающий может найти на сайте technet.microsoft.com или проведя несколько лабораторных работ, развернув на виртуальном стенде несложную инфраструктуру. И напоследок старые добрые советы: не работайте с правами доменного администратора, используйте делегирование прав, читайте документацию и отключайте учетные записи вместо удаления. Удачи.

            Рудь Илья

            MCSE/MCT

            me@rudilya.ru