Автоматизация процессов в сети::Журнал СА 8.2004
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1420
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1542
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1169
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 911
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1477
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Автоматизация процессов в сети

Архив номеров / 2004 / Выпуск №8 (21) / Автоматизация процессов в сети

Рубрика: Карьера/Образование /  Образование

Иван Коробко ИВАН КОРОБКО

Автоматизация процессов в сети

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

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

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

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

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

Системный администратор может самостоятельно создать файлы – административные шаблоны, содержащие групповые политики (файл с расширением ADM), и применять их к пользователям, входящим в группу/домен (domain), подразделение (Organization Unit, OU).

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

Реестр

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

В Microsoft Windows 3.x все настройки программного обеспечения располагались в файлах инициализации, которые имели расширение INI. Вся конфигурационная информация располагалась в двух файлах: SYSTEM.INI и WIN.INI. При установке любого приложения все его настройки сохранялись в одном из этих файлов. Приложения пользовались небольшим количеством параметров. Главная причина – размер INI-файла, размер которого не должны превышать 64 Кб. Чтобы обойти эти ограничения, для каждой программы создавался свой INI-файл.

Со временем из-за большого количества конфигурационных файлов производительность операционной системы значительно понизилась. В 1993 году была создана операционная система Microsoft Windows NT, в которой множество INI-файлов было заменено единой базой данных – реестром.

С точки зрения файловой системы реестр представляет собой файл с расширением DAT. Для Windows NT/200x реестр хранится в файле NTUSER.DAT, который находится в каталоге %Windir%Profiles.

В Windows 9x реестр состоит из двух файлов: USER.DAT и SYSTEM.DAT, которые хранятся в каталоге %Windir%. USER.DAT содержит настройки индивидуального пользователя, а SYSTEM.DAT – настройки компьютера.

Реестры Windows 9x, NT, 2000 несовместимы друг с другом, однако идея построения реестров едина.

Ветви реестра

Реестр состоит из разделов верхнего уровня, называемых кустами (hives):

  • HKEY_CLASSES_ROOT (HKCR);
  • HKEY_CURRENT_USER (HKCU);
  • HKEY_LOCAL_MACHINE (HKLM);
  • HKEY_USER (HKU);
  • HKEY_CURRENT_CONFIG (HKCC).

Структура реестра такова: в каждом из кустов находятся ключи, в которых содержатся параметры, имеющие значения.

В разделе HKLM находится информация об аппаратном и программном обеспечении, а также сведения о системе безопасности. Этот раздел является одним из самых больших. Раздел HKCR является виртуальной ссылкой на раздел HKLMSoftwareClasses. В нем содержатся сведения обо всех расширениях файлов, определениях типов, ярлыках, привязке, классах идентификаторов и т. д.

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

Изменения в HKU и HKLM можно сделать только с помощью утилиты REGEDT32.EXE в том случае, если у вас ОС Windows 2000, и REGEDIT.EXE – если Windows XP. Пользователь, от имени которого запускаются эти утилиты, должен обладать правами системного администратора.

Раздел HKCU содержит сведения о текущем пользователе и имеет название, соответствующее значению идентификатора безопасности (SID) данного пользователя. Каждый раз при перезагрузке компьютера HKCU создается заново.

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

Раздел HKDD (HKEY_DYN_DATA) не хранится в реестре, а динамически создается при загрузке операционной системы. В нем содержатся сведения о самонастраивающихся устройствах (Plag-and-Play).

Как и любая база данных, реестр поддерживает несколько типов данных:

Таблица 1

Наименование Тип данных Описание
REG_NONE Не определен Зашифрованные данные
REG_SZ Строка Текст, состоящий из алфавитно-цифровых символов
REG_EXPAND_SZ Строка Текст с символическими именами переменных окружения Windows. И при обработке строки вместо имен переменных будут подставляться значения.
REG_BINARY Двоичный Двоичные данные
REG_DWORD Число Цифровые данные
REG_DWORD_BIG_ENDIAN Число Данные с «не-интеловским» порядком байт
REG_LINK Строка Путь к файлу
REG_MULTI_SZ Несколько строк Массив строк
REG_RESOURCE_LIST Строка Список оборудования
  Строка Идентификатор оборудования
REG_FULL_RESOURCE_LIST Строка Идентификатор оборудования

Windows 9x поддерживает следующие типы параметров: REG_BINARY и REG_DWORD, REG_SZ и REG_NONE.

Групповые политики, описанные в ADM-файлах, могут производить операции только со следующими типами данных : REG_SZ, REG_EXPAND_SZ, REG_DWORD.

Сценарий регистрации пользователей в сети

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

Перечислим некоторые задачи, которые могут быть решены с помощью сценария загрузки:

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

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

Существует несколько языков, предназначенных для создания сценариев загрузки. Среди них стандартными являются сценарии на базе командной строки (файлы с расширением BAT, PIF), Windows Script Host (WSH), Microsoft Java Script (JScript), Microsoft Visual Basic Script Edition (VBScript).

Существуют также языки, специально разработанные для создания скриптов, такие как KIXtart, AutoIT, CLRScript, WinBatch.

