 |
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Автоматизация процессов в сети
Автоматизация процессов в сети В повседневной работе системному администратору необходимо многократно выполнять одни и те же рутинные действия. Для облегчения собственного бытия имеет смысл автоматизировать следующие процессы: управление сетевыми ресурсами (автоматическое отключение/подключение сетевых принтеров и дисков в зависимости от членства пользователей в соответствующей группе безопасности), конфигурирование рабочей станции, сбор информации об аппаратном и программном обеспечении рабочих станций (решение задачи инвентаризации). Так или иначе, решение задач этого круга сводится к чтению/записи данных реестра. Управление реестром осуществляется с помощью нескольких инструментов, которые будут рассмотрены в настоящей статье. Основными из них являются сценарии регистрации пользователей в сети (сценарии загрузки или скрипты) и групповые политики. Системный администратор не может реализовать весь желаемый функционал, используя только сценарии загрузки, поскольку с их помощью невозможно безопасно выполнить изменения в ветвях реестра 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):
Структура реестра такова: в каждом из кустов находятся ключи, в которых содержатся параметры, имеющие значения. В разделе 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
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 функций и обладает следующим функционалом:
Необходимо отметить, что сценарии, созданные на 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. Сценарий, обеспечивающий автоматическое управление подключением сетевых дисков работает по следующей схеме:
Рисунок 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
Обеспечение интерактивности работы скрипта Сценарии на языке KIXTart можно визуализировать по крайней мере тремя способами:
Рассмотрим все три способа. Визуализация работы скрипта с помощью стандартных диалоговых окон Пользователю выводится информация на экран в виде сообщения. Этот метод рекомендуется использовать в начале сценария, чтобы уведомить пользователя о начале работы скрипта. Основным недостатком этого метода визуализации является полное отсутствие интерактивности работы сценария. Визуализация скрипта с помощью сторонней надстройки 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"] Описание параметров:
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 поместить файлы:
В скрытую сетевую папку скопировать 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 Пояснения к синтаксису файла START.BAT:
На время выполнения скрипта необходимо скрыть CMD-панель, в которой выполняется cкрипт, и приостановить загрузку рабочего стола до окончания всего скрипта. Этого результата добиваются с помощью групповой политики, распространяющейся на домен («Default Domain Controllers Policy»). В разделе групповой политики «User Configuration» необходимо соответственно включить «Run legacy logon script synhronously» (Запускать сценарий загрузки синхронно) и «Run legasy script hidden» (Запускать сценарий скрыто). Для этого необходимо проделать следующее:
Рисунок 3
Рисунок 4
Рисунок 5 Групповые политики Групповые политики (Group Policy, GP) представляют собой средство, обеспечивающее централизованное управление настройками рабочих станций, профилями пользователей. С их помощью определяют поведение операционной системы, рабочего стола, безопасности ОС, выключения компьютера, приложений и т. д. Реализации всех возможностей групповых политик добиваются их совместным использованием с Active Directory (AD) при условии, что в качестве рабочих станций используется ОС Windows 2000. Политики могут быть применены к следующим объектам AD: сайт (site), домен (domain), подразделение (Organization Unit, OU). Дополнительно групповые политики могут быть применены к таким объектам, как группа безопасности, соответственно к пользователям, входящим в эту группу. Групповые политики включают в себя следующие компоненты: Таблица 3
С помощью политик, как говорилось ранее, можно корректировать только ветви реестра 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. Кратко рассмотрим возможности языка, с помощью которого создаются политики безопасности. Синтаксис языка включает в себя следующие ключевые компоненты:
Комментарии Комментарии полезно использовать для документирования содержимого создаваемого шаблона. Комментарии предваряют точкой с запятой (;) или двумя прямыми слэшами (//). Комментарии также можно помещать в конце строки. Приведем пример комментария: Пример 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 где:
Пример 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 В разделе CATEGORY могут быть использованы следующие ключевые слова:
POLICY Используйте ключевое слово POLICY, чтобы определить политику. В одной категории может быть включено несколько разделов POLICY, каждый из которых должен заканчиваться инструкцией END POLICY. Приведем пример синтаксиса элемента POLICY: POLICY Name [KEYNAME SubKey] EXPLAIN Help VALUENAME Value [PARTS] ………………. END POLICY где:
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 где:
Таблица 4
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 где:
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 где:
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 где:
EDITTEXT Ключевое слово EDITTEXT позволяет вводить в текстовом поле информацию, состоящую из букв и цифр. По умолчанию редактор политик сохраняет этот текст в значении типа REG_SZ. Приведем синтаксис элемента EDITTEXT: PART Name EDITTEXT [DEFAULT Default] [EXPANDABLETEXT] [MAXLENGHT] Max [NOSORT] [REQUIRED] VALUENAME Value END PART где:
LISTBOX Ключевое слово LISTBOX добавляет в диалоговое окно политик список с кнопками Add и Remove. Это единственный тип, который может быть использован системным администратором для управления несколькими значениями, содержащимися в одном ключе. В разделе LISTBOX невозможно использовать опцию VALUENAME, поскольку он не связан с каким-либо конкретным значением. Приведем синтаксис элемента LISTBOX: PART Name LISTBOX [EXPANDABLETEXT] [NOSORT] [ADDITIVE] [EXPLICITVALUE| VALUEPREFIX Prefix] END PART где:
NUMERIC Ключевое слово NUMERIC позволяет вводить буквенно-цифровой текст, используя элемент управления «счетчик», который увеличивает или уменьшает число. По умолчанию переменные имеют тип данных REG_DWORD, однако, используя инструкцию TXTCONVERT, данные могут быть сохранены в формате REG_SZ. Приведем синтаксис элемента LISTBOX: PART Name NUMERIC [DEFAULT Default] [MAX Max] [MIN Min] [REQUIRED] [SPIN] [TXTCONVERT] VALUENAME Value END PART где:
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 Внедрение административных шаблонов Для загрузки ADM-файла, содержащего политику, необходимо выполнить следующие действия:
Удаление административного шаблона Для удаления политики, подгруженной с помощью ADM-файла, необходимо выполнить действия в следующем порядке:
Заключение Используя в сценарии регистрации пользователей в сети вместе с административными шаблонами политик безопасности, системный администратор автоматизирует большую часть рутинных операций. Эффективность его работы при грамотном использовании описанных инструментов значительно возрастает. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ИВАН КОРОБКО
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
