Множественные политики паролей в домене (Fine-Grained Password and Lockout Policies)

В Windows Server 2008 / R2 появилась возможность задания различных парольных политик (длина пароля, комплексность, частота его замены и т.п.) внутри одного домена. Например, для администраторских учетных записей можно установить более строгие требования, чем для учетных записей обычных пользователей.

Теория

---

В Windows Server настройки параметров паролей и блокировки учетных записей являются свойствами объекта "домен". Изменить эти настройки можно либо через политику, привязанную к домену, либо непосредственно через консоль Active Directory Users and Computers (свойства домена, вкладка Attribute Editor). Действуют эти политики абсолютно на все учетные записи, созданные в домене.

Поскольку ни у каких других объектов Active Directory аналогичных свойств нет, задать собственные специфические политики пароля и блокировки для них нельзя. Разные политики паролей/блокировки в рамках одного предприятия, соответственно, требуют проектирования многодоменной структуры Active Directory. В Windows Server 2000 / 2003 именно так и происходит: разные парольные политики - множественные домены.

Для устранения необходимости создания нескольких доменов в Windows Server 2008 / R2 появился обходной маневр, названный Fine-Grained Password and Lockout Policies. В русском варианте Windows и TechNet это длинное название переводится как Подробные политики паролей и блокировки учетных записей.

Коротко идея подробных политик паролей состоит в следующем. В Active Directory создаются один или несколько объектов Password Settings Objects (PSO), содержащих в себе значения политики паролей и блокировки учетных записей. Для применения выбранной политики объект PSO назначается глобальным группам или отдельным учетным записям. После этого домен Active Directory начинает соблюдать не только политику паролей по умолчанию (хранящуюся в свойствах объекта "домен"), но и политики паролей, хранящиеся в связанных с учетной записью объектах PSO.

Важно! Парольная политика из PSO применяется целиком, т.е. невозможно длину пароля описать в доменной политике, а настройки блокировки учетной записи описать в политике PSO. Парольная политика применяется либо из домена, либо из PSO.

Подробное описание настроек PSO, разрешение конфликтов и т.п. описано ниже.

Практика

---

Требования к домену

Для создания объектов PSO домен должен иметь функциональный уровень Windows Server 2008 или выше.

Создание PSO

Все созданные объекты PSO помещаются в контейнер Password Settings Container, расположенный в контейнере System текущего домена.

В Windows Server 2008 / R2 нет специализированных утилит управления объектами PSO. Процесс создания PSO производится вручную через штатные графические утилиты или через PowerShell. Ниже рассмотрим процесс создания PSO через ADSI Editor.

Для создания нового PSO нужно в утилите ADSI Editor (Start –> Run –> adsiedit.msc)открыть контейнер System -> Password Settings Container и через контекстное меню запустить мастер создания нового объекта.

Единственно возможный для создания тип объекта как раз и будет PSO: объект класса msDS-PasswordSettings.

Далее заполняете окна мастера. Напоминаю, что объект PSO включает в себя сразу весь набор требований к паролю и к блокировке учетной записи.

Первый вопрос мастера - имя нового PSO. Можно указать любое, но лучше что-то описательное, например Restricted Policies for Admins.

Вторым вопросом мастер запрашивает значение параметра msDS-PasswordSettingsPrecedence, т.е. приоритет нового PSO. Этот параметр будет важен для разрешения конфликтов при создании многих PSO. В скобках приведены примеры значений, которые нужно вводить. Обратите внимание на правильность ввода атрибутов типа Duration (в формате DD:HH:MM:SS, т.е. дни, часы, минуты и секунды).

Последующие вопросы мастера - собственно политика паролей...

• msDS-PasswordReversibleEncryptionEnabled (false);
• msDS-PasswordHistoryLength (10);
• msDS-PasswordComplexityEnabled (true);
• msDS-MinimumPasswordLength (7);
• msDS-MinimumPasswordAge ( (none), т.е. слово none в скобках );
• msDS-MaximumPasswordAge (21:00:00:00, т.е. 21 день).