Из всех этих языков рекомендуется остановить свой выбор на языке KIXtart[2], поскольку, обладая огромными возможностями, он распространяется бесплатно. KIXtart 4.21 поддерживает 48 команд, 56 макросов-функций, более 100 функций и обладает следующим функционалом:

  • вывод информации в виде диалоговых сообщений;
  • подключение сетевых ресурсов;
  • чтение информации из входного потока;
  • расширенная поддержка редактирования реестра;
  • поддержка INI-файлов;
  • расширенная поддержка операций со строками и массивами;
  • сбор информации о пользователе и рабочей станции;
  • поддержка OLE-объектов;
  • операции с файлами и каталогами;
  • создание ярлыков Windows.

Необходимо отметить, что сценарии, созданные на VBScript, Jscript, могут быть легко переписаны на KIXtart.

Рассмотрим подробнее каждую из задач, решаемую скриптом.

Инвентаризация

Решение задачи инвентаризации состоит из нескольких частей – сбора, записи на носитель в определенном формате и обработки информации.

Так или иначе, информация черпается либо из BIOS с помощью программы, либо, что происходит чаще всего, из реестра с помощью стандартных средств ОС Window. Решение задачи инвентаризации c помощью WMI было описано в [1].

Подключение сетевых ресурсов

Сетевыми ресурсами являются сетевые диски и принтеры.

Подключение сетевых принтеров

Вопрос установки, настройки и автоматического подключения сетевых принтеров был подробно освещен в статьях [2], [3].

Подключение сетевых дисков

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

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

В файле в квадратных скобках перечислены названия разделов, которые включают в себя букву, на которую будут монтироваться ресурс и его порядковый номер, присваивающийся для обеспечения возможности подключать на одну и ту же букву разные ресурсы. Каждый раздел содержит пять параметров: название сервера (SERVER), путь к сетевой папке (SHARE), группы безопасности, членам которых будет подключаться ресурс (ACCESSGROUP1 и ACCESSGROUP2), описание ресурса (DESCRIPTION). Пример файла приведен ниже:

Пример 1

[L1]  

SERVER=Main

SHARE=Consultant

ACCESSGROUP1=everyone

ACCESSGROUP2=Все

[W1]

SERVER=Second

SHARE=workdepartment1

ACCESSGROUP1=department1

ACCESSGROUP2=department3

[W2]

SERVER=Second

SHARE=workdepartment2

ACCESSGROUP1=department2

ACCESSGROUP2=

Таким образом, на основе данных, прочитанных сценарием из примера, всем пользователям будет подключен «Консультант+» на букву «L», находящийся по пути mainconsultant. Пользователям, являющимся членами групп departament1, departament2, departament3, будет подключен диск W. Для членов групп departament1, departament3 подключается ресурс по адресу: secondworkdepartament1, для departament2 – secondworkdepartament2.

Сценарий, обеспечивающий автоматическое управление подключением сетевых дисков работает по следующей схеме:

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

Рисунок 1

Рисунок 1

Автоматическое конфигурирование рабочей станции

Поскольку скрипт выполняется от имени пользователя, который не обладает правами системного администратора, то изменения могут быть внесены только в ветвь HKCU. В этом разделе хранятся сведения о текущем зарегистрированном пользователе, и он имеет название, соответствующее значению идентификатора безопасности (SID) текущего пользователя. Каждый раз при перезагрузке компьютера раздел создается заново на основе данных, считанных из HKU. Автоматическое конфигурирование ветви HKU выполняется с помощью групповых политик и будет рассмотренно позже. Изменения в ветви HKCU осуществляется с помощью скрипта.

Ветвь HKCU не является точной копией HKU. Приведем наглядный пример. После запуска Windows 2k пользователь видит сообщение, в котором предлагается одновременно нажать CTRL+ALT+DEL. Нажав эту комбинацию клавиш, ему предлагается ввести имя учетной записи, пароль. Информация о языковых настройках в этом диалоговом окне, а именно язык по умолчанию и комбинация клавиш, с помощью которой осуществляется переключение между раскладками клавиатуры, хранится в ветви HKEY_USERS.DEFAULTKeyboard Layout.

Пример 2. По умолчанию установлен английский язык, переключение между раскладками клавиатур осуществляется нажатием CTRL+SHIFT.

Windows Registry Editor Version 5.00

[HKEY_USERS.DEFAULTKeyboard LayoutPreload]

"1"="00000409"

"2"="00000419"

[HKEY_USERS.DEFAULTKeyboard LayoutToggle]

"Hotkey"="2"

Однако аналогичная ветвь в ветви HKСU (см. пример 3) отвечает за управление языковыми настройками рабочего стола пользователя. В данном случае нет никакой взаимосвязи между настройками ветвей HKU и HKCU.

Пример 3. По умолчанию установлен английский язык, переключение между раскладками клавиатур осуществляется нажатием CTRL+SHIFT.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USERKeyboard LayoutPreload]

"1"="00000409"

"2"="00000419"

