Иван Коробко

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

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

Системный администратор не может реализовать весь желаемый функционал, используя только сценарии загрузки, поскольку с их помощью невозможно безопасно выполнить изменения в ветвях реестра 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[1].

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

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

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

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

n  HKEY_CLASSES_ROOT (HKCR);

n  HKEY_CURRENT_USER (HKCU);

n  HKEY_LOCAL_MACHINE (HKLM);

n  HKEY_USER (HKU);

n  HKEY_CURRENT_CONFIG (HKCC).

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

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

Раздел 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_DESCRIPTION	Строка	Идентификатор оборудования
REG_FULL_RESOURCE_LIST	Строка	Идентификатор оборудования

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

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

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

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

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

n  Инвентаризация. Включает в себя сбор информации о регистрирующемся в сети пользователе, рабочей станции и формировании файла отчета.

n  Автоматическое подключение сетевых ресурсов: принтеров и дисков.

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

n  Обеспечение интерактивности работы скрипта. В ходе выполнения скрипта на экране отображается соответствующая информация.

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

Существует несколько языков, предназначенных для создания сценариев загрузки. Среди них стандартными являются сценарии на базе командной строки (файлы с расширением 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 функций и обладает следующим функционалом:

n  вывод информации в виде диалоговых сообщений;

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

n  чтение информации из входного потока;

n  расширенная поддержка редактирования реестра;

n  поддержка INI-файлов;

n  расширенная поддержка операций со строками и массивами;

n  сбор информации о пользователе и рабочей станции;

n  поддержка OLE-объектов;

n  операции с файлами и каталогами;

n  создание ярлыков 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=Все

DESCRIPTION="Консультант+"

 

[W1]

 

SERVER=Second

SHARE=work\department1

ACCESSGROUP1=department1

ACCESSGROUP2=department3

DESCRIPTION="Ресурсы отдела 1"

 

[W2]

 

SERVER=Second

SHARE=work\department2

ACCESSGROUP1=department2

ACCESSGROUP2=

DESCRIPTION="Ресурсы отдела 2"

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

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

n  Чистка локального кэша на рабочей станции, содержащего список групп, в которые входит пользователь. Удаление ветви реестра HKEY_CURRENT_USER\Software\KiXtart.

n  Чтение параметрического файла. Данные рекомендуется помещать в соответствующие массивы. Схема чтения конфигурационного файла приведена на рис. 1.

n  Отключение всех доступных сетевых дисков.

n  Подключение сетевых дисков, на которые данный поль-зователь имеет права.

n  Вывод на экран статистики о подключенных сетевых дисках.

Рисунок 1

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

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

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

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

 

Windows Registry Editor Version 5.00

 

[HKEY_USERS\.DEFAULT\Keyboard Layout\Preload]

"1"="00000409"

"2"="00000419"

 

[HKEY_USERS\.DEFAULT\Keyboard Layout\Toggle]

"Hotkey"="2"

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

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

 

Windows Registry Editor Version 5.00

 

[HKEY_CURRENT_USER\Keyboard Layout\Preload]

"1"="00000409"

"2"="00000419"

 

[HKEY_CURRENT_USER\Keyboard Layout\Toggle]

"Hotkey"="2"

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

Таблица 2

 

Ключи реестра	Описание
[HKEY_CURRENT_USER\Keyboard Layout\Preload] "1"="00000409" "2"="00000419" [HKEY_CURRENT_USER\Keyboard Layout\Toggle] "Hotkey"="2"	Установка языковых настроек рабочего стола пользователя: английского языка по умолчанию и переключение раскладок Ctrl+Shift.
[HKEY_CURRENT_USER\Control Panel\International] sTimeFormat=”HH:mm:ss tt” s1159=”Am” s2359=”Pm”	После текущего времени в правом нижнем углу рабочего стола пишется AM/PM в зависимости от времени суток.
[HKEY_CURRENT_USER\Control Panel\Desktop] "PaintDesktopVersion"=dword:00000001	В нижнем правом углу экрана демонстрируется версия операционной системы
[HKEY_CURRENT_USER\Control Panel\Desktop] "Wallpaper"="desktop.bmp" "WallpaperStyle"="2"	Подменяет картинку на Desktop пользователя, растягивает ее на весь экран.

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

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

n  с помощью стандартных диалоговых окон;

n  с помощью сторонней надстройки KIXTart в виде DLL-библиотеки;

n  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"]

 

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

n  “dialog” – строка, содержащая URL, указывающий на HTML-документ.

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

n  “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 поместить файлы:

n  KIX32.EXE;

n  SCRIPT.KIX;

n  START.BAT

n  KIXWIN.EXE

n  подкаталог 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

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

n  Принцип определения операционной системы основан на том, что в Win9x отсутствует переменная окружения %os%; В Windows 2k переменная %os%=WindowsNT.

n  С помощью строки «start /wait Kix32.exe Script.kix» добиваются последовательной загрузки – сначала скрипт, затем рабочий стол и т. д., а не одновременной. То есть на время выполнения скрипта многозадачность «отключается».

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

n  Для корректной работы 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» (Запускать сценарий скрыто). Для этого необходимо проделать следующее:

n  Зарегистрироваться на сервере с помощью учетной записи, имеющей административные права.

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

Рисунок 3

Рисунок 4

 

n  В загруженной групповой политике (Default Domain Policy) необходимо в «User Configuration» (настройках пользователя) войти в «Administrative Templates» (административные шаблоны).

n  Там выбрать раздел «System» (система), вкладку «logon/logoff» (вход/выход) и включить раннее оговоренные политики (см. рис. 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.
Scripts	Настройка параметров при вкл/выкл компьютера.
Folder Redirection	Управление перенаправлением файлов и папок в сети.

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

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

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

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

n  Комментарии

n  Строки

n  CLASS

n  CATEGORY

n  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 Configuration\Administrative Templates\»; Значение MACHINE соответственно определяет, что политика компьютерная. Изменения будут вноситься в реестр в ветви HKLM, настройку политики следует осуществлять в разделе «Computer Configuration\Administrative Templates\».

CATEGORY

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

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

CATEGORY Name

    KEYMAME SubKey

    ………………………..

END CATEGORY

 

где:

n  Name – это имя папки, которое будет отображаться в редакторе Group Policy. Используйте строковую перемену или строку, заключенную в кавычках.

n  SubKey – является необязательным параметром. Информация о параметрах и конфигурации групповых политик сосредоточена в HKLM\Software\Policies (предпочтительное расположение) или HKLM\Software\Microsoft\Windows\CurrentVersion\Policies для раздела Computer Configration; в HKU\Software\Policies (предпочтительное расположение) или HKU\Software\Microsoft\Windows\CurrentVersion\Policies для раздела User Configration. Не используйте в пути корневой ключ (HKLM, HKU), поскольку он уже описан ключевым словом CLASS. Если путь содержит пробелы, заключайте его в кавычки.

 

Пример 9

 

CLASS USER

CATEGORY "POLICIES"

      CATEGORY !!SubPol1

         KEYNAME "Software\Policies\SubPol1"

      …………………………

      END CATEGORY

 

      CATEGORY !!SubPol2

         KEYNAME "Software\Policies\SubPol1"

      …………………………

      END CATEGORY

END CATEGORY

 

[strings]

SubPol1="Policy1"

SubPol2="Policy2"

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

n  CATEGORY

n  END

n  KEYNAME

n  POLICY

POLICY

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

POLICY Name

[KEYNAME SubKey]

EXPLAIN Help

VALUENAME Value

[PARTS]

……………….

END POLICY

 

где:

n  Name – это название политики, отображаемое в редакторе Group Policy. Используйте строковую переменную или строку, заключенную в кавычках.

n  SubKey является необязательным параметром. Информация о параметрах и конфигурации групповых политик сосредоточена в HKLM\Software\Policies (предпочтительное расположение) или HKLM\Software\Microsoft\Windows\CurrentVersion\Policies для раздела Computer Configration; в HKU\Software\Policies (предпочтительное расположение) или HKU\Software\Microsoft\Windows\Current Version\Policies для раздела User Configration. Не используйте в пути корневой ключ (HKLM, HKU), поскольку он уже описан ключевым словом CLASS. Если путь содержит пробелы, заключайте его в кавычки. Ко всем политикам применяется последнее ключевое слово KEYNAME.

n  Help – эта строка, содержимое которой редактор Group Policy отображает в разделе EXTENDED политики. Для перевода каретки используйте «\n».

n  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, которое может меняться в зависимости от того, включена ли политика.

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

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

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

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

Пример 10

 

CLASS USER

CATEGORY "Admin Policies"

    CATEGORY "Keyboard Toggle "

    KEYNAME ".Default\Keyboard Layout\Toggle"

           POLICY "Toggle Policy"

                 EXPLAIN !!help

                 VALUENAME "Hotkey"

                 VALUEON 2

                 VALUEOFF 1

           END POLICY

    END CATEGORY

END CATEGORY

[strings]

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

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

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

PART Name Type

    Keywords

    [KEYNAME Subkey]

    [DEFAULT Default]

    VALUENAME Name

END PART

 

где:

n  Name – указывается название раздела, которое будет отображено в консоли во время редактирования политики.

n  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	Отображает текстовую строку (метку). Не сохраняет в реестре никаких значений. Отображается только  подсказок в диалоговом окне настройки групповой политики

 

n  Keywords – эта информация специфична для каждого из типов. Дополнительная информация приведена ниже.

n  Subkey – это необязательный подключ HKLM или HKU. Не используйте в пути корневой ключ (HKLM, HKU), поскольку он уже описан ключевым словом CLASS. Если путь содержит пробелы, заключайте его в кавычки.

n  Defaults – это значение параметра по умолчанию. Когда администратор включает политику, то осуществляется считывание параметров по умолчанию.

n  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

 

где:

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

n  Value – название параметра, которое необходимо изменить.

n  Value1 – значение, задаваемое при установленном флажке и включенной политике.

n  Value2 – значение, задаваемое при снятом флажке и включенной политике.

COMBOBOX

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

PART Name COMBOBOX

    SUGGESTIONS

           “Suggestion1”  “Suggestion2” …  “Suggestionm”

    END SUGGESTIONS