Устранение неполадок

Каждый случай разобран по одному образцу: как проверить по журналу, в чём причина, что делать. Журнал — единственный источник, по которому видно, что решила служба; он лежит в %ProgramData%\LaPorta USB\logs, разбор полей — в journal-reference.md.

Путь к политике не задан

Как проверить. Событие service_started с версией политики 0 и событие policy_unavailable рядом с ним. В реестре HKLM\SOFTWARE\LaPortaUsb\PolicyPath стоит \\server\laportausb$\policy.json — значение по умолчанию.

Причина. POLICYPATH при установке не передали. Тихая установка (/qn) в этом случае проходит без предупреждения: условие установщика пропускает её, чтобы раскатка групповой политикой не спотыкалась. Предупреждение показывается только при установке руками, и тогда установка прерывается совсем — ни службы, ни файлов в системе не появляется.

Служба идёт по умолчанию на сетевую шару, которой на одиночной машине нет, не находит файл и уходит в запасной режим: политика недоступна — разрешено всё. Программу ставили ради запрета, а машина осталась без единого запрета.

Что делать. Задать путь заново при восстановлении пакета и перезапустить службу:

msiexec /i LaPortaUsb.msi POLICYPATH="C:\ProgramData\LaPortaUsb\policy.json" REINSTALL=ALL REINSTALLMODE=amus /qn

Проверить, что в журнале появилось policy_reloaded с ненулевой версией.

Политика недоступна

Как проверить. Событие policy_unavailable; в поле message — текст отказа («Файл не найден: …»). Оно пишется один раз при входе в это состояние, а не на каждом цикле опроса, поэтому смотреть надо не последнюю строку журнала, а первую после запуска. Дальше — на версию политики в service_started и на поле policy_version у событий attach.

Причина и что делать — по тому, что видно рядом:

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

Не проверено: поведение на настоящей сетевой шаре. В приёмке недоступность сводилась к отсутствию локального файла; SMB отвечает иначе — таймаутами, способными подвесить чтение политики на десятки секунд.

Запрет не применился

Как проверить. Событие apply_failed, а у соседнего attach — applied: false и enforcement_failed: true. В поле message — стадия отказа и код, который вернула система. Подробности Windows пишет в свой журнал; там же, событием 225, названы по имени процесс и командная строка того, кто держит том.

Код 5 — том занят. Кто-то удерживает открытый файл на носителе: сторонний процесс, проводник, антивирус или индексатор. Пока дескриптор держат, носитель остаётся полностью доступен.

Что делать: ничего. Служба возвращается к носителю на каждом тике рабочего цикла и применит решение, как только том освободится, — в журнале появится enforced. Журнал при этом не засоряется: отказ пишется один раз и успех один раз, сколько бы попыток ни было между ними.

Если ждать нельзя — закрыть держателя (его имя есть в журнале Windows) или перезапустить службу.

Код 13 — отказ установщика классов. Возникал на носителях с несколькими томами: каждая попытка начиналась с размонтирования и сама создавала условие, из-за которого отказывал следующий за ней вызов. Исправлено — повторяется отключение узла, а не вся последовательность целиком.

Что делать: если код 13 виден в журнале, версия программы старше исправления. Обновить.

Одна запись на много подключений

Как проверить. Искать события attach_blocked — по одному на каждое подключение уже заблокированного носителя. Класс в них unknown, полей решения нет, серийный номер на месте.

Причина. Узел диска у заблокированного носителя остаётся отключённым и при переподключении в системе не появляется — уведомления нет, и служба о повторной вставке не узнаёт. Заблокированную флешку можно было втыкать сколько угодно, и в журнале оставалась одна запись. Закрыто подпиской на USB-узел устройства: он поднимается даже тогда, когда дочерний узел диска отключён.

Решение по такому носителю не пересчитывается намеренно: у неработающего узла не прочитать ни томов, ни сменности, а без неё флешку от внешнего диска не отличить. Отсюда класс unknown.

Что делать. Если событий attach_blocked нет вовсе, а носитель заведомо приносили — версия программы старше исправления, обновить.

Отдельный случай — носитель, вставленный до запуска службы. Уведомление о подключении система рассылает только в момент подключения. Носитель, стоявший в разъёме при старте машины, раньше оставался доступен и в журнал не попадал — готовый обход контроля через выключение машины. Закрыто осмотром подключённых носителей при запуске службы.

Строгий режим

Превентивный слой правит ветку ограничений установки устройств (HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions) и не даёт неизвестному носителю установиться вовсе. Устройство слоя разобрано в overview.md.

Носитель перестал устанавливаться.

Как проверить: искать носитель в ветке AllowInstanceIDs. В журнале службы записи о нём не будет вовсе — Windows не дала устройству установиться, и служба о попытке не узнала. Этим случай отличается от запрета реактивным слоем, где запись attach с decision: block есть всегда.

Причина: носитель выпал из белого списка по сроку хранения журнала (retention_days) либо не регистрировался вовсе — не был подключён при выключенном strict_mode ни разу. Выпадение по сроку следует из того, как строится список: служба берёт из журнала носителей за окно retention_days, и носитель, чьи записи в него не попадают, в списке не участвует. Не проверено — на приёмке истечение срока не воспроизводили ни на живой машине, ни тестом.