... и политика блокировки учетных записей:

• msDS-LockoutThreshold (10);
• msDS-LockoutObservationWindow (0:30:00:00, т.е. 30 минут);
• msDS-LockoutDuration (0:01:00:00, т.е. 1 час).

Также допустимыми параметрами для атрибутов, содержащих время, являются значения (never) и (none).

Важно!
Значение атрибута msDS-MaximumPasswordAge должно быть БОЛЬШЕ или РАВНО значению атрибута msDS-MinimumPasswordAge.
Значение атибута msDS-LockoutDuration должно быть БОЛЬШЕ или РАВНО значению атрибута msDS-LockoutObservationWindow.

Если будут введены недопустимые значения, вы получите ошибку
Operation failed. Error code: 0x20e7
The modification was not permitted for security reasons.

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

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

Назначение политики PSO группе или пользователю

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

Назначение PSO производится через консоль Active Directory Users and Computers. В свойствах объекта PSO на вкладке Attribute Editor (вкладка будет доступна, если в консоли включен режим View -> Advanced Features) нужно найти атрибут msDS-PSOAppliesTo и добавить в него пользователя или глобальные группы, на которые будет распространяться политика PSO.

Важно!
Пользователь или группа, к которым будет применяться PSO, указываются в атрибуте msDS-PSOAppliesTo в формате DN, distinguished name (например, CN=Domain Admins, CN=Users, DC=gorbunov, DC=pro). Если группа или пользователь будут переименованы, PSO потеряет привязку к ним и перестанет к ним применяться!!

Разрешение конфликтов нескольких PSO

Какие парольные политики будут действовать на пользователя, если в домене описана своя политика, для пользователя создан собственный PSO, а к группе, в которую входит пользователь, привязан еще один PSO?

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

Далее рассмотрим возможные конфликты.

Правило №1. При наличии PSO политика из PSO имеет больший приоритет, чем доменная политика.

Правило №2. При наличии PSO, назначенного непосредственно пользователю, полностью игнорируются политики PSO, назначенные глобальным группам, в которые пользователь может входить.

Правило №3. При наличии нескольких PSO, назначенных одной и той же группе или пользователю, действует политика из PSO с более высоким приоритетом (т.е. PSO, у которого значение атрибута msDS-PasswordSettingsPrecedence меньше). Важно: не забывайте правило №2.

Правило №4. При наличии нескольких PSO с одинаковым приоритетом и назначенных одной и той же группе или пользователю применяется политика из PSO с более низким значением GUID.

ВАЖНО! В итоге к пользователю всегда применяется политика только одного PSO.

Узнать, какой же в итоге PSO реально применяется можно через консоль Active Directory Users and Computers (не забудьте включить режим View -> Advanced Features).

В свойствах пользователя нужно открыть вкладку Attribute Editor и найти атрибут msDS-ResultantPSO. В нем указано имя PSO, который в итоге и применяется к данному пользователю.

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

Выводы

---

Механизм Fine-Grained Password and Lockout Policies устраняет одну из фундаментальных проблем Windows Server 2000 / 2003, требовавших проектирования многодоменной структуры Active Directory. Новая технология в Windows Server 2008 / R2 приближает нас к идеальной структуре Active Directory, состоящей всего из одного домена.

Отсутствие специализированных утилит создания и управления объектами PSO в текущих версиях Windows Server требует повышенного внимания к проектированию и документированию парольных политик.

Привязка PSO к группе или пользователю делает его очень уязвимым к переименованию или перемещению таких объектов.

 

Дополнительная информация:
http://technet.microsoft.com/en-us/library/cc770842.aspx

---

Похожие статьи:

• Плохо документированные особенности настройки парольных политик домена через Group Policy
• Квотирование в Active Directory (Active Directory Quotas)