Изменить политику паролей windows server 2008 r2 - Доктор Windows

Здесь будет рассказано как изменить политику паролей в Windows Server 2008. По умолчанию все пароли в Windows должны отвечать политике безопасности, а именно:

Не содержать имени учетной записи пользователя или частей полного имени пользователя длиной более двух рядом стоящих знаков.
Иметь длину не менее 6 знаков.
Содержать знаки трех из четырех перечисленных ниже категорий:
1. Латинские заглавные буквы (от A до Z)
2. Латинские строчные буквы (от a до z)
3. Цифры (от 0 до 9)
4. Отличающиеся от букв и цифр знаки (например, !, $, #, %)

Чтобы изменить политику паролей надо зайти в «Пуск» — «Администрирование» — «Локальная политика безопасности»

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

Все, теперь можно использовать любые пароли, но нужно помнить, что это небезопасно.

Запись опубликована в рубрике Windows Server 2008 R2 с метками Windows Server 2008. Добавьте в закладки постоянную ссылку.

Источник

Обновлено 03.12.2014

Здесь будет рассказано как изменить политику паролей в Windows Server. По умолчанию все пароли в Windows должны отвечать политике безопасности, а именно:

Не содержать имени учетной записи пользователя или частей полного имени пользователя длиной более двух рядом стоящих знаков.
Иметь длину не менее 6 знаков.
Содержать знаки трех из четырех перечисленных ниже категорий:
1. Латинские заглавные буквы (от A до Z)
2. Латинские строчные буквы (от a до z)
3. Цифры (от 0 до 9)
4. Отличающиеся от букв и цифр знаки (например, !, $, #, %)

Чтобы изменить политику паролей надо зайти в «Пуск» — «Администрирование» — «Локальная политика безопасности»

Как измененить политики паролей для сервера в Windows Server 2008 R2-01

В открывшейся оснастке раскрываем ветку «Политика учетных записей» и «Политику паролей». Здесь мы можем изменять несколько параметров, в частности отключить политику «Пароль должен отвечать требованиям сложности» или gpedit.msc

Как измененить политики паролей для сервера в Windows Server 2008 R2-02

Можно так же этот параметр задать и через групповые политики, идем в оснастку gpmc.msc. Конфигурация компьютера-Конфигурация Windows-Параметры безопасности-Политики учетных записей-Политики паролей

Как измененить политики паролей для сервера в Windows Server 2008 R2-03

Дек 3, 2014 22:43

Источник

Политика паролей является первоосновой в безопасной IT-инфраструктуры компании. Пароли должны содержать прописные и заглавные буквы, цифры и спецсимволы, иметь определенный срок действия и состоять минимум из восьми символов.

Как изменить политику паролей:

Открываем нужную нам групповую политику.
Нам нужна ветка Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Политика паролей (Рис.1).

Здесь мы можем изменять следующие параметры:

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

Рис.1.

Успехов!

Источник

2 августа
2013

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

Иметь длину не менее 6 знаков.
Содержать знаки трех из четырех перечисленных ниже категорий:
1. Латинские заглавные буквы (от A до Z)
2. Латинские строчные буквы (от a до z)
3. Цифры (от 0 до 9)
4. Отличающиеся от букв и цифр знаки (например, !, $, #, %)

Чтобы изменить политику паролей надо зайти в «Пуск» — «Администрирование» — «Локальная политика безопасности»

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

Все, теперь можно использовать любые пароли, но нужно помнить, что это небезопасно.

Источник: Сайт

Опубликовано 2 августа, 2013 Кирилл в категории «Servers

Источник

Благодаря детальным политикам паролей Windows Server 2008 можно назначать различные политики паролей разным категориям пользователей в домене. В статье «Политики паролей Windows Server 2008», Жан де Клерк объясняет, как с помощью политик паролей Windows установить требования к качеству паролей учетных записей пользователей, и отмечает, что Windows Server 2003 и Windows 2000 Server позволяют задавать только одну политику паролей, применяемую ко всем учетным записям пользователей в домене. Однако в Windows Server 2008 это ограничение устранено. Поняв, как использовать политики паролей Windows в Server 2008, можно развернуть детальные политики паролей, назначая разные политики различным категориям пользователей в домене.

Использование теневых групп

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

В Windows Server 2008 группы безопасности можно использовать для назначения детальных политик паролей организационным единицам. Группа типа Shadow Group (теневая группа) просто объединяет группы безопасности, содержащие все пользовательские объекты в конкретной организационной единице.

Существует несколько инструментов, с помощью которых можно создать теневые группы, в том числе Windows PowerShell, LDIFDE и VBScript, но самый простой способ — задействовать встроенные команды службы каталогов AD. Следующая команда выполняет запрос к пользовательским объектам в организационной единице отдела кадров (HR) в домене с именем ad.mycompany.com.

dsquery user ou=hr, dc=ad, dc=mycompany, dc=com | dsmod group cn=hr_ou_users, ou=groups, dc=ad, dc=mycompany, dc=com -chmbr

Эта команда также изменяет членство существующей глобальной группы безопасности, hr_ou_users, которая находится в OU, именуемой groups, отражая результаты начального пользовательского запроса. Команда dsquery используется для запуска запросов LDAP, направленных к AD. В этом примере пользователь указывает тип искомого объекта; результаты ограничиваются объектами в организационной единице HR. Команда dsmod изменяет существующие объекты AD; group указывает тип изменяемого объекта, а следом указывается точное местоположение в AD. Ключ -chmbr заменяет всех членов группы.

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

Только администраторы домена могут создавать или изменять объекты Password Settings (PSO) и связывать их с группами при стандартных параметрах безопасности AD. Чтобы позволить сотрудникам службы поддержки изменять политику паролей, применяемую к конкретному пользователю, рекомендуется привязать объекты PSO к группам и предоставить администраторам и инженерам возможность перемещать пользователей между группами. Если построить удачную модель делегирования для компании, то специалисты службы поддержки смогут изменить назначенную пользователю политику, не изменяя AD напрямую.

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

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

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

dsget user «cn=administrator, cn=users, dc=ad, dc=com» -effectivepso

В результате выполнения команды будет получен объект PSO, применяемый к учетной записи администратора (если она есть) в следующем формате, где passpol_Admins — имя эффективного PSO:

effectivepso «CN=passpol_Admins, CN=Password Settings Container, CN=System, DC=ad, DC=mycompany, DC=com» dsget succeeded

Если выбрать пункт Advanced Features из меню View в оснастке Active Directory Users and Computers консоли Microsoft Management Console (MMC), можно также выяснить значение атрибута msDS-ResultantPSO, обнаружив пользовательский объект с помощью графической оболочки. Щелкните правой кнопкой мыши на имени пользователя, выберите пункт Properties и перейдите на вкладку Attribute Editor. Чтобы увидеть атрибут msDS-ResultantPSO, щелкните Filter на вкладке Attribute Editor и добавьте Constructed в разделе Show read-only attributes. Этот метод может быть самым подходящим для начинающих сотрудников службы поддержки.

Создание объектов PSO с помощью PowerShell

Компания Microsoft не предоставляет инструментов графического интерфейса для создания объектов PSO. Добавлять объекты PSO в AD можно не только с помощью стандартных инструментов, таких как ADSI Edit или ldp.exe. Компания Quest Software предоставляет бесплатный набор команд PowerShell как часть оболочки ActiveRoles Management Shell for Active Directory, используя который можно администрировать AD. В наборе предусмотрено несколько команд для управления объектами PSO. Эти команды также могут пригодиться для автоматизации процесса создания PSO. Перед загрузкой и установкой команд необходимо установить PowerShell и .NET Framework.

Зарегистрируйтесь как администратор домена и запустите PowerShell из меню Start.
Для работы с новыми командами из PowerShell выполните команду

add-pssnapin quest.activeroles. admanagement

Чтобы создать новый объект PSO для администраторов домена, введите

new-qadpasswordsettingsobject -name

- admins
  precedence 10-passwordhistorylength 5
  passwordcomplexityenabled $true
  minimumpasswordlength 6
Чтобы применить политику к группе Domain Admins, введите

add-qadpasswordsettingsobjectappliesto admins -appliesto ‘addomain admins’

Убедитесь, что объект PSO admins связан с группой Domain Admins, и все другие атрибуты установлены корректно:

get-qadpasswordsettingsobject | format-list

как показано на экране 1.

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

get-qaduser administrator -includedproperties msds-resultantpso | format-list name, msds-resultantpso

Введите следующую команду, чтобы удалить административный PSO:

remove-qadobject admins

Перед удалением PSO будет выдан запрос на подтверждение.

Создание объектов PSO с помощью Specops

Еще вместо ADSI Edit или командной строки при создании объектов PSO может использоваться инструмент Specops Password Policy Basic компании Special Operations Software. Его можно бесплатно загрузить по адресу www.specopssoft.com/wiki/index.php/SpecopsPasswordPolicyBasic/Download.

В простом интерфейсе Password Policy Basic можно создавать, редактировать и удалять объекты PSO. Создавать объекты PSO имеют право только администраторы домена, но специалисты службы поддержки могут воспользоваться средством Lookup password policy for user консоли MMC для просмотра приоритета PSO, как показано на экране 2.

Зарегистрируйтесь как администратор домена и запустите Password Policy Basic из меню Start.
В разделе Connected domains убедитесь, что домен есть в списке. В этом случае подключенный домен — ad.com. Щелкните на кнопке Configure selected domain.
Политика паролей по умолчанию домена будет показана в правой области MMC. Щелкните New password policy, чтобы создать новый объект PSO. Дайте политике имя Administrators.
Настройте нужные параметры для PSO в разделах Password policy settings и Account lockout settings, как показано на рисунке.
Щелкните Add member внизу справа от диалогового окна Password policy, добавьте группу Domain Admins в окно Select Users or Groups в AD и нажмите OK.
На рисунке ниже показана новая политика Administrators, которая имеет приоритет для пользователей, которые являются членами группы Domain Admins. Если требуется настроить более одного объекта PSO, можно использовать стрелки в правой стороне MMC, чтобы изменить приоритет; самый высокий — у верхнего PSO.
Щелкните Lookup password policy for user и введите слово administrator в диалоговом окне Select Users. Должно появиться сообщение о том, что для учетной записи Administrator действует политика Administrators.

Подождем R2…

Администраторы, которым неудобно использовать встроенные механизмы AD в Server 2008 для работы с детальными политиками паролей, могут использовать для их настройки PowerShell или программы независимых разработчиков с графическим интерфейсом. Но помните: в состав Server 2008 R2 войдет PowerShell 2.0 с командами для управления детальными политиками паролей.

Рассел Смит — независимый ИТ-консультант, специализируется на управлении системами

Журнал «Windows IT Pro», Издательство «Открытые системы» (http://www.osp.ru/)

Источник

What will you do if you’ve forgotten your Windows Server 2008 password from time to time? Prepare a Windows Server 2008 password reset disk or a reset software? Maybe we can put our hands to the setting of password policy. It is generally acknowledged that the password for Windows Server 2008 is relative more complicated and stricter by default than that in other operation systems, with the total quantity of capital letters, lowercase letters and numbers no less than eight. In fact, if you take measures to edit Windows Server 2008 Password policy to disable complexity requirement, the problem will get worked out.

Steps

1

Click “Start” menu on the lower right corner of your desktop, and then go to “Run”.
2

Input “gpedit.msc” (without quotations). Then it appears the Group Policy box.
3

Select “Computer Configuration” under the directory of “Group Policy”, and hit “Local Computer Policy”, and then “Computer Configuration-Windows Settings–Security Settings–Password Policy”.
4

Find in the box “Password must meet complexity requirements”, and then set it as “Disable”.
5

Look for the line “ length” and set it as “0 characters”. If it shows “6 characters” by default, it means your new password should consist of at least 6 words.
6

Set “Minimum password age” as “o days”.
7

Set “Enforce password history” as “o days”.
8

After we finished the above settings, input “gpupdate/force” to force it to refresh group policy.
9

Set your new less complex password.

Add New Question

Question

Can’t change policy. Modification is denied. Any ideas?

Check to make sure that you are logged in as an administrator and try again. If that does not work, then log in with the system administrator account.

Ask a Question

200 characters left

Include your email address to get a message when this question is answered.

Submit

References

About this article

Thanks to all authors for creating a page that has been read 109,191 times.

Is this article up to date?

Источник

Steps

1

Click “Start” menu on the lower right corner of your desktop, and then go to “Run”.
2

Input “gpedit.msc” (without quotations). Then it appears the Group Policy box.
3

Select “Computer Configuration” under the directory of “Group Policy”, and hit “Local Computer Policy”, and then “Computer Configuration-Windows Settings–Security Settings–Password Policy”.
4

Find in the box “Password must meet complexity requirements”, and then set it as “Disable”.
5

Look for the line “ length” and set it as “0 characters”. If it shows “6 characters” by default, it means your new password should consist of at least 6 words.
6

Set “Minimum password age” as “o days”.
7

Set “Enforce password history” as “o days”.
8

After we finished the above settings, input “gpupdate/force” to force it to refresh group policy.
9

Set your new less complex password.

Add New Question

Question

Can’t change policy. Modification is denied. Any ideas?

Check to make sure that you are logged in as an administrator and try again. If that does not work, then log in with the system administrator account.

Ask a Question

200 characters left

Include your email address to get a message when this question is answered.

Submit

References

About this article

Thanks to all authors for creating a page that has been read 109,191 times.

Is this article up to date?

Источник

Настройка параметров пароля в 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:

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

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

Приступим

Сперва, давайте запустим 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 атрибутов. Наберите значение, как показано в таблице ниже (не забудьте ввести знаку минуса для тех значений, где это требуется) или же ввести свои настройки.

Таблица 1

Атрибут	Значение	Краткое описание
Cn	PassPolAdmins	Название политики. Старайтесь присваивать политикам понятные имена, если у вас их будет много.
msDS-PasswordSettingsPrecedence	10	Параметр, используемый в качестве стоимости или приоритета для различных политик на тот случай, если для одного пользователя настраивается несколько политик PSO. Чем выше приоритет у настройки пароля PSO, тем меньше значение этого параметра.
msDS-PasswordReversibleEncryptionEnabled	False	Булевое значение. Верно, если пароль хранится и использованием обратного шифрования (обычно очень полезно)
msDS-PasswordHistoryLength	32	Количество ранее использованных паролей, которое должны помнить система
msDS-PasswordComplexityEnabled	True	Булевое значение. Верно, если вы хотите, чтобы пользователь использовал сложный пароль
msDS-MinimumPasswordLength	16	Минимальное количество символов для пароля для учетной записи пользователя
msDS-MinimumPasswordAge	-864000000000(9 нулей)	Минимальное время жизни пароля (в этом случае 1). Не забудьте поставить знак минус.
msDS-MaximumPasswordAge	-36288000000000(9 нулей)	Максимальное время жизни пароля? (в этом случае 42 дня). Не забудьте поставить знак минус.
msDS-LockoutTreshold	30	Количество попыток ввода неверного пароля после которого учетная запись будет заблокирована
msDS-LockoutObservationWindow	-18000000000(9 нулей)	Через это время счетчик количества попыток ввода неверного пароля будет обнулен (в этом случае 6 минут). Не забудьте поставить знак минус.
msDS-LockoutDuration	-18000000000(9 нулей)	Как долго будет заблокирована учетная запись пользователя при вводе большого количества неверных паролей (в этом случае 6 минут). Не забудьте поставить знак минус.

После завершения ввода этой информации вы увидите следующее диалоговое окно – просто нажмите в нем на кнопку 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 определяется следующим образом:

PSO, которая связана напрямую с пользователем, будет использоваться до тех пор, пока напрямую пользователю не назначено несколько PSO. Если назначено более одной PSO, то результирующей PSO будет PSO с наименьшим значением (msDS-PasswordSettingsPrecedence). Если система обнаружит, что с пользователем связаны две или более PSO с одинаковым значением msDS-PasswordSettingsPrecedence, то будет применена PSO с меньшим значением глобального уникального идентификатора (Global Unique Identifier GUID).
Если ни один 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 и многое другое …

Источник

Как известно, домен в 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.

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

Источник