Не обновляются групповые политики windows 7

Обновлено: 04.07.2024

Всё о PowerShell в Windows и на Linux. Системное администрирование Windows

В этой статье мы покажем, как актуализировать параметры групповой политики (GPO) на компьютерах Windows в домене Active Directory: как автоматически обновлять (актуализировать) групповые политики, как использовать команду GPUpdate, как обновлять их удалённо с помощью Group Policy Management Console, GPMC.msc (консоль Управления групповой политикой) или командлет PowerShell Invoke-GPUpdate.

Как изменить интервал актуализации групповой политики?

Прежде чем новые параметры, заданные вами в локальной или доменной групповой политике (GPO), будут применены к клиентам Windows, служба клиента групповой политики должна прочитать политики и внести изменения в настройки Windows. Этот процесс называется Group Policy Update (актуализация групповой политики). Параметры GPO обновляются при загрузке компьютера, входе пользователя в систему и автоматически обновляются в фоновом режиме каждые 90 минут + случайное смещение времени 0–30 минут (это означает, что параметры политики обязательно будут применены к клиентам через 90–120 минут после обновления файлов GPO на контроллере домена).

По умолчанию контроллеры домена обновляют настройки GPO чаще: каждые 5 минут.

Вы можете изменить интервал обновления GPO, используя параметр Set Group Policy refresh interval for computers («Установить интервал обновления групповой политики для компьютеров»). В редакторе управления групповыми политиками эта настройка находится поо пути Computer Configuration → Administrative Templates → System → Group Policy (в русскоязычной версии «Конфигурация компьютера» → «Административные шаблоны» → «Система» → «Групповая политика»).

Включите политику и установите время (в минутах) для следующих параметров:

  • Первое значение позволяет настроить частоту применения групповой политики к компьютерам (от 0 до 44640 минут), как часто клиент должен обновлять параметры GPO в фоновом режиме. Если вы установите здесь 0, то политики будут обновляться каждые 7 секунд (делать этого не стоит);
  • Второе значение — это случайная величина, добавляемая к интервалу времени обновления, во избежание одновременных запросов групповой политики всеми клиентами (от 0 до 1440 минут). Это максимальное значение случайного временного интервала, добавляемого в качестве смещения к предыдущему параметру (используется для уменьшения количество одновременных обращений клиентов к DC для загрузки файлов GPO).


Обратите внимание, что частое обновление GPO приводит к увеличению трафика на контроллеры домена и приводит к увеличению нагрузки на сеть.

Использование команды GPUpdate.exe для принудительного обновления настроек GPO

Все администраторы знают команду gpupdate.exe, которая позволяет обновлять параметры групповой политики на компьютере:

Эта команда заставляет ваш компьютер читать все объекты групповой политики с контроллера домена и повторно применять все настройки. Это означает, что когда используется ключ /force, клиент подключается к контроллеру домена, чтобы получить файлы для ВСЕХ политик, нацеленных на него. Это может привести к увеличению нагрузки на вашу сеть и контроллер домена.

Команда gpudate без каких-либо параметров применяет только новые и изменённые настройки GPO.

В русифицированной версии:


Если некоторые политики или параметры не были применены, используйте команду GPResult для диагностики проблемы и следуйте инструкциям в статье «Устранение неполадок: групповая политика (GPO) не применяется».

Вы можете обновить только настройки GPO пользователя:

или только параметры политики компьютера:

Если некоторые политики не могут быть обновлены в фоновом режиме, gpupdate может завершить сеанс текущего пользователя:

Или перезагрузить компьютер (если изменения GPO можно применить только при загрузке Windows):

Как принудительно обновить удалённый объект групповой политики из консоли управления групповой политикой (GPMC)?

В Windows Server 2012 и новее вы можете обновлять параметры групповой политики на компьютерах домена удалённо, используя GPMC.msc (консоль управления групповой политикой).

В Windows 10 вам нужно будет установить RSAT, чтобы использовать консоль GPMC:

