Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Спасибо за подробное описание и рецепт со схемой. Лучше поздно, чем никогда.
Я бы, наверное, порекомендовал последовать инструкции, даже если сейчас не применяется фильтрация: обновление ломает инструмент фильтрации, без изменения схемы нельзя будет им пользоваться. Когда возникнет необходимость фильтрации, нужно будет вручную редактировать список доступа.
Если вручную не удаляли группу Authenticated Users (прошедшие проверку), и не убирали с неё права на чтение, фильтрация должна работать. Если я не прав, поясните в чем заблуждаюсь.
Вот по шагам поведение после установки обновления и без применения инструкции:
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, добавляем нужную группу — всё сразу работает.
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, добавляем нужную группу — всё сразу работает.
Вопрос — зачем теперь нужен secuirty filtering, если нам надо потом руками лезть в список контроля доступа?
Так ведь если не выполняем пункт
2.2. Удаляем Authenticated Users (автоматически удаляется и read и apply!), то все работает, правильно?
Работает, но смысла лишает. Политика применяется ко всем, а не к группе.
Информация из статьи, о том, что нужно сделать, если в групповой политике используется фильтрация по группам:
Перевод:
Каково же решение?
Простого добавления группы Authenticated Users с правами на чтение должно быть достаточно. Компьютеры домена являются членами группы Authenticated Users. Authenticated Users имеют такие права на любую новую политику по умолчанию. Повторюсь, решением является добавление прав на «Чтение» группе Authenticated Users и запрет на применение для этой же группы.
То есть при выполнении описанных выше условий фильтрация по группам должна работать.
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 и запрет на применение для этой же группы.
То есть при выполнении описанных выше условий фильтрация по группам должна работать.
Всё верно — GPO будет работать после добавления руками Authenticated Users или Domain Computers с правами read в список контроля доступа каждый раз после того, как вы попытаетесь воспользоваться security filtering. Изменение схемы нужно для того, чтобы избежать необходимости производить эти действия руками каждый раз.
Возможно, вы путаете инструмент Security Filtering (изображён на скриншоте «Список фильтров безопасности (security filtering)» в статье) и закладку Security при редактировании политики? Это разные (хоть и связанные) инструменты. Ручное редактирование в закладке Security будет работать, если вы всю оставшуюся жизнь будете помнить, что там теперь нельзя убирать read для Authenticated Users (не заменив его Domain Computers).
Возможно, вы путаете инструмент Security Filtering (изображён на скриншоте «Список фильтров безопасности (security filtering)» в статье) и закладку Security при редактировании политики? Это разные (хоть и связанные) инструменты. Ручное редактирование в закладке Security будет работать, если вы всю оставшуюся жизнь будете помнить, что там теперь нельзя убирать read для Authenticated Users (не заменив его Domain Computers).
Но ведь руками нужно добавлять Authenticated Users только если до этого руками же и удалили данную группу. По умолчанию она там есть и с нужными правами. Или я не прав?
Да, если никогда не пользоваться инструментом Security Filtering, то политики работают. Именно поэтому, по всей видимости, ни разработчики обновления, ни тестировщики (если они ещё остались) не заметили на тестовом localhost никакой проблемы и выпустили, мягко говоря, проблемное обновление изначально даже без приписки об изменении поведения групповых политик.
— Доктор, когда я делаю вот так, у меня вот тут болит!
— А вы вот так не делайте!
И под «руками» я имел в виду "ручное редактирование списка контроля доступа на закладке Security в свойствах политики в режиме её редактирования". Использование инструмента Security Filtering на первой странице Group Policy Editor я бы не стал называть ручным редактированием: он даёт упрощённую и наглядную картину. И как бы мы не называли использование инструмента Security Filtering, работать этот инструмент после применения обновления перестаёт.
Если честно, то мне кажется, мы ходим по кругу. Создайте тестовую политику и посмотрите, чем отличается инструмент GPEdit Security Filtering от редактирования списка контроля доступа (закладка Security в свойствах политики).
Особенный контраст вы заметите, если между вашей рабочей станцией и контроллером домена будет хотя бы 10-20ms пинга, но это так, дополнительный «бонус», в статье не про это речь.
— Доктор, когда я делаю вот так, у меня вот тут болит!
— А вы вот так не делайте!
И под «руками» я имел в виду "ручное редактирование списка контроля доступа на закладке Security в свойствах политики в режиме её редактирования". Использование инструмента Security Filtering на первой странице Group Policy Editor я бы не стал называть ручным редактированием: он даёт упрощённую и наглядную картину. И как бы мы не называли использование инструмента Security Filtering, работать этот инструмент после применения обновления перестаёт.
Если честно, то мне кажется, мы ходим по кругу. Создайте тестовую политику и посмотрите, чем отличается инструмент GPEdit Security Filtering от редактирования списка контроля доступа (закладка Security в свойствах политики).
Особенный контраст вы заметите, если между вашей рабочей станцией и контроллером домена будет хотя бы 10-20ms пинга, но это так, дополнительный «бонус», в статье не про это речь.
Ну, скажете тоже, «откуда не ждали».
За последнее время:
KB3148812 ломает WSUS
KB3145126 ломает DNS
.NET Framework 4.6.1 ломает дофига всего
За последнее время:
KB3148812 ломает WSUS
KB3145126 ломает DNS
.NET Framework 4.6.1 ломает дофига всего
Тоже столкнулся с данной проблемой, но на выходных таки ее решил, благодаря описанию AD DS Team.
Но хочется спросить: а вам не кажется, что подобное решение, описанное выше — является своего рода «кастомным-костылем», ведь в случае, если администратор поднимет новый домен — этот поинт ему придется пройти, как обязательный. Т.е. грубо говоря придется учитывать данную «модификацию» схемы, как необходимую.
Я так думаю, что проще следовать инструкции бюллетеня и не заморачиваться на дополнительное изменение. «Завтра» Microsoft выпустит очередной апдейт и «вашу схему» придется вновь модифицировать\подстраивать, чтобы она работала. А простодушный админ в поисках решения — будет ждать как манны небесной от вас статьи «как это сделать»… не хорошо…
Но хочется спросить: а вам не кажется, что подобное решение, описанное выше — является своего рода «кастомным-костылем», ведь в случае, если администратор поднимет новый домен — этот поинт ему придется пройти, как обязательный. Т.е. грубо говоря придется учитывать данную «модификацию» схемы, как необходимую.
Я так думаю, что проще следовать инструкции бюллетеня и не заморачиваться на дополнительное изменение. «Завтра» Microsoft выпустит очередной апдейт и «вашу схему» придется вновь модифицировать\подстраивать, чтобы она работала. А простодушный админ в поисках решения — будет ждать как манны небесной от вас статьи «как это сделать»… не хорошо…
Я это всё подробно рассмотрел в статье, пожалуйста, прочтите внимательно.
Ещё раз в двух словах: «решение» AD DS Team предполагает фактически отказ от использования Security Filtering и необходимость помнить это «решение» как «Отче наш» при каждом создании/изменении политик.
Предложенное изменение схемы AD делает только одну вещь: автоматизирует то же действие, которое предписывается делать каждый раз руками, следуя «решению» AD DS Team.
Более того, я целый абзац «Предупреждение» посвятил альтернативе для тех, кто не готов изменять схему.
Поведение политик не менялось 16 лет, и, если Microsoft вдруг захочется изменить его ещё раз, то всем, вне зависимости от того, следовали они этой статье или нет, придётся снова что-то менять.
Отменить предложенное изменение схемы можно в любой момент, убрав SDDL-вставку так же, как она была добавлена. Даже если это сделать спустя много лет, результат будет 100% тот же, как если бы все эти годы администратор вручную следовал решению AD DS Team, добавляя Domain Computers в новые политики. Никаких других изменений не предлагается.
Ещё раз в двух словах: «решение» AD DS Team предполагает фактически отказ от использования Security Filtering и необходимость помнить это «решение» как «Отче наш» при каждом создании/изменении политик.
Предложенное изменение схемы AD делает только одну вещь: автоматизирует то же действие, которое предписывается делать каждый раз руками, следуя «решению» AD DS Team.
Более того, я целый абзац «Предупреждение» посвятил альтернативе для тех, кто не готов изменять схему.
Поведение политик не менялось 16 лет, и, если Microsoft вдруг захочется изменить его ещё раз, то всем, вне зависимости от того, следовали они этой статье или нет, придётся снова что-то менять.
Отменить предложенное изменение схемы можно в любой момент, убрав SDDL-вставку так же, как она была добавлена. Даже если это сделать спустя много лет, результат будет 100% тот же, как если бы все эти годы администратор вручную следовал решению AD DS Team, добавляя Domain Computers в новые политики. Никаких других изменений не предлагается.
Очень странно. WSUS по поиску во «Все обновления» не находит KB3163622, а по поиску MS16-072 выдает, что это kb3159398. Домен контроллеры на Win2012, поднята роль WSUS.
У меня тоже AD и WSUS на Win2012R2, такой установленной KB не нашел у себя, политики работают, единственно что я обновления не сразу ставлю, а по прошествии недели-двух и сейчас в обновлениях этой кв тоже нету
Спасибо за замечание!
В зависимости от ОС, номер непосредственно устанавливаемого обновления в WSUS будет различаться, я добавил все номера в статью.
В зависимости от ОС, номер непосредственно устанавливаемого обновления в WSUS будет различаться, я добавил все номера в статью.
Есть ещё один интересный вопрос. А мастер «Моделирование групповой политики» как считает, по-старому?
Огромное спасибо за статью. Совершенно случайно на нее наткнулся поиском. Больше нигде подобного описания не нашел. Две недели не мог понять причину странного поведения одного из компьютеров (обновления не часто ставим). «Моделирование групповой политики» показывает «логичное» поведение, которое должно быть и куда копать было абсолютно не понятно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обновление MS16-072 ломает Group Policy. Что с этим делать?