- Group Policy Settings Used in Windows Authentication
- Configure security policy settings
- To configure a setting using the Local Security Policy console
- To configure a security policy setting using the Local Group Policy Editor console
- To configure a setting for a domain controller
- Group policy windows security
- Для чего нужен механизм фильтрации GPO
- Виды фильтрации групповых политик
- Фильтр безопасности GPO
- Фильтрация GPO через ACL (Запрет GPO)
- Фильтрация GPO по WMI
- Фильтрация через состояние GPO
Group Policy Settings Used in Windows Authentication
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016
This reference topic for the IT professional describes the use and impact of Group Policy settings in the authentication process.
You can manage authentication in Windows operating systems by adding user, computer, and service accounts to groups, and then by applying authentication policies to those groups. These policies are defined as local security policies and as administrative templates, also known as Group Policy settings. Both sets can be configured and distributed throughout your organization by using Group Policy.
Features introduced in Windows Server 2012 R2 , let you configure authentication policies for targeted services or applications, commonly called authentication silos, by using protected accounts. For information about how to do this in Active Directory, see How to Configure Protected Accounts.
For example, you can apply the following policies to groups, based on their function in the organization:
Log on locally or to a domain
Log on over a network
The following table lists policy groups relevant to authentication and provides links to documentation that can help you configure those policies.
| Policy group | Location | Description |
|---|---|---|
| Password Policy | Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Account Policies | Password policies affect the characteristics and behavior of passwords. Password policies are used for domain accounts or local user accounts. They determine settings for passwords, such as enforcement and lifetime. For information about specific settings, see Password Policy. |
| Account Lockout Policy | Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Account Policies | Account lockout policy options disable accounts after a set number of failed logon attempts. Using these options can help you detect and block attempts to break passwords. For information about account lockout policy options, see Account Lockout Policy. |
| Kerberos Policy | Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Account Policies | Kerberos-related settings include ticket lifetime and enforcement rules. Kerberos policy does not apply to local account databases because the Kerberos authentication protocol is not used to authenticate local accounts. Therefore, the Kerberos policy settings can be configured only by means of the default domain Group Policy Object (GPO), where it affects domain logons. For information about Kerberos Policy options for the domain controller, see Kerberos Policy. |
| Audit Policy | Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy | Auditing policy lets you control and understand access to objects, such as files and folders, and to manage user and group accounts and user logons and logoffs. Auditing policies can specify the categories of events that you want to audit, set the size and behavior of the security log, and determine of which objects you want to monitor access and what type of access you want to monitor. |
| User Rights Assignment | Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment | User rights are typically assigned on the basis of the security groups to which a user belongs, such as Administrators, Power Users, or Users. The policy settings in this category are typically used to grant or deny permission to access a computer based on the method of access and security group memberships. |
| Security Options | Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options | Policies relevant to authentication include: — Devices Configure security policy settingsApplies to Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller. You must have Administrators rights on the local device, or you must have the appropriate permissions to update a Group Policy Object (GPO) on the domain controller to perform these procedures. When a local setting is inaccessible, it indicates that a GPO currently controls that setting. To configure a setting using the Local Security Policy consoleTo open Local Security Policy, on the Start screen, type secpol.msc, and then press ENTER. Under Security Settings of the console tree, do one of the following:
When you find the policy setting in the details pane, double-click the security policy that you want to modify. Modify the security policy setting, and then click OK.
To configure a security policy setting using the Local Group Policy Editor consoleYou must have the appropriate permissions to install and use the Microsoft Management Console (MMC), and to update a Group Policy Object (GPO) on the domain controller to perform these procedures. Open the Local Group Policy Editor (gpedit.msc). In the console tree, click Computer Configuration, click Windows Settings, and then click Security Settings. Do one of the following:
In the details pane, double-click the security policy setting that you want to modify. В If this security policy has not yet been defined, select the Define these policy settings check box. Modify the security policy setting, and then click OK. If you want to configure security settings for many devices on your network, you can use the Group Policy Management Console. To configure a setting for a domain controllerThe following procedure describes how to configure a security policy setting for only a domain controller (from the domain controller). To open the domain controller security policy, in the console tree, locate GroupPolicyObject [ComputerName] Policy, click Computer Configuration, click Windows Settings, and then click Security Settings. Do one of the following:
In the details pane, double-click the security policy that you want to modify. В If this security policy has not yet been defined, select the Define these policy settings check box. Modify the security policy setting, and then click OK.
Group policy windows security
Для чего нужен механизм фильтрации GPOКакую бы вы сложную иерархию Active Directory не создавали у вас рано или поздно появится ситуация, что вам нужно для двух и более объектов находящихся в одном OU иметь разные настройки, а для кого-то вообще запретить применение определенной групповой политики, но перемещать объект нельзя, так как в текущей иерархии он получает все настройки по корпоративному стандарту, и усложнять структуру не представляется возможным. Лично я стараюсь не создавать лишних организационных подразделений, так как, чем проще система, тем проще ею управлять. У вас может быть вообще одна OU и все навалено в ней, но это вам не мешает грамотно применять политики к конкретным объектам, благодаря фильтрации на разных этапах GPO. Виды фильтрации групповых политик
Фильтр безопасности GPOДанный метод метод ограничения применений групповой политикой самый очевидный и используемый. Тут логика простая, что если вы хотите применить групповую политику, только к определенным объектам:
то вы можете их добавить в данный фильтр, после чего нужно удалить группу «Прошедшие проверку (authentication user)«, так как в нее входят все пользователи и компьютеры домена. Давайте это попробуем. Открываем оснастку «Управление групповой политикой». В прошлый раз я создавал политику «Настройка MaxTokenSize» в задачи которой входило изменение размера токена kerberos. Предположим, что я хочу применить ее только в локальной доменной группе MaxTokenSize. Для этого я нажимаю кнопку «Добавить» в области «Фильтры безопасности«, находим ее и нажимаем «Ok».
Теперь нам необходимо удалить группу по умолчанию «Прошедшие проверку«, напоминаю, что в нее входят все компьютеры и пользователи домена.
В итоге мы видим в фильтрах безопасности одну нашу группу. Пробуем зайти на компьютер, где она должна отработать.
В начале 2016 года я столкнулся с тем, что моя политика не отработала, хотя все фильтры безопасности были настроены правильно. Открыв вывод команды gpresult/ r, я обнаружил статус (Unknown reason).
Начав разбираться, все пришло к тому, что новые обновления Microsoft (KB3159398, KB3163017, KB3163018) закрывал одну нехорошую вещь, которая длилась с 2000 года. Проблема заключалась в том, что злоумышленник мог применять атаку «Человек посередине (Man in the Middle)», тем самым делать подмену ответа от контроллера домена на целевом компьютере, это выливалось в то, что он подделывал политику безопасности, которая давала ему права локального администратора для скомпрометированной учетной записи. Microsoft долго билась с этой проблемой и пришла к решению поменять порядок считывания политики, теперь это могут делать только компьютеры домена. Раньше политики пользователя считывал пользователь, политики компьютера, компьютер. Установив KB3163622 теперь для считывания GPO используется только компьютер и если он не входит в фильтр безопасности политики, то она не применится (Подробнее можете посмотреть вот тут https://support.microsoft.com/en-us/help/3163622/ms16-072-security-update-for-group-policy-june-14-2016). Исходя из данной ситуации, чтобы политики успешно применялись Microsoft предложило добавлять одну из групп безопасности в ACL политики «Прошедшие проверку» или «Все компьютеры». Переходим к ACL. Фильтрация GPO через ACL (Запрет GPO)И так фильтрацию в фильтре мы сделали, чтобы политика применилась нам необходимо выбрать политику и перейти на вкладку «Делегирование». Тут нам необходимо добавить одну из двух групп «Прошедшие проверку (Authenticated Users)» или «Все компьютеры (Domain Computers)«. Я добавляю первую. Нажимаем кнопку «Добавить» и находим нашу группу.
Уровень прав оставляем «Чтение», этого будет достаточно.
Пробуем проверить применение нашей политики. В качестве испытуемого у меня идет виртуальная машина с Windows 10. После загрузки, я открываю командную строку и смотрю применение политики, для этого пишем команду: В итоге я вижу, что среди примененных объектов групповой политики, моя «Настройка MaxTokenSize» в списке присутствует.
Если бы пользователь не был членом группы, которая фигурирует с фильтре безопасности, то мы видели бы вот такую картину, что следующие политики GPO не были применены, так как они отфильтрованы по причине отказано (Безопасность). Как видим нет прав на чтение.
Еще вкладку «Делегирования» используют и для запрещения, простой пример вы сделали политику которая для всех пользователей домена применяет корпоративные обои на рабочий стол. Допустим, что вам для администраторов домена или для круга избранных нужно сделать так, чтобы к ним не применялась политика. Вы создаете группу и уже ей запрещаете чтение данной политики, хоть пользователи и будут по прежнему входить в группу «Прошедшие проверку», но прочитать они ее не смогут так как явный запрет для другой группы куда они входят, гораздо сильнее и приоритетнее чем права чтения.
Добавляем группу для которой хотим запретить применение политики, у меня это Forbidden MaxTokenSize.
Далее даем права «Чтение».
Далее нажимаем кнопку «Дополнительно«, у вас откроется окно параметром безопасности. Тут вы выбираете нужную вам группу, для которой вы хотите запретить применение групповой политики и ставите галку «Запретить«. В таком случае данная группа будет получать при попытке считать GPO «Отказано (безопасность)». Фильтрация GPO по WMIЕще одним действенным методом фильтровать получателей групповой политики, это использование WMI фильтров. Мы с вами их уже применяли, когда нужно было применить политику только к ноутбукам. Простой пример вы создали политику и хотели бы ее применить скажем только на компьютеры у кого установлена операционная система Windows 7. Для нашей задачи нам необходимо создать WMI фильтр, для этого перейдем в «Фильтры WMI«, где выбираем соответствующий пункт.
Задаем имя WMI фильтра, после чего нажимаем кнопку «Добавить». Откроется окно для составления запроса. Конструкция для Windows 7 будет такая: Номера для Win32_OperatingSystem
Тип продукта отвечает за назначение компьютера и может иметь 3 значения:
Вот вам пример вывода в PowerShell команды показывающей версию операционной системы:
Сохраняем наш WMI запрос.
Если хотите перед внедрение проверить будет ли применена групповая политика к нужному объекту, то можете провести тестирование в WMI Filter Validation Utility. Если все настроено корректно, но политика не применяется, почитайте по ссылке возможные варианты. Далее берем вашу политику и применяем к ней WMI.
Теперь если компьютер не соответствует критериям WMI фильтра, то вы увидите в gpresult /r /scope:computer вот такую запись (Отказано фильтр WMI)
Фильтрация через состояние GPOЕще на вкладке «Сведения» есть такая настройка, как состояние GPO. Она необходима для ускорения обработки политики, путем отключения лишних веток. Например у вас политика исключительно на пользователя и вам смысла нет, чтобы компьютер при загрузке пытался прочитать настройки для компьютера, тратя на это время. В таких случаях отключают данный функционал. Тут есть варианты:
|
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами научились отключать защитник Windows 8.1, у каждого была своя причина произвести данное действие. Сегодня я хочу вас научить очень полезной вещи, без которой системный администратор управляющий групповой политикой не сможет активно и гибко ее применять. И речь пойдет про применение фильтров на разных этапах применения групповой политики к компьютерам и пользователям.