Затем после изменения каких-либо параметров или создания и сопряжения нового объекта групповой политики достаточно щёлкнуть правой кнопкой мыши нужное организационное подразделение (OU) в консоли управления групповыми политиками и выбрать в контекстном меню пункт Group Policy Update («Обновление групповой политики»). В новом окне вы увидите количество компьютеров, на которых будет обновлён GPO. Подтвердите принудительное обновление политик, нажав Yes («Да»).


Затем GPO будет удалённо обновляться на каждом компьютере в OU один за другим, и вы получите результат со статусом обновления групповой политики на компьютерах Succeeded/Failed («Успешно / Не удалось»).

Эта функция создаёт задачу в Планировщике задач с помощью команды «GPUpdate.exe /force» для каждого вошедшего в систему пользователя на удалённом компьютере. Задача запускается в произвольный период времени (до 10 минут), чтобы снизить нагрузку на сеть.

Чтобы функция обновления удалённого объекта групповой политики GPMC работала на клиенте, должны быть выполнены следующие условия:

  • TCP-порт 135 должен быть открыт в правилах брандмауэра Защитника Windows;
  • Должны быть включены службы Windows Management Instrumentation and Task Scheduler («Инструментария управления Windows и планировщика задач»).

Фактически, эта функция работает так же, как если бы вы обновили настройки GPO вручную с помощью команды «GPUpdate /force» на каждом компьютере.


Invoke-GPUpdate: принудительное обновление удалённой групповой политики через PowerShell

Вы также можете вызвать удалённое обновление GPO на компьютерах с помощью командлета PowerShell Invoke-GPUpdate (являющегося частью RSAT). Например, чтобы удалённо обновить параметры политики пользователя на определённом компьютере, вы можете использовать следующую команду:

Если вы запустите командлет Invoke-GPUpdate без каких-либо параметров, он обновит настройки GPO на текущем компьютере (как и gpudate.exe).

Вместе с командлетом Get-ADComputer вы можете обновить объект групповой политики на всех компьютерах в определённом подразделении:

или на всех компьютерах, отвечающих определенным требованиям (например, на всех хостах Windows Server в домене):

Вы можете установить случайное смещение для обновления GPO с помощью -RandomDelayInMinutes. Благодаря этой опции вы можете снизить нагрузку на сеть, если обновляете параметр групповой политики одновременно на нескольких компьютерах. Для немедленного применения параметров групповой политики на всех компьютерах используется параметр -RandomDelayInMinutes 0.

Команда Invoke-GPUpdate возвращает следующую ошибку для недоступных компьютеров:


Если вы запустите командлет Invoke-GPUpdate удаленно или обновите объект групповой политики из консоли управления групповыми политиками, на рабочем столе пользователя на короткое время может появиться окно консоли с запущенной командой gpupdate.

gpo update

Для чего нужно уметь обновлять групповую политику?

Перед тем, как перейти к практической части я бы хотел описать ряд ситуаций, которые вы можете встретить в своей практике, где вам можете потребоваться ручное обновление GPO. Еще хочу напомнить, что по умолчанию, любая операционная система Windows, являющаяся членом домена AD сама, автоматически производит обновление групповых политик каждые 90-120 минут, это позволяет не генерировать много сетевого трафика и сделать балансировку при обращении к мастеру PDC, но бывают и другие ситуации.

Предположим, что вы внесли важные обновления настроек для ваших серверов, например для авторизации CredSSP, или закрываете какую-то дыру безопасности, логично, что в Active Directory, это делается через групповые политики. Когда у вас 5-10 серверов, то нет проблем чтобы зайти на каждый из них через удаленный рабочий стол и выполнить команду, а когда серверов сотни, тут уже нужна массовость. Еще не нужно сбрасывать со счетов ситуации, когда вы по RDP не можете зайти, через редактор политик обновить не получается, что делать, тут можно сделать все удаленно через PowerShell или командную строку, об этом то же поговорим.