[HKEY_CURRENT_USERKeyboard LayoutToggle]

"Hotkey"="2"

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

Таблица 2

Ключи реестра Описание
[HKEY_CURRENT_USERKeyboard LayoutPreload]
"1"="00000409"
"2"="00000419"

[HKEY_CURRENT_USERKeyboard LayoutToggle]
"Hotkey"="2"
Установка языковых настроек рабочего стола пользователя: английского языка по умолчанию и переключение раскладок Ctrl+Shift.
[HKEY_CURRENT_USERControl PanelInternational]
sTimeFormat=”HH:mm:ss tt”
s1159=”Am”
s2359=”Pm”
После текущего времени в правом нижнем углу рабочего стола пишется AM/PM в зависимости от времени суток.
[HKEY_CURRENT_USERControl PanelDesktop]
"PaintDesktopVersion"=dword:00000001
В нижнем правом углу экрана демонстрируется версия операционной системы

[HKEY_CURRENT_USERControl PanelDesktop]
"Wallpaper"="desktop.bmp"
"WallpaperStyle"="2"

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

Обеспечение интерактивности работы скрипта

Сценарии на языке KIXTart можно визуализировать по крайней мере тремя способами:

  • с помощью стандартных диалоговых окон;
  • с помощью сторонней надстройки KIXTart в виде DLL-библиотеки;
  • c помощью сторонней утилиты, передающей параметры из KIXTart в HTML-файл.

Рассмотрим все три способа.

Визуализация работы скрипта с помощью стандартных диалоговых окон

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

Визуализация скрипта с помощью сторонней надстройки KIXTart в виде DLL-библиотеки

Визуализация и интерактивность работы скрипта реализуются с помощью специально созданной для этих целей надстройкой – KIXForms 3.2 или KIXGui 1.1.Обе программы можно загрузить с сайта http://www.kixtart.org. У этих программ есть только один недостаток: для корректной работы визуализационной части необходимо на рабочей станции зарегистрировать соответствующую DLL-библиотеку. Для регистрации этой библиотеки необходимо обладать правами администратора. Конечно, можно создать MSI-архив, который будет централизованно распространяться по сети с помощью групповых политик, но это неудобно. Визуализировать работу сценария, таким образом, выгодно только в небольших сетях с маленьким количеством рабочих станций.

Визуализация работы скрипта c помощью сторонней утилиты, передающей параметры из KIXTart в HTML-файл

