Групповая политика изменена вирусом

Групповые политики — это параметры, управляющие функционированием системы. Групповая политика упрощает администрирование, предоставляя администраторам централизованный контроль над привилегиями, правами и возможностями пользователей и компьютеров.

Изменять групповые политики можно с помощью Редактора локальной групповой политики.

В редакциях операционной системы Windows 7 Starter, Home Basic и Home Premium редактор локальной групповой политики недоступен. Также он недоступен в редакциях Home Windows 8 и 10.

Групповые политики в Windows 10 позволяют управлять различными штатными средствами системы:

Политики для настройки встроенного брандмауэра Windows;
Политики для управления электропитанием;
Политики для настройки панели управления, панели задач и др.
Политики для настройки антивирусной защиты;
Политики для управления подключаемых устройств;
Политики для настройки штатных средств шифрования
Политики для настройки штатного браузера;
Политики для настройки беспроводных сетей и многое многое другое.

Для настройки параметров в операционной системе MS Windows 10 используется оснастка Редактор локальной групповой политики. Данная оснастка служит для просмотра и редактирования объектов групповой политики (Group Policy Object, GPO), в которых хранятся параметры локальных политик для компьютера и пользователей.

Оснастку Редактор объектов групповой политики можно запустить, например, введя в окне Выполнить, либо в поисковой строке gpedit.msc.

Рис.1 Окно Выполнить

Оснастка Локальная политика безопасности входит в состав оснастки Редактор

Для удобства можно добавить ярлык оснастки на рабочий стол. Для этого необходимо открыть C:\Windows\System32 , выбрать правой клавишей мыши gpedit и отправить ярлык на рабочий стол.

Рис.2 Создание ярлыка для оснастки Редактор локальной групповой политики

Чтобы работать с объектами локальной групповой политики, необходимо войти в систему с учетной записью администратора.

Структура редактора групповой политики

Оснастка Редактор локальной групповой политики позволяет изменять политики, распространяющиеся как на компьютеры, так и на пользователей.

В панели пространства имен оснастки Редактор локальной групповой политики представлено два узла: Конфигурация компьютера и Конфигурация пользователя.

Узел Конфигурация компьютера содержит параметры политик, определяющих работу компьютера. Эти политики регулируют функционирование операционной системы, определяют права пользователей в системе, работу системных служб и средств безопасности и т. д.

Узел Конфигурация пользователя содержит параметры политик, определяющих работу пользователей.

Рис.3 Редактор локальной групповой политики

Изменение в групповых политиках по умолчанию в операционной системе Windows применяются через полтора часа (90 мин.). За данную настройку опять же отвечает отдельная политика. Частота обновления определяется политикой Интервал обновления групповой политики для компьютеров, которая расположена в узле Конфигурация компьютера > Административные шаблоны > Система > Групповая политика. Интервал указывается в минутах и определяет, как часто компьютер будет предпринимать попытку обновления политик. Рационально уменьшать интервал обновления групповой политики при частом применении изменений.

Рис.4 Настройка частоты обновления политик

Рис.5 Настройка частоты обновления политик

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

осуществить перезагрузку операционной системы
использовать утилиту gpupdate.exe для принудительного обновления групповой политики. Для этого необходимо либо в окне Выполнить, либо в командной строке ввести gpupdate /force и нажать ОК.

Рис.6 Обновление политик в командной строке

С использованием параметра /target можно указать, будет ли это обновление параметров применяться только для пользователя или только для компьютера. Если не указано, обновляются параметры обеих политик.

Например, для выполнения обновления политик для пользователя, необходимо ввести gpupdate /target:user .

Рис.7 Обновление политик для пользователя в командной строке

Пример последовательности действий при редактировании определенной политики

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

Войти в систему под учетной записью администратора.
Запустить Редактор локальной групповой политики
- Открыть окно Выполнить,
- Ввести gpedit.msc,
- Нажать Enter.
Последовательно развернуть элементы Конфигурация пользователя >Административные шаблоны >Панель управления в окне Редактора локальной групповой политики.

Рис.8 Редактирование параметра политики Отображать только указанные объекты панели управления