Вы всегда должны уметь и иметь возможность вносить массовые изменения на ваших серверах, и применять их как можно скорее

Методы обновления GPO

Давайте составим список способов и инструментов, которые вы можете использовать:

  • Командная строка Windows - позволяет быстро выполнить обновление, работает локально
  • Оболочка PowerShell - так же, как и cmd позволяет сделать обновление, как локально, так и удаленно
  • Оснастка "Управление групповой политикой" - удаленное обновление GPO, есть возможность выбрать отдельные объекты
  • Утилита PsExec - позволяет удаленно выполнить задачу

Давайте теперь опробуем каждый из этих методов.

Как обновить GPO через командную строку

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

Как обновить GPO через командную строку

Ключ /force произведет принудительное обновление групповой политики. Хочу отметить, что некоторые настройки могут применяться, только после выхода из системы. Если политика показала, что успешно обновилась, но эффекта не произошло, то смотрите мою статью "Почему не применяются GPO", придется делать траблшутинг.

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

Как обновить GPO через cmd

Еще интересный ключик, это выполнить задержку /Wait: .По умолчанию значение 600 секунд.

Как обновить GPO через PowerShell

Оболочка PowerShell так же имеет отдельный командлет, который легко может инициировать запрос на обновление групповой политики, называется он Invoke-GPUpdate.

Invoke-GPUpdate - это командлет обновляющий параметры групповой политики, включая настройки безопасности, которые установлены на удаленных компьютерах с помощью планирования хода выполнения команды Gpupdate. Вы можете комбинировать этот командлет по сценарию, чтобы запланировать команду Gpupdate на группе компьютеров. Обновление может быть запланировано для немедленного запуска параметров политики или ожидания в течение определенного периода времени, максимум до 31 дня. Чтобы избежать нагрузки на сеть, время обновления будет смещено на случайную задержку.

Давайте запросим обновление политик GPO на моем тестовом сервере с Windows Server 2019, для этого запускаем оболочку PowerShell и вводим команду:

Как обновить GPO через PowerShell Invoke-GPUpdate

Ключ –RandomDelayInMinutes 0 установит задержку в выполнении на ноль секунд, в противном случае обновление будет выполнено рандомно, через некоторое время.

окно Политика обновления

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

Как обновить GPO через PowerShell

Если нужно выполнить принудительно без запроса подтверждения пользователя, то укажите ключ -Force.

Если нужно указать явно, что необходимо запросить политики только для пользователя или компьютера, то можно использовать ключ -Target, который имеет значения User или Computer. Кстати если удаленный компьютер не отвечает, то вы получите ошибку:

Invoke-GPUpdate : Компьютер "dc01.root.pyatilistnik.org" не отвечает

Еще одним преимуществом командлета PowerShell является то, что у вас есть больше возможностей в выборе машин, которые вы хотите обновить. Например, с помощью приведенной ниже команды вы должны выбрать все компьютеры, которые начинаются с "Note*".

Если нужно выбрать все компьютеры, то ставим звездочку "*"

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

Не забываем, что можно ограничить поиск отдельным организационным подразделением, для этого есть ключ -Searchbase и команда примет вот такой вид:

Get-ADComputer –Filter * -Searchbase "OU=Windows10,OU=Компьютеры,OU=Оргструктура,DC=root, DC=pyatilistnik,DC=org" | foreach< Invoke-GPUpdate –Computer $_.name -Force -RandomDelayInMinutes 0>

Массовое обновление GPO в домене

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

$comps = Get-Content "C:\temp\comps.txt"
foreach ($comp in $comps)
Invoke-GPUpdate –Computer $_.name -Force -RandomDelayInMinutes 0
>

Я также добавил здесь параметр -Force, чтобы обеспечить повторное применение параметров групповой политики, даже если клиент замечает, что новые версии GPO недоступны. Таким образом, когда мы говорим о принудительном обновлении групповой политики, мы на самом деле имеем в виду две разные вещи. Без параметра Force мы просто незамедлительно инициируем обновление; если мы добавим параметр Force, мы форсируем обновление, даже если обновлять нечего. Параметр Force вступает в игру, если вы считаете, что что-то пошло не так в предыдущем обновлении объекта групповой политики.

