Отладка и устранение неполадок элемента управления приложениями
Примечание.
Некоторые возможности управления приложениями для бизнеса доступны только в определенных версиях Windows. Дополнительные сведения о доступности функций управления приложениями.
В этой статье описывается отладка и устранение неполадок приложений и сценариев при использовании управления приложениями для бизнеса.
1. Сбор диагностических данных элемента управления приложениями
Перед отладкой и устранением проблем с элементом управления приложениями необходимо собрать сведения с устройства, демонстрирующего поведение проблемы.
Выполните следующие команды в окне PowerShell с повышенными привилегиями, чтобы собрать необходимые диагностические сведения:
Соберите общие диагностические данные элемента управления приложениями и скопируйте их в папку %userprofile%\AppData\Local\Temp\DiagOutputDir\CiDiag:
cidiag.exe /stopЕсли CiDiag.exe отсутствует в вашей версии Windows, соберите эти сведения вручную:
- Двоичные файлы политики управления приложениями из системных секций Windows и EFI
- Журналы событий элемента управления приложениями
- Журналы событий AppLocker
- Другие журналы событий, которые могут содержать полезную информацию из других приложений и служб Windows
Сохраните сведения о системе устройства в папку CiDiag:
msinfo32.exe /report $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\SystemInformation.txtИспользуйте CiTool.exe для инвентаризации списка политик управления приложениями на устройстве. Пропустите этот шаг, если CiTool.exe отсутствует в вашей версии Windows.
citool.exe -lp -json > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\CiToolOutput.jsonЭкспортируйте данные раздела реестра AppLocker в папку CiDiag:
reg.exe query HKLM\Software\Policies\Microsoft\Windows\SrpV2 /s > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt; reg.exe query HKLM\Software\Policies\Microsoft\Windows\AppidPlugins /s >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt; reg.exe query HKLM\System\CurrentControlSet\Control\Srp\ /s >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txtПримечание.
Может появиться сообщение об ошибке о том, что системе не удалось найти указанный раздел или значение реестра. Эта ошибка не указывает на проблему и ее можно игнорировать.
Скопируйте все файлы политики AppLocker из %windir%System32\AppLocker в папку CiDiag:
Copy-Item -Path $env:windir\System32\AppLocker -Destination $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\ -Recurse -Force -ErrorAction IgnoreСоберите сведения о файлах политики AppLocker, собранных на предыдущем шаге:
Get-ChildItem -Path $env:windir\System32\AppLocker\ -Recurse | select Mode,LastWriteTime,CreationTime,Length,Name >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerPolicyFiles.txtЭкспортируйте действующую политику AppLocker:
Get-AppLockerPolicy -xml -Effective > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xmlСбор сведений о конфигурации и состоянии служб AppLocker:
sc.exe query appid > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query appidsvc >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query applockerfltr >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt
Журналы событий Core App Control
События элемента управления приложениями создаются в двух расположениях:
- Журналы приложений и служб — Microsoft — Windows — CodeIntegrity — Operational
- Журналы приложений и служб — Microsoft — Windows — AppLocker — MSI и скрипты
В выходном каталоге CiDiag эти журналы событий называются CIOperational.evtx и ALMsiAndScript.evtx соответственно.
Другие журналы событий Windows, которые могут быть полезны
Иногда вы можете дополнить сведения, содержащиеся в основных журналах событий Элемента управления приложениями, сведениями, найденными в этих других журналах событий. CIDiag.exe не собирает те, которые показаны курсивом.
- Журналы приложений и служб — Microsoft — Windows — CodeIntegrity — Подробные сведения
- Журналы приложений и служб — Microsoft — Windows — AppLocker — EXE и DLL
- Журналы приложений и служб — Microsoft — Windows — AppLocker — упакованое приложение—развертывание
- Журналы приложений и служб — Microsoft — Windows — AppLocker — упакованое приложение — выполнение
- Журналы приложений и служб - Microsoft - Windows - AppID - Operational
- Журналы приложений и служб — Microsoft — Windows — CAPI2 — операционные
- Журналы приложений и служб - Microsoft - Windows - DeviceGuard - Operational
- Журналы приложений и служб — Microsoft — Windows — PowerShell — *
- Windows — приложение
- Windows — система
2. Использование данных диагностики и журналов для выявления проблем
Собрав необходимые диагностические сведения с устройства, вы можете приступить к анализу диагностических данных, собранных в предыдущем разделе.
Проверьте набор активных и применяемых политик управления приложениями. Убедитесь, что в настоящее время активны только те политики, которые должны быть активны. Помните о политиках папки "Входящие" Windows , которые также могут быть активными. Можно использовать любой из следующих методов:
- Проверьте выходные данные CiTool.exe -lp, если применимо, который был сохранен в выходном каталоге CIDiag как CiToolOutput.json. См . статью Использование Microsoft Edge для просмотра отформатированного json-файла.
- Просмотрите все события активации политики из основного журнала событий управления приложениями, который находится в разделе Журналы приложений и служб — Microsoft — Windows — CodeIntegrity — Operational. В выходном каталоге CIDiag этот журнал событий называется CIOperational.evtx.
Просмотрите все события блоков для исполняемых файлов, библиотек DLL и драйверов из основного журнала событий управления приложениями, который находится в разделе Журналы приложений и служб — Microsoft — Windows — CodeIntegrity — Operational. В выходном каталоге CIDiag этот журнал событий называется CIOperational.evtx. Используйте сведения из событий блока и связанные с ними события со сведениями о сигнатуре 3089, чтобы исследовать необъяснимые или непредвиденные блоки. См. пример заблокированного исполняемого файла, описанный далее в этой статье.
Просмотрите события блоков для упакованных приложений, установщиков MSI, скриптов и COM-объектов из журнала событий принудительного выполнения основных сценариев, который находится в разделе Журналы приложений и служб — Microsoft — Windows — AppLocker — MSI и Скрипт. В выходном каталоге CIDiag этот журнал событий называется ALMsiAndScript.evtx. Используйте сведения из событий блоков и связанные с ними события сигнатуры 8038, чтобы исследовать необъясненные или непредвиденные блоки.
Большинство проблем, связанных с элементом управления приложениями, включая сбои приложений и скриптов, можно диагностировать с помощью предыдущих шагов.
Анализ событий для примера заблокированного исполняемого файла
Ниже приведен пример подробных сведений о EventData из типичного события блока 3077 режима управления приложениями и одного из связанных событий сведений о сигнатуре 3089. В таблицах, которые следуют за каждым снимка экрана события, описываются некоторые элементы, содержащиеся в событиях. Ниже описаны пошаговые инструкции по использованию событий, чтобы понять причину блокировки.
Событие 3077 — событие блока принудительного применения элемента управления приложениями
| Имя элемента | Описание |
|---|---|
| Система — корреляция — [ActivityID] |
Не показано на снимке экрана Используйте идентификатор активности корреляции, чтобы сопоставить событие блока управления приложениями с одним или несколькими событиями сигнатуры 3089. |
| Имя файла | Путь и имя файла на диске, который был заблокирован для запуска. Так как имя на диске изменяемо, это значение не используется при создании правил файлов управления приложениями с -Level FileNameпомощью . Вместо этого см. элемент OriginalFileName далее в этой таблице. |
| Имя процесса | Путь и имя файла, который пытался запустить заблокированный файл. Также называется родительским процессом. |
| Запрошенный уровень подписи | Уровень авторизации подписывания Windows— код, необходимый для запуска. См . раздел Запрошенный и проверенный уровень подписи. |
| Проверенный уровень подписи | Уровень авторизации подписывания Windows, предоставленный коду. См . раздел Запрошенный и проверенный уровень подписи. |
| Состояние | Windows NT код состояния. Вы можете использовать certutil.exe -error <status> для поиска значения кода состояния. |
| Хэш SHA1 | Хэш SHA1 Authenticode для заблокированного файла. |
| Хэш SHA256 | Хэш SHA256 Authenticode для заблокированного файла. |
| SHA1 Flat Hash | Хэш неструктурированного файла SHA1 для заблокированного файла. |
| SHA256 Flat Hash | Хэш неструктурированного файла SHA256 для заблокированного файла. |
| PolicyName | Понятное имя политики управления приложениями, которая вызвала событие блока. Отдельное событие блока 3077 (или событие блока аудита 3076) отображается для каждой политики, которая блокирует запуск файла. |
| PolicyId (Идентификатор политики) | Понятное значение идентификатора политики управления приложениями, вызвавшее событие блока. |
| PolicyHash | Хэш SHA256 Authenticode двоичного файла политики управления приложениями, вызвавшего событие блока. |
| OriginalFileName | Неизменяемое имя файла, заданное разработчиком в заголовке ресурса заблокированного файла. Это значение используется при создании правил файлов управления приложениями с -Level FileNameпомощью . |
| InternalName | Еще одно неизменяемое значение, заданное разработчиком в заголовке ресурса заблокированного файла. Это значение можно заменить значением OriginalFileName в правилах файлов на -Level FileName -SpecificFileNameLevel InternalName. |
| FileDescription | Еще одно неизменяемое значение, заданное разработчиком в заголовке ресурса заблокированного файла. Это значение можно заменить значением OriginalFileName в правилах файлов на -Level FileName -SpecificFileNameLevel FileDescription. |
| ProductName | Еще одно неизменяемое значение, заданное разработчиком в заголовке ресурса заблокированного файла. Это значение можно заменить значением OriginalFileName в правилах файлов на -Level FileName -SpecificFileNameLevel ProductName. |
| FileVersion | Значение VersionEx политики, используемое для принудительного управления версиями для подписанных политик. |
| PolicyGUID | PolicyId политики элемента управления приложениями, вызвавшего событие блока. |
| UserWriteable | Логическое значение, указывающее, находится ли файл в удобном для записи пользователем расположении. Эти сведения полезны для диагностики проблем при разрешении правилами FilePath. |
| PackageFamilyName | Имя семейства пакетов для упаковаемого приложения (MSIX), включающее заблокированный файл. |
Событие 3089 — событие сведений о сигнатуре элемента управления приложениями
| Имя элемента | Описание |
|---|---|
| Система — корреляция — [ActivityID] | Используйте идентификатор активности корреляции, чтобы сопоставить событие сигнатуры элемента управления приложениями с событием блока. |
| TotalSignatureCount | Общее число подписей, обнаруженных для заблокированного файла. |
| Signature | Число индексов, начиная с 0, текущей сигнатуры, отображаемой в этом событии 3089. Если файл содержит несколько подписей, вы найдете другие события 3089 для других подписей. |
| Хэш | Хэш-значение, используемое элементом управления приложениями для сопоставления с файлом. Это значение должно соответствовать одному из четырех хэшей, отображаемых в событии блока 3077 или 3076. Если для файла не найдены подписи (TotalSignatureCount = 0), отображается только хэш-значение. |
| SignatureType | Тип подписи. |
| ValidatedSigningLevel | Уровень авторизации подписывания Windows, с которым выполнена подпись. См . раздел Запрошенный и проверенный уровень подписи. |
| VerificationError | Причина, по которой эта конкретная сигнатура не прошла политику управления приложениями. См. раздел VerificationError. |
| PublisherName | Значение общего имени (CN) из конечного сертификата. |
| IssuerName | Значение CN из самого высокого доступного сертификата в цепочке сертификатов. Этот уровень обычно находится на одном сертификате ниже корневого каталога. |
| PublisherTBSHash | Хэш TBS конечного сертификата. |
| IssuerTBSHash | Хэш ТБS самого высокого доступного сертификата в цепочке сертификатов. Этот уровень обычно находится на одном сертификате ниже корневого каталога. |
Пошаговое руководство по примерам событий 3077 и 3089
Теперь давайте рассмотрим, как использовать данные событий в примерах событий 3077 и 3089, чтобы понять, почему политика управления приложениями заблокировала этот файл.
Сведения о том, какой файл блокируется и контекст блока
Ссылаясь на событие 3077, найдите сведения, определяющие политику, заблокированный файл и родительский процесс, который пытался ее запустить. Рассмотрим эти сведения о контексте, чтобы определить, является ли блок ожидаемым и нужным.
В этом примере заблокированный файл PowerShell.exe, который является частью Windows и обычно должен выполняться. Однако в этом случае политика основана на шаблоне политики Windows в S-режиме, который не позволяет узлам сценариев выполняться как способ ограничения направлений атаки. Для S-режима это событие блока выполнено успешно. Но предположим, что автор политики не знал об этом ограничении при выборе шаблона и рассматривал этот блок как непредвиденный.
Определение причины отклонения файла элементом управления приложениями
Опять же, ссылаясь на событие 3077, мы видим, что запрошенный уровень подписи 2 означает, что код должен передать политику управления приложениями. Но уровень проверенной подписи 1 означает, что код обрабатывается как неподписанный. "Без знака" может означать, что файл действительно не подписан, подписан, но с недопустимым сертификатом или подписан, но без сертификатов, разрешенных политикой управления приложениями.
Теперь давайте просмотрим связанные события 3089 для заблокированного файла. В этом примере мы рассматриваем только первую сигнатуру (индекс подписи 0), найденную в файле с несколькими подписями. Для этой сигнатуры validatedSigningLevel имеет значение 12, то есть он имеет подпись продукта Microsoft Windows. Параметр VerificationError 21 означает, что сигнатура не прошла политику управления приложениями.
Важно просмотреть сведения для каждого коррелированного события 3089, так как каждая сигнатура может иметь разные значения ValidatedSigningLevel и VerificationError.
Важно.
Обратите внимание, что уровень подписи для события 3077 интерпретируется совершенно иначе, чем ValidatedSigningLevel в событии 3089.
В случае события 3077 проверка уровня подписи сообщает нам, как двоичный файл фактически обрабатывается Windows.
В случае события 3089, с другой стороны, ValidatedSigningLevel сообщает нам о потенциальном максимальном уровне, который может получить сигнатура. Мы должны использовать VerificationError, чтобы понять, почему подпись была отклонена.
3. Устранение распространенных проблем
Проанализировав диагностические данные элемента управления приложениями, вы можете выполнить действия по устранению проблемы или выполнить дополнительные действия по отладке. Ниже приведены некоторые распространенные проблемы и действия, которые можно попытаться устранить или изолировать корневую проблему.
Проблема. Файл заблокирован, который вы хотите разрешить
- Используйте данные из основных журналов событий элемента управления приложениями, чтобы добавить правила, разрешая доступ к заблокированным файлам.
- Повторно разверните файл или приложение с помощью управляемого установщика, если ваша политика доверяет управляемым установщикам.
Проблема: политика активна, непредвиденная
Это условие может существовать, если:
- Политика удалена, но система не была перезагружена.
- Политика была частично удалена, но копия политики по-прежнему существует в разделе System или EFI.
- Политика с Идентификатором политики {A244370E-44C9-4C06-B551-F6016E563076} (формат одной политики) была скопирована в расположение политики с несколькими политиками перед активацией, что привело к дублированию двоичного файла политики на диске. Проверьте наличие файлов SiPolicy.p7b и {A244370E-44C9-4C06-B551-F6016E563076}.cip в разделах System и EFI.
- Политика была неправильно развернута на устройстве.
- Злоумышленник с правами администратора применил политику, чтобы вызвать отказ в обслуживании для некоторых критически важных процессов.
Чтобы устранить такую проблему, следуйте инструкциям по удалению политик управления приложениями для определенной политики.
Проблема. Происходит необработанное сбой приложения и события элемента управления приложениями не наблюдаются
Некоторые приложения изменяют свое поведение, когда активна политика управления приложениями в пользовательском режиме, что может привести к непредвиденным сбоям. Это также может быть побочным эффектом принудительного применения скриптов для приложений, которые неправильно обрабатывают поведение принудительного применения, реализованное узлами скриптов.
Попробуйте изолировать первопричину, выполнив следующие действия:
- Проверьте другие журналы событий, перечисленные в разделе 1 этой статьи, на наличие событий, соответствующих непредвиденным сбоям приложения.
- Временно замените политику управления приложениями другой политикой, которая отключает принудительное применение скриптов и повторное тестирование.
- Временно замените политику управления приложениями другой политикой, которая разрешает все COM-объекты и повторное тестирование.
- Временно замените политику управления приложениями другой политикой, которая ослабляет другие правила политики и повторно тестирует.
Проблема. Приложение, развернутое управляемым установщиком, не работает
Чтобы отладить проблемы с помощью управляемого установщика, попробуйте выполнить следующие действия:
- Убедитесь, что политика управления приложениями, блокирующая приложение, включает параметр включения управляемого установщика.
- Убедитесь, что действующая политика AppLocker $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml является правильной, как описано в разделе Автоматическое разрешение приложений, развернутых управляемым установщиком.
- Убедитесь, что службы AppLocker запущены. Эти сведения находятся вenv:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt$ , созданных в разделе 1 этой статьи.
- Убедитесь, что существует файл AppLocker с именем MANAGEDINSTALLER. APPLOCKER существует в папке CiDiag, созданной ранее. Если это не так, повторите шаги для развертывания и включения конфигурации AppLocker управляемого установщика.
- Перезапустите процесс управляемого установщика и проверка, что событие 8002 наблюдается в журнале событий AppLocker — EXE и DLL для процесса управляемого установщика с policyName = MANAGEDINSTALLER. Если вместо этого вы видите событие с 8003 или 8004 с PolicyName = MANAGEDINSTALLER, проверка правила ManagedInstaller в XML-коде политики AppLocker и убедитесь, что правило соответствует процессу управляемого установщика.
- Используйте fsutil.exe , чтобы убедиться, что файлы, написанные процессом управляемого установщика, имеют расширенный атрибут источника управляемого установщика. В противном случае повторно разверните файлы с помощью управляемого установщика и проверка снова.
- Протестируйте установку другого приложения с помощью управляемого установщика.
- Добавьте другой управляемый установщик в политику AppLocker и протестируйте установку с помощью другого управляемого установщика.
- Убедитесь, что приложение сталкивается с известным ограничением управляемого установщика. В этом случае необходимо авторизовать приложение с помощью других средств.
Проблема. Приложение, которое вы ожидали разрешить граф интеллектуальной безопасности (ISG), не работает
Чтобы отладить проблемы с помощью ISG, выполните следующие действия:
- Убедитесь, что политика управления приложениями, блокирующая приложение, включает параметр для включения графа интеллектуальной безопасности.
- Убедитесь, что службы AppLocker запущены. Эти сведения находятся вenv:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt$ , созданных в разделе 1 этой статьи.
- Используйте fsutil.exe , чтобы убедиться, что у файлов есть расширенный атрибут источника ISG. В противном случае повторно разверните файлы с помощью управляемого установщика и проверка снова.
- Убедитесь, что приложение сталкивается с известным ограничением isg.
4. При необходимости сообщите о проблемах в корпорацию Майкрософт
Если после выполнения рекомендаций, описанных в этой статье, вы считаете, что обнаружили проблему с продуктом, сообщите о проблеме в корпорацию Майкрософт.
- Клиенты со службой поддержки Microsoft Premier должны регистрировать запрос на обслуживание через обычные каналы.
- Все остальные клиенты могут сообщать о проблемах непосредственно группе разработчиков по управлению приложениями через Центр отзывов Windows. Выберите категорию Безопасность & конфиденциальность — управление приложениями , чтобы убедиться, что проблема правильно перенаправлена в группу продуктов управления приложениями.
При сообщении о проблемах обязательно укажите следующие сведения:
- Все диагностические данные элемента управления приложениями , описанные выше.
- Если это возможно, заблокированные файлы.
- Четкие инструкции по воспроизведению проблемы.