Этот способ мне кажется наиболее оптимальным для реализации визуализации и интерактивности работы скрипта в крупных сетях, поскольку утилита самодостаточна и представляет собой файл с расширением EXE, который рекомендуется располагать в каталоге Netlogon, вместе со скриптом. В качестве такой утилиты лучше использовать KixWin 1.1 (http://www.kixtart.org). И вызывать ее из скрипта с набором параметров.

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

Раздробление скрипта на две части является основным недостатком данного варианта. DHTML-файл вместе с сопутствующими ему файлами (GIF, JPEG, CSS) рекомендуется располагать в скрытой сетевой папке. DHTML-файл содержит в себе сценарии, созданные с помощью VBScript или JScript.

Приведем синтаксис утилиты и фрагмент DHTML-файла:

kixwin "dialog" ["arguments"] ["options"]

Описание параметров:

  • dialog” – строка, содержащая URL, указывающий на HTML-документ.
  • arguments” – строка, содержащая параметры, передаваемые из KIX в HTML. Для разделения параметров в HTML-файле используют строку window.dialogArguments. split(«;»). В данном примере разделителем параметров является «;».
  • style” – строка, которая определяет оформление диалогового окна. Используются один или несколько из следующих параметров стиля:

dialogHeight:sHeight

dialogLeft:sXPos

dialogTop:sYPos

dialogWidth:sWidth

center:{ yes | no | 1 | 0 | on | off }

dialogHide:{ yes | no | 1 | 0 | on | off }

edge:{ sunken | raised }

help:{ yes | no | 1 | 0 | on | off }

resizable:{ yes | no | 1 | 0 | on | off }

scroll:{ yes | no | 1 | 0 | on | off }

status:{ yes | no | 1 | 0 | on | off }

unadorned:{ yes | no | 1 | 0 | on | off }

Логическое разделение передаваемых параметров осуществляется с помощью заранее оговоренного символа. DHTML возвращает в KIX код ошибки после обработки кода в виде целого числа макросу @ERROR в случае успешного завершения операции @ERROR=0.

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

Пример 4

shell '%0/../kixwin.exe $html "$system_info ^ $hardware_info ^ Установленные программы: $en $prog \

^ Подключенные сетевые диски:$en $n1 ^ Подключенные сетевые принтеры:$en $n2" "scroll:off;resizable:on"'

Как отмечалось ранее, параметры передаются DHTML-странице, содержащей вставки на VBScript. Наличие вставок позволяет сделать DHTML-страницу интерактивной для пользователя. Чтение параметров, передаваемых из сценария загрузки, осуществляется по следующей схеме:

Пример 5

<Script Language="JavaScript">

var argv;

argv = window.dialogArguments.split("^");

document.all.parametr0  = argv[0];

</Script>

Внедрение скрипта в эксплуатацию

Скрипт выполняется каждый раз при регистрации пользователя в сети, если он указан в разделе Profile свойствах пользователя (см. рис. 2) службы Active Directory: Users and Computers.

Для автоматизации установки KIXtart на рабочих станциях домена предлагается следующее: в папку Netlogon поместить файлы:

  • KIX32.EXE;
  • SCRIPT.KIX;
  • START.BAT
  • KIXWIN.EXE
  • подкаталог Win9x, содержит файлы KX16.DLL и KX32.DLL

В скрытую сетевую папку скопировать DHTML- файл и все сопутствующие ему файлы.

В ходе выполнения файла START.BAT определяется тип операционной системы, установленной на рабочей станции, и запускается скрипт. В зависимости от версии ОС происходит копирование файлов, необходимых для поддержки KIX этой операционной системой.

Пример 6

@ECHO OFF

if c:\%os%==c:\goto win9x

if not c:\%os%==c:\goto winnt

:winnt

start /wait Kix32.exe Script.kix

goto kix

:win9x

copy %0\..\win9x\*.dll c:\windows\system /y

%0\..\Kix32.exe %0\..\Script.kix

goto kix

:kix

@echo End Of Batch File

Рисунок 2

Рисунок 2

Пояснения к синтаксису файла START.BAT:

  • Принцип определения операционной системы основан на том, что в Win9x отсутствует переменная окружения %os%; В Windows 2k переменная %os%=WindowsNT.
  • С помощью строки «start /wait Kix32.exe Script.kix» добиваются последовательной загрузки – сначала скрипт, затем рабочий стол и т. д., а не одновременной. То есть на время выполнения скрипта многозадачность «отключается».
  • Это делается для того, чтобы до окончания действия скрипта дальнейшая загрузка операционной системы не производилась.
  • Для корректной работы Win9x в качестве пути к файлу необходимо указывать «%0\..\filename.ext». Windows XP не воспринимает относительного пути «%0/./», поэтому для Windows семейства 2k необходимо указать только имя файла, который находится в папке Netlogon.

На время выполнения скрипта необходимо скрыть CMD-панель, в которой выполняется cкрипт, и приостановить загрузку рабочего стола до окончания всего скрипта. Этого результата добиваются с помощью групповой политики, распространяющейся на домен («Default Domain Controllers Policy»). В разделе групповой политики «User Configuration» необходимо соответственно включить «Run legacy logon script synhronously» (Запускать сценарий загрузки синхронно) и «Run legasy script hidden» (Запускать сценарий скрыто). Для этого необходимо проделать следующее:

  • Зарегистрироваться на сервере с помощью учетной записи, имеющей административные права.
  • Загрузить в Active Directory Users and Computers («Start –> Programs –> Administrative Tools») и войти в свойства контроллера домена (см. рис. 3). Перейти во вкладку вкладку «Group Policy» и зарузить «Default Dоmain Policy» (см. рис. 4).

Рисунок 3

Рисунок 3

Рисунок 4

Рисунок 4

  • В загруженной групповой политике (Default Domain Policy) необходимо в «User Configuration» (настройках пользователя) войти в «Administrative Templates» (административные шаблоны).
  • Там выбрать раздел «System» (система), вкладку «logon/logoff» (вход/выход) и включить раннее оговоренные политики (см. рис. 5).

Рисунок 5

Рисунок 5

Групповые политики

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

Реализации всех возможностей групповых политик добиваются их совместным использованием с Active Directory (AD) при условии, что в качестве рабочих станций используется ОС Windows 2000. Политики могут быть применены к следующим объектам AD: сайт (site), домен (domain), подразделение (Organization Unit, OU). Дополнительно групповые политики могут быть применены к таким объектам, как группа безопасности, соответственно к пользователям, входящим в эту группу.

Групповые политики включают в себя следующие компоненты:

Таблица 3

Компонент Описание
Administrative Templates Политики, действия которых основано на изменении ветвей HKLM, HCU реестра.
Security Settings Настройка безопасности для следующих объектов: домена, компьютеров, пользователей.
Software Installation Управление централизованной установкой программ из MSI-архивов.
Internet Explorer Malignance Настройка браузера IE.
  Настройка параметров при вкл/выкл компьютера.
Folder Redirection Управление перенаправлением файлов и папок в сети.

С помощью политик, как говорилось ранее, можно корректировать только ветви реестра HKLM и HKU. В консоли групповых политик (см. рис. 5), вызываемой с помощью команды GPEDIT.MSC, все политики логически делятся на две части: Computer Configuration и User Configuration. В разделе Computer Configuration сосредоточены политики, посредством которых изменяется ветвь реестра HKLM, в разделе User Configuration соответственно HKU. Информация о параметрах и конфигурации групповых политик сосредоточена в HKLMSoftwarePolicies (предпочтительное расположение) или HKLMSoftwareMicrosoftWindowsCurrentVersionPolicies для раздела Computer Configration; в HKUSoftwarePolicies (предпочтительное расположение) или HKUSoftwareMicrosoftWindowsCurrentVersionPolicies для раздела User Configration.

Административные шаблоны. Синтаксис

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

Синтаксис языка включает в себя следующие ключевые компоненты:

  • Комментарии
  • Строки
  • CLASS
  • CATEGORY
  • POLICY

Комментарии

Комментарии полезно использовать для документирования содержимого создаваемого шаблона. Комментарии предваряют точкой с запятой (;) или двумя прямыми слэшами (//). Комментарии также можно помещать в конце строки. Приведем пример комментария:

Пример 7

; Это комментарий

// И это комментарий

CLASS USER       // Определение класса USER, отвечающего за пользовательские  настройки

CLASS MACHINE    // Определение класса MACHINE, отвечающего за общекомпьютерные  настройки

Строки

Все возможные словесные описания – описание политики, названия разделов, параметров и т. д. рекомендуется располагать в специально предназначенном разделе [strings]. В тексте политики перед переменной, ссылающейся на текст в разделе [strings], ставят два восклицательных знака (!!). Каждая строка в разделе [strings] имеет формат name=«строка». Приведем два равнозначных примера. В первом примере не будем использовать преимущества строк.

Пример 8а)

CLASS Machine

POLICY "Пример политики"

………………

END POLICY

Пример 8б)