Обновление групповой политики через оснастку GPMC

Начиная с операционной системы Windows Server 2012 R2, компания Microsoft расширила функционал оснастки по управлению политиками. Разработчики внедрили механизм, массового и точечного инициирования применения политик GPO к нужным объектам и заметьте через графический интерфейс. Откройте оснастку "Управление групповой политикой", проще всего, это сделать через окно "Выполнить", введя там там команду gpmc.msc.

Запускаем gpmc.msc

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

Обновление групповой политики через gpmc

У вас появится окно "Принудительное обновление групповой политики", в котором вы увидите количество объектов, к которым будет применено действие

окно Принудительное обновление групповой политики

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

Успешное обновление групповой политики через оснастку gpmc

При желании все результаты команды можно сохранить в CSV файле

Сохранение лога обновления GPO

Вот пример содержимого такого файла

Содержимое лога обновления GPO

на компьютерах, где таким методом была запущена процедура принудительного применения GPO, вы в логах Windows можете обнаружить событие с кодом 1704:

Политика безопасности в объектах групповой политики успешно применена.

Политика безопасности в объектах групповой политики успешно применена

То же самое можно посмотреть и в Windows Admin Center, где нужно зайти в раздел события.

Событие 1704

Ошибка 8007071a "Удаленный вызов процедуры был отменен"

Иногда в консоли GPMC вы можете получать ошибку:

Ошибка 8007071a "Удаленный вызов процедуры был отменен"

Обновление GPO через PSexec

Я вам очень часто рассказываю в своих примерах из моей практики, об утилите PSexec и сборнике SysInternals от Марка Руссиновича. Суть метода в том, что с помощью специальной утилиты вы сможете выполнить удаленную команду, ранее я так удаленно включал RDP на сервере или клиентской машинке.

Далее вы распаковываете архив, если он в таком виде и открываете папку с утилитами SysInternals в командной строке, напомню сделать, это можно через команду cd или через правый клик с зажатым Shift по нужной папке, выбрав пункт "Открыть окно команд".

Запуск PSexec в cmd

Обращаю внимание, что у вас должны быть соблюдены несколько требований:

  • Как и в случае Invoke-GPUpdate, вы должны изменить настройки брандмауэра на своих клиентах. Поскольку PsExec использует протокол SMB, вам нужно открыть TCP-порт 445. Как открыть порт я уже подробно рассказывал, можете посмотреть, советую использовать для этого групповую политику.
  • Второе, это наличие прав на удаленном компьютере, чтобы запустить там Gpupdate

Теперь выполните команду:

Обновление GPO через PSexec

на удаленном компьютере в журналах системы вы увидите два события 1500 и 1501.

Событие 1500: Параметры групповой политики для этого компьютера обработаны успешно. Не обнаружено изменений со времени последней успешной обработки групповой политики.

Событие 1500: Параметры групповой политики для этого компьютера обработаны успешно. Не обнаружено изменений со времени последней успешной обработки групповой политики.

Событие 1501: Параметры групповой политики для этого пользователя обработаны успешно. Не обнаружено изменений со времени последней успешной обработки групповой политики.

Событие 1501: Параметры групповой политики для этого пользователя обработаны успешно. Не обнаружено изменений со времени последней успешной обработки групповой политики

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

удаленное выполнение gpupdate

Далее просто пишите gpupdate /force, обратите внимание я через команду hostname показал, что подключение идет с одного компьютера на другой.

Couldn’t access ComputerName:The network name cannot be found.
Make sure that the default admin$ share is enabled on ComputerName

Couldn’t access ComputerName:The network name cannot be found

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

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

Get-ADComputer –filter 'Name -like "*"' | Select-Object -ExpandProperty Name | foreach< Invoke-Expression –Command ".\psexec.exe \\$_ -i gpupdate.exe">

