Инструменты совместимости приложений Microsoft (часть 1)

Инструменты совместимости приложений представляют собой простое и элегантное решение многих проблем доступа к приложениям, с которыми сталкиваются администраторы служб терминалов. В этой статье представлено введение в инструменты, и особое внимание будет уделено средству проверки приложений.

Введение

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

Существует множество различных решений для «исправления» проблем с приложениями, и они варьируются от виртуальных машин рабочих станций на одном конце спектра до простого перенаправления API на другом. На данный момент самым модным способом решения проблем с приложениями является виртуализация приложений с использованием таких продуктов, как Citrix Application Streaming, Altiris SVS, Softgrid, Thinstall, AIE и т. д. Поместите приложение в пузырь, где у него есть собственный перенаправленный реестр, файловая система и т. д. просто запустите его. Если бы только жизнь была такой простой.

Виртуализация приложений не является новой концепцией, и упомянутые продукты — не единственный способ избежать взломов реестра и т. д., необходимых для корректной работы приложений. На самом деле, с начала 2003 года у нас была возможность исправить 80-90% распространенных проблем с доступом к приложениям в терминальных службах просто с помощью инструментов Microsoft для обеспечения совместимости приложений.

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

Проблемы совместимости приложений были в центре внимания Microsoft с выпуском Windows XP, особенно Home Edition. Потому что как заставить людей покупать Windows XP, если они не могут запускать свои игры и приложения для Windows 9X? Ответом стали исправления совместимости приложений, серия DLL перенаправления API, позволяющая приложениям Windows 9X (в основном играм) без проблем работать на XP.

Почти четыре года назад в RTM-версии Windows Server 2003 появились некоторые новые исправления совместимости, направленные на решение многих проблем с доступом к приложениям, возникающих, когда пользователь не является локальным администратором. Это были исправления ограниченной учетной записи пользователя (LUA), где LUA — это пользователь без прав администратора с доступом только для чтения к системным файлам и реестру.

В Windows Vista LUA больше не является исключением, а стала стандартной учетной записью пользователя, и приложения должны быть совместимы с контролем учетных записей (UAC). Безопасность больше не является необязательным дополнением, и даже работа от имени локального администратора (защищенный администратор) дает вам ограниченную и контролируемую среду.

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

Изменения в наборе инструментов совместимости из более ранних версий в Версию 4.1 и, наконец, в бета-версию Версии 5 указывают путь Microsoft к набору инструментов для обеспечения совместимости приложений. Последняя версия представляет собой автоматизированный инструмент перед развертыванием, который использует клиентский агент для сбора данных о проблемах с приложением, сохраняет эту информацию в центральной базе данных SQL, а затем после анализа развертывает исправления для этих проблем. Хотя он предназначен для облегчения перехода на Vista в организации, он, очевидно, будет весьма полезен и для миграции рабочих станций на службы терминалов.

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

Верификатор приложений

Я потерял счет тому, сколько раз я использовал filemon и regmon, чтобы выяснить, были ли у приложения на TS/Citrix проблемы с доступом к реестру или файловой системе. Затем были циклы прерывания/исправления, пытающиеся запустить приложение в качестве стандартного пользователя (не администратора) и снять защиту ключей реестра в качестве администратора, пока приложение, наконец, не запустилось без ошибок.

Этот сценарий радикально изменился, поскольку средство проверки приложений позволяет вам запускать приложение от имени администратора и определять все операции доступа к реестру и файлам, которые завершились бы неудачей, если бы приложение запускалось обычным пользователем. Таким образом, вам не нужно тестировать приложение в закрытой среде или даже в системе TS/Citrix, чтобы выяснить, что оно может сломать.

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

