• Юридические аспекты информационной безопасности

    • Рубрика: Security,Новое
    • Автор: Владимир Безмалый
    • Дата: Tuesday 07 Apr 2009

    law Сегодня я хотел бы поговорить с вами о весьма волнующей меня проблеме. Думаю, что в  большинстве предприятий весьма и весьма актуальной является задача контроля электронной переписки своих сотрудников. Тема не простая. Обеспечить ее техническими средствами, создав архив входящих/исходящих писем и обеспечив его целостность, не так уж и сложно.
    Однако здесь мы с вами упираемся в законность своих пожеланий, а именно. Конституция Украины гарантирует тайну переписки. Заметьте, не частной, а переписки вообще! Что это значит для нас с вами?
    Формально – мы не можем читать почту сотрудников, так как нарушаем Конституцию. Более того, даже если вы обнаружите доказательства преступлений, то формально это доказательством не является, ведь добыто с нарушением закона. Что делать?
    На разных форумах предлагают брать расписки с сотрудников, о том, что они не возражают против чтения электронной почты. Простите, но охарактеризовать это другим термином кроме БРЕД, причем в тяжелой форме, я не могу! В любой момент сотрудник может отказаться  от этой бумаги, а так как вы нарушаете Конституцию, то виноваты вы! Это однозначно и в дополнительных доказательствах не нуждается!
    Однако, а что же все таки делать? Вразумительного ответа украинские, впрочем, и российские юристы, увы, не дают!
    На мой взгляд, можно в инструкции при приеме на работу указывать, что вся информация, обрабатываемая на компьютерах фирмы информация принадлежит фирме, а следовательно, руководство компании может в любой момент времени ознакомиться с этой информацией само или поручить это соответствующему сотруднику.
    Таким образом, в любой момент времени компьютер ЛЮБОГО сотрудника может быть изъят на проверку. Соответственно, просмотрено может быть содержимое электронного почтового ящика любого сотрудника.
    Так как информация принадлежит фирме, то и просматривать СВОЮ информацию руководство может в любой момент времени. А вы как считаете?

    • Восстановление контроллера домена 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

      • Эксперимент: Виртуализация и виртуальные жесткие диски

        • Рубрика: Virtualization,Новое
        • Автор: Александр Косивченко
        • Дата: Wednesday 01 Apr 2009

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

        Заметнее всего падение быстродействия – при виртуализации серверов, очень активно обращающихся к жестким дискам: например – серверов баз данных, почтовых серверов. Здесь уже приходится идти на хитрости ради того, чтобы выиграть пару-тройку лишних IOps’ов.

        Рассмотрим работу с жесткими дисками в среде Hyper-V.

        1. VHD-файлы

        Наиболее известный способ, выбираемый по дефолту: использование в качестве дисков для виртуальной машины – файлов *.vhd (Virtual Hard Disk). Этот способ имеет три преимущества:

        • VHD-файлы могут храниться где угодно и могут быть легко перемещены;
        • Удобство создания резервных копий: копирование одного большого файла – намного легче и быстрее, чем копирование всего содержимого жесткого диска (VHD-файл может быть легко скопирован средствами VSS, без остановки самой виртуальной машины, а в случае бэкапа содержимого физического диска – может потребоваться перезагрузка как минимум гостевой ОС);
        • Рациональное использование дискового пространства: на одном физическом диске может храниться множество VHD-файлов, и каждой виртуальной машине можно отвести ровно столько дискового пространства, сколько ей необходимо

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

        2. Прямое обращение к физическому диску

        Hyper-V, помимо использования VHD-файлов – предоставляет возможность использования виртуальной машиной физических дисков. Плюс тут один: более высокое быстродействие в сравнении с VHD-файлами. Минусов же больше:

        • Немного сложнее создавать резервные копии и переносить информацию в другое место;
        • Менее рациональное использование дискового пространства (весь объем диска используется одной виртуальной машиной, не может регулироваться динамически и распределяться между несколькими виртуалками);

        Ну а теперь – перейдем от теории к практике.

        Эксперимент.

        В качестве экспериментального стенда использовался сервер HP ML150G5, снабженный четырёхъядерным процессором Intel® Xeon® E5420 2,5 ГГц и 4Гб оперативной памяти. Дисковая подсистема представлена двумя дисками объемом 72Гб с интерфейсом SAS, объединенными в массив RAID1 и двумя SATA-дисками объемом 250Гб, так же объединенными в RAID1. На сервере установлена ОС Microsoft Windows Server 2008 Std. 64bit с поддержкой Hyper-V. Других задач, помимо виртуализации у него нет. Далее – все эксперименты, о которых я буду писать в этом блоге – будут проводиться именно на этом сервере.

        Для чистоты эксперимента все действующие ВМ были остановлены, и создана новая ВМ с 512Мб ОЗУ и двумя жесткими дисками: один – для установки гостевой ОС, другой – для эксперимена. На ВМ была установлена ОС Microsoft Windows Server 2003 32bit, были установлены компоненты интеграции. Для создания нагрузки на диски и измерения параметров быстродействия была использована бесплатная утилита IOMeter. Параметры доступа к диску в IOMeter были заданы следующие:

        • Объем страницы: 64Кб;
        • 75% – случайный доступ, 25% – линейный;
        • 75% – чтение, 25% – запись.

        Опыт первый: VHD-файл.

        Как я уже писал выше, экспериментальная ВМ имеет два виртуальных жестких диска: на один устанавливается ОС, другой – используется для измерения быстродействия. В первом моем опыте я использовал VHD-файл фиксированного размера 10Гб. Файл размещался на зеркале из двух 250Гб SATA-дисков. Я получил следующие результаты:

        • Total I/O per sec: 111,5
        • Total MB per sec: 6,92
        • Average I/O Response Time: 9,0152 ms
        • Maximum I/O Response Time: 526,0630 ms

        Результаты сильно удручают: 7Мбайт в секунду – это очень и очень мало. Для примера, в хостовой ОС, копирование файла с одного массива на другой показывало скорость порядка 37-40Мбайт/c. Правда, это показания самой ОС, которые могут и не соответствовать действительности. Увы, судя по сайту разработчиков – последняя версия IOMeter’а вышла 27 июля 2006 года, так что не удивительно, что под Windows Server 2008 она хоть и запустилась, но корректно не работала: она просто не “видела” жесткие диски. Если кто-нибудь посоветует мне более новую утилиту, аналогичную IOMeter и нормально работающую под Windows Server 2008 – с меня пиво 🙂

        Время отклика – тоже очень и очень плохое: 9 миллисекунд в среднем, и 526 миллисекунд (просто вдумайтесь в это: больше, чем пол-секунды!) максимум. Вобщем – для, к примеру, веб-сервера вполне бы сгодилось, но устанавливать с таким быстродействием, к примеру, сервер БД какой-нибудь ERP-системы я бы не рискнул.

        Опыт второй: прямое обращение к диску.

        Теперь я удалил злосчастный VHD-файл и перевел наш 250Гб массив в режим Offline через консоль Computer Management (это – необходимое условие, чтобы Hyper-V “увидела” наш диск и его можно было бы подключить к ВМ). После этого – в свойствах тестовой ВМ вместо VHD-файла был подключен наш физический диск и так же – запущен IOMeter c теми же параметрами. Результаты получились следующие:

        • Total I/O per sec: 126,7
        • Total MB per sec: 7,9
        • Average I/O Response Time: 7,9362 ms
        • Maximum I/O Response Time: 96,1755 ms

        Сказать честно – результаты меня удивили. Я не ожидал такой маленькой разницы в iops и в mbps. Чем это вызвано – самому интересно. Вполне возможно, что здесь мы уперлись в потолок быстродействия SATA-дисков. А вот время отклика уже – намного лучше: 8 миллисекунд в среднем и 96 в максимуме, против 9 и 526 соответственно. Как видно, среднее время отклика улучшилось ненамного, возможно, что не улучшилось и вовсе: одна миллисекунда вполне укладывается в погрешность измерения. А вот максимальное время отклика – уменьшилось почти в 60 раз, что не может не радовать.

        Вывод.

        Из всего этого напрашивается следующий вывод: если планируется виртуализировать какие-либо задачи, требующие активного доступа к дискам – нужно использовать прямой доступ к диску. Во всех же остальных случаях я настоятельно рекомендую использовать, как и обычно, VHD. В случае, если использование прямого доступа необходимо – “соломоновым решением”, наверное, будет использование двух виртуальных дисков у одной ВМ: один – в виде VHD – для установки ОС и приложений, а другой – с использованием прямого доступа – для хранения данных.

        P.S. У меня имеются подозрения, что на эксперимент сильно повлиял потолок быстродействия SATA-дисков. Недавно у нас в распоряжении оказалась дисковая полка HP MSA2000 с интерфейсом SAS. Завтра – попробую подключить эту полку к серверу, собрать на ней RAID10 и повторить эксперимент. О результатах – обязательно отпишусь. Оставайтесь на канале!

        Александр Косивченко

        • Использование в работе «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

          • Внутренние угрозы в период кризиса

            • Рубрика: Security,Новое
            • Автор: Владимир Безмалый
            • Дата: Tuesday 31 Mar 2009

            Firewall.cpl_I296a_0409 На сегодняшний день в мире сумма ущерба, причиняемого от атак внутренних злоумышленников (инсайдеров), уже давно превышает сумму от внешних атак. Поэтому защита от внутренних угроз уже стала необходимостью. Особенно сегодня, когда проблема инсайдеров накладывается на проблему кризиса и необходимость массовых увольнений сотрудников. Не стоит думать, что все увольняемые, как равно и остающиеся сотрудники будут лояльны по отношению к увольняющим их работодателям! Именно этой проблеме и будет посвящена данная статья.
            Вначале я хотел бы, чтобы уважаемые читатели сами себе ответили на несколько непростых вопросов. Да-да, именно себе! Итак, вот они:

            • 1. Вы собираетесь увольнять персонал?
              2. Если да, то, как вы думаете, будут ли эти сотрудники лояльны к вам?
              3. Подумайте, не захотят ли ваши (почти бывшие) сотрудники унести информацию, к которой они имеют доступ, с собой?
              4. Сможете ли вы что-либо этому противопоставить?
              5. Готова ли ваша служба безопасности к такой постановке вопроса?
              6. Если вы даже обнаружите, что ваш сотрудник похищает информацию, –  готовы ли вы доказать это в суде?
              7. Готовы ли вы к рискам, связанным с применением нелицензионного программного обеспечения?
              8. Полагаю, список вы сможете продолжить сами…

            Без сомнения, многие предприятия сейчас будут вынуждены сокращать персонал. Некоторые – цивилизованно, с соблюдением законодательства, некоторые просто извещают сотрудников, что с сегодняшнего дня не нуждаются в их работе. Оба подхода тяжело бьют по людям. Но второй подход бьет еще и по организации: таким образом руководство компании  показывает, что оно готово во имя сегодняшней призрачной выгоды не считаться с законом. А следовательно – завтра обойтись так же с партнерами и заказчиками! Это удар по престижу организации, и информация такого рода разносится быстро. Кроме того, тем самым руководство дает увольняемым незаконные, но весомые основания поступить и с предприятием в обход закона. Эту ветвь рассуждений далее можно не детализировать. Перейдем к вынужденному вполне законному процессу сокращения персонала.
            Если вы приняли решение об увольнениях, придется побеспокоиться, чтобы уходящие не могли «прихватить» с собой конфиденциальную информацию.  Если вы не были готовы к этому – вы существенно проиграли! У вас не было политики безопасности? Не была классифицирована информация по степени конфиденциальности? Более того, у вас не было вообще службы ИТ-безопасности, всем занимались сисадмины? Увы… Но самое печальное, если ваши сотрудники при приеме на работу не подписывали соглашение о неразглашении информации! Тогда – формально — сотрудник, «уводящий» с предприятия, скажем, базу клиентов – ничего не нарушал, и вы не сможете предъявить ему претензии в суде.
            Но сложная экономическая полоса — это еще и повод (если это не было сделано ранее) выделить если не подразделение, то хотя бы определенного специалиста, который бы занимался ИТ-безопасностью. И этот человек (отдел) должен подчиняться напрямую первому лицу в компании. Как вариант — за аудит и обеспечение ИТ-безопасности может взяться сторонняя компания с большим опытом в этой области… что, впрочем, редко избавляет от необходимости сформировать собственную группу или пригласить доверенного специалиста.
            Да, если это не сделано ранее, вас ожидают некие дополнительные затраты. Но следует помнить, что общий уровень экономической безопасности предприятия напрямую зависит от безопасности информационной! Ведь любая акция, направленная против экономических интересов хозяйственного субъекта, начинается с этапа сбора информации. Сегодня нельзя представить себе не то что крупные экономические преступления вроде вывода активов предприятия, а даже мелкие противоправные действия без соответствующего информационного обеспечения.
            Помимо того, что наиболее важной информационной угрозой становится та, что направлена изнутри предприятия,- она все чаще приобретает характер «инициативной вербовки», когда сотрудник сам, по собственной инициативе, собирает те или иные сведения для продажи их конкурентам или иностранным спецслужбам. К счастью, все большее число руководителей компаний начинают осознавать реальный масштаб инсайдерских угроз.
            Согласно исследованию «Инсайдерские угрозы в России 2009» проведенного с 01 декабря 2008 г. по 23 января 2009 года специалистами аналитического центра Perimetrix:

            • • Наибольшие опасения вызывают угрозы утечки информации (73%), а также халатность служащих (70%)
              • Главной причиной актуальности внутренних проблем являются продолжающиеся утечки информации – только 5% компании заявили об отсутствии подобных инцидентов за последний год.
              • Специалисты по безопасности осознали собственную незащищенность перед утечками – сразу 42% респондентов затруднились назвать точное количество утечек.
              • Криптографические системы используют 41% компаний, а системы защиты от утечек – 29%.
              • В подавляющем большинстве случаев нарушители внутренней безопасности не несут практически никакой ответственности. 45% халатных нарушителей наказываются неформальными выговорами, а 51% злонамеренных инсайдеров увольняются из компаний по собственному желанию.

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

            • • Почему вы хотите защищаться от внутренних угроз?
              • Как выглядит портрет возможного нарушителя?
              • Какие ресурсы вы готовы потратить на защиту от внутренних угроз?

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

            Таблица 1.
            Цели и методы внедрения системы защиты против внутренних угроз

            Цель Внедрение
            Соответствие требованиям нормативов и стандартов Внедрение мер, которые обеспечат соответствие и проверяются при  аудите
            Сохранность информации Гласное внедрение в сочетании с кадровой работой
            Выявление канала утечки Открытое внедрение в сочетании с оперативными мероприятиями
            Подтверждение непричастности Архивация движения данных и сетевых операций для доказательства того, что источник утечки не внутри фирмы

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

            Средства защиты

            Сегодня к мерам по защите информации от внутренних угроз компании относят технические решения по контролю доступа к ресурсам (Интернет, электронная почта, USB), а также сигнатурную контентную фильтрацию (как правило, это специальным образом настроенный антиспам-фильтр). Однако стоит понимать, что эти методы позволяют противодействовать либо низко квалифицированным, либо неосторожным пользователям.
            Стоит помнить, что сигнатурная контентная фильтрация легко обходится либо удалением «опасных» слов либо примитивным кодированием, т.е. заменой символов одной кодировки (западноевропейской) другой (кириллической). Легко отметить что слова «секретно» и «ceкpeтно» читаются одинаково, в то время, как во втором слове выделенные буквы набраны в западноевропейской кодировке. Более того, кто или что может мешать заменить букву «о» на цифру «0» или букву «s» на цифру «5»? А сигнатурный анализатор просто пропустит это слово как нераспознанное.
            Вместе с тем стоит понимать, что принцип «запретить все» неприменим, так как сотрудникам необходимо продолжать работать.
            То есть стоит понимать, что с одной стороны компании нуждаются в упорядочении системы хранения конфиденциальной информации, а с другой – во внедрении более совершенной системы защиты от внутренних угроз.

            Положение о конфиденциальной информации в электронном виде

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

            Контентное категорирование

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

            Классификация информации по уровню конфиденциальности

            Конфиденциальную информацию можно разнести по следующим категориям (пример):

            • • «СТРОГО КОНФИДЕНЦИАЛЬНАЯ» – к данной категории относится информация, являющаяся конфиденциальной в соответствии с требованиями действующего законодательства (банковская тайны, персональные данные), а также информация, ограничения на распространение которой введены решениями руководства организации (коммерческая тайна), разглашение которой может привести к тяжким финансово-экономическим последствиям для организации вплоть до банкротства (нанесению тяжкого ущерба жизненно важным интересам его клиентов, корреспондентов, партнеров или сотрудников);
              • «КОНФИДЕНЦИАЛЬНАЯ» – к данной категории относится информация, не отнесенная к категории «СТРОГО КОНФИДЕНЦИАЛЬНАЯ», ограничения на распространение которой вводятся решением руководства организации в соответствии с предоставленными ему, как собственнику (уполномоченному собственником лицу) информации, действующим законодательством правами, разглашение которой может привести к значительным убыткам и потере конкурентоспособности организации (нанесению ощутимого ущерба интересам его клиентов, корреспондентов, партнеров или сотрудников);
              • «ОТКРЫТАЯ» – к данной категории относится информация, обеспечения конфиденциальности (введения ограничений на распространение) которой не требуется.

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

            Метки документов

            Необходимо обратить особое внимание на организацию процесса пометки конфиденциальных документов. Каждый конфиденциальный документ должен содержать метку, по содержанию которой контролирующие программы могли бы определить степень его конфиденциальности и категорию пользователей, которые могут проводить с ним потенциально опасные операции – публикацию в Интернет, копирование на сменные носители, переименование, отправку по электронной почте и т.п. Технические и организационные методы установки меток выбирает заказчик. Если все защищаемые документы хранятся исключительно в формате MS Office, то в качестве метки может использоваться запись “конфиденциально” в соответствующих полях свойств документов. Некоторые производители систем документооборота используют программные метки и специальные форматы файлов. Однако самый распространенный и простой способ присваивания меток – именование файлов по специальной маске. Например, первые 10 символов – тематическая группа, к которой относится документ (название клиента, рабочей группы, подразделения, отрасли и т.д.), затем знак подчеркивания, затем 20 символов для описания документа, снова знак подчеркивания и 8-значная дата в формате YYYYMMDD.
            Следует обратить внимание на то, что процесс внедрения процедуры именования файлов – не какая-то разовая акция, а постоянная работа по обучению персонала именовать файлы именно таким образом. Необходимо понимать, что кроме организационных методов (закрепление приказом только такой формы именования, поддержка способа именования всем топ-менеджментом и инструктаж новых сотрудников), надо привлечь на помощь и технические средства. Самый простой технический способ внедрения этой процедуры – разрешать выкладывать на файловый сервер, класть в корпоративное хранилище или публиковать в Интранет только те файлы, которые именованы по заранее утвержденному шаблону. Со временем все файлы, которые прошли через электронную почту, файловые серверы, хранилище данных и Интранет, будут называться правильным образом.
            После того, как все файлы документов будут названы по такой маске, документы будут автоматически попадать в поле зрения контролирующих систем и перехватываться при запрещенных с ним действиях пользователя не только средствами контентной фильтрации, но и мониторами, действующими на основании политик. В отличие от контентной фильтрации, этот метод дает практически 100% гарантию. Это удобно и при ведении визуального контроля, ведь даже в очереди на печать можно сразу увидеть конфиденциальные документы. К тому же не будет лишним еще раз напомнить пользователю при открытии файла, что документ конфиденциален.

            Хранение информации

            После того, как реестр конфиденциальных документов будет создан, можно приступить к организации их хранения. Во многих компаниях организационными и техническими методами запрещено хранить на рабочих станциях конфиденциальную информацию. Как правило, такие данные хранятся на специальных клиент-серверных или web-приложениях (корпоративных интранет-порталах, документных хранилищах, бизнес-приложениях, справочно-нормативных базах, системах документооборота, ERP и т.д.), которые позволяют разделить права пользователей и защитить информацию от попытки сохранить в несанкционированном месте. Несмотря на то, что защита таких данных является многоуровневой (уровни аппаратной платформы, СУБД, приложения), тем не менее, риски утечки такой информации с рабочих станций существуют.

            Способы хранения конфиденциальной информации

            Прежде всего, в организации необходимо обеспечить защиту от утечки информации следующих типов:

            • • сводная информация;
              • конфиденциальные документы;
              • интеллектуальная собственность.

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

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

            Неструктурированная информация
            Хищение документов, содержащих неструктурированную информацию, также может привести к моральным и материальным потерям. Защита от утечек подобной информации крайне затруднена.
            Одним из вероятных путей утечки информации, используя санкционированный доступ, являются клиентские приложения. Большинство используемых в качестве рабочих станций – компьютеры на платформе Intel. Хранение информации в незашифрованных временных файлах, встроенная в операционную систему возможность копирования информации в буфер (операции Copy и PrintScreen), наличие многих каналов ввода-вывода (дискеты, CD-R, USB, Wi-Fi, Bluetooth и т. д.) делают рабочую станцию весьма опасным устройством для реализации внутренних IT-угроз. Таких угроз практически нет при использовании тонких клиентов.

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

            Основные направления защиты

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

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

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

            Мониторинг (аудит) действий пользователей
            Для процесса защиты от внутренних утечек информации крайне важно не только то, кто получил доступ к файлу, но и то, что он делал с документом, ведь разные пользователи будут использовать документы по-разному. При этом для соблюдения правил внутренней безопасности в первую очередь важно контролировать те действия, которые могут привести к утечке. Это такие как:

            • • перемещение документа, как единого целого;
              • копирование информации из документа;
              • изменение документа с целью обмана следящих систем.

            К первой группе можно отнести копирование файла на сменные носители, отправку по почте, публикацию в Интернет, печать.
            Ко второй – копирование информации из документа в буфер Windows, копирование временного файла Windows и т.п.
            К третьей группе – переименование файла или его расширения, сохранение файла под другим именем, сохранение в другом формате, архивирование, кодирование и шифрование.
            Операция с конфиденциальной информацией, которая недопустима для данного пользователя, должна либо блокироваться, либо сведения о такой операции должны поступать к офицеру безопасности. При этом система внутренней безопасности должна быть настроена так, чтобы пользователь (его руководитель) узнавали, что он пытается совершить запрещенную операцию, либо чтобы эта информация была доступна только офицеру информационной безопасности.
            Однако если вы думаете что это все, что вам нужно сделать – вы ошибаетесь. На самом деле вы должны еще классифицировать потенциального нарушителя, создать его портрет, продумать нетехнические методы защиты. Рассмотрение этих вопросов требует достаточно большого объема информации и не может быть втиснуто в одну статью. Что вам сказать – вам предстоит работать и работать! И учтите, времени у вас нет! Это все должно быть сделано еще на позавчера!
            Кроме этого можно рекомендовать следующее:

            • • Создать выделенную структуру ИТ-безопасности (и/или найти организацию, которая поможет в анализе рисков информационной безопасности, написании соответствующих документов и внедрении соответствующих аппаратно-программных средств);
              • Классифицировать данные и создать каталог конфиденциальной информации;
              • Разобраться, кто к этой информации имеет доступ;
              • Закрыть доступ тем сотрудникам, кому эта информация не нужна по служебной необходимости;
              • Закрыть возможность записи на внешние носители, а в случае недоступности такой меры – организовать теневое копирование информации и контроль действий за соответствующих сотрудников;
              • Запретить удаление любой информации с дисков общего доступа;
              • Включить фильтр на почтовом сервере по определённым словам (на исходящую электронную почту);
              • Запретить использование внешних бесплатных почтовых серверов, ненужных в работе социальных сервисов и средств мгновенного обмена сообщениями;
              • Для наиболее ответственных рабочих мест предусмотреть средства регистрации действий персонала;
              • Создать инструкции по использованию ПК, ПО, уже внедренных и новых систем и средств автоматизации управления;
              • Под роспись ознакомить пользователей с правилами работы по работе с конфиденциальной информацией;
              • Объединить усилия топ-менеджмента, ответственных за экономическую, физическую и информационную безопасность.

            Это, конечно, не панацея,- но принимаемые меры позволят если не исключить, то хотя бы минимизировать возможные потери от внутренних угроз в наше непростое время.

            Безмалый В.Ф.
            MVP Consumer Security
            vladb@windowslive.com
            http://vladbez.spaces.live.com

            • Зачем же нужна виртуализация?

              • Рубрика: Virtualization,Новое
              • Автор: Александр Косивченко
              • Дата: Sunday 29 Mar 2009

              General Раз уж мы говорим о виртуализации – наверняка у кого-то возникает вполне резонный вопрос: а для чего же это вообще нужно? Оговорюсь, что далее речь пойдет о виртуализации серверов. О виртуализации представлений и приложений – возможно, напишу чуть позже.

              Я, признаться честно, являюсь технарем "до мозга костей", и модные аббревиатуры вроде TCO, ROI, etc., которыми очень любят оперировать господа маркетологи – для меня являются "китайской грамотой". Соответственно – буду писать о том, что я вижу как технарь.

              Наверняка у многих сисадминов в хозяйстве имеется несколько серверов. И обычно это оправданно: многие задачи рекомендуется разносить по разным серверам. К примеру, Microsoft настоятельно не рекомендует совмещать контроллер домена Active Directory и интернет-шлюз на одном физическом сервере. Это создает серьезную угрозу безопасности: в случае атаки на вашу сеть каких-нибудь хакеров или вирусов – первым примет на себя удар, как Брестская Крепость, интернет-шлюз. В случае, если на нем размещался еще и контроллер домена – существует вероятность, что базы AD будут повреждены, либо, что еще хуже – окажутся в руках хакеров. В первом случае понадобится тратить время на восстановление из бэкапов, во втором – очень высокая вероятность дальнейших и более продуманных атак, с использованием логинов и паролей действующих пользователей сети. Ну или просто попадание e-mail адресов пользователей компании в базы спамеров – тоже приятного мало. Одна старая пословица говорит: "Не клади все яйца в одну корзину".

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

              Но тут возникает новая проблема: каждый отдельный сервер – стоит денег, причем не малых (если речь идет о брэндовых серверах). Каждый отдельный сервер потребляет электроэнергию, и занимает место на столе либо в стойке. Возможно, кому-то это покажется не особо актуальным, тем не менее – это является важным преимуществом. Особенно, если сервера размещаются в стороннем датацентре, где взымают плату за занимаемые юниты в стойках и энергопотребление строго ограничивается. К тому же, в европейских странах существует некий налог, который напрямую зависит от объемов электроэнергии, потребляемых компанией. Не помню, как этот налог называется – что-то связанное с экологией и выбросом CO2.

              Кроме этого, каждое из приложений редко потребляет много системных ресурсов: те же контроллеры доменов и интернет-шлюзы – на них редко загрузка процессора превышает 10%. Использование под каждую такую задачу отдельного сервера выглядит нерационально. Совмещать все на одном сервере – как мы уже выяснили, не правильно с точки зрения безопасности. Где же золотая середина? Как же сделать, чтобы и волки были сыты, и овцы целы (и пастуху – вечная память! :)) Ответ дает как раз технология виртуализации.

              Что же такое виртуализация? Виртуализация (а именно – виртуализация серверов) – это технология программной эмуляции аппаратного обеспечения компьютера. Причем, на одной физической машине может быть запущено несколько таких виртуальных "компьютеров". На такие виртуальные машины можно ставить операционную систему и приложения, и работать с ними, как с отдельными физическими машинами. Каждая виртуальная машина использует для своей работы какую-то часть аппаратных ресурсов физической машины. Причем, как правило, объем аппаратных ресурсов, выдаваемых отдельным виртуальным машинам можно регулировать – как жестко (статически), так и динамически. Таким образом, аппаратные ресурсы используются намного более рационально.

              Простой пример: если у нас есть два приложения, которым для работы необходимо 128Мб оперативной памяти, и которые нельзя устанавливать на один физический сервер, можно:

              • 1) Купить два сервера с 128M RAM;
              • 2) Купить один сервер с 256M RAM (плюс еще какое-то количество "про запас" и для запуска хостовой ОС) и запустить оба приложения в отдельных виртуальных машинах.

              Как видно, во втором случае ресурсы сервера (в частности, CPU) используется более рационально, и стоимость р
              ешения гораздо ниже, т.к. один сервер с чуть большим объемом RAM всегда дешевле двух серверов.

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

              Если же необходимо избежать единой точки отказа – можно купить, к примеру, два сервера и развернуть кластер. В этом случае, два физических сервера будут действовать как единая платформа для виртуализации. Если виртуальных машин, к примеру, 5 – это все равно выгоднее 5и отдельных серверов. А при отказе одного из серверов в кластере – виртуальные машины продолжат работу на другом – вот и все. Пользователи этого скорее всего не заметят. Ну, возможно, прервется у них работа на несколько секунд, это не так критично, как отказ на несколько часов.

              Еще важный момент: виртуализация (если речь идет о решении от Microsoft) поможет сэкономить на лицензиях. К примеру, лицензия на Windows Server 2008 Standard позволяет бесплатно запускать внутри одну виртуальную машину, Enterprise – до 4, а Datacenter – вообще неограниченно (в пределах одного физического хоста).

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

              Как известно, развертывание нового сервера занимает определенное время. Это – установка ОС, установка драйверов, установка приложений и т.п. Да, конечно, все параметры установки ОС можно задать в файле ответов автоматической установки, драйвера можно интегрировать в дистрибутив, приложения установить, например, через RunOnce, но все равно установка занимает время. Даже если создать полный образ системы – во-первых, его развертывание все равно займет порядка 10-15 минут просто из-за его объема и скорости чтения из сети или с DVD-ROM, во-вторых – для создания такого образа, как правило, необходимо прибегать к помощи стороннего ПО. С виртуальными же машинами все намного проще: можно создавать абсолютно идентичные "клоны" виртуальной машины за пару кликов мышью, и процесс займет порядка нескольких минут – ведь скорость работы дисковой подсистемы сервера намного выше, чем пропускная способность сети или скорость чтения DVD-ROM.

              Приведу пример из собственного опыта. Контора, где я однажды работал, занималась, помимо прочего, и разработкой ПО. Естественно, разработчикам было необходимо где-то тестировать и отлаживать свои программы. Как нельзя лучше для этого подходили виртуальные машины. Благодаря клонированию – удалось создать эталонный образ, в результате которого развертывание новой виртуальной машины занимало порядка 3 минут. А у нас было целых два сервера, на каждом из которых работало примерно по 20 виртуальных машин. К слову сказать – использовался VMWare ESX Server, было просто два отдельных сервера – без VMotion и кластеров. Правда, для управления использовался Virtual Center.

              Еще одна головная боль любого сисадмина – резервные копии. Как утверждает пословица: "Есть два типа сисадминов: те, которые еще не делают бэкапы, и те, которые уже делают". Резервное копирование – на первый взгляд, возможно, кажется бесполезной процедурой, но как только жареный петух куда-нить клюнет – тот, кто не делал бэкапы – начинает рвать на себе волосы, кусать локти и развертывать все заново. Если на сервере уже были какие-то важные данные – это то еще удовольствие. А если там была, например, база данных, содержащая бухгалтерию предприятия за последние 10 лет – то это просто смерти подобно. Не говоря уже, опять же, о простое – который может обернуться серьезными убытками. Ну не поймут клиенты, если им будут говорить "Подождите пожалуйста, у нас сервер не работает!" – они просто пойдут и купят у кого-то другого. Директор, естественно, админа за такое дело по головке не погладит.

              Даже если делается бэкап, то не всегда можно дать 100% гарантию, что из него можно будет восстановить ОС на "голом железе", и она будет работать без ошибок. Особенно – если конфигурация аппаратного обеспечения будет немно
              го отличаться от предыдущей. Близкую к 100%-ной гарантию дают системы резервного копирования, имеющие функцию "Bare Metal Restore" – например, Symantec BackupExec, CA ArcServe, IBM Tivoli Storage Manager, HP Data Protector. Но само это ПО стоит вполне приличных денег, и за функцию "Bare Metal Restore" придется заплатить отдельно: для ее использования, как правило, необходима отдельная лицензия.

              С виртуальными же машинами намного проще: все "железо" там стандартное, ибо эмулируемое, и для полного бэкапа достаточно просто скопировать один или несколько файлов. Всё. Для восстановления достаточно просто скопировать файл(ы) на новый сервер, где уже установлена хостовая ОС со средой виртуализации, и "подцепить" их – и виртуальная машина будет работать как ни в чем не бывало.

              Еще необходимо упомянуть так называемые моментальные снимки (snapshots): это – грубо говоря – бэкап виртуальной машины, хранящийся внутри нее самой. При необходимости можно просто "откатить" виртуалку на момент снятия моментального снимка – и она будет работать, как будто с того момента ничего не изменилось. Причем, у одной виртуальной машины может быть много таких snapshot’ов, и они могут образовывать древовидную структуру. Это позволяет "откатывать" систему ровно к необходимому моменту. Такой функцией могут пользоваться, к примеру, системные администраторы, делая snapshot до и после каких-либо важных изменений, и, если понадобиться, к примеру – откатиться до момента изменений. Или еще раньше. А потом, если надо – позже. И не нужно развертывать систему с нуля и снова повторять все свои действия. Наши разработчики, кстати, по достоинству оценили такую возможность: раньше, когда они использовали VirtualPC на своих рабочих станциях – делать такие "откаты" было затруднительно, часто приходилось создавать машину заново с эталонного образа.

              Итак, подводя итог, вкратце – почему все же виртуализация серверов – это гуд:

              • Рациональное использование аппаратных ресурсов серверов;
              • Экономия денег на покупке новых серверов, экономия электроэнергии и физического пространства;
              • Экономия лицензий на виртуальные ОС (если речь о Microsoft);
              • Простота администрирования: легкость перемещения виртуальных машин с одного физического сервера на другой, быстрота развертывания новой машины из эталонного образа, простота создания резервной копии и восстановления из нее, использование "моментальных снимков".

              Собственно, на этом хотелось бы завершить данную статью.

              Александр Косивченко

              • System Center Configuration Manager 2007 – решение для автоматизации управления ИТ инфраструктурой предприятия

                • Рубрика: System Center,Новое
                • Автор: Алексей Тараненко
                • Дата: Sunday 29 Mar 2009

                logo_sccm2007 В каждой организации процесс поддержки компьютеров различается кардинально. Но можно выделить два подхода: работать ногами или головой. Представителям первой когорты приходиться целыми днями бегать по этажам: создать ярлык на косынку секретарше, поставить новый банк-клиент в бухгалтерии или спешить на помощь к финансовому директору, у которого почему—то не открылись одноклассники. Свободного времени у таких людей почти нет и статью эту они скорее всего не увидят. Я же хочу поговорить со второй, надеюсь большей половиной ИТ сообщества, которая ленива и умна. С людьми, которые предпочитают работать головой, а не ногами. Автоматизировать свою работу можно по-разному, кто-то использует радмин и все делает руками, но уже удаленно, а кто-то использует скрипты и групповые политики. Сегодня я хочу рассказать вам о другом подходе к автоматизации, об использовании Configuration Manager 2007.

                Чем же интересен Confguration Manager для ИТ?

                Службе технического обеспечения, он будет интересен своими инструментами отчетов и инвентаризации. Больше нет необходимости бегать по этажам с бумажками и отслеживать передвижение планки памяти. Вся история обновления железа будет сохранена в базе. Вы всегда сможете четко сказать, сколько процессоров Pentium IV 3ГЦм установлено на ваших компьютерах.

                capture_03272009_112357

                Рисунок 1 Вид таблицы отчетов

                Техподдержка, больше не будет требовать купить себе Radmin. В SCCM входит функционал Remote managmetn, который использует три компонента для обеспечения удаленного управления: Remote Tools (набор драйверов и ПО обеспечивающих возможность удаленной работы наподобие Radmin\VNC), Remote Assistance и Remote Desktop. Кроме того, можно забыть о суматохе при смене ПО – теперь установка ПО на сотни компьютеров, требует трех щелчков мыши. Когда в следующий раз AOL снова сменит протокол, новая версия QIP будет установлена на компьютеры наших горячо любимых менеджеров в течение часа. При этом 10 минут вы будете ее скачивать, 5 интегрировать в SCCM, и оставшиеся 45 посвятите чтению сайта itband.ru, ожидая отчетов об установке.

                Даже ваш отдел мотивации труда будет рад – вы можете показать им отчеты, на которых будет видно, что 90% рабочего времени менеджеры играют в косынку.

                И это далеко не все возможности Configuration Manager.

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

                Сайт SCCM (Site system) – группа серверов выполняющих роли SCCM.

                Central site – верхний primary-сайт в иерархии сайтов.>

                Primary site – группа серверов, которые используют для работы собственную базу данных

                Secondaryт site – группа серверов, которые используют для работы базу данных родительского сайта.

                Branch distribution> point – хотя это не отдельный сайт, а роль сайта, все же стоит отметить отдельно. Данная роль предназначена для упрощения обслуживания особо маленьких филиалов организации. В таких филиалах сеть может представлять из себя 3 компьютера в рабочей группе. В отличие от primary\secondary сайтов Branch DP может устанавливаться и на рабочие станции. Обладает функционалом только точки распространения программ\обновлений.

                Границы сайта – IP подсети, диапазоны IP адресов, сайты AD и IPv6 Prefix определяющие зону управления того или иного сайта.

                Коллекция (collection) – группа объектов (пользователи, компьютеры, группы безопасности) объединенная, по какому либо признаку. Именно над коллекциями производится большинство действий, таких как установка программ\ОС\обновлений.

                Роль SCCM (role) – компонент SCCM обеспечивающий выполнение определенной функции, например, такой как установка ПО или создание отчетов. Все роли могут быть совмещены на одном сервере, либо разнесены на отдельные сервера.

                Client Agent – определенный функционал клиентской части SCCM. Часть агентов может быть отключена.

                Функциональность SCCM можно разделить на три больших класса:

                Инвентаризация и отчеты

                • Инвентаризация аппаратного обеспечения (Hardware inventarization)
                  Инвентаризация  программного обеспечения (Software inventarization)
                  Слежение за используемым ПО и лицензиями (Asset Intelligence)
                  Отчеты (Reporting)

                Развертывание приложений и ОС

                • Развертывание операционных систем (OS Deploy)
                  Распространение ПО (Software distribution)
                  Распространение и управление виртуализированным ПО (Application virtualization management)
                  Управление обновлениями (Software update)

                Управление клиентскими устройствами

                • Мониторинг используемых программ (Software metering)
                  Удаленное управление клиентами (Remote management)
                  Управление мобильными устройства (Modile device management)
                  Управление клиентами Intel vPRO (Out  of band management)
                  Поддержка заданной конфигурации (Desied configuration manager)
                  Защита подключающихся к сети (Network access protection)

                roleSCCM

                Рисунок 2 Роли сайта SCCM R2 2007

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

                SCCM  совместима с большинством ОС Microsoft. table legend

                Рисунок 3 Поддержка ОС в Configuration Manager 2007

                Рассмотрим по отдельности некоторые основные возможности.

                Установка ОС (OS Deploy)

                Как часто вам приходится устанавливать ОС на компьютеры? Я думаю, что большинство системных администраторов использует ту или иную технологию (RIS\WDS) для облегчения установки. OSD в SCCM позволяет облегчить весь процесс установки до одного простого действия: подключения в сеть и включения компьютера. Далее запуститься мастер установки SCCM и на компьютер будет последовательно развернуты: ОС из файла wim, все драйвера необходимые для работы компьютера, заданный набор программ и все самые свежие обновления безопасности. Я не могу сказать, что по сравнению с WDS SCCM  совершил революцию, нет, это скорее эволюция. То, что при использовании WDS было ранее невозможно или требовало от системного администратора много времени и сил, теперь стало доступно по двум щелчкам мыши.

                OSD_WinPE_1

                Рисунок 4 Приветствие мастера установки ОС в OSD

                Установка приложений (Software distribution)

                Иногда бывает так, что пользователям приходится менять свои компьютеры. У кого-то эта ситуация ярко выраженная, у кого-то менее. Довольно часто случаются курьезные ситуации в стиле башорга: «А перенесите мне мой старый монитор, там у меня на рабочем столе важная программа осталась!». Можно конечно подойти и поставить все вручную. Но нужно ли? SCCM позволяет назначать установку программ на коллекции. При этом установка будет происходить в фоновом режиме, поэтому пользователь пересевший за новый компьютер, на котором установлено только базовое ПО, в течение часа получит все программы которые ему назначены. Причем в этот момент он будет продолжать работать с почтой, просматривать интернет страницы или раскладывать косынку – т.е. полноценно работать, а не стоять у вас над душой с криком: «У меня отчет! У меня сроки горят!»

                Рассмотрим другую ситуацию: в компании жестко определены наборы приложений, которые используют те или иные группы пользователей. Когда пользователь переходит из группы в группу ему необходимо добавлять эти приложения. Конечно, можно было бы воспользоваться групповой политикой, но тогда весь комплект программ будет установлен пользователю сразу. Действительно ли это так необходимо? Или же лучше ставить программы по запросу? SCCM позволяет пользователям с ограниченными привилегиями самостоятельно устанавливать на своих компьютерах необходимые и ободренные администратором программы. Причем только вы решаете – будет это шаблонная установка, или вы позволите продвинутому пользователю пройти весь мастер установки самостоятельно.

                Или бывает так: в 17:45 вас вызывает к себе начальство и говорит, завтра в 9:00 утра на всех наших пятистах компьютерах должна быть новая супер программа от наших партнеров. Не правда ли, знакомая ситуация? Раньше в такой ситуации приходилось до ночи засиживаться в офисе. С помощью SCCM можно спокойно уйти домой в 18:00. А SCCM ночью централизованно включит компьютеры (с помощью технологии WakeOnLan) и установит все необходимые программы, после чего снова выключит их. По-моему, это гораздо лучше, чем засиживаться на работе? 😉

                capture_03272009_134433

                Рисунок 5 Выбор ПО доступного для установки

                Управление обновлениями (Software Update)

                SCCM расширяет возможности хорошо известной службы обновлений WSUS 3.0, позволяя управлять не только обновлениями Windows Update, но и обновлениями сторонних организаций. Вы может обновлять с помощью него даже свой собственный корпоративный софт. Сам процесс управления обновлениями стал гораздо более гибким.

                В SCCM, в отличие от WSUS нельзя установить автоматическое одобрение обновлений. Все обновления должны быть предварительно одобрены администратором. Я считаю такой подход оправданным, все изменения в системе должны проходить предварительное тестирование. В моей практике бывали случаи, когда одно исправление способно нарушить работу бизнес приложений. Но это не означает, что управление обновлениями усложнено. Для действий над группами обновлений существуют листы обновлений (update list). Благодаря им, администратор может оперировать не отдельными обновлениями, а целыми списками, к примеру всеми критическими обновлениями выпущенными в последний «вторник».

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

                • позволить пользователям самостоятельно принимать решение об установке того или иного исправления;
                • дать время пользователю «подумать», а по истечении определенного срока установить обновление принудительно;
                • либо же сразу устанавливать обновление принудительно, в том числе автоматически включая компьютер с помощью WakeOnLan технологии ночью.

                capture_03272009_134342

                Рисунок 6 Возможность выбора применяемых обновлений

                Решение для филиалов и удаленных клиентов

                В России структура средних и больших компаний такова, что их офисы отделены друг на тысячи километров и несколько часовых поясов. Причем линии связи между филиалами могут быть абсолютно разными. Начиная от выделенных оптических линий от магистральных провайдеров, заканчивая городской Wi-Fi которая имеет «приятное» свойство зависать во время дождя. Некоторые филиалы могут не уступать в размере и качестве подготовки обслуживающих их ИТ специалистов головному предприятию, а в некоторых на большое количество «манагерского» состава, будет всего один эникей, ну а некоторые филиалы будут довольствоваться тремя компьютерами в каком-нибудь промышленном пригороде, куда даже студента старшего курса не заманишь для обслуживания этого хозяйства. Мне пару раз приходилось устанавливать 1С с использованием радмина, через спутник. Я получил просто массу «удовольствия» и убил на это не один час. Если мы используем SCCM, то даже в самых отдаленных и маленьких филиалах сможем использовать его возможности. Где то это будет полноценный сайт, где-то secondary сайт,  ну а в особо маленьких филиалах компьютер секретаря будет использован как Branch distribution point.

                Лицензирование и цены

                Разумеется, в вводной статье нельзя не затронуть такую тему как лицензирование. Как и для большинства продуктов SystemCenter, для Configuration Server 2007 нам понадобиться покупка нескольких типов лицензий.

                Управляющий сервер (Management Server)

                Configuration Manager 2007 R2 Server
                Лицензия нужна для каждого сервера (site server) запущенного в физической или виртуальной среде. Так же отдельная лицензия нужна, на каждый узел NLB-кластера сервера SCCM.
                Вам не требуется дополнительно покупать лицензии Management Server, если любая из перечисленных ролей установлена на сервере, отличном от сервера с ролью Site server:

                • Configuration Manager Console
                  Configuration Manager Client
                  Device Management Point
                  Custom Updates Publishing Tool
                  Distribution Point
                  Fallback Status Point
                  Inventory Tool for Microsoft Updates
                  PXE Service Point
                  Management Point
                  Reporting Point
                  System Center Update Publisher
                  Secondary Site Server
                  Server Locator Point
                  Software Update Point
                  State Migration Point
                  System Health Validator Point
                  Configuration Pack

                Вам так же не требуется лицензия Management Server для сервера SQL (role site database server), на котором будет храниться база данных сайта SCCM.
                Хочу обратить особое внимание на Secondary сайты. Для Secondary-сайта не требуется дополнительная лицензия Management Server, поскольку secondary сайт работает с базой главного сайта.
                http://technet.microsoft.com/en-us/library/bb632547.aspx

                Серверные лицензии на управление (Management Licenses for Managed Servers)

                Configuration Manager 2007 R2 Enterprise Server ML
                Управление экземплярами серверного программного обеспечения с использованием DCM:
                Конфигурации IT Compliance и Governance
                Основной нагрузкой операционной системы
                Все другие утилиты операционных систем, нагрузки служб, а также любые приложения, работающие в лицензионных операционных средах.
                Configuration Manager 2007 R2 Standard Server ML
                Управление экземплярами серверного программного обеспечения с использованием Desired Configuration Management (DCM) (Управление заданной конфигурацией) основной нагрузки операционной системы, работающей в лицензированной операционной среде, а также управление любыми приложениями, работающими в этой операционной среде, которые не требуют использования DCM.

                «Основные нагрузки операционной системы» включают:
                следующие служебные программы операционной системы:  диспетчер системных ресурсов, служба уведомлений о смене пароля, анализатор безопасности Baseline Security Analyzer, службы надежности и доступности;
                нагрузки следующих файловых служб и служб печати:  сервер печати, распределенная файловая система (DFS), служба репликации файлов (FRS), сетевая файловая система (NFS), протокол передачи файлов (FTP) и службы Windows Sharepoint Services;
                нагрузки следующих сетевых служб:  распределенная служба имен DNS, протокол динамической настройки сети DHCP и служба имен Windows Internet Naming Service (WINS).

                Для каждой серверной операционной среды (среда OSE) на одном устройстве, которым необходимо управлять, требуется лицензия на управление серверами (лицензия ML).  Если у вас имеется более одной среды OSE, для такого устройства потребуется эквивалентное количество лицензий ML.  Для управления любым количеством сред OSE на одном сервере можно использовать одну лицензию System Center Server Management Suite Enterprise.  Кроме того, серверные лицензии ML разрешают управление средами OSE на рабочих станциях.
                Важно помнить, что любые варианты лицензирования управляемых или обслуживающих устройств — с помощью отдельных ML не влияют на необходимость лицензирования управляющих серверов, и тем более не отменяют эту необходимость.

                Клиентские лицензии на управление (Management Licenses for Managed Clients)

                Configuration Manager 2007 R2 Client ML
                Хотя серверные ML можно использовать для лицензирования не-серверных сред, это вряд ли оправдано экономически. Для лицензирования не-серверных сред, существует клиентская лицензия Client ML. Client ML бывает трех видов:
                Client ML — per OSE привязываются аналогично серверным ML — к каждой среде (OSE) в отдельности. Таким образом, отдельная лицензия требуется для каждой запущенной среды с не-серверной ОС. При этом такой тип лицензии позволяет управлять не-серверной средой вне зависимости от того, сколько пользователей использует эту ОС.
                Client ML — per user дает возможность лицензировать управление не-серверными ОС по количеству пользователей, которые используют эти среды. Клиентская лицензия на управление такого типа позволяет управлять всеми средами, которые используются лицензированными пользователями.
                Client ML лицензия, включенная в наборы Core CAL и Enterprise CAL. В этом случае, она позволяет управлять любым количеством не-сервеных сред для любого количества пользователей, то есть лицензируется на устройство (per device).

                Для примера возьмем среднюю организацию, в которой 10 серверов и 150 рабочих станций. При этом у организации два офиса – основной и дополнительный. В основном расположены 100 пользователей, в дополнительном 50. 5 топ-менеджеров  используют в свой работе КПК на базе Windows Mobile. Тогда для внедрения SCCM нам понадобятся следующие типы лицензий:
                -клиентские лицензии (Client ML) – 155 = 150+5
                -лицензии на управление серверами (Server ML) – 10
                -лицензия на SCCM R2 – 1
                Если каналы между офисами более-менее стабильны, то вы можете развернуть в дополнительном офисе Secondary сайт. При этом, стоимость лицензий не поменяется.

                licensing

                Рисунок 7 Схема лицензирования

                Цены

                Configuration Manager Server 2007 R2 ~ 580$
                Enterprise ML ~430$
                Standard ML ~ 160$
                Client ML  ~ 40$

                Подробнее о лицензировании:
                http://www.microsoftvolumelicensing.com/userights/Downloader.aspx?DocumentId=2084
                http://www.microsoft.com/systemcenter/configurationmanager/en/us/pricing-licensing.aspx

                Вместо заключения

                SCCM это очень мощное и красивое решение для автоматизации управления компьютерами организации. Но за кажущейся простотой и красотой административной консоли не должна дарить вам чувство эйфории. Как подчинить этого «монстра» я расскажу в последующих статьях.

                Алексей Тараненко

                MCP/MCTS: SCCM 2007

                altaranenco@gmail.com

                • Восстановление удаленных доменных учетных записей в 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

                  • Обзор технологий высокой доступности Exchange Server 2007 и настройка Standby Continuous Replication.

                    e12icon[7] Корректное функционирование и доступность почтовых систем становятся все более и более критичными для бизнеса.  Почтовые системы выросли от просто инструмента обмена письмами до средства групповой работы. Сегодня нередко от администраторов почтовых систем требуют обеспечить высокую доступность сервиса.
                    Как обеспечить отказоустойчивость почтовых серверов? Что такое высокая доступность? Какие технологии высокой доступности есть в Exchange Server 2007 и в чем разница между ними? Как обеспечить высокую доступность почтовых серверов с минимальными затратами? В данной статье я попробую ответить на эти и другие вопросы

                    В первоначальном выпуске Exchange 2007 (RTM) существовало три технологии для обеспечения высокой доступности и отказоустойчивости. В данной статье я хотел бы более подробно остановится на четвертой технологии – Standby Continuous Replication, включенной в состав Service Pack 1 для Exchange Server 2007. Почему именно на ней? Во-первых, эта технология включена в функционал Exchange Server Standard Edition.

                    Табл. 1. Технологии обеспечения высокой доступности и выпуски Exchange Server.

                    Exchange Standard Edition

                    ( $ 728,42 или 25 879,45 p.)

                    Exchange Enterprise Edition

                    ($ 4 166,03 или 148 011,55 p)

                    Local Continuous Replication (LCR)

                    Поддерживается

                    Поддерживается

                    Standby Continuous Replication (SCR)

                    Поддерживается

                    Поддерживается

                    Cluster Continuous Replication (CCR)

                    Не поддерживается

                    Поддерживается

                    Single Copy Cluster (SCC)

                    Не поддерживается

                    Поддерживается

                    Примечание: Стоимость и курс доллара даны на начало марта 2009 года и являются примерными. В данном случае стоимость взята с сайта ms-expert.ru. Точная стоимость зависит от «жадности» продавца.

                    Во-вторых, технология достаточно новая и не включается с помощью графических мастеров.

                    Давайте вообще определимся, что такое технологии высокой доступности и почему может не хватить обычного резервного копирования. При составлении дизайна почтовой инфраструктуры мы всегда определяем процедуры резервного копирования и восстановления. Однако время, затрачиваемое на восстановление из резервной копии, может оказаться неприемлемым для бизнеса. Представим, что устройство, с которого мы будем восстанавливать базу данных почты, имеет скорость восстановления 20 Gb в час. Соответственно для восстановления почтовой базы в 100 Gb (рекомендуемый максимальный размер базы без технологий обеспечения высокой доступности) придется затратить 5-6 часов. По бизнес требованиям это может оказаться недопустимым. При дизайне и составлении соглашения о сервисе бизнес может выдвинуть требования о максимальном времени простоя гораздо меньшим и тогда необходимо обращаться к данным технологиям.

                    Краткий обзор технологий обеспечения высокой доступности.

                    Local Continuous Replication (LCR). Есть два жестких диска на одном сервере (вторым жестким диском может быть, например SAN). База почтовых ящиков работает на одном диске, второй диск хранит пассивную копию базы данных. Первоначально копируется база на второй диск и затем ее идентичность базе на первом диске обеспечивается за счет доставки и применения журналов транзакций. В случае падения первого диска мы имеем возможность восстановить базу со второго диска (например, подключив его под той же буквой или используя Volume Mount Point под тем же именем папки, как и оригинальная база). В отличие от восстановления с резервной копии получается значительный выигрыш во времени восстановления – база уже есть, журналы транзакций на нее применены, остается только настроить ее подключение на место оригинала. Переключение ручное. Рекомендуемый максимальный размер базы – 200 Gb. Точка отказа – жесткий диск. Самая дешевая технология. Журналы транзакции доставляются сразу после их закрытия (по достижении 1 Mb)

                    Cluster Continuous Replication (CCR). Настраивается два сервера в кластер. У каждого узла свой диск. Один узел хранит активную базу, второй пассивную. Идентичность баз обеспечивается за счет доставки и применения логов на пассивный узел. У каждого узла по два сетевых интерфейса. Один для внутренней сети кластера (по ней общаются узлы, чтобы узнать живой ли сосед), второй для обслуживания клиентов (причем оба узла видятся для клиентов как единый IP адрес). Кроме того настраивается сервер-свидетель который служит для корректного автоматического переключения в случае отказа одного из узлов. Переключение автоматическое. Рекомендуемый максимальный размер базы – 200 Gb. Точка отказа – сервер. Технология подороже. Требуется выпуски Windows Server Enterprise Edition и Exchange Server Enterprise Edition, еще как минимум один сервер (свидетелем может быть любой другой сервер даже не с Exchange). Журналы транзакции доставляются сразу после их закрытия (по достижении 1 Mb)

                    Single Copy Cluster (SCC). Кластер в классическом понимании. Есть два компьютера – оба подключены к одному внешнему хранилищу. Оба компьютера могут работать с одной и тоже базой (база то доступна обоим компьютерам), но в один момент времени только один компьютер обслуживает одну базу. В случае его отказа второй компьютер автоматически берет на себя обслуживание базы. У каждого узла по два сетевых интерфейса. Один для внутренней сети кластера (по ней общаются узлы, чтобы узнать живой ли сосед), второй для обслуживания клиентов (причем оба узла видятся для клиентов как единый IP-адрес). Свидетель не требуется. Самая дорогая технология, так как по сравнению с CCR требуется еще определенное железо, которое поддерживает такую кластеризацию. Точка отказа – сервер.

                    Standby Continuous Replication (SCR). Как можно увидеть технологии, которые позволяют избежать неработоспособности в случае отказа сервера до SP 1 были включены только в Enterprise Edition Exchange Server 2007. Local Continuous Replication не обеспечивала доступности в случае отказа сервера, только в случае отказа жесткого диска. В SP1 встроена технология обеспечения доступности в случае отказа сервера в редакции Standard – это SCR. Технология позволяет доставлять транзакционные лог файлы на другой сервер и применять их. В случае падения сервера, несущего нагрузку по обслуживанию рабочей базы – мы можем переключить пользователей на второй сервер уже готовый их обслуживать (он настроен – база есть).

                    Что необходимо учесть:

                    1. Поддерживается сколь угодно много серверов, на которые доставляются журналы в случае с SCR (рекомендуется не более четырех). В LCR и CCR поддерживается только один получатель.

                    2. В случае LCR и CCR журналы транзакций применяются автоматически и практически сразу. В случае SCR по умолчанию журналы транзакции не применяются сразу после доставки – должно выполнится два условия (эту логику частично можно изменить):

                    a. Должно быть доставлено 50 журналов с рабочего сервера.

                    b. Должно пройти 24 часа с момента доставки журналов на сервер – получатель.

                    3. Нельзя использовать разные ОС на источнике и получателе. Например, нельзя, чтобы на источнике была Windows Server 2003 а на получателе Windows Server 2008.

                    4. Как и для LCR и CCR также и для SCR требуется чтобы была только одна база данных в одной группе хранения (Storage Group).

                    Итак, после теоретической части включим и настроим SCR.

                    Часть 1. Настраиваем SCR.

                    В итоге мы должны пройти через следующие этапы:

                    1. Включение SCR

                    2. Имитацию падения рабочей базы

                    3. Восстановление почты из копии.

                    Сценарий. Есть два сервера. Оба под управление Windows Server 2008, на обоих серверах установлен Exchange Server 2007 SP1. Один сервер (SYD-DC1) является рабочим сервером, второй сервер (SYD-EX2) является сервером для копии.

                    image

                    Рис.1 Создаем на рабочем сервере группу хранения:

                    Имя группы SCR-SG, месторасположение E:\ExchDataSCR.

                    Создаем в данной группе хранения почтовую базу SCR-DB

                    image

                    Рис 2. Место хранения E:\ExchDataSCR\SCR-DB.edb

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

                    После подготовки базы, можно в ней завести пользователей, я заведу пользователя для тестирования работоспособности и отработки механизма переключения пользователя. Итак, я завожу пользователя Vasya Pupkin с почтовым ящиком в данной базе (SCR-DB)

                    image

                    Рис.3

                    image

                    Рис.4 Отправляю несколько писем от Администратора и обратно к нашему Васе.

                    Теперь давайте настроим SCR. Как я уже писал, настраивается только с помощью Power Shell. Для настройки репликации необходимо запустить командлет на рабочем сервере :

                    Enable-StorageGroupCopy « группа хранения» -StandbyMachine «имя удаленного сервера»

                    В нашем случае группа хранения SCR-SG, удаленный сервер SYD-EX2. В итоге мы запускаем

                    Enable-StorageGroupCopy SCR-SG -StandbyMachine SYD-EX2

                    image

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

                    Я указал параметр –RelayLagTime и поставил значение 0.0:0:0 (дни.часы:минуты:секунды). Напомню, что по умолчанию для применения журналов транзакций в SCR должно быть выполнено два условия:

                    1. Должно быть доставлено 50 журналов (доставляются как только они зарываются – после достижения размера в 1 Мб).

                    2. Должно пройти 24 часа с момента доставки.

                    Я изменил второй параметр и указал применять сразу после доставки 50 логов. Можно его настроить в диапазоне от 0 секунд до 7 дней. Первый параметр изменить нельзя. Такая задержка была встроена специально. Представим себе, что у Вас повредилась рабочая база, причем ее повреждение было вызвано некорректным письмом. В случае мгновенной доставки и применения логов это некорректное письмо будет отображено во всех базах и все базы будут неработоспособны. При наличии задержки мы можем предусмотреть эту ситуацию и, например не применить на сервере транзакционные лог файлы с некорректным письмом и вернуться к работоспособному состоянию. Эти параметры нельзя изменить в последующем. Для их изменения Вам придется перенастроить SCR.

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

                    Еще один важный момент у меня база на диске E. На сервере получателе должен быть диск с буквой E иначе не создастся SCR. Обратите внимание, что мы на сервере получателе ничего не делали, ни создавали базу данных , ни группу хранения. Единственное требование – идентичная серверу источнику операционная система и наличие диска с такой же буквой, какая у диска на которой хранится боевая база данных.

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

                    image

                    Рис.6

                    Обратите внимание, что на втором сервере в момент выполнения командлета Enable-StorageGroupCopy создалась на диске E папка ExchDataSCR (соответствует названию папки группы хранения рабочего сервера) и в ней появились логи. Причем только логии и самой базы нет (не доставлено еще 50 логов). Логов всего 7.

                    image

                    Рис.7 Я сымитировал ведение деловой переписки Васей

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

                    image

                    Рис.8

                    Стало всего восемь логов на сервере получателе. Также мы можем убедиться в корректности работы SCR с помощью командлета Get-StorageGroupCopyStatus. Обратите внимание, что данный командлет был запущен на сервере-источнике (вверху на синей полосе контекст SYD-DC1)

                    Get-StorageGroupCopyStatus SCR-SG –StanbyMachine Syd-ex2

                    image

                    Рис 9. Командлет проверки состояния SCR на сервере-источнике

                    Причем мы можем выполнить эту команду, как на источнике, так и на сервере получателе. Только на получателе необходимо еще указать имя сервера перед именем группы хранения. Обратите внимание, что данный командлет был запущен на сервере-получателе (вверху на синей полосе контекст SYD-EX2).

                    image

                    Рис 10. Командлет проверки состояния SCR на сервере-получателе.

                    В консоли управления Exchange на сервере получателе Вы не увидите базы SCR-DB.

                    image

                    Рис 11. Консоль управления Exchange на сервере – получателе.

                    Все репликация настроена.

                    Часть 2. А что если все-таки база упадет?

                    Теперь давайте сымитируем падение рабочей базы.

                    Я отмонтирую базу на рабочем сервере и для чистоты эксперимента удалю ее файлы.

                    image

                    Рис. 12 Отмонтированная база на сервере-источнике и удаленные файлы из места расположения базы.

                    Теперь нам необходимо восстановить базу на сервере получателе (SYD-EX2).

                    Для этого необходимо выполнить командлет

                    Restore-StorageGroupCopy SYD-DC\SCR-SG –StandbyMachine SYD-EX2 –Force

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

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

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

                    image

                    Рис. 13 Создание SG на сервере получателе

                    image

                    Рис.14 Создание базы данных на сервере получателе.

                    Далее я запускаю командлеты для переноса путей созданной базы в место, где доставлялись логи с рабочего сервера. Для того, что бы существующая база не затерла доставленные логии и базу я указываю параметр  –ConfigurationOnly

                    Move-StorageGroupPath SYD-EX2\RecoveredSCR-SG -SystemFolderPath E:\ExchDataSCR -LogFolderPath E:\ExchDataSCR –ConfigurationOnly

                    Move-DatabasePath  SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB  -EdbFilePath E:\ExchDataSCR\SCR-DB.edb  –ConfigurationOnly

                    На все вопросы говорю Yes

                    image

                    Рис. 15 Перемещение путей на сервере получателе.

                    База данных находится в отмонтированном состоянии. Для ее подмонтирования я должен поставить галочку «This database can be overwritten by a restore» в свойствах базы или выполнить командлет

                    Set-MailboxDatabase SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB  -AllowFileRestore:$true

                    и подмонтировать базу опять же либо с помощью консоли управления Exchange либо с помощью командлета

                    Mount-Database SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB

                    База готова. Однако у пользователей в AD до сих пор ссылка на место хранения своей почты на сервер SYD-DC1. Нам необходимо провести замену этой ссылки и сказать, что теперь у пользователей база на SYD-EX2. Это делается опять же с помощью командлета Move-Mailbox с добавочкой –ConfigurationOnly.

                    Важно! Необходимо, чтобы перемещались почтовые ящики всех кроме системного помощника Exchange и системные ящики.  Для этого я наберу командлет:

                    Get-Mailbox -Database SYD-DC1\SCR-SG\SCR-DB |where {$_.ObjectClass -NotMatch ‘(SystemAttendantMailbox| ExOleDbSystemMailbox)’}| Move-Mailbox -ConfigurationOnly -TargetDatabase  SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB

                    image

                    Рис.  17 Перемещение почтовых ящиков.

                    Все я готов к работе. Давайте войдем как VasyaPupkin.

                    image

                    Рис. 18 Вся важная деловая переписка сохранена.

                    image

                    Рис. 19 Почтовый ящик пользователя на новой базе.

                    Для пользователя все прозрачно. Если у пользователя Outlook 2003, то необходимо будет еще переуказать путь к новому серверу в его профиле Outlook. Для Outlook 2007 с настроенным Autodiscovery неактуально. Теперь можем опять настроить SCR. Итог.В этой статье мы прошли с Вами через весь процесс создания SCR и познакомились с основными концепциями ее работы.

                    Хочу привести командлеты для настройки:

                    Disable-StorageGroupCopy – Отключает назначение репликации SCR для группы хранения.

                    Get-StorageGroupCopyStatus –  Определяет текущее состояние назначения репликации SCR.

                    New-StorageGroup –  Создает новую группу хранения с поддержкой SCR, при этом не требуется отдельно включать SCR с помощью командлета Enable-StorageGroupCopy.

                    Restore-StorageGroupCopy – Отключает SCR и делает базу данных назначения SCR пригодной для присоединения с помощью операции Mount-Database в процедуре восстановления.

                    Resume-StorageGroupCopy –  Восстанавливает непрерывную репликацию для группы хранения, в которой она была приостановлена.

                    Suspend-StorageGroupCopy – Приостанавливает непрерывную репликацию для группы хранения, в которой она была включена.

                    Update-StorageGroupCopy –  Используется для заполнения целевой группы хранения.

                    Николай Муравлянников, MCITP, MCSE

                    • Настройка безопасности Windows Vista

                      Все чаще и чаще дома и на работе мы используем новую ОС от фирмы Microsoft – Windows Vista.

                      И все чаще перед нами встает вопрос, а как правильно настроить данную ОС с точки зрения безопасности. Читая статьи в Интернет можно увидеть как полезные так и откровенно вредные советы. Постараемся разобраться в этом и определить перечень необходимых мероприятий для настройки вашей Windows Vista с точки зрения безопасности. Именно о защите клиентского компьютера (компьютера домашнего или офисного пользователя) и будет идти речь. Не секрет, что любую атаку гораздо проще начинать именно с клиентского рабочего места. Ведь основное внимание в вопросах защиты традиционно уделяется серверам локальных сетей. Несомненно, на рабочих местах необходима и антивирусная защита и усиленные меры идентификации и аутентификации пользователей. Но все же в первую очередь, с моей точки зрения, необходимо обеспечить защиту с помощью встроенных средств операционной системы.

                      С уважением Безмалый Владимир
                      MVP Consumer Security