массовое Обновление GPO через PSexec

Или можно из конкретного OU добавив

Get-ADComputer –filter 'Name -like "*"'-Searchbase "OU=Windows10,OU=Компьютеры,OU=Оргструктура,DC=root, DC=pyatilistnik,DC=org" | Select-Object -ExpandProperty Name | foreach< Invoke-Expression –Command ".\psexec.exe \\$_ -i gpupdate.exe">

Другой вариант - сначала экспортировать все имена компьютеров из контейнера Active Directory в текстовый файл с помощью командлета Get-ADComputer:

Get-ADComputer –filter 'Name -like "win*"' -Searchbase "OU=Windows10,OU=Компьютеры,OU=Оргструктура,DC=root, DC=pyatilistnik,DC=org" | Select-Object -ExpandProperty Name | Out-File -Encoding ascii c:\tmp\ComputerList.txt

Обратите внимание, что мы должны кодировать выходной файл с помощью ASCII, чтобы мы могли прочитать его содержимое из пакетного файла следующим образом:

For /f "tokens=*" %%a in (c:\tmp\ComputerList.txt) Do psexec \\%%a -i gpupdate

PsExec против Invoke-GPUpdate

Основным недостатком метода PsExec является то, что он относительно медленный. Это может занять от 3 до 4 секунд на компьютер, а для компьютеров, которые не подключены к сети, это может занять еще больше времени. PsExec иногда даже зависал во время моих тестов.

Разрешение входящих подключений через порт 445 является угрозой безопасности. Компьютерные черви могут использовать этот порт, а хакеры могут делать много неприятных вещей с помощью PsExec. Открытие порта планировщика заданий для Invoke-GPUpdate также проблематично, но я думаю, что порт 445 более популярен среди программистов вредоносных программ.

Таким образом, в большинстве сценариев Invoke-GPUpdate является лучшим вариантом. Однако, если вы все равно открыли порт 445 по другим причинам и не хотите открывать порты Invoke-GPUpdate, вы можете предпочесть PsExec для принудительного обновления групповой политики.

Удаленное обновление GPO через Enter-PSSession

Еще в PowerShell есть командлет для удаленного подключения к компьютеру, называется он Enter-PSSession, его принцип работ, как у PsExec. Откройте оснастку PowerShell и введите:

Удаленное обновление GPO через Enter-PSSession

Далее вы подключитесь к удаленному компьютеру, где потом просто введите gpupdate /force.

Удаленное обновление GPO через Windows Admin Center

Если вы в своей практике используете утилиту удаленного администрирования Windows Admin Center, то вы легко можете подключиться к удаленному серверу и обновить политики GPO все через тот же gpupdate /force.

Ошибка: Filtering: Not Applied (Unknown Reason)

Ничего не предвещало беды в прошлый «вторник обновлений» (14 июня): бюллетень обновлений содержал лишь сухой список важных обновлений безопасности и стандартные рекомендации по их немедленной установке. Однако, после применения обновлений, системные администраторы по всему миру столкнулись со странным поведением политик безопасности. Наиболее распространённый симптом: начали «отваливаться» сетевые принтеры и папки.

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

Кто виноват?

«Виновником» такого поведения стало обновление безопасности из статьи KB3163622 (бюллетень безопасности MS16-072, номер KB для различных ОС: KB3159398, KB3163017, KB3163018, KB3163016), призванное закрыть дыру в безопасности процесса применения групповых политик. С момента появления технологии групповых политик не было уделено должное внимание обеспечению доверенности источника политик. Атакующий, применяя тактику MitM (Man in the Middle — атака посредника), мог подменить ответ от контроллеров домена и прислать на атакуемый компьютер поддельные политики безопасности, дающие, например, права локального администратора скомпрометированной учётной записи рядового пользователя.