Дважды щелкнуть ЛКМ по параметру политики Отображать только указанные объекты панели управления.
Выбрать значение Включено.

Рис.9 Редактирование параметра политики Отображать только указанные объекты панели управления

Нажать кнопку Показать, чтобы вызвать диалоговое окно Вывод содержания.
Ввести имя апплета или апплетов, которые необходимо показывать в Панели управления, и нажать Enter.

Рис.10 Список разрешенных элементов панели управления

Нажать OK.
Закрыть редактор локальной групповой политики
Проверить результат

Для некоторых политик, чтобы изменения вступили в силу сразу, необходимо в окне Выполнить ввести gpupdate /force .

Рис.11 Список элементов панели управления до изменения параметра локальной групповой политики

Рис.12 Список элементов панели управления после изменения параметра локальной групповой политики

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

Чтобы настраивать политики для конкретных пользователей, в операционной системе Windows применяется многоуровневая локальная групповая политика:

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

Последовательность действий при добавлении объектов групповой политики через консоль управления (Microsoft Management Console, MMC)

В окне Выполнить ввести MMC и нажать Enter
Открыть меню Файл и выбрать опцию Добавить или удалить оснастку

Рис.13 Добавление оснастки через консоль управления

Найти и выделить Редактор объектов групповой политики и нажать кнопку Добавить

Рис.14 Диалоговое окно Добавление и удаление оснасток

В открывшемся мастере групповой политики в поле Объект групповой политики оставить по умолчанию Локальный компьютер (первый уровень, стандартная локальная политика) и нажать кнопку Готово.

Рис.15 Диалоговое окно выбора объекта групповой политики

В окне Добавление и удаление оснасток добавить новую оснастку Редактор объектов групповой политики.
В мастере групповой политики в поле Объект групповой политики нажать кнопку Обзор.
На вкладке Пользователи выбрать Администраторы и нажать кнопку ОК и Готово

Рис.16 Настройка объекта групповой политики второго уровня

В окне Добавление и удаление оснасток добавить новую оснастку Редактор объектов групповой политики.
В мастере групповой политики в поле Объект групповой политики нажать кнопку Обзор.
На вкладке Пользователи выбрать нужную учетную запись.
Нажать ОК, чтобы закрыть диалоговое окно Добавление и удаление оснасток.

Рис.17 Консоль управления

Для удобства, используя команды в главном меню Файл >Сохранить как, сохранить файл консоли управления на рабочем столе для последующего редактирования политик.

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

Не знаю, чем руководствовались люди из Microsoft, когда проектировали и создавали систему групповых политик в Windows, но получилось у них не очень. Система получилась гибкой и функциональной, но с немалым количеством лазеек, позволяющих обойти ограничения и добраться до тех мест ОС, доступ к которым запрещен.

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

Что такое Групповые политики (Group Policy)?

Если верить скучным определениям, то групповые политики (или Group Policy) — это эффективный и централизованный механизм управления многочисленными параметрами операционных систем и приложений. Групповые политики позволяют админам определять правила, в соответствии с которыми настраиваются параметры рабочей среды как для пользователей, так и для компьютеров. Проще говоря, это довольно мощный инструмент для ограничения в действиях обычных пользователей. Существует масса различных политик и прав, с помощью которых можно запретить вызов диспетчера задач или редактора реестра, запретить доступ к меню "Пуск", а также довольно гибко ограничить запуск программного обеспечения (это реализуется с помощью так называемых Software Restriction Policies). Является ли этот механизм эффективным? Лишь отчасти. Доступ к шорткатам, запуск левого ПО и системных приложений, изменение настроек — все это достаточно легко запрещается с помощью групповых политик, и с этой точки зрения можно сказать спасибо разработчикам ОС. Но, увы, как это обычно бывает, эти политики зачастую можно обойти. Тут стоит сделать оговорку. Все политики можно разбить на две категории — для компов и для пользователей. Групповые политики доступны как в домене, так и на локальном компе. Если речь идет о локальной машине, то их можно посмотреть через специальную оснастку gpedit.msc (secpol.msc). В данной статье основной акцент сделан именно на доменные групповые политики. Итак, приступим.

