Централизованное управление настройками приложений
В любой информационной системе компании используются самые разные приложения. Поддержка работоспособности этих приложений отнимает у системного администратора большую часть рабочего времени, не в последнюю очередь из-за путаницы в настройках. Проблема в том, что не все пользовательские приложения изначально рассчитаны на работу в корпоративной среде, не для всех приложений существуют средства централизованного администрирования. Программы — обозреватели сети (если используется не Internet Explorer), почтовые программы (если используется не Outlook Express и не Outlook), персональные межсетевые экраны (если это не Windows Firewall из состава Windows XP Service Pack 2) обычно бывают рассчитаны на работу на отдельном компьютере и предусматривают возможность настройки только через пользовательский интерфейс.
К счастью, параметры эти в любом случае сохраняются на компьютере, чаще всего — в реестре, что позволяет задействовать групповые политики для тиражирования таких настроек либо напрямую (через административные шаблоны), либо опосредованно (можно с помощью сценариев импортировать конфигурационные файлы или REG-файлы с настройками).
Лучше всего, если разработчики программ снабжают свои творения готовыми административными шаблонами для централизованной настройки. Это избавляет администратора от дополнительной работы по исследованию приложения. Но даже если таких шаблонов нет, их можно создать самостоятельно.
Варианты с применением сценариев для импорта готовых настроек следует рассматривать как запасные, ибо их применение требует соблюдения достаточно жесткого условия: стереотипной конфигурации установки приложения (каталог для установки, набор установленных компонентов) на всех компьютерах, для которых предполагается использовать данный настроечный файл или REG-файл. Тем не менее и такой способ нельзя сбрасывать со счетов, ибо он позволит вовлечь в орбиту централизации настроек компьютеры и приложения, которые другим способом централизованной настройке не поддаются.
Синтаксис шаблона
Административные шаблоны представляют собой текстовые файлы, в которых на специальном языке можно описать, какие параметры реестра настраивать и каким должен быть интерфейс для отображения этих настроек в редакторе групповых политик. Полное описание языка определения административных шаблонов можно отыскать, например, на сайте Microsoft: http://www.microsoft.com/technet/ prodtechnol/windows2000serv/deploy/confeat/ regappgp.mspx. Примеры административных шаблонов поставляются вместе с системой, это стандартный набор административных шаблонов для настройки системных компонентов, который записан в папку %Windir%inf, — соответствующие файлы имеют расширение ADM. Чтобы не запутаться, стоит начать изучение готовых шаблонов с относительно несложного шаблона WUAU.ADM, в котором определен интерфейс указания настроек автоматического обновления с помощью Software Update Service. На примере этого шаблона можно изучить основные элементы синтаксиса.
В начале шаблона указывается, относятся данные настройки к параметрам компьютера или параметрам пользователя.
Если это параметры компьютера, то в качестве первой значащей строки следует указать CLASS MACHINE. Если же параметры пользователя — нужно указать CLASS USER
Далее следует категория. Категория — это наименование ветви в древовидной структуре параметров редактируемой групповой политики. Все категории, содержащиеся в загруженных в данный объект групповых политиках, отображаются в оснастке редактора объектов групповой политики в разделе Computer ConfigurationAdministrative Templates или User ConfigurationAdministrative Templates соответственно. Tак, если указать:
CATEGORY «My Category Name»
отобразится ветвь ...Administrative TemplatesMy Category Name.
Здесь и в других местах можно либо указывать текстовые строки (наименований, пояснительного текста и т. п.) непосредственно, заключив их в двойные кавычки, либо разместить в конце описания шаблона раздел, начинающийся с оператора:
[Strings]
В этом разделе можно сосредоточить определения всех текстовых строк, используемых при описании административного шаблона, в формате: Название=«Содержание». Название не должно содержать пробелов, за ним — знак равенства, содержание заключено в двойные кавычки. Заготовив такие описания, можно вместо собственно текста указывать названия текстовых констант, определенных в разделе [Strings], предваряя их двумя восклицательными знаками. Так, добавив туда строчку:
MyCategoryName=«My Category Name»
можно использовать ее в операторе категории:
CATEGORY !!MyCategoryName
Результат будет такой же, как если после ключевого слова Category указать в двойных кавычках непосредственно текст.
Описание данной категории в шаблоне должно завершаться оператором END CATEGORY. Оно может, в свою очередь, содержать описания категорий, эти категории будут отображаться как дочерние ветви, описание каждой категории должно завершаться оператором END CATEGORY.
Комбинируя операторы CATEGORY — END CATEGORY, можно добиться того, что настраиваемые параметры будут отображаться в дереве настроек именно так, как нужно. При этом следует иметь в виду, что если в нескольких административных шаблонах, загруженных в объект групповой политики, содержится описание одинаковой категории, причем каждый административный шаблон предполагает там описание своих параметров, то в оснастке будут отображены параметры, определенные в последнем загруженном административном шаблоне. Чтобы этого избежать, следует давать категориям наименования, заведомо не используемые в других административных шаблонах.
Помимо дочерних категорий, в описании категории описываются отдельные политики. Каждая политика определяет диалог редактирования одного или нескольких параметров реестра, располагающихся внутри одного и того же раздела.
Описание политики начинается с оператора:
POLICY название политики
Заканчивается описание оператором:
END POLICY
Название политики появляется в оснастке редактора GPO как отдельная строка в правой части, при нажатии на которую отображаются параметры, определяемые в описании политики.
После оператора POLICY следует указать раздел в реестре, содержащий задаваемые параметры:
KEYNAME полный путь к разделу реестра без указания раздела
Механизм расширения групповых политик с помощью административных шаблонов позволяет настраивать параметры, располагающиеся в разделах реестра HKEY_LOCAL_MACHINESoftware и HKEY_CURRENT_USERSoftware. Но указывать в операторе KEYNAME следует раздел ... SoftwarePolicies. Это обусловлено механизмом применения рассматриваемой части групповых политик. Вначале, перед загрузкой групповых политик, содержимое разделов HKLMSoftwarePolicies и HKCUSoftwarePolicies очищается. Затем, в ходе загрузки групповых политик, в этих разделах формируется структура дочерних разделов с соответствующими параметрами так, как это описано в групповых политиках, с учетом содержащихся в них административных шаблонов. По окончании загрузки GPO данная структура переносится в разделы HKLMSoftware и HKCUSoftware, частично дополняя, частично замещая то, что было там записано ранее.
В разделе, указанном в операторе KEYNAME, могут содержаться один или несколько параметров разнообразных типов, которые может потребоваться задать. Для каждого типа параметров предусмотрен свой вариант синтаксиса. Полное описание можно найти по указанной выше ссылке, здесь же приведем несколько простейших вариантов.
Единственный параметр, принимающий значения «да» или «нет». В этом случае в диалоговом окне присутствует только переключатель: Enabled/Disabled/Not configured. Состояние Not configured означает, что ничего не задано, а для состояний Enabled/Disabled нужно указать название параметра (тип — обязательно REG_DWORD) и численные значения, соответствующие Enabled («да») и Disabled («нет»). Записывается это в виде следующей конструкции:
VALUENAME название параметра
VALUEON NUMERIC значение «да»
VALUEOFF NUMERIC значение «нет»
Один или несколько параметров разных типов, объединенные в один диалог. В этом случае диалог будет состоять из нескольких частей, каждая из которых представляет собой либо текстовое пояснение, либо интерфейс редактирования: окно редактирования строки или числа либо список.
Каждая часть описывается отдельно, описание начинается оператором PART и заканчивается оператором END PART. Если это текстовое пояснение, отображающееся в диалоге, то синтаксис следующий:
PART текст TEXT
END PART
Если это список, предназначенный для указания одного из возможных режимов, соответствующего одному из значений численного параметра, то:
PART отображаемое название DROPDOWNLIST
VALUENAME имя параметра
ITEMLIST
NAME название числового значения VALUE NUMERIC числовое значение
...
NAME название числового значения VALUE NUMERIC числовое значение DEFAULT
...
NAME отображаемое название значения VALUE NUMERIC числовое значение
END ITEMLIST
END PART
Если это редактируемое поле для текста:
PART отображаемое название EDITTEXT
VALUENAME имя параметра
END PART
Если это редактируемое поле для числа:
PART отображаемое название NUMERIC
VALUENAME имя параметра
MIN минимальное допустимое значение
MAX максимальное допустимое значение
DEFAULT значение по умолчанию
END PART
Синтаксис позволяет создавать и более сложные диалоги, но для начала должно хватить и описанных здесь возможностей.
Какие параметры подставлять
Остается основной вопрос: какие параметры реестра описывают тот или иной режим работы в параметрах выбранной программы. Чаще всего описание структуры хранения параметров в реестре с программой не поставляется, если только программа не распространяется по лицензии GNU. Значит, программу требуется исследовать. Для исследования программы предлагается воспользоваться утилитой Regmon компании Sysinternals, которую можно бесплатно загрузить с сайта. Текущая версия доступна по адресу: http://www.sysinternals.com/ntw2k/source/regmon.shtml.
Предлагается действовать следующим образом. При запуске Regmon вначале отображается диалог настройки фильтра отображаемой активности. В этом диалоге надо указать название исполняемого файла исследуемой программы, а также отображаемые действия: запись в реестр (см. экран 1).
|
| Экран 1. Фильтр отображения утилиты Regmon |
После этого, оставив запущенной программу Regmon, нужно запустить исследуемую программу и вызвать окно настройки. В диалоговом окне, выставляя все возможные значения по каждому параметру и применяя те или иные настройки (кнопки OK или Apply), необходимо каждый раз в окне утилиты Regmon отыскивать строчку, соответствующую записи искомого параметра, среди прочих действий, которые зафиксировала программа. Можно в настройках фильтра указать параметры подсветки искомых подстрок, чтобы было легче искать.
Следует искать строки, в которых фигурируют операции, совершенные тем процессом, который соответствует запущенной программе, касающиеся успешной записи в реестр.
Анализируя таким образом программу, можно выяснить, какому значению какого параметра в каком разделе реестра (дочернем по отношению к разделу HKLMSoftware или HKCUSoftware) какая настройка программы соответствует, после чего на основе полученной информации можно сформировать административный шаблон. Удобно, чтобы параметры в нем были разбиты по категориям, соответствующим разделам диалогового окна настроек программы, а отображаемые значения настраиваемых параметров и отдельных возможных значений также соответствовали формулировкам из окна настроек.
При указании в шаблоне раздела реестра не нужно вписывать раздел HKEY_LOCAL_MACHINE или HKEY_CURRENT_USER. Эта информация будет подставлена системой на основе параметра оператора CLASS в начале описания шаблона. Следует также не забыть в пути к разделу реестра после Software подставить Policies — в противном случае шаблон удастся импортировать в объект групповой политики, но описанные в нем параметры отображаться в редакторе не будут (можно включить такой режим работы редактора групповых политик, что эти параметры будут показаны, но об этом чуть позже).
|
| Экран 2. Импорт административного шаблона в GPO |
После того как шаблон подготовлен, следует импортировать его в объект групповой политики (см. экран 2). Лучше сначала испытать шаблон на примере локальной групповой политики одного компьютера, отладить его (возможно, поначалу при импорте будут отображаться сообщения о синтаксических ошибках с указанием строки — на данном этапе процесс отладки мало чем отличается от отладки любого сценария), а потом уже использовать в групповых политиках своей организации.
Вспомогательные инструменты
Выше уже упоминалась утилита Regmon от компании Sysinternals. Стоит рассказать еще об одной программе — Regtoadm, входящей в состав разработанного израильским программистом Ишхаром Гурвицем (Yizhar Hurwitz) пакета утилит NUTS (http://teachers.sivan.co.il/yizhar/). Программа позволяет, импортировав REG-файл, создать на его основе административный шаблон (см. экран 3).
|
| Экран 3. Утилита Regtoadm |
В результате работы программа выдает корректный с точки зрения синтаксиса файл административного шаблона, в котором, впрочем, следует не забыть подставить в путях к ключам реестра Policies — утилита сама этого не делает. Кроме того, созданный с помощью утилиты Regtoadm административный шаблон содержит лишь простейшие определения для редактирования параметров — ввод числа либо текстовой строки с клавиатуры, не более того. Впрочем, в качестве основы для дальнейших действий по доработке дизайна шаблона такой вариант годится.
Другие возможные ситуации
Если параметры хранятся в реестре, но не в составе разделов HKCUSoftware и HKLMSoftware, то можно действовать тремя путями. Первый: заготовить REG-файлы со всеми возможными вариантами настроек, после чего с помощью сценариев в составе GPO копировать нужный файл из общей папки, где находятся эти REG-файлы, а затем в том же сценарии вызвать команду REGEDIT:
REGEDIT имя файла /S
Параметр /s необходим, чтобы не отображалось окошко с запросом для подтверждения на импорт файла реестра. Кстати, много полезной информации по реестру Windows и способам работы с ним можно найти на сайте Registry Guide for Windows — это раздел ресурса WinGuides Network (www.winguides.com).
Второй путь: определить расширение интерфейса редактора шаблонов безопасности Windows (оснастка secedit.msc), позволяющее редактировать с его помощью любой параметр в реестре. Параметры отображаются в разделе шаблона безопасности Local PoliciesSecurity Options.
Текущее определение параметров, отображаемых в редакторе шаблонов безопасности в разделе Local PoliciesSecurity Options, хранится в файле %Windir%infSecregvl.inf. Туда следует добавить строку определенного синтаксиса (который описан в комментариях внутри самого файла) по каждому параметру реестра, который требуется править (см. экран 4).
|
| Экран 4. Открытый в блокноте файл Secregvl.inf |
После этого нужно перерегистрировать библиотеку, отвечающую непосредственно за экранный интерфейс редактирования шаблона безопасности, введя в командной строке команду:
Regsvr32 scecli.dll
Соответствующие изменения в отображении редактором шаблонов безопасности действуют только на том компьютере, на котором проделаны описанные выше манипуляции, но если расширенный шаблон безопасности импортировать в групповую политику, соответствующие изменения будут действовать на всех компьютерах, независимо от дополнительных настроек отображения параметров в шаблоне безопасности.
Такой способ плох тем, что в разделе Local PoliciesSecurity Options все параметры отображаются общим списком, без дополнительной группировки, поэтому при необходимости расширения редактора шаблонов безопасности для редактирования настроек множества программ с большим количеством параметров отыскать в списке нужный параметр будет затруднительно. Но возможности настройки при этом все равно более гибкие, чем при импорте сценариями заранее заготовленных REG-файлов.
Третий путь: опять использовать административные шаблоны и групповые политики. Можно задействовать режим работы редактора групповых политик, в котором отображаются любые параметры реестра, определенные в административном шаблоне (параметры операторов KEYNAME и VALUENAME), а не только находящиеся в разделах HKLMSOFTWAREPOLICIES и HKCUSOFTWAREPOLICIES. Режим этот включается в главном меню редактора групповых политик, пункты меню называются по-разному в Windows 2000 и в Windows Server 2003. В редакторе групповых политик из состава Windows 2000 — меню View, пункт Show Policies Only, — отключить этот режим. В редакторе групповых политик из состава Windows Server 2003 — меню View, пункт Filtering, — в открывшемся окне снять галочку Only show policy settings that can be fully managed. Тогда будут отображаться все параметры, определенные в административных шаблонах в параметрах оператора KEYNAME.
При использовании всех трех подходов остается одна проблема: единственная возможность полностью контролировать ситуацию с параметрами какой-либо программы, сохраняющимися в реестре за пределами разделов HKLMSoftware и HKCUSoftware, — это определять абсолютно все параметры, которые могут фигурировать в рассматриваемом приложении. Дело в том, что в отличие от параметров, определяемых через групповые политики штатным образом, перед началом загрузки GPO не происходит очистки параметров, лежащих за пределами разделов HKLMSoftwarePolicies и HKCUSoftwarePolicies. Если бы такая очистка производилась, можно было бы однозначно сказать: если какой-то параметр не определен в результирующем наборе параметров, сформированном после применения всех групповых политик, то этот параметр примет значение по умолчанию. А раз очистка не проводится, какое значение примет параметр в подобном случае — заранее неизвестно, так как останется та настройка, которая была установлена для данного пользователя на данном компьютере через пользовательский интерфейс рассматриваемой программы.
Параметры в настроечных файлах
В такой ситуации необходимо обеспечить тиражирование корректного файла (или файлов, или даже целого профиля настроек — зависит от программы), содержащего необходимые настройки, на клиентские компьютеры, где функционирует рассматриваемое приложение.
Для успеха данной операции необходимо обеспечить выполнение двух условий.
1. Должно быть известно, в каких файлах хранятся настройки. Желательно знать и формат хранения данных, но это не принципиально, если соблюдать второе условие.
2. Требуется, чтобы рассматриваемое приложение на всех компьютерах, на которые тиражируются настройки, было установлено одинаковым образом. Это означает одинаковую структуру папок, используемых приложением, вплоть до букв логических дисков включительно. В этом случае фигурирующие в файлах настройки полные пути к тем или иным используемым файлам будут гарантированно существовать на всех компьютерах и назначение соответствующих файлов и папок будет одинаковым.
Если в документации, поставляемой вместе с приложением, содержится информация о структуре файлов конфигурации, это сэкономит немало усилий. В противном случае потребуется исследовать приложение. Для исследования предлагается задействовать утилиту Filemon производства той же компании Sysinternals: http://www.sysinternals.com/ntw2k/source/filemon.shtml. Интерфейс ее очень похож на интерфейс программы Regmon, разве что при запуске не отображается диалоговое окно с параметрами фильтрации, поэтому приходится вызывать его при уже запущенной программе.
Предлагается действовать таким же образом, как при использовании утилиты Regmon для выявления параметров реестра, в которые приложение записывает настройки. В данном случае требуется выявить не параметры реестра, а файлы, в которые программа записывает данные в ходе обращения к различным элементам окна настроек.
Дальше — дело техники: набор файлов настройки копируется в отдельную папку на сервере, в групповую политику добавляется сценарий загрузки, копирующий файлы с сервера в нужное место. Наконец, если необходимо — в параметрах безопасности компьютера в составе групповой политики указываются разрешения на эти файлы, предоставляющие доступ на запись только администраторам (как это делается — см. статью «Безопасность своими руками», Windows .NET Magazine/RE №3 за 2004 год). Последнее требуется не всегда: если конфигурация сохраняется, например, в INI-файле в системной папке, соответствующие разрешения наследуются от нее.
Старые версии Windows
Если используются старые версии клиентских операционных систем, не поддерживающие групповые политики, то в данном случае невозможно использовать административные шаблоны и групповые сценарии для загрузки, но существуют другие способы.
Для Windows 95/98/ME можно задействовать сценарий регистрации пользователей. В этом случае настроечные файлы копируются в нужное место, а параметры реестра следует предварительно экспортировать в REG-файл, после чего копировать этот файл на клиентский компьютер и импортировать в реестр, вписав в сценарий соответствующий вызов команды Regedit. Блокировка изменения параметров приложения пользователем при работе с этими операционными системами если и возможна, то весьма относительная: на конфигурационных файлах можно установить атрибут Read Only, который квалифицированный пользователь сможет без труда снять, а защита от модификации разделов реестра и параметров реестра невозможна в принципе. Поведение системы в отношении данного приложения будет подобно поведению систем семейства Windows NT с обязательным профилем: изменения в настройках, сделанных в ходе сеанса работы, будут теряться в момент завершения сеанса работы с системой, но до окончания текущего сеанса измененные настройки будут действовать.
Кроме того, и на компьютеры под Windows 95/98/ME, и на компьютеры под Windows NT 4.0 можно установить компонент поддержки Windows Management Interface (WMI) и воспользоваться всем богатством возможностей удаленного управления и администрирования, предоставляемых этим механизмом.
Успешной работы!
Для чего нужно использовать централизованные настройки приложений — объяснять не требуется. Любой системный администратор знает, что, если отдать настройку системы и приложений на откуп пользователям, исправление результатов такого рода деятельности потребует гораздо больших усилий, чем потребовала бы первоначальная настройка приложений и внедрение централизованного управления ими. К тому же централизованный контроль настроек — необходимая составная часть поддержания порядка при эксплуатации информационных систем, что в свою очередь является необходимым условием обеспечения безопасности и защиты информации. Надеюсь, данная статья поможет системным администраторам и администраторам безопасности сэкономить свои силы, добиваясь этой цели.
Алексей Сотский — преподаватель учебного центра, имеет сертификаты MCSE, MCT. С ним можно связаться по адресу: alex100@infosec.ru