Windows 2008 server политика паролей домена windows

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

Политика паролей в Default Domain Policy

По-умолчанию в домене AD настройка общих требований к паролям пользователей осуществляется с помощью групповых политик. Политика паролей учетных записей домена настраивается в политике Default Domain Policy. Эта политика прилинкована к корню домена и обязательно должна применяться к контролеру домена с FSMO ролью PDC эмулятор.

1. Чтобы настроить политику паролей, откройте консоль управления доменными GPO (Group Policy Management console –
   gpmc.msc
   );
2. Разверните ваш домен и найдите политику Default Domain Policy. Щелкните по ней ПКМ и выберите Edit;
3. Политики паролей находятся в следующем разделе редактора GPO: Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политика паролей (Computer configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy);
4. Чтобы отредактировать настройки параметра политики, дважды щелкните по ней. Чтобы включить политику, отметьте галку Define this policy settings и укажите необходимую настройку (в примере на скриншоте я задал минимальную длину пароля пользователя 8 символов). Сохраните изменения;
5. Новые настройки парольной политики будут применены ко все компьютерам домена в фоновом режиме в течении некоторого времени (90 минут), при загрузке компьютера, либо можно применить новые параметры групповых политик немедленно, выполнив команду
   gpupdate /force

Вы можете изменить настройки политики паролей из консоли управления GPO или с помощью PowerShell командлета Set-ADDefaultDomainPasswordPolicy:

Set-ADDefaultDomainPasswordPolicy -Identity winitpro.ru -MinPasswordLength 14 -LockoutThreshold 10

Основные настройки политики паролей

Рассмотрим все доступные для настройки параметры управления паролями пользователями. Всего есть шесть параметров политики паролей:

• Вести журнал паролей (Enforce password history) – определяет количество старых паролей, которые хранятся в AD, запрещая пользователю повторно использовать старый пароль (однако администратор домена или пользователь, которому делегированы права на сброс пароля в AD, может вручную задать для аккаунта старый пароль);
• Максимальный срок действия пароля (Maximum password age) – определяет срок действия пароля в днях. После истечения срока действия пароля Windows потребует у пользователя сменить пароль. Обеспечивает регулярность смены пароля пользователями;

  Вы можете узнать когда истекает пароль определенного пользователя можно получить с помощью командлета:
  Get-ADUser -Identity dbpetrov -Properties msDS-UserPasswordExpiryTimeComputed | select-object @{Name="ExpirationDate";Expression= {[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed") }}

• Минимальный срок жизни пароля (Minimum password age) – как часто пользователи могут менять пароль. Этот параметр не позволит пользователю несколько раз подряд сменить пароль, чтобы вернуться к любимому старому паролю, перезатерев пароли в журнале Password History. Как правило тут стоит оставить 1 день, чтобы предоставить пользователю самому сменить пароль в случае его компрометации (иначе менять пароль пользователю придется администратору);
• Минимальная длина пароля (Minimum password length) – не рекомендуется делать пароль короче, чем 8 символов (если указать тут 0 – значит пароль не требуется);
• Пароль должен отвечать требование сложности (Password must meet complexity requirements) – при включении этой политики пользователю запрещено использовать имя своей учетной записи в пароле (не более чем два символа подряд из
  username
  или
  Firstname
  ), также в пароле должны использоваться 3 типа символов из следующего списка: цифры (0 – 9), символы в верхнем регистре, символы в нижнем регистре, спец символы ($, #, % и т.д.). Кроме того, для исключения использования простых паролей (из словаря популярных паролей) рекомендуется периодически выполнять аудит паролей учетных записей домена.
• Хранить пароли, использую обратимое шифрование (Store passwords using reversible encryption) – пароли пользователей в базе AD хранятся в зашифрованном виде, но в иногда нужно предоставить доступ некоторым приложениям нужно к паролю пользователя в домене. При включении этой политики пароли хранятся в менее защищенной виде (по сути открытом виде), что небезопасно (можно получить доступ к базе паролей при компрометации DC, в качестве одной из мер защиты можно использовать RODC).

Если пользователь пытается сменить пароль, которые не соответствует политике паролей в домене, у него появится ошибка:

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

Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.

Кроме того, нужно отдельно выделить настройки в разделе GPO: Политика блокировки учетной записи (Account Lockout Password):

• Пороговое значение блокировки (Account Lockout Threshold) – как много попыток набрать неверный пароль может сделать пользователь перед тем, как его учетная запись будет заблокирована;
• Продолжительность блокировки учетной записи (Account Lockout Duration) – на какое время нужно заблокировать учетную запись (запретить вход), если пользователь ввел несколько раз неверный пароль;
• Время до сброса счетчика блокировки (Reset account lockout counter after) – через сколько минут после последнего ввода неверного пароля счетчик неверных паролей (Account Lockout Threshold) будет сброшен.

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

Настройки парольных политик домена Active Directory по-умолчанию перечислены в таблице:

В Security Compliance Toolkit Microsoft рекомендует использовать следующие настройки парольных политик:

• Enforce Password History: 24
• Maximum password age: not set
• Minimum password age: not set
• Minimum password length: 14
• Password must meet complexity: Enabled
• Store passwords using reversible encryption: Disabled

Что интересно, в недавних рекомендациях Security Baseline 1903 Microsoft указывает, что не нужно включать функцию истечения паролей для пользователей. Это не увеличивает безопасность и только создает ненужные проблемы (ссылка).

Просмотр текущей парольной политики в домене

Вы можете посмотреть текущие настройки политики паролей в Default Domain Policy в консоли
gpmc.msc
(вкладка Settings).

Также можно вывести информацию о политике паролей с помощью PowerShell (на компьютере должен быть установлен модуль AD PowerShell):

Get-ADDefaultDomainPasswordPolicy

ComplexityEnabled : True
DistinguishedName : DC=winitpro,DC=ru
LockoutDuration : 00:30:00
LockoutObservationWindow : 00:30:00
LockoutThreshold : 0
MaxPasswordAge : 42.00:00:00
MinPasswordAge : 1.00:00:00
MinPasswordLength : 7
objectClass : {domainDNS}
objectGuid : a5daca80-6c2c-49a6-8704-d1e4db76e851
PasswordHistoryCount : 24
ReversibleEncryptionEnabled : False

Или можно проверить текущие настройки политики паролей AD на любом компьютере домена с помощью стандартной утилиты gpresult.

Несколько парольных политик в домене Active Directory

За управление доменной парольной политики отвечает контроллер домена, владелец FSMO роли PDC Emulator. Политика применяется к компьютерам домена, а не пользователям. Для редактирования настроек Default Domain Policy необходимы права администратора домена.

В домене может быть только одна политика паролей, которая применяется на корень домена и действует на всех пользователей без исключения (есть, конечно, нюансы, но о них ниже). Даже если вы создадите новую GPO с другими парольными настройками и примените ее к OU с параметрами Enforced и Block Inheritance, она не будет применяться к пользователям.

Доменная политика паролей действует только на объекты AD типа user. Для паролей компьютеров, обеспечивающих доверительные отношения с доменом, есть собственные настройка GPO.

До версии Active Directory в Windows Server 2008 можно было настраивать только одну политику паролей для домена. В новых версиях AD вы можете создать отдельные политики паролей для различных групп пользователей с помощью гранулированных политик паролей Fine-Grained Password Policies (FGPP). Гранулированные политики паролей позволяют создавать и применять разные объекты параметров паролей (Password Settings Object — PSO). Например, вы можете создать PSO повышенной длиной или сложностью пароля для учетных записей доменных администраторов (см. статью о защите административных учетных записей в AD), или наоборот упростить (отключить) пароль для каких-то учетных записей.

В рабочей группе политики паролей придется настроить на каждом компьютере отдельно помощью редактора локальной GPO – gpedit.msc, либо вы можете перенести настройки локальных GPO между компьютерами так.

Как известно, домен в Active Directory (AD) является границей общей области безопасности. В связи с этим в домене Windows Server 2003 AD может существовать только одна политика паролей. На самом деле, ограничена не только политика паролей, но и более широкий набор параметров, относящихся к политикам учетных записей:

• Политики паролей (Password Policy)
• Политики блокировки учетных записей (Account Lockout Policy)
• Политики Kerberos (Kerberos Policy)

Параметры в этом объекте групповой политики управляют политиками учетных записей для всех пользователей и для всех компьютеров домена. Раньше, при необходимости использования разных политик учетных записей для разных групп пользователей  приходилось создавать несколько доменов, однако в Windows Server 2008 появилась возможность указывать разные политики для различных пользователей и групп. Эта новая функциональность называется раздельной политикой паролей  (Fine-Grained Password Policy) и основана на введении двух новых классов объектов в схему AD: контейнер настроек пароля (Password Settings Container) и настройки пароля (Password Setting). Эти объекты предоставляют нам возможность введения нескольких политик паролей в одном домене AD.

Настройка раздельной политики паролей

Первым делом открываем оснастку Active Directory Users and Computers (ADUC) и проверяем функциональный уровень домена Active Directory

Он должен быть не ниже Windows Server 2008

В этой же оснастке ADUC создаем глобальную группу безопасности, для которой в дальнейшем будут применяться новые политики паролей. (Да, как это не странно, политика паролей применяется не к организационным единицам, а к группам безопасности).

Затем запускаем редактор ADSI Edit

Щелкаем правой кнопкой в корне ADSI Edit и выбираем Connect to (Подключиться к)

Здесь у нас  появится возможность развернуть домен

Затем разворачиваем контейнер System и нажав правой кнопкой мыши Password Settings Container выбираем New — Object (Новый — Объект)

Теперь мы должны выбрать класс для нового объекта (правда, для выбора есть лишь один элемент). Выбираем msDS-PasswordSettings и нажимаем Next (Дальше):

После этого запускается мастер, который поможет нам создать объект настроек для пароля (Password Settings Object, PSO). Нам необходимо будет указать значение для каждого из следующих 11 атрибутов. Набираем значение, как показано в примере, не забывая ввести знак минуса для тех значений, где это требуется.

CN — название политики. Стоит присвоить политике понятное имя, если у вас их будет несколько.

msDS-PasswordSettingsPrecedence — параметр, используемый в качестве приоритета для различных политик. Используется в том случае, если для одного пользователя настраивается несколько политик PSO. Чем выше приоритет, тем меньше значение этого параметра.

msDS-PasswordReversibleEncriptionEnabled — булево значение. Верно, если пароль хранится с использованием обратного шифрования (может быть полезно для повышения безопасности).

msDS-PasswordHistoryLength — количество ранее использованных паролей, которое должна помнить система.

msDS-PasswordComplexityEnabled — булево значение. Верно, если вы хотите, чтобы пользователь использовал сложный пароль.

msDS-MinimumPasswordLength — минимальное количество символов для пароля для учетной записи пользователя.

msDS-MinimumPasswordAge — минимальное время жизни пароля (в примере 1 день).

msDS-MaximumPasswordAge — максимальное время жизни пароля (в примере 42 дня).

msDS-LockoutThreshold — количество попыток ввода неверного пароля, после которого учетная запись будет заблокирована.

msDS-LockoutObservationWindow — время, через которое счетчик количества попыток ввода неверного пароля будет обнулен (в примере 15 минут).

msDS-LockoutDuration — время, в течение которого будет заблокирована учетная запись пользователя при вводе большого количества неверных паролей (в примере 15 минут).

После завершения ввода этой информации в следующем диалоговом окно нажимаем в на кнопку Finish (Завершить).

Новая политика паролей создана, остается только назначить ее определенному пользователю или глобальной группе безопасности. Для этого щелкаем правой кнопкой на созданном объекте и выбираем пункт Properties (Свойства).

Теперь выбираем пункт msDS-PSOAppliesTo жмем  на кнопку Edit (Редактировать).
Здесь можно добавить необходимое имя пользователя или глобальной группы безопасности.

В  примере я добавил ранее созданную глобальную группу безопасности Simple Password. Теперь каждая учетная запись пользователя, которая входит в состав этой группы, будет подчиняться новой политике пароля Simple Password (чтобы не путаться, я назвал одинаково политику и группу) вместо доменной политики по умолчанию.

Если к пользователю применяется несколько политик PSO, то результирующая политика будет определяться следующим образом:

• PSO, которая связана напрямую с пользователем, будет использоваться до тех пор, пока напрямую пользователю не назначено несколько PSO. Если назначено более одной PSO, то результирующей будет PSO с наименьшим значением msDS-PasswordSettingsPrecedence. Если система обнаружит, что с пользователем связаны две или более PSO с одинаковым значением msDS-PasswordSettingsPrecedence, то будет применена PSO с меньшим значением глобального уникального идентификатора Global Unique Identifier (GUID).
• Если ни один PSO не связан с пользователем, то входит в рассмотрение членство пользователя в глобальной группе безопасности (global security group). Если пользователь является членом нескольких групп безопасности с различными PSO, то результирующим будет PSO с наименьшим значением. Если система обнаруживает два или более PSO, назначенных для групп, в состав которых входит этот пользователь, с одинаковым значением msDS-PasswordSettingsPrecedence, то применяется PSO с наименьшим значением GUID.
• Если не удается получить ни одного PSO исходя из предыдущих условий, то применяются настройки для пароля и блокировки из доменной политики по умолчанию, точно также как и в предыдущих версиях Active Directory.

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

Дек 3, 2014 22:43

Одни из самых важных политик безопасности Windows, знакомые каждому администратору Windows, — политики паролей. Эти политики позволяют назначить требования к качеству паролей (например, минимальную длину и максимальный возраст пароля) локальных и доменных учетных записей пользователя. Как известно, у политик паролей Windows Server 2003 и Windows 2000 Server есть ряд существенных ограничений. Далее в статье разъясняются эти ограничения и способы использования политик паролей Server 2008. На момент подготовки статьи компания Microsoft выпустила Server 2008 Release Candidate 0 (RC0) и готовит к выходу в свет окончательную версию.

Гибкое решение

Существенное ограничение политик паролей в Windows 2003 и Windows 2000 заключается в том, что администраторы могут определить лишь одну политику паролей, которая применяется ко всем учетным записям пользователей в домене. Глобальную доменную политику паролей можно задать параметрами Password Policy объекта групповой политики (GPO) Default Domain Policy или из любого другого GPO, связанного с объектом домена Active Directory (AD). Для доступа к интерфейсу настройки политик паролей следует обратиться к GPO-контейнеру Computer ConfigurationWindows SettingsSecurity SettingsAccount Policies. В объектах GPO можно определять различные политики паролей и связывать их с организационными единицами (OU) AD или учетными записями компьютеров, но политики паролей не применяются к учетным записям в домене. Они применяются к локальным учетным записям, определенным в базах данных безопасности учетных записей компьютеров, на которые воздействуют объекты GPO.

Часто компании выдвигают особые требования к качеству паролей определенных категорий учетных записей домена. Типичный пример — различные политики паролей для учетных записей администраторов и рядовых пользователей. Логика безопасности проста: учетные записи администраторов имеют больше прав, чем учетные записи простых пользователей, поэтому к администратору естественно применить более строгую проверку подлинности, чем к обычному сотруднику. Другой способ повысить надежность проверки — ввести для учетных записей администраторов регистрацию с помощью смарт-карт.

В Windows 2003 и Windows 2000 применяется два обходных приема для компаний, которым нужно определить различные политики паролей в одном домене, хотя оба способа довольно сложны. Один из них — развернуть отдельные домены для каждой категории учетных записей, которой назначается специальный пароль. Другой обходной прием — подготовить специальную DLL-библиотеку «фильтрации паролей» и развернуть ее на всех контроллерах домена (DC). Второй вариант применяется редко, так как он еще более трудоемок, чем первый.

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

Такая же функциональность появилась в Server 2008 для политик блокирования учетных записей, которые в прошлых версиях Windows Server имели те же ограничения (можно определить лишь одну политику блокирования для всех учетных записей домена). Политики блокирования учетных записей гарантируют, что учетные записи пользователей автоматически становятся недоступны, если пользователь определенное число раз вводит неверный пароль. Настраивая политику блокирования учетных записей, администратор должен определить порог для неверных паролей.

Настройка детализированных политик паролей

Настройка детализированных политик паролей Server 2008 коренным образом отличается от определения обычной политики паролей доменной или локальной учетной записи в предшествующих версиях Windows (описанных раньше). Нельзя использовать настройки GPO для детализированных политик паролей, так как здесь применяется другой (не на основе GPO) механизм для хранения и применения этих политик.

Детализированные политики паролей Server 2008 хранятся в новом контейнере AD, именуемом AD Password Settings Container, который находится в контейнере System контекста именования домена AD. Чтобы определить новую детализированную политику паролей, необходимо создать в этом контейнере новый объект AD класса msDS-PasswordSettings. В документации Microsoft объекты этого класса именуются объектами настроек пароля (Password Settings object, PSO). По умолчанию только члены группы Domain Admins могут создавать объекты PSO, так как только члены этой группы имеют разрешения AD Create Child и Delete Child в контейнере Password Settings. Инструменты, используемые для создания и настройки объектов PSO, будут рассмотрены ниже.

Чтобы применить подготовленные объекты PSO, необходимо связать PSO с объектом пользователя или группы AD. Для этого не требуется разрешений собственно в объекте AD; достаточно разрешения записи в объекте PSO. По умолчанию это разрешение имеют только члены группы Domain Admins. Поэтому только члены группы Domain Admins могут связать объект PSO с группой или пользователем, хотя, конечно, разрешения можно делегировать другим администраторам.

В таблице приведена сводка атрибутов, связанных с объектами PSO в Windows Server 2008. Обратите внимание, что в объекте PSO могут храниться не только настройки политики паролей, но и настройки политики блокирования учетных записей. Помните, что Server 2008 поддерживает детализированные как политики паролей, так и блокирования учетных записей. Два важных атрибута PSO — msDS-PSOAppliesTo и msDS-PasswordSettingsPrecedence.

PSOAppliesTo — атрибут со многими значениями, который определяет, к каким учетным записям пользователей или групп AD привязан объект PSO. Хотя политики паролей и блокирования учетных записей могут быть связаны с любым объектом пользователя, группы или компьютера AD либо организационной единицей (OU), объекты PSO действуют только для учетных записей пользователей и глобальных групп, с которыми они связаны. Кроме того, объекты PSO действуют только в том случае, если домен AD находится на собственном функциональном уровне Windows Server 2008, т. е. все контроллеры домена (DC) в домене должны работать с Windows Server 2008.

Атрибут msDS-PasswordSettingsPrecedence объекта PSO содержит целочисленное значение, которое используется для устранения конфликтов при применении нескольких объектов PSO к объекту пользователя или группы. Малое значение msDS-PasswordSettings Precedence указывает, что приоритет данного объекта PSO выше, чем у других PSO. Например, если с объектом пользователя связаны два объекта PSO, один со значением msDS-PasswordSettings Precedence, равным 10, а другой со значением 40, то объект PSO со значением атрибута 10 (меньшим) имеет более высокий ранг и будет применен к объекту пользователя. Если с группой или пользователем связано несколько объектов PSO, то Windows Server 2008 выбирает PSO по следующим критериям.

• Объект PSO, связанный напрямую с объектом пользователя, является результирующим PSO. Если более одного PSO напрямую связаны с объектом пользователя, то результирующим будет объект PSO с наименьшим значением msDS-PasswordSettingsPrecedence.

• Если с объектом пользователя не связано ни одного PSO, но объекты PSO связаны с глобальными группами, в которые входит пользователь, то Windows Server 2008 сравнивает значение msDS-PasswordSettingsPrecedence различных объектов PSO глобальных групп. И вновь результирующим будет объект PSO с наименьшим значением msDS-PasswordSettingsPrecedence.

• Если по этим условиям не удается определить объект PSO, то применяется традиционная политика домена по умолчанию.

Чтобы администраторы могли без труда определить объект PSO, в конечном итоге применяемый к пользователю, компания Microsoft дополнила каждый объект пользователя AD новым атрибутом msDS-ResultantPSO. Этот атрибут содержит составное имя (DN) объекта PSO, примененного к данному пользователю.

Инструменты создания и настройки объектов PSO

Компания Microsoft не планирует выпуск инструмента с графическим интерфейсом или оснастку консоли Microsoft Management Console (MMC) для настройки детализированных политик в первом выпуске Windows Server 2008. Однако можно использовать существующие инструменты запросов LDAP, такие как LDP или LDIFDE, или оснастку ADSI Edit консоли MMC, чтобы определить и настроить объекты PSO. Эти инструменты доступны в любой установке AD в Windows Server 2008. Несмотря на сложность этих трех инструментов, опытные администраторы AD смогут без проблем назначать с их помощью новые политики паролей.

Начинающие администраторы AD или опытные специалисты, желающие упростить задачу, могут воспользоваться инструментом командной строки Джо Ричардса, psomgr.exe или программой Specops Password Policy фирмы Special Operations Software. Благодаря Specops Password Policy можно использовать специальную оснастку MMC для настройки объектов PSO из графического интерфейса Windows. Оба инструмента скрывают сложность AD за детализированными политиками паролей и существенно упрощают их настройку. Инструмент PSOMgr можно загрузить по адресу www.joeware.net/freetools/tools/psomgr . Полнофункциональная коммерческая версия Specops Password Policy опубликована по адресу www.specopssoft.com/products/specopspasswordpolicy ; бесплатную версию с ограниченными возможностями, Specops Password Policy Basic, можно получить по адресу www.specopssoft.com/wiki/index.php/specopspasswordpolicybasic . Полнофункциональная версия расширяет обычную политику паролей Windows, дополняя ее такими возможностями, как запрет использования в паролях имен пользователей и определенных слов и автоматическое уведомление пользователя об истечении срока действия пароля по электронной почте.

Чтобы применить ADSI Edit для определения нового объекта PSO, необходимо запустить ADSI Edit и подключиться к домену, в котором предстоит определить детализированную политику паролей. Затем нужно перейти к контейнеру SystemPassword Policy Settings. Щелкните на контейнере правой кнопкой мыши и выберите New, Object. В диалоговом окне Create Object (экран 1) выберите класс объекта msDSPasswordSettings и введите нужный пароль и значения политики блокирования учетных записей для различных атрибутов PSO.

Чтобы применить LDP для определения нового объекта PSO, необходимо инициировать несколько команд LDAP из интерфейса LDP. Дополнительные сведения об использовании LDP см. в статье Microsoft «Using Ldp.exe to Find Data in the Active Directory» по адресу support.microsoft.com/kb/224543. Прежде чем применить утилиту командной строки LDIFDE, чтобы определить новый PSO, необходимо создать файл конфигурации LDF, который задает различные атрибуты PSO. Информацию по использованию LDIFDE можно найти в статье Microsoft «Using LDIFDE to import and export directory objects to Active Directory» по адресу support.microsoft.com/kb/237677. Более подробные инструкции приведены в статье «Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration» по адресу technet2.microsoft.com/windowsserver2008/en/library/2199dcf7-68fd-4315-87cc-ade35f8978ea1033.mspx?mfr=true.

При использовании версии ADSI Edit, поставляемой вместе с Windows Server 2008 для определения объектов PSO, требуется ввести четыре временных атрибута PSO (msDS-MaximumPasswordAge, msDS-MinimumPasswordAge, msDS-LockoutObservationWindow и msDS-LockoutDuration) в формате дни:часы:минуты:секунды. Например, чтобы задать максимальный срок действия пароля 40 дней, нужно указать срок 40:00:00:00. При использовании команды ldifde или старой (предшествующей Server 2008) версии ADSI Edit для создания объектов PSO необходимо вводить значения этих атрибутов в формате I8 (целочисленное представление в 8 байт). Время в формате I8 хранится в интервалах -100 нс. Это означает, что при использовании LDIFDE или старой версии ADSI Edit для присвоения атрибутам PSO значений нужно преобразовать время в минутах, часах и днях во время в интервалах в 100 нс, а затем поставить перед полученным значением знак «минус» (-).

Формат I8 использовать неудобно, поэтому рекомендуется определять объекты PSO с помощью версии ADSI Edit для Server 2008, PSOMgr или Specops Password Policy. В статье Microsoft «Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration» (technet2.microsoft.com/windowsserver2008/en/library/2199dcf7-68fd-4315-87cc-ade35f8978ea1033.mspx?mfr=true) приведено более подробное объяснение преобразования I8.

Наряду с использованием ADSI Edit, LDP, LDIFDE, PSOMgr или Specops Password Policy, для привязки объектов PSO к пользователям или глобальным группам можно задействовать оснастку Active Directory Users and Computers консоли MMC. Чтобы связать PSO с пользователем или группой из этой оснастки, следует открыть оснастку и проверить, активизировано ли представление Advanced Features. Чтобы включить его, воспользуйтесь разделом Advanced Features в меню View. Затем нужно открыть контейнер Passwords Settings в контейнере System, щелкнуть правой кнопкой мыши на PSO, который предстоит привязать, и выбрать пункт Properties. В диалоговом окне Properties следует выбрать вкладку Attribute Editor, атрибут msDS-PSOAppliesTo и щелкнуть на кнопке Edit. Наконец, в окне Edit (экран 2) необходимо ввести составное имя пользователя или группы, которое можно получить из оснастки Active Directory Users and Computers. В области подробностей оснастки щелкните правой кнопкой мыши на имени пользователя или глобальной группы безопасности, выберите пункт Properties, вкладку Attribute Editor и посмотрите значение атрибута distinguishedName пользователя или группы в списке Attributes.

Ценное дополнение

Детализированные политики паролей и блокирования учетных записей Server 2008 — ценное дополнение к набору средств управления безопасностью Windows. Хотя в первом выпуске Server 2008 определить и настроить эти политики непросто (настоятельно рекомендуется использовать инструмент PSOMgr или Specops Password Policy), политики значительно повышают гибкость управления. Например, благодаря детализированным политикам паролей Server 2008 отпадает необходимость в развертывании дополнительных доменов Windows или проектировании специальных фильтров паролей.

Жан де Клерк (jan.declerq@hp.com ) — член Security Office корпорации HP. Специализируется на проблемах управления идентичностью и вопросах безопасности продуктов Microsoft

Использование политик паролей Server 2008

Шаг 1. Политики паролей Windows Server 2003 и Windows 2000 Server позволяют администраторам определить только одну политику паролей, применяемую ко всем учетным записям пользователей в домене.

Шаг 2. В Windows Server 2008 появились детализированные политики паролей, с помощью которых администратор может определить разные политики паролей для различных категорий учетных записей в одном домене.

Шаг 3. Необходимо создать объекты Password Settings (PSO), чтобы определить новые детализированные политики паролей.

Шаг 4. Чтобы определить и настроить созданные объекты PSO, следует использовать инструмент запросов LDAP (например, LDP, LDIFDE, ADSI Edit), PSOMgr или Specops.

Настройка параметров пароля в Windows Server 2008

В предыдущих версиях Active Directory (AD) у нас была лишь одна политика для пароля и блокировки учетной записи (account lockout policy) для всего домена. У некоторых компаний возникает необходимость использования нескольких доменов, чтобы использовать различные политики пароля (password policy) для различных пользователей; другие должны разрабатывать свои собственные фильтры для паролей или покупать решения сторонних производителей. В операционной системе Windows Server 2008 у нас есть возможность указать различные политики паролей для различных пользователей и групп.

Новое в классе

Коротко, новая функциональность, называемая “Granular Password Settings” или “Fine-Grained Password Policy“, основана на введении двух новых классов объектов в схему: контейнер настроек пароля или “Password Settings Container” и настройки пароля “Password Setting”. Эти объекты предоставляют нам возможность введения нескольких политик паролей в одном домене AD. Но давайте посмотрим, что нам еще для этого нужно …

Инструменты и требования

Это краткий обзор инструментов и требований, необходимых для создания дополнительных политик пароля.

ADUC

Прежде всего весь функциональный уровень домена Active Directory должен использовать “Windows Server 2008”. Это можно проверить с помощью инструмента под названием Active Directory Users and Computers (ADUC пользователи и компьютеры AD). Нажимаем правой кнопкой мыши на домене > выбираем “Raise domain functional level (поднять функциональный уровень домена)” – текущий функциональный уровень домена должен быть “Windows Server 2008” (ниже представлен рисунок для версии beta 3 операционной системы Windows Server 2008 номер сборки 6001):

GPMC

Мы все равно должны использовать консоль управления политиками группы (Group Policy Management Console или GPMC), чтобы задать политику пароля по умолчанию для всего домена. Если вы забыли, как задать настройки политики паролей и политики блокировки учетной записи по умолчанию, то их можно найти в GPMC на уровне домена в “Default Domain Policy” > Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy/Account Lockout Policy.

Между прочим, GPMC включен в состав операционной системы Windows Server 2008 (как и Windows Vista), но ее необходимо добавить из “Feature” – выбрать “Add Feature” в Server Manager, выбрать ‘Group Policy Management’ и через некоторое время ‘Group Policy Ready’ (политика группы готова).

ADSI Edit

Самый важный инструмент для этого упражнения – это инструмент, который большинство администраторов боялись на протяжении многих лет – т.к. оно используется лишь тогда, когда все очень плохо. Я говорю о утилите под названием ADSI Edit (adsiedit.msc). Большинство настроек политики паролей создается и настраивается с помощью этого инструмента. ADSI Edit является частью Windows Server 2008, поэтому вам не нужно устанавливать его дополнительно.

Этапы

Это краткий обзор этапов, необходимых для настройки ‘Granular Password Settings’ в операционной системе Windows Server 2008:

1. Создание объекта настроек пароля или Password Settings Object (PSO) в контейнере настроек пароля или Password Settings Container (PSC) с помощью ADSI Edit
2. Настройка параметров PSO с помощью обычного мастера ADSI Edit
3. Назначение PSO для учетной записи пользователя или глобальной группы безопасности
4. Подтверждение настроек

Теперь, когда мы знаем все этапы, давайте приступим!

Приступим

Сперва, давайте запустим ADSI Edit, нажав на Start > Run… > “adsiedit.msc” и нажав на кнопку OK (или клавишу Enter).

Щелкните правой кнопкой в корне “ADSI Edit” и выберите “Connect to…” (подключиться к…)

Нажмите на кнопку OK, чтобы выбрать настройки по умолчанию в диалоговом окне “Connection Settings” (настройки соединения):

В ADSI Edit у вас теперь появится возможность развернуть домен, развернуть контейнер ‘System’ и после этого нужно нажать правой кнопкой мыши ‘Password Settings Container’ (PSC) и выбрать New > “Object…”.

Теперь вы должны выбрать класс для нового объекта, но у вас для выбора лишь один элемент (иногда здорово иметь всего один вариант, не так ли?). Выберите msDS-PasswordSettings и нажмите на кнопку Next (далее):

После этого мастер поможет нам создать объект настроек для пароля (Password Settings Object или PSO). Нам необходимо будет указать значение для каждого из следующих 11 атрибутов. Наберите значение, как показано в таблице ниже (не забудьте ввести знаку минуса для тех значений, где это требуется) или же ввести свои настройки.

После завершения ввода этой информации вы увидите следующее диалоговое окно – просто нажмите в нем на кнопку Finish (Завершить).

Сделаем это

Теперь, когда мы создали объект PSO, он должен появиться ниже PSC в ADSI Edit и ADUC/Server Manager (не забудьте подключить “Advanced Features (дополнительные возможности)” в меню View (просмотр)), и должен выглядеть примерно так:

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

Для этого щелкните правой кнопкой на PSO в ADUC (или в ADSI Edit) и выберите пункт Properties (свойства)– нажмите на Filter (фильтр) и убедитесь, что у вас выбраны следующие настройки:

Если вы не видите рисунок, то я могу рассказать вам, что выбраны следующие параметры: “Mandatory”, “Optional”, “Constructed”, “Backlinks” и “System-only”. Параметр “Show only attributes that have values” не выбран.

Теперь найдите msDS-PSOAppliesTo, выберите его и нажмите на кнопку Edit (Редактировать).

В редакторе “Multi-valued String Editor” вставьте необходимое имя пользователя или глобальной группы безопасности в поле “Value to add” и нажмите на кнопку Add (Добавить). Вы можете добавить несколько различных имен с помощью этого окна – после того, как вы закончите, просто нажмите на кнопку OK.

В примере, изображенном на рисунке, я добавил глобальную группу безопасности под названием “Admins” (полное имя “CN=Admins,CN=Users,DC=Contoso,DC=Local”). Каждая учетная запись пользователя, которая входит в состав этой группы, теперь будет подчиняться новой политике пароля “PassPolAdmins”, вместо доменной политики по умолчанию (Default Domain Policy). Здорово!

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

Вы заметили перемены?

Когда вы раньше работали в ADUC, вы обратили внимание на новую закладку “Attribute Editor” (редактор атрибутов), которая теперь есть для большинства объектов (необходимо зайти View > “Advanced Features”)?

Это в действительности здорово, т.к. она позволяет администратору просматривать и редактировать множество элементов, что обычно делается при помощи инструмента ADSI Edit. С помощью этой закладки мы можем перенести свойства PSO в домен и изменить атрибут msDS-PSOAppliesTo, чтобы легко применить политику пароля для пользователя или группы (или удалить пользователя или группу из этой политики). Пожалуйста, обратите внимание, что вы не можете установить политику пароля в свойствах пользователя или группы – информация о том, какая политика применяется к пользователю или группе устанавливается самим объектом настроек пароля Password Settings Object!

Как я могу увидеть, что политика выиграла?

Может быть очень сложно определить, что политика ‘выиграла’ для конкретного пользовательского объекта. Но я рад сообщить вам, что компания Microsoft подумала об этом, и ввела атрибут msDS-ResultantPSO для пользовательского объекта (только лишь).

Это значение позволяет определить, какая политика применяется для конкретного пользователя (в нашем примере пользователь называется “Windows Admin”). Другими словами это активная политика пароля и блокировки учетной записи для выбранного пользователя.

И объекты групп и объекты пользователей имеют еще один новый атрибут, msDS-PSOApplied, который описывает (в многострочной строке) все политики, под влияние которых попадает группа или пользователь – либо напрямую, либо благодаря членству. В примере ниже группа под названием “Admins” попадает под действие двух различных политик пароля.

Примечание: Если вы не видите значения, о которых я здесь говорю, не забудьте задать настройки фильтра в закладке “Attribute Editor”, о которых я упоминал в параграфе под названием «Сделаем это».

Почему я захочу это сделать?

Теперь мы увидели, как создать PSO и назначить их для пользователей и групп, но для чего нам нужно несколько политик пароля и блокировки учетной записи (password and account lockout policy), можете спросить вы? Хорошо. Существует множество причин для этого – одно может заключаться в размещении сценариев, когда несколько компаний представлены в одном домене AD domain. Другая причина, которая встречается гораздо чаще, заключается в том, что мы должны более жестко контролировать группы людей с расширенными правами (как администраторы домена, сотрудники службы помощи и т.п.).

Для этих привилегированных учетных записей могут предъявляться особые требования к сложности и длине пароля, к другим, более ограниченным учетным записям могут предъявляться более легкие требования – хотя я всем рекомендую использовать пароли длинной не мене 16 символов (более подробно об этом ниже в этой статье).

Чего это может коснуться?

Рискуя повториться, я все же скажу, чтобы это было на 100% ясно. Новая функциональность многопарольной политики (“multiple password policy”) в операционной системе Windows Server 2008 (кодовое название “Longhorn”) позволяет нам задавать индивидуальные политики пароля и блокировки учетной записи для объектов пользователей (user), объектов interOrgPerson и глобальных групп безопасности (global security groups).

Новые политики пароля нельзя напрямую применить для организационной единицы OU – теперь вместо этого мы должны применять эти политики для групп. Но не для любых групп, это должны быть группы безопасности (security group) глобальной области действия. Существует также возможность установки параметров/атрибутов для других групп; однако, это работает не так, как ожидалось (настройки игнорируются).

Если мы действительно хотим обрабатывать политики паролей внутри структуры OU, то могут быть полезны теневые группы ‘Shadow Groups’ – смотрите раздел ‘Shadow Groups and how to script them’ ниже в этой статье.

По умолчанию только члены группа администраторы домена “Domain Admins” могут устанавливать, создавать и удалять политики пароля – лучше известные как объекты настроек пароля (Password Setting Objects PSO). Однако, эти привилегии можно также передавать и забирать в случае необходимости, но для большинство сред этих настроек будет достаточно. Чтобы быть более точным, только члены группы администраторов домена (Domain Admins) имеют необходимые привилегии ‘Create Child’ (создать дочерний объект) и ‘Delete Child’ (удалить дочерний объект) для объекта Password Settings Container (PSC).

Чтобы применить PSO для пользователя или группы, вы должны обладать привилегиями на запись (‘Write’ permission) для объекта PSO – по умолчанию такими привилегиями обладают члены группы администраторов домена (Domain Admin).

Посмотрите на эти атрибуты

Я также должен упомянуть об некоторых из атрибутов, которые делают все это возможным.

msDS-PSOAppliesTo

Каждый объект PSO имеет атрибут под названием msDS-PSOAppliesTo, который известен также, как ссылка, связывающая с пользователем или группой. Она может указывать на одного пользователя, одну группу, несколько пользователей, несколько групп или несколько пользователей и групп. Эти ссылки в действительности лишь выдающиеся имена (distinguished names), например, “CN=GroupA,OU=MyGoups,DC=Contoso,DC=Local” для объектов.

У вас может возникнуть вопрос, а что будет, если мы переименуем или удалим пользователя или группу (в другой контейнер или OU), последует ли PSO за объектами? Да – атрибут PSO под названием msDS-PSOAppliesTo автоматически обновится службой директории в фоновом режиме, и будет указывать на новое место.

msDS-PSOApplied

Вышеупомянутый атрибут msDS-PSOAppliesTo для PSO можно редактировать в отличие от атрибута msDS-PSOApplied, который представляет пользователя или группу. Последний атрибут предназначен только для чтения и обрабатывается в фоновом режиме службой директории.

Атрибут msDS-PSOApplied содержит ссылку на PSO, указывающий на родительский объект – как пользователи, так и группы могут иметь несколько PSO, назначенных им.

msDS-ResultantPSO

Атрибут msDS-ResultantPSO существует только для объектов пользователей. Он содержит вычисляемое значение, которое также называют “Resultant Set of Policy” (RsoP результирующий набор политики). Это ссылка на один “счастливый” PSO, который активен для определенного объекта пользователя. Это значение определяется службой директории в фоновом режиме с помощью правил, упомянутых в следующем разделе этой статьи (“Проект”).

Вы можете спросить, если политика пароля активна для пользователя, который добавлен в группу? Как только пользователь добавляется в группу, то результирующая PSO также высчитывается для пользовательского объекта службой директории (directory service). То же самое происходит при удалении учетной записи пользователя из группы.

msDS-PasswordSettingsPrecedence

Атрибут msDS-PasswordSettingsPrecedence присутствует на объектах PSO. Низкое значение этого атрибута говорит о том, что PSO имеет высокий приоритет. Этот атрибут используется в том случае, когда для одного пользователя применяется несколько PSO – т.о. выбирается самое низкое значение. Если вы назначите несколько уникальных значений для каждого объекта PSO в домене, то легко можно будет определить эффективную политику пароля для определенного пользователя.

Проект

Перед тем, как реализовать несколько политик паролей (multiple password policies) в домене, рекомендуется получить обзор того, какие политики необходимы для завершения общего дизайна этих политик и их взаимодействия.

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

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

Простые правила …

Результирующая PSO определяется следующим образом:

1. PSO, которая связана напрямую с пользователем, будет использоваться до тех пор, пока напрямую пользователю не назначено несколько PSO. Если назначено более одной PSO, то результирующей PSO будет PSO с наименьшим значением (msDS-PasswordSettingsPrecedence). Если система обнаружит, что с пользователем связаны две или более PSO с одинаковым значением msDS-PasswordSettingsPrecedence, то будет применена PSO с меньшим значением глобального уникального идентификатора (Global Unique Identifier GUID).
2. Если ни один PSO не связан с пользователем, то входит в рассмотрение членство пользователя в глобальной группе безопасности (global security group). Если пользователь является членом нескольких групп безопасности с различными PSO, то результирующим PSO будет PSO с наименьшим значением. Если система обнаруживает два или более PSO, назначенных для групп, в состав которых входит этот пользователь, с одинаковым значением msDS-PasswordSettingsPrecedence, то применяется PSO с наименьшим значением GUID.

Если не удается получить ни одного PSO исходя из условий 1 и 2, то применяются настройки для пароля и блокировки из доменной политики по умолчанию “Default Domain Policy”, точно также как и в предыдущих версиях Active Directory (AD).

Таким образом, мы немного сократили нашу историю: PSO, назначенный пользователю, выиграет у PSO, назначенному группе, а меньшее значение выиграет у большего – если такое сравнение не удается, то в ход вступает значение GUID. А если ничего не подходит, то мы приходим к началу – к доменной политике по умолчанию “Default Domain Policy”!

В качестве общих рекомендаций, я упомяну эти:

Поле ‘Description’ (описание) может быть использовано для указания настроек пароля и блокировки, которые включены в PSO. Используйте его для краткого описания конфигурации PSO.

Используйте соглашение по наименование (naming convention) для PSO, как вы делаете это для других объектов AD.

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

Назначайте уникальное значение (unique precedence value) для каждого PSO в вашем домене, так будет намного проще определить эффективную политику пароля для определенного пользователя.

Правило Default Deny All (по умолчанию запретить все)

Я знаю, что это может быть не очень популярно, но я рекомендую вам установить настройки политик, содержащихся в “Default Domain Policy” (доменная политика по умолчанию) на очень высокий уровень безопасности. Это делается для того, что вы или кто-нибудь еще может забыть включить пользователя в одну из групп политик безопасности. В этом случае для учетной записи такого пользователя будут применяться политики для пароля, заданные в политике по умолчанию, которая задается на уровне домена.

Можно сравнить политику безопасности для доменной политики по умолчанию (Default Domain Policy) с правилом “Default Deny All” (запретить все по умолчанию) для брандмауэра – если ни одно из правил (политик) не подходит для пользователя (или группы, членом которой он является), то мы должны применить к нем самую строгую политику. В этом случае пользователь почти наверняка позвонит в службу помощи, чтобы исправить это. Если же мы дадим пользователю слишком много прав, то он скорее всего никогда не позвонит.

Еще одни способ выполнить это, заключается в указании политики паролей для группы “Domain Users” (пользователи домена) с использованием наименьшего приоритета – но опять же, по каким-либо причинам учетная запись может выпасть из этой группы… Поэтому лично я всегда задаю правило Default Deny All (запретить все по умолчанию)!

Теневые группы и как их описывать в сценарии

Если вы никогда не слышали о теневых группах “Shadow Groups”, не беспокойтесь – два месяца назад я тоже ничего о них не слышал. Теневая группа (Shadow Group SG) – это группа безопасности (в этом случае глобальная группа безопасности), которая содержит объекты внутри определенной OU в качестве членов. Можно сказать, что SG – это группа безопасности, которая отображается на OU.

Например, у вас может быть OU, “OU=Sales,OU=CorpUsers,DC=Contoso,DC=Local”, с учетными записями для всего отдела продаж – SG будет группа, которая на 100% соответствует ее содержимому. Для политик паролей это действительно может быть хорошей возможностью, если мы хотим, чтобы политики паролей виртуально удовлетворяли структуре OU, вместо того, чтобы совпадать со структурой группы безопасности (Security Group).

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

Этот сценарий собирает учетные записи пользователей из определенной OU, которая указывается в качестве аргумента для сценария, и помещает их в объект словарь. Сценарий затем собирает пользователей внутри определенной группы, которая указывается в качестве аргумента к сценарию – и помещает их в другой объект словарь. Путем сравнения этих словарей, сценарий добавляет или удаляет пользователей и теневой группы. Сценарий запускается по расписанию, и может быть использован со следующим синтаксисом: ShadowGroup.vbs «Target OU» «Shadow Group»

Пример:

ShadowGroup.vbs "OU=Test,DC=Contoso,DC=Local" "CN=Shadow,OU=Test,DC=Contoso,DC=Local"

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

Написание сценариев

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

Конечно, мы можем использовать инструмент под названием LDIFDE, или PowerShell. Windows PowerShell включен в состав операционной системы Windows Server 2008 и может быть добавлен в качестве инструмента – выберите “Add Feature” (добавить возможность) в новом менеджере сервера Server Manager, выберите Windows PowerShell и через несколько секунд PowerShell готов к использованию

Я также рекомендую вам попробовать Quest AD Cmdlets и зайти на PowerGui.org.

Бесплатный инструмент, работающий из командной строки под названием PSOmgr, уже доступен от Joeware. С помощью этого инструмента вы можете управлять объектами настроек паролей Password Settings Objects в операционной системе Windows Server 2008 очень просто, в том числе просматривать примененные политики и эффективность политики для определенного пользователя, просматривать PSO в домене/лесу, добавлять или удалять пользователя из PSO, создавать, переименовывать, удалять, изменять PSO и многое другое …

В службах AD DS Windows Server 2008 появился новый механизм AD DS Fine-Grained Password and Account Lockout Policy, позволяющий в рамках домена создавать несколько разных политик паролей, применяемых к конкретным доменным пользователям или доменным глобальным группам безопасности. Такой механизм может быть полезен в случае, если, например, необходимо для определенной группы пользователей иметь ослабленные/усиленные политики безопасности, отличающиеся от тех, что заданы на уровне всего домена в Default Domain Policy.

Рассмотрим сценарий создания объекта PSO в домене соответствующего следующим критериям:

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

Создание объекта PSO с помощью MMC-оснастки Active Directory Services Interface editor (ADSI Edit)

Откроем оснастку ADSIEDIT.MSC и подключимся к контексту именования по умолчанию нашего домена указав в поле Name FQDN имя нашего домена

Перейдём в контейнер DC=holding, DC=com -> CN=System —> CN=Password Settings Container

И в контекстном меню на контейнере Password Settings Container выберем создание нового объекта PSO (msDC-PasswordSettings)

Укажем имя нашего нового объекта PSO

Укажем значение атрибута msDS-PasswordSettingsPrecedence. Значение этого атрибута определяет приоритет в случае конфликта нескольких PSO, применяемых к одной и той же группе безопасности или пользователю.

Значение атрибута msDS—PasswordReversibleEncryptionEnabled определяет возможность обратимого шифрования пароля для учетных записей пользователей. Устанавливаем его в false как рекомендуемое.

Зададим значение атрибута msDS—PasswordHistoryLength определяющего количество неповторяемых паролей для учетных записей пользователей.

Значение атрибута msDS—PasswordComplexityEnabled, установленное нами в true, определяет включение требования соблюдения сложности паролей и является рекомендуемым.

Значение атрибута msDS-MinimumPasswordLength, установленное нами в 8, определяет минимальную длину паролей учетных записей пользователей.

Значение атрибута msDS-MinimumPasswordAge, установленное нами в 1:00:00:00 (1 день), определяет минимальный срок действия паролей учетных записей пользователей.

Значение атрибута msDS-MaximumPasswordAge, установленное нами в 90:00:00:00 (90 дней), определяет максимальный срок действия паролей учетных записей пользователей.

Значение атрибута msDS-LockoutThreshold, установленное нами в 5, определяет порог блокировки учетных записей пользователей (после 5 неудачных попыток авторизации срабатывает механизм блокировки учетной записи).

Значение атрибута msDS-LockoutObservationWindow, установленное нами в 0:00:30:00 (30 минут), определяет период сброса счетчика блокировок учетных записей пользователей.

Значение атрибута msDS-LockoutDuration, установленное нами в 0:00:30:00 (30 минут), определяет продолжительность блокировки заблокированных учетных записей пользователей.

На этом работа мастера создания PSO завершается.

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

Среди списка атрибутов находим атрибут msDS-PSOAppliesTo и убедившись в том что его значение не определено, открываем его редактирование.

В окне редактирования Multi—valued Distinguished Name With Security Principal Editor нажимаем Add Windows Account и выбираем соответствующую доменную глобальную группу безопасности, которую мы создали ранее.

Сохраняем свойства объекта PSO и убеждаемся в том, что привязка к соответствующей группе безопасности произведена (для этого можно проверить значение атрибута msDS-PSOApplied в свойствах самой группы безопасности).

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

Создание объекта PSO с посмощью CLI-утилиты LDIF Directory Exchange (LDIFDE)

Помимо создания объекта PSO через оснастку ADSIEDIT.MSC, мы можем создать его с помощью утилиты командной строки LDIFDE. В некоторых сценариях это может быть более быстро и удобно. Для этого нам предварительно нужно подготовить файл в формате *.LDF (LDAP Data Interchange Format) следующего содержания:

dn: CN=KOM-SRV-PSO-Users,CN=Password Settings Container,CN=System,DC=holding,DC=com
changetype: add
objectClass: msDS-PasswordSettings
msDS-MaximumPasswordAge: -77760000000000
msDS-MinimumPasswordAge:-864000000000
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:5
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-18000000000
msDS-LockoutDuration:-18000000000
msDS-LockoutThreshold:5
msDS-PasswordSettingsPrecedence:1
msDS-PSOAppliesTo:CN=KOM-SRV-PSO-Users,CN=Users,DC=holding,DC=com

Обратите внимание на то, что значения атрибутов связанных со временем указываются в формате I8 (интервалы по -100 наносекунд). Преобразование в данный формат производится по следующей схеме

То есть, например, чтобы установить значение атрибута msDS-LockoutDuration равным 30 минутам, для получения значения в формате I8 нужно умножить 30 на -600000000 (в этом примере значение равно -18000000000). Более подробную информацию по этому поводу можно получить в приложении Appendix B: PSO Attribute Constraints

После того как мы подготовили LDF файл, произведём импорт указанной в нём информации командой:

LDIFDE -i -f NewPSO.ldf

Более подробную информацию об использовании утилиты LDIFDE можно найти в статье KB237677 — Использование средства LDIFDE для импорта и экспорта объектов каталогов в Active Directory

Дополнительные источники информации:

Windows Server TechCenter — AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

TechDays.ru — Active Directory: политика паролей

Чтобы обеспечить высокий уровень безопасности учётных записей пользователей в домене Active Directory, администратор должен настроить и реализовать политику паролей домена. Политика паролей должна обеспечивать достаточную сложность, длину пароля и частоту смены паролей учётных записей пользователей и служб. Таким образом, вы можете затруднить злоумышленнику возможность перебора или перехвата паролей пользователей при их отправке по сети.

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

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

Политика паролей в политике домена по умолчанию (Default Domain Policy)

По умолчанию для установки общих требований к паролям пользователей в домене AD используются параметры групповой политики (GPO). Политика паролей учётных записей пользователей домена настраивается в Default Domain Policy (политике домена по умолчанию). Эта политика связана с корнем домена и должна применяться к контроллеру домена с ролью эмулятора PDC.

1. Чтобы настроить политику паролей учётной записи AD, откройте консоль Управления групповой политикой (gpmc.msc);

2. Разверните свой домен и найдите объект групповой политики с именем Default Domain Policy. Щёлкните его правой кнопкой мыши и выберите «Изменить»;

3. Политики паролей находятся в следующем разделе GPO: Computer configuration→ Policies→ Windows Settings → Security Settings → Account Policies → Password Policy (в русскоязычной версии это соответственно Конфигурация компьютера → Политики → Конфигурация Windows → Параметры безопасности → Политики учетных записей → Политика паролей);

4. Дважды щёлкните параметр политики, чтобы изменить его. Чтобы включить определённый параметр политики, установите флажок Define this policy settings («Определить следующий параметр политики») и укажите необходимое значение (на скриншоте ниже я установил минимальную длину пароля 8 символов). Сохраните изменения;

Новые параметры политики паролей будут применены ко всем компьютерам домена в фоновом режиме через некоторое время (90 минут), во время загрузки компьютера, или вы можете применить политику немедленно, запустив команду

gpupdate /force

Вы можете изменить параметры политики паролей из консоли управления GPO или с помощью командлета PowerShell Set-ADDefaultDomainPasswordPolicy:

Set-ADDefaultDomainPasswordPolicy -Identity ds.hackware.ru -MinPasswordLength 10 -LockoutThreshold 3

Основные параметры политики паролей в Windows

Рассмотрим все доступные настройки паролей Windows. В GPO есть шесть настроек пароля:

• Enforce password history (Вести журнал паролей) — определяет количество запоминаемых паролей, хранимых с целью недопущения их повторного использования.
  Однако администратор домена или пользователь, которому были делегированы разрешения на сброс пароля в AD, могут вручную установить старый пароль для учётной записи;
• Maximum password age (Максимальный срок действия пароля) — устанавливает срок действия пароля в днях. По истечении срока действия пароля Windows попросит пользователя сменить пароль. Эта настройка обеспечивает регулярность смены пароля пользователями. Не зависимо от данной политики, в Параметрах учётной записи пользователя можно включить опцию «Срок действия пароля не ограничен», эта опция будет иметь приоритет;

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

Get-ADUser -Identity MiAl -Properties msDS-UserPasswordExpiryTimeComputed | Select-Object name,samaccountname,@{Name="Истекает";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed") }}

Либо вывести информацию о дате истечения паролей сразу для всех пользователей:

Get-ADUser -Filter * -Properties "msDS-UserPasswordExpiryTimeComputed" | Select-Object name,samaccountname,@{Name="Истекает";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}}

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

• Minimum password length (Минимальная длина пароля) – рекомендуется, чтобы пароли содержали не менее 8 символов (если вы укажете здесь 0, то пароль станет необязательным);
• Minimum password age (Минимальный срок действия пароля) – устанавливает, как часто пользователи могут менять свои пароли. Этот параметр не позволит пользователю менять пароль слишком часто, чтобы вернуться к старому паролю, который ему нравится, удалив его из истории паролей после того, как пароль был изменён несколько раз подряд. Как правило, здесь стоит выставить 1 день, чтобы пользователи могли сами сменить пароль в случае его взлома (иначе его менять придётся администратору);
• Password must meet complexity requirements (Пароль должен отвечать требованиям сложности) — если эта политика включена, пользователь не может использовать имя учётной записи в пароле (не более 2-х символов подряд из username (имени пользователя) или Firstname (имени)), также в пароле необходимо использовать 3 типа символов: цифры (0–9), прописные буквы, строчные буквы и специальные символы ($, #,% и так далее). Также, чтобы предотвратить использование слабых паролей (из словаря паролей), рекомендуется регулярно проверять пароли пользователей в домене AD;
• Store passwords using reversible encryption (Хранить пароли, используя обратимое шифрование) – пароли пользователей хранятся в зашифрованном виде в базе данных AD, но в некоторых случаях вам необходимо предоставить доступ к паролям пользователей для некоторых приложений. Если этот параметр политики включён, пароли менее защищены (почти обычный текст). Это небезопасно (злоумышленник может получить доступ к базе данных паролей, если контроллер домена скомпрометирован; контроллеры домена только для чтения (RODC) могут использоваться в качестве одной из мер защиты).

Если пользователь попытается изменить пароль, который не соответствует политике паролей в домене, появится сообщение об ошибке:

Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.

В русскоязычной версии сообщение звучит так:

Введённый пароль не отвечает требованиям политики паролей. Укажите более длинный или сложный пароль.

Кроме того, в разделе GPO Account Lockout Password («Политика блокировки учётной записи») должны быть настроены следующие параметры пароля:

• Account Lockout Threshold (Пороговое значение блокировки) – количество неудачных попыток входа в систему (с неправильным паролем), которое может быть выполнено пользователем до блокировки его учётной записи;
• Account Lockout Duration (Продолжительность блокировки учётной записи) — как долго будет заблокирована учётная запись, если пользователь несколько раз ввёл неверный пароль;
• Reset account lockout counter after (Время до сброса счётчика блокировки) — количество минут, по истечении которых счётчик порога блокировки учётной записи будет сброшен.

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

Параметры политик паролей по умолчанию в домене AD перечислены в таблице ниже:

В Security Compliance Toolkit (наборе средств обеспечения соответствия требованиям безопасности) Microsoft рекомендует использовать следующие параметры политики паролей:

• Использовать историю паролей: 24
• Максимальный срок действия пароля: не установлен
• Минимальный возраст пароля: не установлен
• Минимальная длина пароля: 14
• Пароль должен соответствовать сложности: Включено
• Хранить пароли с использованием обратимого шифрования: Отключено

В недавней рекомендации Security Baseline 1903 Microsoft указывает, что нет необходимости включать политику истечения срока действия пароля для пользователей. Истечение срока действия пароля не увеличивает безопасность, а только создаёт ненужные проблемы (ссылка).

Как проверить текущую политику паролей в домене AD

Вы можете увидеть текущие параметры политики паролей в Default Domain Policy в консоли gpmc.msc (на вкладке Settings «Параметры»).

Вы также можете отобразить информацию о политике паролей с помощью PowerShell (на компьютере должен быть установлен Модуль Active Directory для PowerShell):

Get-ADDefaultDomainPasswordPolicy

ComplexityEnabled           : True
DistinguishedName           : DC=ds,DC=hackware,DC=ru
LockoutDuration             : 00:30:00
LockoutObservationWindow    : 00:30:00
LockoutThreshold            : 0
MaxPasswordAge              : 42.00:00:00
MinPasswordAge              : 1.00:00:00
MinPasswordLength           : 7
objectClass                 : {domainDNS}
objectGuid                  : 15bedbc4-3236-46fb-b01b-5bf1f0a49ba7
PasswordHistoryCount        : 24
ReversibleEncryptionEnabled : False

Кроме того, вы можете проверить текущие параметры политики паролей AD на любом компьютере домена с помощью команды GPResult.

Несколько политик паролей в домене Active Directory

Контроллер домена, владелец FSMO роли эмулятора PDC, отвечает за управление политикой паролей домена. Для редактирования настроек Default Domain Policy требуются права администратора домена.

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

Политика паролей домена влияет только на объекты AD типа User (пользователь). Пароли объектов Computer, обеспечивающие доверительные отношения домена, имеют собственные параметры GPO.

До Active Directory в Windows Server 2008 можно было настроить только одну политику паролей для каждого домена. В более новых версиях AD вы можете создать несколько политик паролей для разных пользователей или групп с помощью Fine-Grained Password Policies (FGPP) (детальных политик паролей). Детализированные политики паролей позволяют создавать и применять различные объекты параметров пароля (PSO). Например, вы можете создать PSO с увеличенной длиной или сложностью пароля для учётных записей администратора домена или сделать пароли некоторых учётных записей более простыми или даже полностью отключить их.

В 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)