Трюк 1. Обходим загрузку политик

Давай разберемся, как вообще каждая машина в локальной сети получает групповые политики из домена? Процесс создания групповых политик можно разбить на следующие условные этапы:

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

Итак, что мы здесь видим: политики подгружаются на стадии входа в систему. Здесь есть небольшая фича. По умолчанию обновление политик выполняется каждые 5 минут. Но если политики не были получены во время входа в систему, то обновляться они не будут! Вырисовывается элементарный способ, как эту особенность можно использовать:

Вынимаем патч-корд из компа.
Включаем комп и логинимся под своей учеткой.
Подключаем патч-корд обратно.

Даже при отсутствии доступа в сеть мы сможем войти в домен, так как винда ранее закешировала наш логин и пароль (это произошло во время предыдущего входа в систему). Но уже без применения групповых политик. При этом мы спокойно сможем использовать ресурсы сети, так как патч-корд к этому моменту будет на месте, а со всякими авторизациями на удаленных ресурсах справится сама винда. Стоит добавить, что в безопасном режиме винды групповые политики вообще не действуют. Комментарии, я думаю, излишни.

Трюк 2. Как происходит проверка политик?

Важно понимать, на каком этапе происходит сопоставление действия, которое хочет выполнить пользователь, с теми ограничениями групповых политик, которые на него накладываются. Сперва давай разберемся, где расположены политики. Изначально, конечно, на контроллере домена, откуда уже передаются на машины в локальной сети. После получения групповых политик на клиентской машине они сохраняются в реестре винды в следующих местах (приведены основные ветки):

Политики для компа:

HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsCurrentVersionPolicies
HKEY_LOCAL_MACHINESoftwarePolicies

Политики для пользователей:

HKEY_CURENT_USERSoftwareMicrosoft WindowsCurrentVersionPolicies
HKEY_CURENT_USERSoftwarePolicies

Когда запускается какой-то процесс, то в нем (то есть в userspace’е) производится проверка данных веток реестра (через подгруженную библиотеку advapi.dll) на те или иные ограничения, которые потом кешируются/сохраняются в памяти процесса. Они проверяются, когда пользователь выполняет какое-то действие, например запуск ПО. В чем подвох? В том, что контроль производится из самого процесса. То есть если процесс "не захочет" проверять политики, то ничто его не заставит их соблюдать. Никакого общего мониторинга не производится! Отсюда вывод: если мы каким-то образом сможем запустить произвольный процесс, то политики нам уже не страшны. Сделать как правило — не проблема. Даже если нет возможности закачать программу на хост, можно выполнить ее удаленно (например, через шару).

Трюк 3. Обходим SRP

