Обновление MS16-072 ломает Group Policy. Что с этим делать?

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

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

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

При попытке разобраться в ситуации, результат GPRESULT поверг в некоторое замешательство: некоторые политики безопасности уровня пользователя (user scope) не применялись, выдавая весьма «информативное» сообщение: «Filtering: Not Applied (Unknown Reason)». Некоторые новые политики просто не появлялись в выводе GPRESULT.

Кто виноват?


«Виновником» такого поведения стало обновление безопасности из статьи 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.

1. Запустите ADSIEdit.msc в меню Action, откройте пункт Connect To и выберите Schema из списка:
Подключение к схеме (schema) AD в ADSIEdit
Подключение к схеме (schema) AD в ADSIEdit

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

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

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

(A;CI;LCRPLORC;;;DC)

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

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

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

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

Заключение


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

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

Ссылки


1. Microsoft KB3163622 (бюллетень безопасности MS16-072).

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

3. Ask the Directory Services Team. Ajay Sarkaria. Подробная статья с описанием изменений поведения политик безопасности.

4. Darren Mar-Elia. Modifying Default GPO Permissions at Creation Time.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 23
  • +5
    Спасибо за подробное описание и рецепт со схемой. Лучше поздно, чем никогда.
    • +2
      Спасибо за хорошую и информативную статью. Я бы, честно говоря, скорее всего пропустил бы эту информацию, если бы не прочитал на Хабре.
      MS подкинул проблем, откуда не ждали. Пойду смотреть, применяется ли у нас фильтрация по пользователям.
      • 0
        Я бы, наверное, порекомендовал последовать инструкции, даже если сейчас не применяется фильтрация: обновление ломает инструмент фильтрации, без изменения схемы нельзя будет им пользоваться. Когда возникнет необходимость фильтрации, нужно будет вручную редактировать список доступа.
        • 0
          Если вручную не удаляли группу Authenticated Users (прошедшие проверку), и не убирали с неё права на чтение, фильтрация должна работать. Если я не прав, поясните в чем заблуждаюсь.
          • 0
            Вот по шагам поведение после установки обновления и без применения инструкции:
            1. Создаём тестовую политику с правами по умолчанию.
            2. Заходим в Security Filtering на первой странице политики.
            2.1. Добавляем группу, к которой политика должна применяться.
            2.2. Удаляем Authenticated Users (автоматически удаляется и read и apply!).
            3. В случае user scope политики получаем ошибку применения, если установлено обновление.
            4. Руками добавляем Domain Computers/Authenticated Users в Security.
            5. Только после этого политика начинает работать.
            Вопрос — зачем теперь нужен secuirty filtering, если нам надо потом руками лезть в список контроля доступа?

            Приведённая инструкция возвращает нормальное поведение security filtering: убираем authenticated users, добавляем нужную группу — всё сразу работает.
            • 0
              Вопрос — зачем теперь нужен secuirty filtering, если нам надо потом руками лезть в список контроля доступа?

              Так ведь если не выполняем пункт
              2.2. Удаляем Authenticated Users (автоматически удаляется и read и apply!)
              , то все работает, правильно?
              • 0
                Работает, но смысла лишает. Политика применяется ко всем, а не к группе.
                • 0
                  Информация из статьи, о том, что нужно сделать, если в групповой политике используется фильтрация по группам:

                  What is the Resolution?

                  Simply adding the “Authenticated Users” group with the “Read” permissions on the Group Policy Objects (GPOs) should be sufficient. Domain Computers are part of the “Authenticated Users” group. “Authenticated Users” have these permissions on any new Group Policy Objects (GPOs) by default. Again, the guidance is to add just “Read” permissions and not “Apply Group Policy” for “Authenticated Users”


                  Перевод:
                  Каково же решение?

                  Простого добавления группы Authenticated Users с правами на чтение должно быть достаточно. Компьютеры домена являются членами группы Authenticated Users. Authenticated Users имеют такие права на любую новую политику по умолчанию. Повторюсь, решением является добавление прав на «Чтение» группе Authenticated Users и запрет на применение для этой же группы.

                  То есть при выполнении описанных выше условий фильтрация по группам должна работать.
                  • 0
                    Всё верно — GPO будет работать после добавления руками Authenticated Users или Domain Computers с правами read в список контроля доступа каждый раз после того, как вы попытаетесь воспользоваться security filtering. Изменение схемы нужно для того, чтобы избежать необходимости производить эти действия руками каждый раз.

                    Возможно, вы путаете инструмент Security Filtering (изображён на скриншоте «Список фильтров безопасности (security filtering)» в статье) и закладку Security при редактировании политики? Это разные (хоть и связанные) инструменты. Ручное редактирование в закладке Security будет работать, если вы всю оставшуюся жизнь будете помнить, что там теперь нельзя убирать read для Authenticated Users (не заменив его Domain Computers).
                    • 0
                      Но ведь руками нужно добавлять Authenticated Users только если до этого руками же и удалили данную группу. По умолчанию она там есть и с нужными правами. Или я не прав?
                      • 0
                        Да, если никогда не пользоваться инструментом Security Filtering, то политики работают. Именно поэтому, по всей видимости, ни разработчики обновления, ни тестировщики (если они ещё остались) не заметили на тестовом localhost никакой проблемы и выпустили, мягко говоря, проблемное обновление изначально даже без приписки об изменении поведения групповых политик.

                        — Доктор, когда я делаю вот так, у меня вот тут болит!
                        — А вы вот так не делайте!

                        И под «руками» я имел в виду "ручное редактирование списка контроля доступа на закладке Security в свойствах политики в режиме её редактирования". Использование инструмента Security Filtering на первой странице Group Policy Editor я бы не стал называть ручным редактированием: он даёт упрощённую и наглядную картину. И как бы мы не называли использование инструмента Security Filtering, работать этот инструмент после применения обновления перестаёт.

                        Если честно, то мне кажется, мы ходим по кругу. Создайте тестовую политику и посмотрите, чем отличается инструмент GPEdit Security Filtering от редактирования списка контроля доступа (закладка Security в свойствах политики).

                        Особенный контраст вы заметите, если между вашей рабочей станцией и контроллером домена будет хотя бы 10-20ms пинга, но это так, дополнительный «бонус», в статье не про это речь.
                        • +1
                          Наконец то понял в чем проблема будет после установки обновления. Мне почему-то казалось, что если убрать группу «Пользователи домена» из фильтра безопасности, то это не должно затронуть параметры безопасности, однако это не так. Спасибо за конструктивную дискуссию.
        • 0
          Ну, скажете тоже, «откуда не ждали».

          За последнее время:

          KB3148812 ломает WSUS
          KB3145126 ломает DNS
          .NET Framework 4.6.1 ломает дофига всего
          • 0
            .NET Framework 4.6.1 — Exchange 2013 уже починили в CU13
            • 0
              Ну так и для патча WSUS решение есть — прямо в тексте KB написано что надо делать ПОСЛЕ его установки. Вот только текст этот появился не сразу.
        • 0
          Тоже столкнулся с данной проблемой, но на выходных таки ее решил, благодаря описанию AD DS Team.
          Но хочется спросить: а вам не кажется, что подобное решение, описанное выше — является своего рода «кастомным-костылем», ведь в случае, если администратор поднимет новый домен — этот поинт ему придется пройти, как обязательный. Т.е. грубо говоря придется учитывать данную «модификацию» схемы, как необходимую.
          Я так думаю, что проще следовать инструкции бюллетеня и не заморачиваться на дополнительное изменение. «Завтра» Microsoft выпустит очередной апдейт и «вашу схему» придется вновь модифицировать\подстраивать, чтобы она работала. А простодушный админ в поисках решения — будет ждать как манны небесной от вас статьи «как это сделать»… не хорошо…
          • 0
            Я это всё подробно рассмотрел в статье, пожалуйста, прочтите внимательно.

            Ещё раз в двух словах: «решение» AD DS Team предполагает фактически отказ от использования Security Filtering и необходимость помнить это «решение» как «Отче наш» при каждом создании/изменении политик.

            Предложенное изменение схемы AD делает только одну вещь: автоматизирует то же действие, которое предписывается делать каждый раз руками, следуя «решению» AD DS Team.

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

            Поведение политик не менялось 16 лет, и, если Microsoft вдруг захочется изменить его ещё раз, то всем, вне зависимости от того, следовали они этой статье или нет, придётся снова что-то менять.

            Отменить предложенное изменение схемы можно в любой момент, убрав SDDL-вставку так же, как она была добавлена. Даже если это сделать спустя много лет, результат будет 100% тот же, как если бы все эти годы администратор вручную следовал решению AD DS Team, добавляя Domain Computers в новые политики. Никаких других изменений не предлагается.
          • 0
            Очень странно. WSUS по поиску во «Все обновления» не находит KB3163622, а по поиску MS16-072 выдает, что это kb3159398. Домен контроллеры на Win2012, поднята роль WSUS.
            • 0
              У меня тоже AD и WSUS на Win2012R2, такой установленной KB не нашел у себя, политики работают, единственно что я обновления не сразу ставлю, а по прошествии недели-двух и сейчас в обновлениях этой кв тоже нету
              • 0
                Спасибо за замечание!
                В зависимости от ОС, номер непосредственно устанавливаемого обновления в WSUS будет различаться, я добавил все номера в статью.
              • 0
                Есть ещё один интересный вопрос. А мастер «Моделирование групповой политики» как считает, по-старому?
                • 0
                  Да, показывается все по старому…
                • 0
                  Огромное спасибо за статью. Совершенно случайно на нее наткнулся поиском. Больше нигде подобного описания не нашел. Две недели не мог понять причину странного поведения одного из компьютеров (обновления не часто ставим). «Моделирование групповой политики» показывает «логичное» поведение, которое должно быть и куда копать было абсолютно не понятно.

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