Как оказалось, для устранения данной проблемы программисты Microsoft не нашли ничего лучше, чем изменить поведение процесса применения групповых политик, которое не менялось со времени выхода Windows 2000. Традиционное поведение предусматривало доступ к политикам безопасности уровня компьютеров (computer scope) от учётной записи компьютера, а к политикам безопасности уровня пользователя (user scope) — от учётной записи пользователя. После установки обновления KB3163622 все запросы стали направляться от учётной записи компьютера, чтобы обеспечить доверенность источника силами протокола Kerberos.

Тестирование обновления (если таковое вообще проводилось) не выявило никаких проблем, так как по умолчанию доступ ко всем групповым политикам разрешён для группы Authenticated Users, которая включает в себя все учетные записи (компьютеров и пользователей).

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

Список фильтров безопасности(security filtering)


Список фильтров безопасности (security filtering)

В результате, на Microsoft полился поток жалоб, а форумы запестрели скороспелыми рекомендациями отменить (decline) обновление KB3163622 в WSUS. Ситуация, к сожалению, стала не редкостью в последние годы, когда чуть ли не каждый месяц некоторые обновления выходят повторно в новой редакции после негативной реакции пользователей. В этот раз, однако, Microsoft дала понять, что не пойдёт на попятную и к новым правилам применения политик безопасности придётся привыкнуть.

15 июня в бюллетень MS16-072 добавили короткое указание, что, как говорится, «это не баг, это — фича», и такое изменение поведения будет сохранено.

Сотрудник Microsoft Ian Farr 16 июня опубликовал скрипт на PowerShell, который позволяет системным администраторам проверить, повлияет ли новое обновление на существующие политики.

На протяжении недели на специализированных ресурсах кипели страсти, так как кроме трех строчек в бюллетене безопасности никакой официальной информации от Microsoft не поступало. Наконец, через 9 дней после выхода обновления, в официальном блоге Ask the Directory Services Team вышла подробная статья, которая, по хорошему, должна была если не предварять выпуск обновления (пусть, по соображениям безопасности, до выхода «заплатки» нельзя раскрывать суть уязвимости), то уж по крайней мере идти первой строкой в июньском бюллетене.

Что делать?

TL;DR: Ниже приведена Инструкция по внесению изменений в GPO и AD для предотвращения ущерба от установки этого обновления.

При всём уважении к AD DS Team, мне кажется, что решение, которое они предлагают — добавить Authenticated Users или Domain Computers с доступом только для чтения во все политики, которые перестали работать, — является полумерой. При модификации или создании новых политик безопасности отныне и навсегда нужно будет помнить о необходимости добавлять одну из вышеупомянутых групп. Наглядный инструмент фильтров безопасности (security filtering), доступный прямо на первой странице редактора политик безопасности (group policy editor) вообще теряет всякий смысл, так как всё равно необходимо вручную изменять списки контроля доступа.

Более простым в эксплуатации мне представляется следующее решение: добавить группу Domain Computers с правами только на чтение (но не на применение) во все политики (если это возможно по соображениям безопасности), а также произвести минимальную модификацию схемы (schema) AD, чтобы новые политики создавались сразу с необходимыми правами.

Плюсом такого решения является отсутствие необходимости его поддержки: поведение групповых политик практически не изменится, нет необходимости менять правила создания/модификации политик. Продолжит работать и механизм фильтров безопасности (security filters), который очень наглядно позволяет представлять и редактировать параметры доступа к политикам.

Минусом является необходимость модификации схемы (schema) AD, но модификация настолько тривиальная, что она не должна вызвать никаких проблем.

Почему я предлагаю добавить Domain Computers, а не Authenticated Users? Во-первых, для того, чтобы не нарушать Принцип минимальных привилегий: даже после такого надругательства над этим принципом, которое совершает данное обновление, мы всё ещё можем не дать непривилегированному пользователю читать политики, которые применяются к привилегированным пользователям простым заходом в SYSVOL. Во-вторых, по умолчанию Authenticated Users уже имеют права на чтение и применение политики. Удаляя Authenticated Users из списка фильтров безопасности (security filtering) мы удаляем не только права на применение, но и права на чтение. В то же время, если группа Domain Computers добавлена в списки доступа только для чтения, она не отображается в списке security filtering и не будет удалена.