Увы, дальше на нашем пути возникает другой механизм ограничений — SRP (Software Restriction Policies). Это группа политик, с помощью которых админ может ограничить список ПО, которое может запускать пользователь, через черный и белый списки. Blacklist и Whitelist определяются с помощью правил, которые можно задавать несколькими способами: по зонам и по сертификатам (первые два варианта практически не используются), а также по пути до файла и по его хешу. О том, что в системе действуют политики SRP, указывает соответствующий пункт в реестре — HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoft WindowsSafer CodeIdentifiersTransparentEnabled со значением большим 0, который, как уже было сказано выше, проверяется при запуске процесса. Наша задача, соответственно, отрубить эту проверку внутри запускаемого процесса. Марк Руссинович еще в далеком 2005 году опубликовал пост в блоге об обходе SRP и представил тулзу GPdisable. Она производит DLL-инъекцию в заданный процесс, подгружая специальную DLL’ку. Когда процесс попытается получить значение ключа реестра HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSafer CodeIdentifiersTransparentEnabled , то есть будет проверять присутствие политик SRP, данная библиотека перехватит запрос и возвратит STATUS_OBJECT_NAME_NOT_FOUND. Таким образом, процесс думает, что все ОК и SRP политики в системе не действуют. После покупки компании Sysinternals Майкрософтом GPdisable перестал был официально доступным (но его по-прежнему легко найти в Сети. Есть еще более продвинутые решения. Утилита GPCul8or от Eric’a Rachner’a выполняет аналогичные функции, но доступна в исходниках. Что это нам дает? Мы можем добавить в GPCul8or любые другие значения реестра винды (DisableTaskMgr, ProxySettingsPerUser к примеру) и таким образом обойти все возможные ограничения политик. Какие именно значения, спросишь ты. Тебе в помощь RegMon от Марка Руссиновича, хотя, по сути — это все значения из ветки Policies. Другой оригинальный способ в своем блоге опубликовал Дидье Стивенс. Используя свою тулзу bpmtk (Basic Process Manipulation Tool Kit), он предложил прямо в памяти процесса изменять значение необходимого для групповой политики ветки реестра.

Трюк 4. Binary planting

Утилита GPdisable состоит из двух файлов:

gpdisable.exe — инъектирует DLL в процесс;

gpdisable.dll — специальная DLL для обхода SRP.

Как я уже сказал, если мы можем запустить приложение, то можем легко обойти SRP и другие политики (через GPdisable, bpmtk, GPCul8or — неважно). Однако в реальной системе может оказаться не так уж просто запустить эти приложения. Но мы можем подгрузить DLL (в том числе gpdisable.dll). Тут есть важный нюанс. Групповые политики при запуске ПО могут проверять и DLL’ки, но при этом достаточно сильно падает производительность системы, потому по умолчанию эта опция отключена. И мы это можем использовать! Очень кстати приходится недавнее исследование от компании Across Security, которое рассказывает о новых (достаточно извращенных, но работающих) методах подгрузки кода в процессы. Прием называется Binary planting (и как его классический пример — dll hijacking), при его изучении у меня возникла мысль: "а почему не использовать его для обхода групповых политик?". Если система разрешает запуск приложений только из белого списка (пускай даже только Word), то этого уже достаточно, чтобы подгрузить нашу полезную DLL для обхода SRP. Итак, попробуем скрестить dll hijacking от парней из Across и GPdisable:

Переименовываем gpdisable.dll в ehTrace.dll.

Создаем папку с именем куку. <2E095DD0-AF56-47E4-A099-EAC038DECC24>(название любое, текст после точки исчезнет).

Кидаем ehTrace.dll в только что созданную папку.

Заходим в папку и создаем там любой документ в Word, Excel или, к примеру, PDF’ку.

Теперь открываем только что созданный файл.

Соответствующая программа должна запуститься. И запустить вместе с подгруженной DLL’кой!

Все, политики нам не страшны.

Трюк 5. Используем исключения

Часто можно обойтись и без подобных ухищрений, если знать тонкости политик, в результате которых их действия распространяются:

на программы, запущенные от имени учетной записи SYSTEM;

драйверы и другие приложения уровня ядра;

макросы внутри документов Microsoft Office;

программы, написанные для общей многоязыковой библиотеки времени выполнения (Common Language Runtime).

Итак, процессы от SYSTEM не контролируются. Первый финт ушами: если есть доступ к какому-то ПО, запущенному под такой учеткой, — атакуем. Например, нажимаем Win+U — запускаются "специальные возможности" (лупа и экранная клавиатура). Utilman.exe (процесс "специальных возможностей") при этом запускается от SYSTEM. Далее идем там в "Справку". Она тоже должна открыться с нужными привилегиями, так как запущена в контексте процесса c правами SYSTEM. Если винда не самая новая (до Vista), то кликаем правой кнопкой на синей верхней панельке "Jump to url", там печатаем "C:" и получаем настоящий встроенный explorer. Если более новая, то можно по правому клику в тексте хелпа просмотреть исходный код (View Source) через блокнот, откуда далее добраться до файлов. Или другой вариант — "добавить" новый принтер, получив опять же доступ к листингу файлов.

Другая интересная категория — макросы внутри документов Microsoft Office. Это страшное дело. Попробуем для начала реализовать запуск ПО. Хотя если запуск заблочен обычными политиками (не SRP), как, например, блокировкой диспетчера задач, то этот обход не сработает. Но нам-то главное — запустить специальный exe’шник. Поэтому в любом документе смело создаем следующий макрос и пробуем запустить его:

Sub GOSHELL()
Shell "C:windowssystem32regedit.exe", vbNormalFocus
End Sub

В результате, как ты можешь догадаться, мы получаем запущенный exe. Хардконный метод предложил опять же Дидье Стивенс. Используя в макросе MS Excel функции VirtualAlloc, WriteProcessMemory и CreateThread, он сумел подгрузить шеллкод из макроса в память процесса. Данный шеллкод подгружает DLL’ку в память процесса, а DLL’ка — не что иное, как cmd.exe. Кстати, ее исходники взяты из проекта ReactOS. Как я уже сказал, SRP может препятствовать запуску DLL’ек (хотя и не делает этого по умолчанию), но если подгрузку библиотек осуществлять, используя функцию LoadLibraryEx с LOAD_IGNORE_CODE_AUTHZ_LEVEL вместо LoadLibrary, то проверка на принадлежность подгружаемой dll к white-листу не происходит!

Трюк 6. Используем переменные среды

Когда начинаешь мучить групповые политики, то приходит осознание, что для создания защищенной системы потребуется попотеть. Дело трудное и с большим количеством тонкостей. Например, разработчики предлагают админам использовать удобный хинт — указывать переменные среды в качестве путей для ограничений SRP. Да вот здесь проблема. У пользователя, если их жестко не прищучить, есть возможность их переопределять. Указал, например, админ, что из папки %TEMP% можно запускать exe’шники, а юзер взял да и переопределил следующей командой:

И вот так просто получил возможность запускать файлы из корня C:. Кроме того, не стоит забывать про стандартные директории, из которых разрешен запуск exe-файлов:

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%*.exe

%HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%System32*.exe

Они разрешают запуск ПО только из папки Windows и Program Files для пользователей. У обычного пользователя нет возможности записи в них, но и здесь могут быть проблемы. Так как на самом деле права на запись у пользователя есть — по дефолту в папку C:windowssystem32spoolPrinters и C:windowstemp. Если у пользователя будет возможность писать в какой-то каталог с софтом, то, считай, соответствующие политики SRP уже не сработают. Кстати, для того чтобы на практике поверить, какие у пользователя есть права, поможет тулза — AccessChk от все того же Руссиновича.

Трюк 7. Используем другого пользователя

Есть способ не подпустить подгрузки политик, но для этого трика нам понадобятся логин и пароль другого пользователя. Суть в том, что нам надо войти в систему "еще раз", но не под собой. Тут два варианта:

+ правый клик на запускаемом файле, далее в контекстном меню выбираем "Run as…".

Через консоль набираем команду: runas /noprofile .

Другой пользователь, под которым ты запускаешь программку, как и ты, может быть обычным пользователем с ограниченными правами. Но политики на запущенную программку уже не будут действовать! См. рисунок.

На нем пользователь test_gpo3 не может запустить regedit из-за политик. Но, запустив под test_gpo2 любой exe’шник (диспетчер задач например), он уже ничем не ограничен и поэтому может запустить regedit. Кроме того, если у нас есть возможность удаленного входа в систему (по RDP, например), то мы можем провести аналогичный финт, но только с одной учеткой (демонстрацию можешь посмотреть в этом видео).

Трюк 8. Вспоминаем про HTA

Последний хинт касается неофициальных исключений, на которые не действуют групповые политики. Вадимc Поданс написал в блоге отличную серию постов, посвещенных SRP-политикам. В частности, он обнаружил отличный путь для их обхода и запуска произвольного кода с использованием приложения HTA (HTML Application).

Итак, последовательность действий:

Создаем файлик с примерно таким текстом:

Сохраняем его с расширением .hta (например, execute_this.hta).

Создаем ярлык для него.

Открываем ссылку — и hta запускается.

Надо ли говорить, что вместо вызова безобидного MessageBox’а VB-код может сделать в системе что угодно? Политики SRP должны проверять весь код, который может исполняться, в том числе и всевозможные скрипты. Однако из-за тонкостей работы групповых политик данный обход работает. К аналогичным "глюковатым" расширениям помимо HTA Вадимс относит REG, MSC, HTA, CHM. Точно так же ситуация наблюдается и с com-файлами (в том числе всякими олдскульными ДОС’овскими программами, которые все еще разбросаны в папке винды). Они не учитывают правила групповых политик, так как работают в виртуальной машине DOS.

Групповые политики в тонких клиентах

Хочется еще рассказать про такие системы, как Citrix XenApp. Что это такое? XenApp, если говорить простым языком, это система "доставки" приложений (хотя это только часть функционала). По сути, это что-то типа терминального сервера винды, но когда пользователю доступно только конкретное приложение. В жизни это выглядит так. Пользователь коннектится клиентом к Citrix-серверу — ему выводится список доступного ПО. Далее юзер запускает какое-то приложение и начинает в нем работать. Основная фича в том, что фактически процесс приложения выполняется на Citrix-сервере. По сути, данный подход хорош (особенно с тонкими клиентами), но у него есть пучок косяков с точки зрения безопасности. Так как процесс — на сервере, то, значит, пользователю доступны все ресурсы сервера (с учетом пользовательских прав, конечно). Это не очень хорошо, так как предполагается, что у пользователя должен быть доступ только к запущенной программе, а не к ОС. Что еще хуже, добраться-то до самой ОС — не проблема. Даже если у самого ПО нет возможности по взаимодействию с ОС (нет меню "Открыть", "Сохранить как"), то стандартные возможности винды все еще работают: нажимаем в Citrix-приложении — нам открывается диспетчер задач Citrix-сервера, или правый клик по раскладке клавиатуры, а оттуда в файл справки с возможностью листинга директорий. Лично я столкнулся с групповыми политиками именно в этом контексте — при взломе Citrix.

Наш итог

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

Групповые политики — это основной инструмент управления пользователями в домене. С их помощью администратор может настраивать практически любые параметры рабочей среды пользователя. Все, начиная от запрета на запуск определенных программ и заканчивая рисунком на рабочем столе можно задать через групповые политики. Управление политиками осуществляется на уровне домена и только члены группы администраторов домена или предприятия имеют к ним доступ.

А можно ли отменить действие групповых политик на компьютере, не будучи при этом администратором домена? Сегодня мы попробуем это выяснить. В качестве подопытного возьмем компьютер с установленной на нем Windows 7, являющийся членом домена. Все действия будем проводить под обычной учетной записью, не имеющей в домене никаких административных полномочий.

За применение групповых политик на локальном компьютере в Windows 7 отвечает служба Group Policy Client (gpsvc). Ее состояние можно посмотреть прямо в Диспетчере задач, на вкладке Службы.

Или в оснастке Службы (Services).

Первое что приходит в голову — просто остановить службу и установить режим запуска в Disabled. Но не все так просто, как кажется. Служба gpsvc запускается от имени локальной системы, и не остановить, не изменить параметры запуска ее из графической оснастки мы не сможем.

Как вариант можно с помощью утилиты psexec запустить командную консоль от имени системы и затем остановить службу командой net stop gpsvc

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

Первым делом нам надо изменить владельца раздела. Для этого идем в дополнительные параметры безопасности и выбираем владельцем свою учетную запись.

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

Теперь можно вернуться к настройкам службы. За режим запуска отвечает параметр Start. По умолчанию он равен 2, что означает режим запуска Авто. Для отключения службы ставим 4.

И еще. Отключив таким образом службу клиента групповой политики, вы периодически будете получать в трее уведомления о недоступности службы Windows.

Чтобы этого избежать, можно удалить (предварительно сохранив) раздел реестра HKLM\SYSTEM\CurrentControlSet\Control\Winlogon\Notifications\Components\GPClient

Таким вот нехитрым способом можно отключить действие групповых политик. При этом совсем не обязательно обладать административными правами в домене, достаточно лишь входить в группу локальных администраторов на компьютере. Правда такой номер может пройти только на компьютерах с Windows 7 или Vista. В более ранних ОС службы gpsvc нет, а за применение групповых политик отвечает служба Winlogon.

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

Читайте также: