Что такое гранулированные политики паролей или PSO (password setting object)

Одна из актуальных тем во многих организациях – это обеспечение своих пользователей безопасными паролями, с чем у большинства пользователей огромные проблемы. Ведь никому не хочется генерировать сложные пароли, несмотря на то, что в компаниях может быть информация, к которой будут пытаться получить доступ злоумышленники, а такого пароля как 111, 123, qwerty и т.п. казалось бы, более чем достаточно. А если пользовательские учетные записи взломают и будут украдены какие-то данные, скорее всего, виноватым окажется ИТ-подразделение, так как не было внедрено должных средств по обеспечению безопасности.

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

Чем так плохи политики паролей?

Многие начинающие системные администраторы, ну, а если говорить совсем честно, то не только начинающие, при работе с политиками паролей допускают одну общую ошибку. Несмотря на то, что в оснастке «Редактор управления групповыми политиками» можно обнаружить такие узлы как «Политика паролей» и «Политика блокировки учетных записей», в связанном объекте групповой политики для каждого подразделения, на самом деле, эти параметры политики для таких объектов GPO не будут применяться. У вас может возникнуть следующий вопрос: почему так и зачем вообще отображаются данные узлы для таких объектов групповой политики?

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

Поэтому, не пытайтесь настраивать данные параметры политики для разных подразделений. В этом нет никакого смысла. Параметры политики паролей и блокировки учетных записей вы можете настраивать лишь в одном объекте групповой политики для каждого домена. Так как по умолчанию уже заданы некоторые настройки в объекте групповой политики Default Domain Policy, лучше всего, вносите изменения в данные параметры именно для этого объекта групповой политики.

Теперь по поводу второй части вопроса, которая могла бы звучать вроде «зачем вообще отображаются данные узлы для таких объектов групповой политики?». Тут тоже нет ничего сверхъестественного. Так как вы можете отключить связь для дефолтного объекта групповой политики, содержащего параметры политики паролей и блокировки учетных записей, можно выполнять такие настройки в любом объекте GPO, а затем связать его с доменом. Поэтому, даже исключив данную возможность для всех объектов групповой политики, также было бы много проблем.

Если учесть это ограничение, то можно прийти к выводу, что в большинстве случаев, это очень плохо, так как всегда находятся какие-либо подразделения, для которых необходимо установить более жесткие ограничения. Например, скажем, юристам компании может понадобиться, чтобы их пароли были не менее 10 знаков и изменять такие пароли необходимо пользователям каждый 20 дней. Так есть ли какое-то средство, позволяющее задавать исключения, для уже существующих политик пролей?

Гранулированные политики паролей

Для этой цели, еще в операционной системе Windows Server 2008 появилась такая замечательная функциональная возможность, которая называется гранулированная политика паролей. Данный компонент операционной системы позволяет вам вывести определение ограничений для паролей в своей организации на, существенно, новый и более серьезный уровень. Другими словами, при помощи гранулированных политик паролей вам предоставляется возможность создавать различные коллекции параметров паролей и блокировки учетных записей для выбранных вами пользователей или групп пользователей. Соответственно, если вы не хотите, чтобы для всех ваших пользователей применялись идентичные параметры паролей, данная функциональная возможность была разработана именно для вас!

Рассмотрим, какие факторы влияют на гранулированные политики паролей.

Прежде всего, гранулированные политики паролей применяются для определенных объектов учетных записей пользователей или групп безопасности. Это обязательно следует учесть, так как если вы захотите применить такие политики паролей на подразделение, которое содержит объекты пользователей, состоящих в разных группах безопасности, создайте для таких пользователей теневые группы. Например, вам будет удобнее, если теневые группы будут названы так же, как и сами подразделения. В таком случае, вам будет существенно проще локализовать их. Естественно, это делать не обязательно, а создание теневых групп – это просто моя небольшая рекомендация. В двух словах напомню, что же такое теневая группа.

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

Стоит обратить внимание на то, что если у вас уже настроены параметры политики паролей, гранулированные политики паролей будут применяться вместе с указанными для домена параметрами политики, однако, для выбранных вами групп или пользователей будут применяться именно гранулированные политики. Самое важное, что следует отметить. Для использования этой функциональной возможности, так это то, что домен просто обязан работать на функциональном уровне Windows Server 2008.

Назначение политики 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, то применяется обычная политика паролей по умолчанию, которая берется из свойств объекта Домен. В следующей статье мы посмотрим как его создать на примере windows server 2008R2