Пароли в домене windows

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

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

Настройки политика паролей пользователей в домене AD по умолчанию задаются через групповую политику Default Domain Policy. Вы можете просмотреть и изменить настройки парольной политики в домене с помощью консоли управления консоль управления доменными GPO

1. Откройте консоль
   gpmc.msc
   и выберите Default Domain Policy, которая назначена на корень домена;
2. Щелкните правой кнопкой по Default Domain Policy и выберите Edit;
   

   Картинка с сайта: winitpro.ru

3. Разверните Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политика паролей (Computer configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy
4. В этом разделе есть шесть параметров политики паролей (описаны ниже);
5. Чтобы изменить настройки параметра, дважды щелкните по ней. Чтобы включить политику, отметьте галку Define this policy settings и укажите необходимую настройку (в примере на скриншоте я задал минимальную длину пароля пользователя 8 символов). Сохраните изменения;
   

   Картинка с сайта: winitpro.ru

6. Новые настройки парольной политики применяться ко всем пользователям домена после обновления настроек GPO на контролере домена с FSMO ролью PDC Emulator.

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

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

• Вести журнал паролей (Enforce password history) – задать количество старых паролей, которые хранятся в AD. Пользователь не сможет повторно использовать старый пароль (однако администратор домена или пользователь, которому делегированы права на сброс пароля в AD, может вручную задать для аккаунта старый пароль);
• Максимальный срок действия пароля (Maximum password age) – срок действия пароля в днях. После истечения срока действия пароля Windows потребует у пользователя сменить его. Обеспечивает регулярность смены пароля пользователями;
• Минимальный срок жизни пароля (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). При включении этой опции нужно дополнительно защищать пароли привилегированных пользователей на удаленных площадках с помощью внедрения Read-Only контроллеров домена (RODC).

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

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

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

Картинка с сайта: winitpro.ru

Обычно вместе с политикой паролей нужно настроить параметры блокировки пользователей при неправильном введении пароля. Эти настройки находятся в разделе GPO: Политика блокировки учетной записи (Account Lockout Password):

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

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

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

Управление параметрами политики паролей AD с помощью PowerShell

Для просмотра настроек и изменения конфигурации политики паролей в AD можно использовать командлеты PowerShell из модуля Active Directory:

Вывести настройки дефолтной политики паролей:

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 : 
PasswordHistoryCount : 24
ReversibleEncryptionEnabled : False

Картинка с сайта: winitpro.ru

Или с помощью команды:
net accounts

Картинка с сайта: winitpro.ru

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

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

net user aivanov /domain

Изменить параметры политики паролей AD:

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

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

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

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

1. Откройте консоль Active Directory Administrative Center (
   dsac.exe
   );
2. Перейдите в раздел System -> Password Settings Container и создайте новый объект PSO (Password Settings Object);
   

   Картинка с сайта: winitpro.ru

3. В открывшемся окне укажите название политики паролей и ее приоритет. Включите и настройте параметры парольной паролей, которые вы хотите применить. В разделе Directly Applies to нужно добавить группы или пользователей, для которых должны применяться ваши особые настройки политики паролей.
   

   Картинка с сайта: winitpro.ru

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

Get-ADUserResultantPasswordPolicy -Identity aivanov

Картинка с сайта: winitpro.ru

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

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

Политика паролей по умолчанию

Из штатных средств в Active Directory для управления паролями есть только групповые политики. По умолчанию настройки паролей располагаются в дефолтной политике домена (Default Domain policy), в разделе Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy.

С помощью политики можно задавать минимальную длину и сложность пароля. Но если с длиной все понятно, то к сложности есть вопросы.

Картинка с сайта: windowsnotes.ru

За сложность пароля отвечает параметр Password must meet complexity requirements (Пароль должен соответствовать требованиям сложности), и его можно либо включить, либо выключить. Произвольно управлять требованиями нельзя, они зашиты в фильтре паролей passfit.dll.

Сами требования выглядят так:

• Пароли не могут содержать имя учетной записи (samAccountName) или отображаемое имя (displayName), без учета регистра символов.
• SamAccountName проверяется полностью, только чтобы определить, является ли оно частью пароля. Если samAccountName имеет длину менее трех символов, это проверка пропускается.
• DisplayName анализируется на наличие разделителей: запятые, точки, дефисы, символы подчеркивания, пробелы, знаки фунта и табуляции. Если какой-либо из этих разделителей найден, displayName разделяется и все проанализированные разделы проверяются на то, что они не будут включены в пароль. Разделы меньше трех символов игнорируются. Например, имя «Vasily I. Pupkin» делится на три части: «Vasily», «I» и «Pupkin». Так как вторая часть имеет длину всего в один символ, она игнорируется. Таким образом, у этого пользователя не может быть пароля, который включал бы в себя «vasily» или «pupkin».
• Пароли должны содержать символы трех из пяти следующих категорий.

Эти требования довольно легко обойти, например всем известные P@$$w0rd или 1Qwe2wsx отлично проходят по критериям сложности. Конечно можно увеличить минимальную длину паролей, скажем до 15 символов. Это заметно повысит надежность паролей, но вызовет у большинства пользователей сложности, поэтому на практике обычно устанавливают минимальную длину 8-10 символов.

Поиск слабых паролей

Для начала немного теории.

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

В Active Directory пароль пользователя не хранится в открытом виде, а сохраняются в виде хеша. Если точнее, то используется два типа хешей — хэш LM и хэш NT. Оба хэша имеют одинаковую длину 16 байт, но различаются в способе их вычисления. Процедура создания хеша LM следующая:

• Пароль пользователя преобразовывается в верхний регистр;
• Если пароль пользователя меньше 14 символов, он дополняется пустыми символами до 14. Если же пароль больше 14 символов, то Windows не использует этот хэш, предпочитая ему хэш NT;
• Затем пароль разбивается на две строки по 7 символов, и каждая строка используется в качестве ключа для шифрования строки KGS!+#$% с использованием криптографического алгоритма DES;
• Полученные два хэша объединяются, в результате получается хэш LM.

Хеш NT вычисляется путем применения алгоритма MD4 непосредственно к паролю пользователя в кодировке UTF-16.

Для наглядности пример хешей:

Password: 12345678
LM hash: 0182BD0BD4444BF836077A718CCDF409
NT hash: 259745CB123A52AA2E693AAACCA2DB52

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

Хеши паролей хранятся в базе данных ntds.dit (в атрибутах unicodePwd, dBCSPwd, lmPwdHistory, ntPwdHistory и extramentalCredentials). По соображениям безопасности эти атрибуты недоступны для чтения обычными средствами администрирования. Но мы сможем добраться до них с помощью специального PowerShell модуля Directory Services Internals (DSInternals).

Модуль опубликован в PowerShell Gallery и его можно  установить командой:

Install-Module -Name DSInternals

Как вариант, модуль можно скачать с GitHub, распаковать в любую папку и импортировать вручную, например:

Import-Module C:\PSModules\DSInternals\DSInternals.psd1

Этот модуль содержит ряд командлетов, которые позволяют выполнять различные нестандартные операции с Active Directory, причем как в онлайн, так и в офлайн режиме (непосредственно с базой ntds.dit). Вывести список доступных командлетов можно командой:

Get-Command -Module DSInternals

Картинка с сайта: windowsnotes.ru

Для получения хэша воспользуемся коммандлетом Get-ADReplAccount. Для примера выведем информацию по одному пользователю:

Get-ADReplAccount -SamAccountName ivanov_i -Server Test-DC

Картинка с сайта: windowsnotes.ru

Как видите, Get-ADReplAccount умеет  извлекать из AD множество интересной информации:

• Наименование учетной записи в различных форматах (DistinguishedName, SID, GUID, SAMAccountname, PrincipalName);
• Свойства учетной записи, хранящиеся в атрибуте UserAccountControl;
• Историю NTLM-хешей пароля учетной записи;
• Историю LM-хешей пароля учетной записи;
• Историю хешей пароля для kerberos аутентификации;
• Предварительно вычисленные хэш-формы, используемые в протоколах дайджест-аутентификации;
• Если включен флаг обратимого шифрования, то добавляется строка с паролем в открытом виде.

Примечание. По сути своей с помощью Get-ADReplAccount производится атака DCSync – атака, позволяющая выдавать себя за контроллер домена с целью получения учетных данных пользователей. В основе атаки лежит механизм, предназначенный для выполнения репликации данных между контроллерами домена. Компания Microsoft рекомендует устанавливать как минимум два и более контроллера для одного домена в корпоративной сети, чтобы обеспечить избыточность и, как следствие, повысить отказоустойчивость доменной инфраструктуры. Механизм репликации данных архитектурно заложен в операционной системе Windows, а службы Active Directory с помощью протокола MS-DRSR обеспечивают взаимодействие между контроллерами домена и осуществляют репликацию. В процессе репликации данных между контроллерами помимо обычных атрибутов объекта (имя, фамилии, списка групп и т.п.) передается и чувствительная информация, например, хеши паролей пользователей, поскольку каждый контроллер выступает как точка для аутентификации и авторизации в домене. Именно из-за наличия такого механизма возможна реализация атаки типа DCSync. Атакующий, имея необходимый набор привилегий, может отправить одному из контроллеров домена организации запрос на выполнение репликации, запросив при этом информацию по одному или нескольким объектам в домене. Таким образом можно удаленно собрать хеши паролей пользователей и другую полезную информацию в домене без выполнения какого-либо вредоносного кода на самих контроллерах домена.

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

Qwewsx123
P@$$w0rd
1qaz2wsx

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

Get-ADReplAccount -All -Server Test-DC -NamingContext "DC=Test,DC=local" | Test-PasswordQuality -WeakPasswordFile "C:\PSModuels\dict.txt" -IncludeDisabledAccounts

В результате получим пользователей, пароли которых совпадают с паролями из нашего списка, а также много другой интересной информации, например пользователей с одинаковыми паролями, пользователей с пустыми паролями (Password Not Required) или тех, у кого пароли которых никогда не истекают (Password Never Expires).

Картинка с сайта: windowsnotes.ru

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

$pwd = ConvertTo-SecureString "QweWsx123" -AsPlainText -Force
ConvertTo-NTHash $pwd

А теперь сравним с хешем одного из пользователей. Как видите, они совпадают.

Картинка с сайта: windowsnotes.ru

Чтобы не изобретать велосипед, можно скачать готовый список слабых\скомпрометированных (pwned) паролей, например вот здесь https://haveibeenpwned.com/Passwords. Список содержит более 500 миллионов записей и постоянно обновляется.

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

Чтобы инсталлятор смог найти нужный пакет, добавляем источник:

dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org

и устанавливаем утилиту командой:

dotnet tool install --global haveibeenpwned-downloader

Картинка с сайта: windowsnotes.ru

Список немаленький, поэтому загружать его лучше в несколько потоков. Например следующая команда выгрузит все NT-хэши в один текстовый файл с именем pwnedpasswords_ntlm.txt, используя 64 потока, перезаписывая файл, если он уже существует:

haveibeenpwned-downloader.exe C:\HIBP\pwnedpasswords_ntlm -n -o -p 64

Картинка с сайта: windowsnotes.ru

После загрузки можем сравнить список скомпрометированных паролей с паролями наших пользователей. Для этого выгрузим из AD хэши паролей в файл командой:

Get-ADReplAccount -All -Server Test-DC -NamingContext "DC=Test,DC=local" | Format-Custom -View HashcatNT | Out-File C:\HIBP\AllHashes.txt -Encoding ASCII

Картинка с сайта: windowsnotes.ru

Для следующего шага нам потребуется  PowerShell модуль Match-ADHashes. Загружаем его и импортируем в текущий сеанс:

Import-Module C:\PSModules\Match-ADHashes.ps1

Сравниваем хэши пользователей со списком:

$list = Match-ADHashes -ADNTHashes C:\HIBP\AllHashes.txt -HashDictionary C:\HIBP\pwnedpasswords_ntlm.txt

Форматируем результат и выгружаем его в CSV-файл:

$list | select Hash,Frequency,@{Name=’user’;Expression={[string]::join(“;”, ($_.user))}} | Export-Csv -Path C:\HIBP\pwned-users-report.csv -Delimiter ‘;’ -NoTypeInformation

Картинка с сайта: windowsnotes.ru

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

Картинка с сайта: windowsnotes.ru

В боевой среде список будет гораздо больше. И тут встает вопрос — а что с ним делать дальше? Можно пройтись по списку и всех кто в него вошел жестоко наказать принудительно заставить сменить пароль. Но гораздо эффективнее будет запретить использование паролей, входящих в этот список. О том, как это сделать, я расскажу в следующей статье.

Password policies are a foundational element of any organization’s security posture, especially in environments managed by Active Directory (AD). These policies help ensure that user credentials meet baseline complexity requirements, reducing the risk of unauthorized access. However, understanding and verifying these requirements—especially with the introduction of fine-grained password policies (FGPP)—can be challenging for IT administrators.

Active Directory password policies are not always what they seem – often there are discrepancies on settings such as password length, password complexity, maximum password age, or long-forgotten Fine-Grained Password Policies configured in the domain. In this guide, we’ll walk through the different ways to check and manage password complexity settings in Active Directory. Whether you’re troubleshooting login issues, auditing security settings, or looking to align with best practices, this article will help you gain clarity and control over your AD password policy landscape.

Understand password policy settings in Active Directory

To ensure password polices are correctly implemented, the sysadmin must first understand the available password policy settings. In Active Directory, there are six available policies.

Enforce password history – with an eye to preventing password reuse, this policy determines how many previous passwords are stored in Active Directory and thus prevented from being set as a password in future.

Maximum password age – sets the maximum length of time a user may go between password resets.

Minimum password length – while the minimum recommended password length is 8 characters, it may also be set at 0. If set at 0, no password will be required.

Minimum password age – prevents users from resetting their password too frequently, perhaps in an attempt to cycle back to an easily remembered password used before.

Password must meet complexity requirements – if the policy is enabled, a user cannot use the account name in a password; 3 types of symbols must be used in the password. Those symbols include: numbers (0–9), uppercase letters, lowercase letters and special characters ($, #, %, etc.).

Store passwords using reversible encryption – user passwords are stored encrypted in the AD database, but in some cases you have to grant certain apps access to user passwords. If this policy setting is enabled, passwords are less protected (almost plain text).

Managing password complexity in Active Directory

Active Directory password policies are typically configured through the Default Domain Policy using the Group Policy Management Console (GPMC), or more granularly using Fine-Grained Password Policies (FGPPs). These policies define requirements such as minimum length, complexity, and history.

Password complexity, when enabled, requires that passwords include characters from at least three of the following categories:

• Uppercase letters (A–Z)
• Lowercase letters (a–z)
• Numbers (0–9)
• Special characters (e.g., !, $, #, %)
• Unicode characters (including non-Latin characters)

To check the current domain password policy using PowerShell, run:

powershellCopyEditGet-ADDefaultDomainPasswordPolicy

This command will return key attributes like:

• MinPasswordLength
• PasswordHistoryCount
• ComplexityEnabled
• LockoutThreshold
• MaxPasswordAge

If your environment uses Fine-Grained Password Policies (FGPPs), you can retrieve those settings with:

powershellCopyEditGet-ADFineGrainedPasswordPolicy

These cmdlets provide accurate, domain-level insight into your password settings—unlike older utilities like net accounts, which only report local policy information and can be misleading in a domain environment.

While Active Directory enforces traditional complexity rules by default, it’s worth noting that modern standards, such as NIST 800-63B, no longer recommend complexity requirements due to usability concerns. If you’re aiming to meet current best practices or compliance requirements, consider third-party tools that offer more flexible and user-friendly password policy enforcement.

Active Directory Default Domain Password Policy

This password policy is the default (and prior to Windows 2008 and the introduction of Fine-Grained Password Policies, the only) password policy for users in the domain.

Картинка с сайта: specopssoft.com

Typically (and by default in a new AD Domain) the built-in Default Domain Policy GPO is used to set the Active Directory password policy as shown in the screenshot above.

However, an important distinction to note is that this GPO only sets the policy in Active Directory. When user passwords are being set AD is not looking at Group Policy but rather at attributes of the root domain object in AD; it is always a good idea to double-check these values to ensure the password policy is set properly.

Let’s look at these attributes using PowerShell.  The first command looks at the actual attribute names; the second looks at the same attributes but gives us clearer names and translates the time values e.g. maxPwdAge to a format we can easily understand:

get-addomain | get-adobject -properties * | select *pwd*

Картинка с сайта: specopssoft.com

Get-ADDefaultDomainPasswordPolicy

Картинка с сайта: specopssoft.com

In most environments the output here will match what is in the Default Domain Policy. In case they do not, we must fully unpack what AD is doing here:

The password policy is read from Group Policy and applied to these attributes by the domain controller holding the PDC emulator role when it runs gpupdate. But the settings do not have to come from the built-in Default Domain Policy. In reality, these are the criteria for a password policy GPO:

• The GPO must be linked to the root of the domain
• The GPO must be applied to the PDC emulator computer account

If your domain password policy does not line up with the Default Domain Policy GPO, look for another GPO linked at the domain root with password policy settings, and blocked Inheritance on the Domain Controllers OU.

How to enable multiple password policies in Active Directory

If multiple GPOs linked at the root have a password policy setting, the GPO with the highest link order will take precedence for that particular setting. Check all GPOs linked at the root for Password Policy settings. For example, here we have added a second GPO called ‘Domain Password Policy’ with a higher link order than the Default Domain Policy and password policy settings. Password Policy settings in this GPO will override those in the Default Domain Policy.

Картинка с сайта: specopssoft.com

Картинка с сайта: specopssoft.com

After making this change and running a gpupdate on the PDC, we can see password complexity is now enabled as per the Domain Password Policy GPO:

Blocked Inheritance on the Domain Controllers OU

If Inheritance is blocked on the domain controllers OU, password policy settings from policies linked at the root of the domain will be ignored. In this example we have blocked inheritance on the domain controllers OU and can confirm the Default Domain Policy are not in the Group Policy Inheritance list – this means password policy settings changes in that GPO will be ignored and whatever the current password policy is will be ‘tattooed’ on the domain.

Картинка с сайта: specopssoft.com

Oddly enough, linking the GPO directly to the domain controllers OU has no effect. The solutions here are either to remove the blocked inheritance on the domain controllers OU or set the link at the root of the domain to ‘enforced’ (which overrides blocked inheritance) – just be mindful of other settings in these GPOs when making changes to inheritance/enforced links. Either way, as long as the policy appears in the Group Policy Inheritance list the settings should take effect.

Картинка с сайта: specopssoft.com

Keep in mind when troubleshooting password policy GPOs in AD you must run gpupdate on the PDC emulator for each change to take effect.

Fine-Grained Password Policies

In Windows 2008 Microsoft introduced the Fine-Grained Password Policies (FGPP) feature, enabling administrators to configure different password policies based on Active Directory security groups.

Note: We sometimes find administrators attempting to set multiple password policies in AD by creating additional GPOs with Password Policy settings and applying them to user OUs.  This does not work in Active Directory; GPOs with Active Directory Password Policy settings linked anywhere but the root of the domain have no effect whatsoever on user password requirements.  The reasoning makes sense in some way – Password Policy settings appear under the ‘computer settings’ scope and thus have no bearing on user objects.  Still, it is at best a counterintuitive design by Microsoft.

Specops Password Policy, on the other hand, uses user-based GPO setting and does directly apply password policy setting objects to user objects where it is applied, making for a much more intuitive administrative experience.

To create or view fine-grained password policies, you can use ADSIEdit, PowerShell, or the Active Directory Administrative Center.

Fine-grained password policy objects are stored under System\Password Settings Container in AD. As fine-grained password policies are not in Group Policy there is no gpupdate required when making changes; they take effect as soon as the settings are configured (excluding any delays in replication among your domain controllers).

Here we have a domain with a single fine-grained policy applied to the Domain Admins group:

Картинка с сайта: specopssoft.com

Картинка с сайта: specopssoft.com

To view the policy in PowerShell:

get-adfinegrainedpasswordpolicy -filter *

Картинка с сайта: specopssoft.com

For members of the groups listed in the ‘applies to’ attribute of the fine-grained password policy, both the password policy and account lockout settings in the fine-grained policy will replace those in the default domain password policy. In case of multiple fine-grained policies applied to any particular user, the precedence value set within each FGPP determines which policy would win.

To confirm which fine-grained policy is applied to a user, search for them in the Global Search in the Active Directory Administrative Center then choose ‘view resultant password settings’ from the tasks menu.

Картинка с сайта: specopssoft.com

Or using PowerShell:

Get-ADUserResultantPasswordPolicy username

Картинка с сайта: specopssoft.com

Note if this command does not return any results the user is affected by the default domain password policy and not a fine-grained policy.

Note: Fine-Grained Password Policies can only be applied to individual users or Active Directory Global groups.  The Active Directory admin tools will happily allow you to add a Universal or Domain Local group to the list of groups the policy applies to, however those groups will be ignored when it comes to actual enforcement of the fine-grained policy.  If you find a fine-grained password policy is not applying to a group as expected, double-check the group scope in Active Directory Users and Computers and ensure it is set to Global.

Картинка с сайта: specopssoft.com

More control for specific users with FGPP

While traditional domain password policies apply to all users in a domain, Fine-Grained Password Policies (FGPPs) allow you to apply different password and lockout settings to specific users or groups. This is especially useful when you want stricter policies for high-privilege accounts or service accounts.

Viewing FGPPs with PowerShell

To list existing FGPPs, use:

powershellCopyEditGet-ADFineGrainedPasswordPolicy

To see which users/groups a policy applies to:

powershellCopyEditGet-ADFineGrainedPasswordPolicy | Select-Object Name, Precedence, AppliesTo

You can also view detailed policy settings like so:

powershellCopyEditGet-ADFineGrainedPasswordPolicy -Identity "PolicyName" | Format-List

Precedence matters

FGPPs include a precedence value—the lower the number, the higher the priority. If a user is targeted by multiple policies (e.g., they’re in two groups with different FGPPs), the policy with the lowest precedence wins.

Example:

• AdminGroupPolicy (precedence 10)
• ServiceAccountPolicy (precedence 20)

If a user is in both groups, they’ll get the AdminGroupPolicy.

Managing FGPPs in the GUI

You can also manage FGPPs through Active Directory Administrative Center (ADAC):

• Open ADAC
• Navigate to System > Password Settings Container
• From here, you can create, view, or edit FGPPs
• Use the “Applies To” field to assign policies to users or groups

Common pitfalls

• Not enforced unless assigned: FGPPs don’t apply unless explicitly linked to a user or group.
• Domain policy still exists: If a user isn’t targeted by an FGPP, the Default Domain Policy still governs their password settings.
• Confusing results: Use Resultant Set of Policy tools or PowerShell to troubleshoot effective settings.

When should you use FGPPs?

• You want stricter policies for admins, but looser rules for general staff
• You’re managing accounts with service credentials that require longer max ages
• You’re aligning with compliance policies that require segmentation of security controls

While Active Directory provides basic controls over password complexity and length, its capabilities are limited when it comes to enforcing modern best practices—like banning breached passwords, preventing predictable patterns, or offering dynamic feedback during password creation.

Specops Password Policy extends the native functionality of Active Directory, giving you more powerful, flexible, and compliant password enforcement without complex scripting or infrastructure changes.

With Specops Password Policy, you can:

• Enforce password rules that block leaked, common, or custom blacklisted passwords
• Provide real-time feedback to users as they create passwords
• Meet compliance requirements like NIST, NCSC, and PCI-DSS
• Apply policies based on group membership—without relying solely on FGPPs
• continuousyky scan your AD against our database of over 4 billion compromised passwords

Try Specops Password Policy for free.

Best practices:

• Regular reviews & updates:
  Routinely audit AD password policies to ensure they keep pace with evolving security threats and compliance requirements.
• Balance usability and security:
  Strike a balance between password complexity and user convenience to minimize support calls without sacrificing strength. Consider using passphrases instead of passwords.
• Leverage FGPPs:
  Use Fine-Grained Password Policies for high-risk groups (like admin accounts) while retaining simpler rules for general users.
• Implement Multi-Factor Authentication (MFA):
  Complement robust password policies with MFA to enhance overall security.

Common pitfalls:

• Overcomplicating policies:
  Excessively strict or complex rules can frustrate users and lead to increased support issues.
• Policy overlap:
  Conflicts between the Default Domain Policy and FGPPs can cause unintended behavior—regularly validate policy precedence with tools like RSOP.
• Neglecting end-user communication:
  Failing to explain policy changes can create confusion; clear, proactive communication is key. You can find a full guide to communicating policy changes here.

Possible future trends:

• Passwordless authentication:
  Organizations may explore passwordless alternatives like biometrics and one-time codes, which are increasingly adopted to reduce reliance on traditional passwords.
• Adaptive authentication:
  Look into systems that adjust security measures dynamically based on user behavior and contextual risk assessment.
• Enhanced user education:
  As trends shift, empower users with the knowledge to navigate new authentication methods, ensuring smoother transitions and sustained security.

Audit your Active Directory today

While it is definitely good to understand how your Active Directory password settings are put together, Specops Password Auditor is a read-only tool that can offer a view into your current Active Directory password policies, their scope, and how they stack up against a number of compliance requirements or recommendations. Password Auditor is available as a free download.

Картинка с сайта: specopssoft.com

Картинка с сайта: specopssoft.com

Download Specops Password Auditor for free.

FAQs