Соображения по применимости данных рекомендаций

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

1. Вторичное ограничение доступа к ресурсу. Например, доступ к сетевому принтеру ограничен группой Example1 в настройках безопасности самого принтера и, дополнительно, политика безопасности, которая подключает этот принтер, применяется только к членам группы Example1. В такой ситуации добавление прав на чтение (но не применение политик) для Domain Computers совершенно безопасно.

2. Ограничение распространения информации, которая содержится в самой политике безопасности. Я не рекомендовал бы хранить уязвимые (sensitive) данные (например, пароли) в политиках безопасности, но, допускаю, что до прошлой недели такой подход имел право на существование, так как доступ к файлам политики безопасности в общей папке SYSVOL автоматически ограничивается списком доступа, применённым к самой политике. После изменений, которые приносит обновление, доступ вынужденно получат учётные записи всех компьютеров. Обратиться к папке SYSVOL от имени компьютера всё ещё не самая тривиальная задача для пользователя с ограниченными правами, но, потенциально, это возможно (например, с применением отдельной уязвимости локального повышения привилегий). Прежде чем переходить к следующим пунктам инструкции, следует взвесить потенциальные риски, и, возможно, убрать уязвимую (sensitive) информацию из политики безопасности.

2a. В условиях повышенных требований к безопасности, согласно Принципу минимальных привилегий, доступ по умолчанию для Authenticated Users может быть заменён на более узкий для всех политик безопасности. В таком случае, необходим полный пересмотр всей стратегии защиты политик. Для политик уровня пользователя (user scope) попытка сузить круг доступа теперь неминуемо приведёт к нарушению постулата о разделения пользовательских и компьютерных политик безопасности. Например, попытка ограничить распространение политики, применимой только к привилегированным пользователям, группой компьютеров, на которых эти пользователи работают, приведёт к фактическому смешению уровней политик (user and computer scope), что не является хорошей практикой.

Инструкция

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

Get-GPO -All | Set-GPPermissions -TargetType Group -TargetName "Domain Computers" -PermissionLevel GpoRead

Данная команда добавит права на чтения (но не применение) политик для группы Domain Computers во все политики безопасности домена. После её выполнения можно смело устанавливать обновление KB3163622, для существующих политик безопасности оно больше не страшно.

Предупреждение. Следующим шагом является изменение схемы (schema) AD для того, чтобы вновь создаваемые политики уже имели разрешение для чтения политики группой Domain Computers в своём списке контроля доступа. Хотя изменение минимально, я хотел бы посоветовать тем администраторам, которые не знают, что такое схема (schema) AD, сперва изучить данное понятие либо ограничиться предыдущим пунктом инструкции и добавлять Domain Computers в новые политики вручную, либо запускать вышеупомянутую команду PowerShell (или её модификацию с заменой «-All» на имя политики) после создания каждой новой политики безопасности.

Дальнейшая инструкция является вольным переводом статьи Darren Mar-Elia.

Проверьте, что у вас есть достаточный уровень доступа для проведения следующих операций. Вы должны входить в состав (напрямую или косвенно) группы Schema Admins.

Подключение к схеме (schema) AD в ADSIEdit

1. Запустите ADSIEdit.msc в меню Action, откройте пункт Connect To и выберите Schema из списка:

Подключение к схеме (schema) AD в ADSIEdit

Класс Group Policy Container в ADSIEdit

2. Раскройте дерево CN=Schema, CN=Configuration. В списке справа выберите CN=Group-Policy-Container:

Класс Group Policy Container в ADSIEdit

3. Двойным щелчком по CN=Group-Policy-Container откройте список атрибутов. Найдите атрибут defaultSecurityDescriptor. Откройте значение атрибута.

4. На всякий случай скопируйте текущее значение атрибута defaultSecurityDescriptor в Notepad и сохраните в файл. Установите курсор в самый конец длинного значения атрибута, после последней закрывающей скобки. Добавьте следующее значение (проверить, что означает данная «магическая» строка можно с помощью утилиты SDDLPARSE):

Редактирование defaultSecurityDescriptor

(A;CI;LCRPLORC;;;DC)


Редактирование defaultSecurityDescriptor

5. Нажмите OK, чтобы применить изменения.

Обновление схемы (schema) AD

6. Запустите MMC, войдите в меню FileAdd/remove snap-ins и в нём выберите Active Directory Schema. Если вы не видите AD Schema в списке, вам необходимо отключить так называемую «защиту от дурака». Запустите командную строку с повышенными привилегиями и введите regsvr32 schmmgmt.dll, после чего перезапустите MMC. Кликните правой кнопкой мыши на пункт «Active Directory Schema» и выберите «Reload the Schema» как показано ниже:

Обновление схемы (schema) AD

Новая политика безопасности

7. В результате вышеперечисленных действий новые групповые политики будут создаваться сразу с настроенным доступом для чтения группе Domain Computers:

Новая политика безопасности

Заключение

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

Следует отметить, что, закрывая брешь MitM повышения уровня доступа (elevation of privilege), обновление KB3163622 открывает множественные бреши раскрытия информации (information disclosure), и с этим придётся считаться.

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

    Существует 3 способа обновить групповую политику:

Способ 1 Обновление групповой политики с помощью команды gpupdate /force

Шаг 1: Запустите окно командной строки

Windows 7


Windows 10

Щелкните правой кнопкой мыши кнопку «Пуск» Нажмите на командную строку(Admin), чтобы открыть окно CMD.



Шаг 2: Запустите команду gpupdate /force

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

Теперь, если у вас есть куча компьютеров, которые нуждаются в обновлении, было бы сложно войти в каждый из них и запустить эту команду. Для её запуска на удаленном компьютере вы можете использовать команду PsExec из набора инструментов Sysinternals. Вот пример использования PsExec для удаленного обновления групповой политики

Просто замените Computername на фактическое имя хоста компьютера

Чтобы выполнить GPUpdate.exe на группе компьютеров, указанных в текстовом файле, используйте команду PSExec.exe:

PSExec.exe @Computers.TXT GPUpdate.exe /force

Шаг 3: Перезагрузите компьютер

После завершения обновления вам будет предложено либо выйти из системы, либо перезагрузить компьютер. Нажмите N,чтобы отклонить эти запросы, а затем перезагрузите компьютер вручную. Иногда вам не будет предложено перезагрузить компьютер или выйти из системы после обновления. Тем не менее, вам все равно следует перезагрузить компьютер, если ИТ-специалист не примет иного решения.

После завершения обновления вы можете перезагрузить компьютер командой gpupdate / boot или вручную. Перезагрузить компьютер вручную немного быстрее, чем через окно командной строки.

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

В Windows Server 2012 и более поздних версиях теперь можно принудительно обновить групповую политику на удаленных компьютерах из консоли управления групповой политикой. Этот метод очень прост и позволяет запускать обновление для одного подразделения или всех подразделений.

Шаг 1. Откройте консоль управления групповыми политиками.



Шаг 2: Щелкните правой кнопкой мыши, чтобы обновить

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

Я собираюсь обновить свой родительский OU «ADPRO Computers», в этом OU есть несколько подразделений, разбитых на отделы. Это запустит обновление групповой политики на всех компьютерах.




Способ 3: использование Powershell Invoke-GPUpdate

В Windows 2012 можно принудительно выполнить немедленное обновление с помощью команды powershell invoke-GPUupdate . Эта команда может использоваться для обновления клиентов Windows 10 и Windows 7.

Вам потребуется установленный Powershell, а также консоль управления групповыми политиками (GPMC).

RandomDelayMinutes 0 гарантирует, что политика обновляется сразу, а не ..

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


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

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

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