CLASS Machine

POLICY !!Pname

………………

END POLICY

[Strings]

Pname="Пример политики"

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

CLASS

Первым элементом в файле, содержащем шаблон групповой политики, является ключевое слово CLASS, которое определяет, к какому типу относится описываемая ниже политика: компьютерная (Computer Configuration) или пользовательская (User Configuration). В одном файле допускается многократное использование ключевого слова CLASS. Приведем пример синтаксиса элемента CLASS:

CLASS Name

где Name может иметь одно из двух значений: USER или MACHINE. Значение USER определяет, что политика пользовательская. Изменения будут вноситься в реестр в ветви HKU, настройку политики следует осуществлять в разделе «User ConfigurationAdministrative Templates»; Значение MACHINE соответственно определяет, что политика компьютерная. Изменения будут вноситься в реестр в ветви HKLM, настройку политики следует осуществлять в разделе «Computer ConfigurationAdministrative Templates».

CATEGORY

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

Приведем пример синтаксиса элемента CATEGORY:

CATEGORY Name

    KEYMAME SubKey

    ………………………..

END CATEGORY

где:

  • Name – это имя папки, которое будет отображаться в редакторе Group Policy. Используйте строковую перемену или строку, заключенную в кавычках.
  • SubKey – является необязательным параметром. Информация о параметрах и конфигурации групповых политик сосредоточена в HKLMSoftwarePolicies (предпочтительное расположение) или HKLMSoftwareMicrosoftWindowsCurrentVersionPolicies для раздела Computer Configration; в HKUSoftwarePolicies (предпочтительное расположение) или HKUSoftwareMicrosoftWindowsCurrentVersionPolicies для раздела User Configration. Не используйте в пути корневой ключ (HKLM, HKU), поскольку он уже описан ключевым словом CLASS. Если путь содержит пробелы, заключайте его в кавычки.

Пример 9

CLASS USER

CATEGORY "POLICIES"

      CATEGORY !!SubPol1

         KEYNAME "SoftwarePoliciesSubPol1"

      …………………………

      END CATEGORY

 

      CATEGORY !!SubPol2

         KEYNAME "SoftwarePoliciesSubPol1"

      …………………………

      END CATEGORY

END CATEGORY

[strings]

SubPol1="Policy1"

SubPol2="Policy2"

Рисунок 6

Рисунок 6

В разделе CATEGORY могут быть использованы следующие ключевые слова:

  • CATEGORY
  • END
  • KEYNAME
  • POLICY

POLICY

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

POLICY Name

[KEYNAME SubKey]

EXPLAIN Help

VALUENAME Value

[PARTS]

……………….

END POLICY

где:

  • Name – это название политики, отображаемое в редакторе Group Policy. Используйте строковую переменную или строку, заключенную в кавычках.
  • SubKey является необязательным параметром. Информация о параметрах и конфигурации групповых политик сосредоточена в HKLMSoftwarePolicies (предпочтительное расположение) или HKLMSoftwareMicrosoftWindowsCurrentVersionPolicies для раздела Computer Configration; в HKUSoftwarePolicies (предпочтительное расположение) или HKUSoftwareMicrosoftWindowsCurrent VersionPolicies для раздела User Configration. Не используйте в пути корневой ключ (HKLM, HKU), поскольку он уже описан ключевым словом CLASS. Если путь содержит пробелы, заключайте его в кавычки. Ко всем политикам применяется последнее ключевое слово KEYNAME.
  • Help – эта строка, содержимое которой редактор Group Policy отображает в разделе EXTENDED политики. Для перевода каретки используйте « ».
  • Value – каждая политика содержит ключевое слово VALUENAME, которое связывает с ней значение реестра. По умолчанию редактор политик предполагает, что это значение переменной типа REG_DWORD равно 1 (0х01), когда политика включена. Редактор политики удаляет значение, если политика выключена. В том случае, если необходимо его сохранить в реестре после удаления политики, то необходимо использовать ключевые слова VALUEON и VALUEOFF, которые следуют непосредственно за словом VALUENAME:

VALUEON [NUMERIC] VValue

VALUEOFF [NUMERIC] VValue

По умолчанию тип данных значение VValue REG_SZ. Если после ключевого слово указано NUMERIC, то тип данных значение VValue – REG_DWORD.

Программирование интерфейса политик безопасности

Программирование интерфейса групповых политик сводится к созданию раскрывающихся списков, флажков, текстовых полей и т. д. Рассмотрим по порядку процедуры создания всех элементов интерфейса.

1) В первом варианте, самом простом, нет никаких управляющих элементов, кроме опции «Вкл/Выкл политику». В файле политики записан ключ реестра и значение, имеющее тип REG_SZ или REG_DWORD, которое может меняться в зависимости от того, включена ли политика.

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

За переключение раскладки языка отвечает параметр «Hotkey», размещающийся в разделе «HKEY_USERKeyboard LayoutToggle» и принимающий значение 2 (CTRL+SHIFT) или 1 (ALT+SHIFT). Параметр «Hotkey» имеет тип данных REG_SZ.

Приступим к созданию политики. Поскольку необходимо редактировать ветвь реестра HKU, то политика является пользовательской и будет создана в разделе «User ConfigurationAdministrative Templates». Исходя из этого, политика принадлежит к классу USER.

Параметр KEYNAME раздела CATEGORY, исходя из поставленной задачи, принимает значение «Keyboard LayoutToggle». В разделе POLICY параметр VALUENAME – «Hotkey». VALUEON – 2, а VALUEOFF – 1. Таким образом, политика выглядит следующим образом:

Пример 10

CLASS USER

CATEGORY "Admin Policies"

    CATEGORY "Keyboard Toggle "

    KEYNAME ".DefaultKeyboard LayoutToggle"

           POLICY "Toggle Policy"

                 EXPLAIN !!help

                 VALUENAME "Hotkey"

                 VALUEON 2

                 VALUEOFF 1

           END POLICY

    END CATEGORY

END CATEGORY

[strings]

help="Управление переключением раскладки клавиатуры при регистрации пользователя в сети При включенной политике переключение

раскладки клавиатуры осуществляется с помощью комбинации клавиш CTRL+SHIFT, при выключенной – ALT+SHIFT."

2) Все остальные элементы интерфейса – флажки, выпадающие меню и т. д. можно реализовать только в разделе PART, являющемся членом раздела POLICY. Рассмотрим подробнее синтаксис раздела PART:

PART Name Type

    Keywords

    [KEYNAME Subkey]

    [DEFAULT Default]

    VALUENAME Name

END PART

где:

  • Name – указывается название раздела, которое будет отображено в консоли во время редактирования политики.
  • Type – может быть одним из следующих типов:

Таблица 4

Тип Описание Тип данных
CHECKBOX Отображает флажок. При установленном флажке принимает значение 1, при снятом – 0; REG_DWORD
COMBOBOX Отображает список с полем ввода REG_SZ (по умолчанию), REG_EXPAND_SZ (при наличии метки EXPANDABLETEXT)
DROPDOWNLIXT Отображает раскрывающийся список с полем ввода. Пользователь может выбрать только одно из заданных значений
EDITTEXT Отображает текстовое поле, в котором можно вводить буквы и цифры
LISTBOX Отображает список с кнопками Add и Remove. REG_SZ
NUMERIC Отображает текстовое поле, позволяющее вводить только число REG_DWORD
TEXT Отображает текстовую строку (метку). Не сохраняет в реестре никаких значений. Отображается только  подсказок в диалоговом окне настройки групповой политики
  • Keywords – эта информация специфична для каждого из типов. Дополнительная информация приведена ниже.
  • Subkey – это необязательный подключ HKLM или HKU. Не используйте в пути корневой ключ (HKLM, HKU), поскольку он уже описан ключевым словом CLASS. Если путь содержит пробелы, заключайте его в кавычки.
  • Defaults – это значение параметра по умолчанию. Когда администратор включает политику, то осуществляется считывание параметров по умолчанию.
  • Value – модифицируемое значение реестра. Тип и данные значения полностью зависят от типа параметра.

CHECKBOX

Ключевое слово CHECKBOX отображает флажок. По умолчанию флажок сброшен. Если требуется, чтобы изначально флажок был установлен, необходимо в теле раздела PART указать ключевое слово DEFCHECKED. При установленном флажке в реестр записывается значение 1, если сброшен – 0.

В реестре по умолчанию представлен значением типа REG_SZ. Если необходимо записать данные в реестр в формате REG_DWORD, то необходимо после значений ключевых слов VALUEON и VALUEOFF добавить NUMERIC.

Приведем синтаксис элемента CHECKBOX:

PART Name CHECKBOX

    [DEFCHEKED]

           VALUENAME Value

           VALUEON [NUMERIC] Value1

           VALUEOFF [NUMERIC] Value2