Последняя версия Application Verifier (v3.3) предназначена для использования в качестве автономного инструмента разработчика для проверки совместимости новых приложений с LUA и UAC. Он делает свою работу очень хорошо, но создаваемые журналы XML немного сложнее анализировать вручную, хотя с бесплатным XMLMarker (http://symbolclick.com/download.htm) это не так уж плохо. Тем не менее, независимо от того, используете ли вы средство проверки приложений версии 2.5 или нет, вам все равно придется установить версию 3.3 для поддержки SUAnalyzer.

Пример:

Давайте посмотрим на использование Application Verifier в сеансе с моим любимым примером приложения, Volo View Express. Если пользователь LUA запускает Volo View Express, он запускается с ошибкой доступа к реестру. Первым портом захода был монитор реестра NT (sysinternals), но в этом случае мы запустим верификатор приложений.

1. Первый шаг — добавить исполняемый файл, который вы хотите протестировать, перейдя к исполняемому файлу:

2. Затем вам нужно отметить параметры тестовых настроек, которые вы хотите отслеживать для этого приложения, например, в этом случае я отметил:
   Блокировки — проверьте использование блокировки.
   Пути к файлам — проверяет использование системного пути.
   RegistryChecks — проверяет использование реестра.
   SecurityChecks — регистрирует потенциальные проблемы безопасности, регистрирует большинство проблем LUA.
3. Нажмите кнопку «Выполнить», и когда приложение запустится, запустите все доступные функции. С Volo View Express это означает открытие файла чертежа, прокрутку/панорамирование и печать файла. Закройте приложение.
4. Нажмите «Просмотреть журналы», чтобы просмотреть журнал приложений:

Журнал показывает, что у нас есть 2 типа нарушений доступа к LUA (обратите внимание на комментарии Microsoft для разработчиков, выделенные курсивом):

Запись в ключ реестра, не являющийся текущим пользователем

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

Открыт объект для слишком большого доступа

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

В обоих случаях имеется полный журнал всех нарушений доступа к реестру, вызванных приложением:

Если мы сохраним журнал, мы сможем открыть файл журнала и извлечь нарушения доступа к реестру (это частичный пример):

Теперь мы можем переработать это, чтобы получить список ключей реестра, которые должны быть доступны для записи обычным пользователем. Если мы извлечем только ключи, мы получим:

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

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

Изменить контроль доступа

Первый подход очень прост: просто измените список управления доступом (ACL) ключа, чтобы разрешить запись.

Я должен подчеркнуть, что, хотя существует ряд инструментов для изменения реестра ACL командной строки, единственный способ изменить реестр компьютера или ACL каталогов/файлов — это использовать групповую политику. Это единственный способ гарантировать, что задокументированное и последовательное изменение может быть применено ко всем существующим, а также к любым новым или перестроенным серверам в OU.

Процесс:

1. Отредактируйте групповую политику и перейдите в «Конфигурация компьютера» > «Параметры Windows» > «Параметры безопасности» > «Реестр». Щелкните правой кнопкой мыши и выберите Добавить ключ

2. Перейдите к ключу, который вы хотите снять с защиты, и нажмите «ОК», затем отметьте «Полный доступ для пользователей» и нажмите «Применить»:

3. Установите флажок Не разрешать замену разрешений для этого ключа и нажмите Применить.

4. Повторите этот процесс для остальных ключей, которые необходимо снять с защиты.

5. Запишите GUID групповой политики, щелкнув правой кнопкой мыши заголовок и выбрав свойства.

Уникальное имя или GUID этого примера групповой политики — {60D0AFB2-3397-48A5-9994-E82C67E575E6}, ваше имя будет другим.

Windows 2000 Server и Windows Server 2003 унаследовали механизм политики безопасности NT 4. Таким образом, когда вы применяете разрешения к файлу или реестру с помощью групповой политики, все, что вы делаете, — это создаете файл шаблона безопасности групповой политики (GptTmpl.inf), который будет применяться к вашим серверам.

В этом примере шаблон безопасности находится под

и когда происходит обновление групповой политики, оно копируется в %systemroot%security emplatespolicies на серверах в OU, и применяются изменения контроля доступа.

Если мы посмотрим на этот файл, мы увидим изменения ACL реестра, перечисленные в разделе [Ключи реестра]:

Если вам интересно, что все это значит, интересным является бит (A;CI;KR;;;BU), который назначает все (A) права встроенным пользователям (BU). Это записи языка определения дескрипторов безопасности (SDDL), и краткий обзор SDDL можно найти по адресу http://www.ciac.org/ciacNT/SCM/SDDL.html.

Проблема с добавлением записей ACL для изменения реестра вручную заключается в том, что это занимает много времени, и если у вас есть 30-40 или более ключей реестра для снятия защиты, шансы совершить ошибку превосходны.

Однако ничто не мешает вам добавить имена ключей и значения SDDL прямо в файл GptTmpl.inf, а затем увеличить номер версии в

После этого ваши изменения будут применены.

Виртуальный Гонконг

Второй способ добиться аналогичного конечного результата — использовать виртуальный HKCR пользователя, HKCUSoftwareClasses. Если вы запустите монитор реестра NT, вы увидите, что операционная система обращается к записям HKCUSoftwareClasses раньше, чем к HKCR. Поэтому, если ключ/значение существует в HKCUSoftwareClasses, он будет использоваться вместо того, что находится в HKCR.

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

Используйте исправление совместимости приложений

Другой способ сделать это, если вы еще не используете Windows 2000 Server, — использовать исправление совместимости приложений, LUARedirectReg (будет обсуждаться позже), которое автоматически создает все ключи и значения в разделе HKCUSoftwareClasses всякий раз, когда « исправлено» приложение пытается писать в HKCR. В системе Windows Server 2003 (но не 2000 Server) с LUARedirectReg, примененным к приложению, вам не нужно ничего делать, чтобы разрешить запись в ключи реестра.

Стоит также отметить, что если у вас Windows Server 2003 Enterprise (или DataCenter), операционная система действует так, как будто LUARedirectReg применяется ко всем приложениям.

На всякий случай, если вы спросите, почему я показал вам, как это сделать с помощью групповой политики, это потому, что это единственный способ изменить ACL для любого раздела системного реестра или файла/папки, и он обеспечивает быстрое исправление для некоторых из более простые проблемы с доступом.

Предупреждение!!

Более новые версии (v3+) верификатора приложений устанавливают флаги реестра, чтобы прокладки мониторинга применялись к каждому экземпляру исполняемого файла при его запуске, а также регистрируются все нарушения и т. д. Это может значительно увеличить нагрузку на производственную систему TS/Citrix. Когда вы закончите мониторинг приложения, обязательно используйте опцию Удалить, чтобы прекратить мониторинг приложения (см. ниже).

Во второй части этой серии мы рассмотрим анализатор стандартных пользователей и администратор совместимости приложений.