Что делать: если носитель просто долго не подключали — увеличить retention_days. Если он не регистрировался никогда — выключить strict_mode, подключить носитель, дождаться в журнале решения allow по нему, и только потом включить режим снова.

Превентивный запрет не включился.

Как проверить: искать в журнале событие strict_mode_conflict; проверить, не стоит ли strict_mode в политике в паре с enforcement_mode: audit; проверить, снялась ли предохранительная копия ветки перед первой правкой — есть ли файл в каталоге %ProgramData%\LaPorta USB\registry-backup.

Причина: strict_mode_conflict пишется, когда ветка при первом обращении оказалась занятой — в неё пишут доменная политика и средства защиты, причём под теми же именами значений, что использует программа. Такая ветка считается чужой и не трогается вовсе, служба остаётся на одном реактивном слое. Пара strict_mode с audit не включает превентивный запрет никогда: режим наблюдения ничего не ограничивает. Не снявшаяся копия ветки останавливает слой раньше, чем он дошёл бы до самой ветки.

Что делать: при занятой ветке — найти её источник (доменную политику, антивирус) и решать вопрос там, программа её не трогает. При паре с audit — перевести enforcement_mode в enforce. При не снявшейся копии — проверить права службы на каталог %ProgramData%\LaPorta USB\registry-backup и перезапустить службу.

Где смотреть подробности. Что именно решил превентивный слой — сколько экземпляров разрешено, не отказала ли копия ветки, — служба пишет в журнал приложений Windows («Просмотр событий» → «Журналы Windows» → «Приложение», источник LaPortaUsb). В журнал программы попадает только strict_mode_conflict: остальное о ветке не относится к носителям и в аудит по устройствам не входит.

Машина не принимает накопители, а программы нет.

Как проверить: программа удалена или служба остановлена не штатно (например, машину выключили посреди работы, а не остановили службу или не удалили программу штатно), а ветка ограничений всё ещё на месте.

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

Что делать: вернуть копию ветки командой reg import — файл лежит в %ProgramData%\LaPorta USB\registry-backup, имя вида restrictions-<время>.reg:

reg import "%ProgramData%\LaPorta USB\registry-backup\restrictions-<время>.reg"

Файл копии не удалять. По его наличию служба узнаёт, что ветку правила она сама, а не доменная политика. Без него служба сочтёт ветку чужой и не снимет ограничения даже при штатной остановке — снимать их придётся вручную, как описано ниже.

Если до первой правки ветки не было вовсе, копия — это файл-заметка с комментарием, а не выгрузка: reg import для неё отвечает «операция успешно завершена», но ничего не делает и ветку не удаляет. В этом случае ветку нужно удалить вручную:

reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions" /f

После снятия ограничений любым из способов узел носителя, которому раньше отказали в установке, сам не оживает — pnputil /scan-devices не помогает. Узел нужно переустановить полностью:

pnputil /remove-device <идентификатор>
pnputil /scan-devices

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

Запрет рядом с антивирусом

Как проверить. По журналу службы. Если носитель не работает, а у события attach стоит decision: block и applied: true — запрет наш. Если decision: allow либо applied: false, а носитель всё равно недоступен, — запрет чужой, и искать его надо в средстве защиты.

Причина. У Kaspersky Endpoint Security есть собственный контроль устройств, который запрещает носители независимо от нашей политики. Два запрета не мешают друг другу, но внешне неразличимы: носитель просто не открывается.

Что проверено. Совместная работа: запрет и метка «только чтение» применялись штатно, размонтирование томов проходило без «том занят», файлы программы не изымались в карантин, служба и агент работали непрерывно. В журнале антивируса не было ни одного упоминания ни программы, ни носителя.

Не проверено: в журнал Windows попадает лишь часть событий антивируса, остальное лежит в его собственной базе и читается только из его окна отчётов. Та часть не проверялась.

Токен

Как проверить. Событие attach с class: token, decision: allow, reason: token_never_enforced, applied: false.

Причина, если такого события нет. Токен не дошёл до службы. Устройство попадает в неё через интерфейсы диска, тома, смарт-карт-ридера и переносимых устройств либо через осмотр дисков при запуске. Токен с фирменным драйвером, не заводящий интерфейса смарт-карт-ридера, до классификатора не дойдёт вовсе — и перечень известных изготовителей токенов этого не исправит, он проверяется уже в классификаторе.

Что делать. Если токен перестал работать, а событие с классом token в журнале есть и в нём applied: false — программа его не трогала: узел устройства не менялся, в учёт отключённых узлов токен не попадал. Причину искать в другом месте.

Токены не блокируются никогда и политикой не настраиваются: класс token в defaults задавать запрещено.

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

Мелочь, которая мешает разбору. Серийного номера у события токена нет (serial_trusted: false), а instance_id построен по номеру порта, а не по устройству: два одинаковых токена в журнале не различить, и тот же токен в другом разъёме даст другой идентификатор. На запрет это не влияет, но восстановить по журналу, кто каким токеном пользовался, нельзя. Поле vendor при этом показывает изготовителя драйвера, а не токена.