END PART

где:

  • Name – указывается название раздела, которое будет отображено в консоли во время редактирования политики. Если в названии раздела встречаются пробелы, заключите его в кавычки.
  • Value – название параметра, которое необходимо изменить.
  • Value1 – значение, задаваемое при установленном флажке и включенной политике.
  • Value2 – значение, задаваемое при снятом флажке и включенной политике.

COMBOBOX

Ключевое слово COMBOBOX добавляет в диалоговое окно политики список с текстовым полем. Внутри COMBOBOX включен обязательный блок SUGGESTIONS, заканчивающийся инструкцией SUGGESTIONS. Внутри этого блока перечислены элементы. Элементы разделяются пробелами, элементы, имеющие пробелы, помещаются в кавычки (см. синтаксис).

PART Name COMBOBOX

    SUGGESTIONS

           “Suggestion1”  “Suggestion2” …  “Suggestionm”

    END SUGGESTIONS

                 [DEFAULT Default]

                 [EXPANDABLETEXT]

                 [MAXLENGHT] Max

                 [NOSORT]

                 [REQUIRED]

           VALUENAME Value

END PART

где:

  • DEFAULT – указывает значение списка по умолчанию.
  • EXPANDABLETEXT – создает значение типа REG_EXPAND_SZ.
  • MAXLENGHT – указывает максимальную длину строки.
  • NOSORT – отключает сортировку списка редактором политик.
  • REQUIRED – указывает обязательное значение.
  • Name – указывается название раздела, которое будет отображено в консоли во время редактирования политики.
  • Suggestions – список элементов, помещающихся в раскрывающийся список. Все элементы, содержащие пробелы, помещаются в кавычки. Элементы списка разделяются пробелами.
  • Default – значение по умолчанию. Считывается при включении политики.
  • Max – максимальная длина данных значения.
  • Value – модифицируемое значение реестра. По умолчанию имеет тип данных REG_SZ.

DROPDOWNLIST

Ключевое слово DROPDOWNLIST добавляет в диалоговое окно политики раскрывающийся список. Внутри DROP DOWNLIST включен обязательный блок ITEMLIST, заканчивающийся инструкцией END ITEMLIST. Внутри этого блока перечислены элементы раскрывающегося списка (см. синтаксис).

Приведем синтаксис элемента DROPDOWNLIST:

PART Name DROPDOWNLIST

    ITEMLIST

           NAME Item VALUE Data

    END ITEMLIST

                 [DEFAULT Default]

                 [EXPANDABLETEXT]

                 [NOSORT]

                 [REQUIRED]

           VALUENAME Value

END PART

где:

  • DEFAULT – указывает значение раскрывающегося списка по умолчанию.
  • EXPANDABLETEXT – создает значение типа REG_EXPAND_SZ.
  • NOSORT – отключает сортировку списка редактором политик.
  • REQUIRED – указывает обязательное значение.
  • Name – указывается название раздела, которое будет отображено в консоли во время редактирования политики.
  • Item – имя каждого из элементов раскрывающегося списка.
  • Data – значение, соответствующее отображаемому элементу Item.
  • Default – значение по умолчанию. Считывается при включении политики.
  • Value – модифицируемое значение реестра. По умолчанию имеет тип данных REG_SZ.

EDITTEXT

Ключевое слово EDITTEXT позволяет вводить в текстовом поле информацию, состоящую из букв и цифр. По умолчанию редактор политик сохраняет этот текст в значении типа REG_SZ. Приведем синтаксис элемента EDITTEXT:

PART Name EDITTEXT

    [DEFAULT Default]

    [EXPANDABLETEXT]

    [MAXLENGHT] Max

    [NOSORT]

    [REQUIRED]

           VALUENAME Value

END PART

где:

  • DEFAULT – указывает значение списка по умолчанию.
  • EXPANDABLETEXT – создает значение типа REG_EXPAND_SZ.
  • MAXLENGHT – указывает максимальную длину строки.
  • REQUIRED – указывает обязательное значение.
  • Name – указывается название раздела, которое будет отображено в консоле во время редактирования политики.
  • Default – значение по умолчанию. Считывается при включении политики.
  • Max – максимальная длина данных значения.
  • Value – модифицируемое значение реестра. По умолчанию имеет тип данных REG_SZ.

LISTBOX

Ключевое слово LISTBOX добавляет в диалоговое окно политик список с кнопками Add и Remove. Это единственный тип, который может быть использован системным администратором для управления несколькими значениями, содержащимися в одном ключе. В разделе LISTBOX невозможно использовать опцию VALUENAME, поскольку он не связан с каким-либо конкретным значением.

Приведем синтаксис элемента LISTBOX:

PART Name LISTBOX

    [EXPANDABLETEXT]

    [NOSORT]

    [ADDITIVE]

    [EXPLICITVALUE| VALUEPREFIX Prefix]

END PART

где:

  • EXPANDABLETEXT – создает значение типа REG_EXPAND_SZ.
  • NOSORT – отключает сортировку списка редактором политик.
  • ADDITIVE – считывает значения, уже хранящиеся в реестре.
  • EXPLICITVALUE – ключевое слово позволяет указать имя и данные значения. Отображаемый список имеет два столбца: один для имени, другой – для данных. Невозможно использовать эту инструкцию совместно с VALUEPREFIX.
  • VALUEPREFIX – указанный префикс определяет имена значений. Если указывается префикс, то редактор групповых политик добавляет к нему возрастающий номер. В том случае, если префикс пустой, генерируются только возрастающие номера.
  • Name – указывается название раздела, которое будет отображено в консоли во время редактирования политики.
  • Prefix – используется для генерации последовательности имен. Если указан префикс, например Sample, то генерируются следующие имена значений: Sample1, Sample2,..Samplen. Если префикс не указан, то генерируются только порядковые номера: 1,2,3,…n.

NUMERIC

Ключевое слово NUMERIC позволяет вводить буквенно-цифровой текст, используя элемент управления «счетчик», который увеличивает или уменьшает число. По умолчанию переменные имеют тип данных REG_DWORD, однако, используя инструкцию TXTCONVERT, данные могут быть сохранены в формате REG_SZ.

Приведем синтаксис элемента LISTBOX:

PART Name NUMERIC

                 [DEFAULT Default]

                 [MAX Max]

                 [MIN Min]

                 [REQUIRED]

                 [SPIN]

                 [TXTCONVERT]

           VALUENAME Value

END PART

где:

  • DEFAULT – указывает значение списка по умолчанию.
  • REQUIRED – указывает обязательное значение.
  • SPIN – указывается шаг арифметической прогрессии. По умолчанию равен 1. Указанное значение 0 делает счетчик невидимым.
  • TXTCONVERT – по умолчанию значения имеют тип данных REG_DWORD. Используйте эту инструкцию, чтобы сохранить данные в формате REG_SZ.
  • Name – указывается название раздела, которое будет отображено в консоли во время редактирования политики.
  • Default – значение по умолчанию. Считывается при включении политики.
  • Max – максимальное значение. По умолчанию равно 9999.
  • Min – минимальное значение. По умолчанию равно 0.
  • Value – модифицируемое значение реестра. По умолчанию имеет тип данных REG_DWORD.

TEXT

Ключевое слово TEXT добавляет в диалоговое окно статический текст.

Приведем синтаксис элемента TEXT:

PART Text TEXT

END PART

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

Практика использования административных шаблонов

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

Пример 11

CLASS Machine

CATEGORY "Office 200"

KEYNAME "SoftwarePolicies"

POLICY "Office2000"

EXPLAIN !!help

    PART "Parametr1" EDITTEXT

    KEYNAME "SOFTWAREClassesInstallerProductsї

           914000001E872D116BF00006799C897ESourceList"

    VALUENAME LastUsedSource

    MAXLEN 100  

    EXPANDABLETEXT

    END PART

PART !!help1 TEXT

END PART

    PART "Parametr2" EDITTEXT

    KEYNAME "SOFTWAREClassesInstallerProductsї

           914000001E872D116BF00006799C897ESourceListNet"

    VALUENAME 1

    MAXLEN 100  

    EXPANDABLETEXT

    END PART

PART !!help2 TEXT

END PART

END POLICY

END CATEGORY

[strings]

help1="Exapmle1: n;3;ServersoftwareOffice2000"

help2="Exapmle2: ServersoftwareOffice2000"

help=" Correcting path to Microsoft Office 2000"

Рисунок 7

Рисунок 7

Внедрение административных шаблонов

Для загрузки ADM-файла, содержащего политику, необходимо выполнить следующие действия:

  • Загрузить консоль групповых политик, выполнив команду GPEDIT.MSC.
  • В любом из разделов («Computer ConfigurationAdminist-rative Templates» или «User ConfigurationAdministrative Templates») вызвать контекстное меню, используя однократное нажатие на правую кнопку мыши.
  • В появившемся меню выбрать «Add/Remove Templates…».
  • В загрузившемся диалоговом окне нажать кнопку «Add». В появившемся окне, указав путь к файлу с расширением ADM, нажать кнопку «Open».
  • Нажать кнопку «Close». После нажатия на эту кнопку программа проверит синтаксис файла. В том случае, если будет допущена синтаксическая ошибка, интерпретатор укажет номер строки, в которой она присутствует, и возможный вариант исправления.

Удаление административного шаблона

Для удаления политики, подгруженной с помощью ADM-файла, необходимо выполнить действия в следующем порядке:

  • Загрузить консоль групповых политик, выполнив команду GPEDIT.MSC.
  • В любом из разделов («Computer ConfigurationAdminist-rative Templates» или «User ConfigurationAdministrative Templates») вызвать контекстное меню, используя однократное нажатие на правую кнопку мыши.
  • В появившемся меню выбрать «Add/Remove Templates…».
  • В загрузившемся диалоговом окне выбрать файл, в котором описана политика, которую необходимо удалить. Нажать кнопку «Remove», затем «Close».

Заключение

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


Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru