Раздельные (гранулированные) политики паролей Fine-Grained Password Policies (FGPP) позволяют создать отдельные политики паролей для определенных пользователей или групп. Множественные политики паролей FGPP доступны, начиная с версии Active Directory в Windows Server 2008. В предыдущих версиях AD 2000 можно было создать только одну политику паролей в каждом домене (в рамках Default Domain Policy).
В этой статье мы покажем, как создать и настроить раздельные политики управления паролями (Password Setting Objects) в домене.
Содержание:
- Множественные политики управления паролями — Fine-Grained Password Policies
- Настройка Password Settings Policy в Active Directory
- Настройка политики паролей PSO с помощью PowerShell
Множественные политики управления паролями — Fine-Grained Password Policies
Fine-Grained Password Policies позволяют администратору создать в одном домене несколько специальных политик управления паролями (Password Settings Policy — PSO). В PSO объектах задаются требования к паролям (длина, сложность, история) и настройки блокировки учетных записей. Политики PSO можно назначать на конкретных пользователей или группы, но не на контейнеры (OU) Active Directory. Если к пользователю/группе привязана политика PSO, то настройки парольной политики из GPO Default Domain Policy к нему более не применяются.
С помощью политик FGPP можно задать более высокие требования на длину и сложность пароля для учетных записей администраторов, сервисных учетных записей или пользователей, имеющих внешний доступ в домена (через VPN или DirectAccess).
Основные требования для использования множественных политик паролей FGPP в домене:
- Функциональный уровень домена Windows Server 2008 или выше;
- Парольные политики можно назначить на пользователей или глобальные (!) группы безопасности (global security);
- FGPP политика применяется целиком (нельзя часть настроек описать в GPO, а часть в FGPP).
Настройка Password Settings Policy в Active Directory
Вы можете создавать и редактировать парольные политики Fine-Grained Password Policies из графического интерфейса консоли Active Directory Administration Center (ADAC).
В данном примере мы покажем, как создать и назначить отдельную парольную политику на доменную группу Domain Admins.
Запустите консоль Active Directory Administrative Center (dsac.msc), переключитесь в древовидный вид и разверните контейнер System. Найдите контейнер Password Settings Container, щелкните по нему ПКМ и выберите New -> Password Settings.
Укажите имя политики паролей (например, Password Policy for Domain Admins) и задайте настройки. Все поля стандартные: минимальная длина и сложность пароля, количество хранимых паролей в истории, частота смены пароля, параметры блокировки при неправильном введении пароля и т.д.
Каждый из параметров объекта PSO (класс
msDS-PasswordSettings
) описывается отдельным атрибутом AD:
- msDS-LockoutDuration
- msDS-LockoutObservationWindow
- msDS-LockoutThreshold
- msDS-MaximumPasswordAge
- msDS-MinimumPasswordAge
- msDS-MinimumPasswordLength
- msDS-PasswordComplexityEnabled
- msDS-PasswordHistoryLength
- msDS-PasswordReversibleEncryptionEnabled
- msDS-PasswordSettingsPrecedence
Обратите внимание на атрибут Precedence. Данный атрибут определяет приоритет данной политики паролей. Если на пользователя AD действуют несколько политик PSO, то к нему будет применена политика с меньшим значением в поле Precedence.
Примечание.
- Если на пользователя действуют две PSO политики с одинаковыми значениями Precedence, будет применена политика с меньшим GUID;
- Если на пользователя назначены несколько политик, причем одна из них действует через группу безопасности AD, а вторая – напрямую на учетную запись, то будет применена политика, назначенная на учетку.
Затем в секции Direct Applies To добавьте группы или пользователей, на которых должна действовать политика (в этом примере Domain Admins). Сохраните политику.
Рекомендуется применять политику PSO к группам, а не отдельным пользователям. Создайте отдельную группу безопасности и добавляйте в нее учетные записи пользователей. Это упростит управление.
С этого момента данная парольная политика будет применяться на всех членов группы Domain Admins.
Запустите консоль Active Directory Users and Computers (с установленной опцией Advanced Features) и откройте свойства любого пользователя из группы Domain Admins. Перейдите на вкладку редактора атрибутов (Attribute Editor) и в поле Filter выберите опцию Constructed.
Найдите атрибут пользователя msDS-ResultantPSO. В этом атрибуте указывается действующая на пользователя парольная политика FGPP (
CN=Password Policy for Domain Admins,CN=Password Settings Container,CN=System,DC=winitpro,DC=ru
).
Также действующую политику PSO для пользователя можно получить с помощью dsget:
dsget user "CN=Dmitriy,OU=Admins,DC=winitpro,DC=ru" –effectivepso
Настройка политики паролей PSO с помощью PowerShell
Вы можете управлять политиками паролей PSO с помощью PowerShell (на компьютере должен быть установлен модуль RSAT-AD-PowerShell).
Для создания новой политики используется командлет New-ADFineGrainedPasswordPolicy:
New-ADFineGrainedPasswordPolicy -Name "Admin PSO Policy" -Precedence 10 -ComplexityEnabled $true -Description “Domain password policy for admins”-DisplayName “Admin PSO Policy” -LockoutDuration “0.10:00:00” -LockoutObservationWindow “0.00:20:00” -LockoutThreshold 5 -MaxPasswordAge “12.00:00:00” -MinPasswordAge “1.00:00:00” -MinPasswordLength 10 -PasswordHistoryCount 4 -ReversibleEncryptionEnabled $false
Теперь можно назначить политику на группу пользователей:
Add-ADFineGrainedPasswordPolicySubject "Admin PSO Policy" -Subjects "Domain Admins"
Чтобы изменить настройки политики PSO:
Set-ADFineGrainedPasswordPolicy "Admin PSO Policy" -PasswordHistoryCount:"30"
Вывести все политики FGPP в домене:
Get-ADFineGrainedPasswordPolicy -Filter *
Для получения результирующей парольной политики, которая применяется к конкретному пользователю используется команды. Имя политики PSO, которая действует на пользователя указано в поле Name.
Get-ADUserResultantPasswordPolicy -Identity username
Список политик PSO, назначенных на группу Active Directory, можно вывести с помощью командлета:
Get-ADGroup "Domain Admins" -properties * | Select-Object msDS-PSOApplied
Чтобы вывести настройки политики паролей по-умолчанию из Default Domain Policy, выполните команду:
Get-ADDefaultDomainPasswordPolicy
Fine-Grained Password Policies (FGPP) allow you to create multiple password policies for specific users or groups. Multiple password policies are available starting with the Windows Server 2008 version of Active Directory. In previous versions of AD, you could create only one password policy per domain (using the Default Domain Policy).
In this article, we’ll show how to create and configure multiple Password Setting Objects in an Active Directory domain.
Contents:
- Fine-Grained Password Policies Concepts
- How to Create Password Setting Policy (PSO) in Active Directory?
- Configuring Fine-Grained Password Policies (PSOs) Using PowerShell
Fine-Grained Password Policies Concepts
Fine-Grained Password Policies allow an administrator to create multiple custom Password Setting Objects (PSO) in an AD domain. In PSOs, you can set the password requirements (length, complexity, history) and account lockout options. PSO policies can be assigned to specific users or groups, but not to Active Directory containers (OUs). If a PSO is assigned to a user, then the password policy settings from the Default Domain Policy GPO are no longer applied to the user.
For example, using FGPP policies you can increase the requirements to the length and complexity of passwords for the administrator accounts, service accounts, or users having external access to the domain resources (via VPN or DirectAccess).
Basic requirements for using multiple FGPP password policies in a domain:
- Domain functional level of Windows Server 2008 domain or newer;
- Password policies can be assigned to users or Global (!) security groups;
- FGPP is applied entirely (you cannot set some of the password settings in the GPO, and some of them in FGPP)
How to Create Password Setting Policy (PSO) in Active Directory?
On Windows Server 2012 and newer, you can create and edit Fine-Grained Password Policies from the graphical interface of the Active Directory Administration Center (ADAC) console.
In this example, we’ll show how to create and assign a separate password policy for the Domain Admins group.
Start the Active Directory Administrative Center (dsac.msc), switch to the tree view and expand the System container. Find the Password Settings Container, right-click it, and select New -> Password Settings.
Specify the name of the password policy (in our example it is Password Policy for Domain Admins) and configure its settings (minimal length and complexity of a password, the number of passwords stored in the history, lockout settings, how often to change password, etc.).
Each of the PSO parameters (msDS-PasswordSettings class) is described by a separate AD attribute:
- msDS-LockoutDuration
- msDS-LockoutObservationWindow
- msDS-LockoutThreshold
- msDS-MaximumPasswordAge
- msDS-MinimumPasswordAge
- msDS-MinimumPasswordLength
- msDS-PasswordComplexityEnabled
- msDS-PasswordHistoryLength
- msDS-PasswordReversibleEncryptionEnabled
- msDS-PasswordSettingsPrecedence
Pay attention to the Precedence attribute. This attribute determines the priority of the current password policy. If an object has several FGPP policies assigned to it, the policy with the lowest value in the Precedence field will be applied.
Note.
- If a user has two policies with the same Precedence value assigned, the policy with the lower GUID will be applied.
- If a user has several policies assigned, and one of them enabled through the AD security group, and another one assigned to the user account directly, then the policy assigned to the account will be applied.
Then add groups or users in the Direct Applies To section to apply the policy (in our case, it is Domain Admins). We recommend that you apply the PSO policy to groups rather than individual users. Save the policy.
After that, this password policy will be applied to all members of the Domain Admins group.
Start the Active Directory Users and Computers (dsa.msc) console (with the Advanced Features option enabled) and open the properties of any user from the Domain Admins group. Go to the Attribute Editor tab and select Constructed option in the Filter field.
Find the msDS-ResultantPSO user attribute. This attribute shows the password policy enabled for a user (CN=Password Policy for Domain Admin,CN=Password Settings Container,CN=System,DC=woshub,DC=com).
You can also get the current PSO policy for a user using the dsget tool:
dsget user "CN=Max,OU=Admins,DC=woshub,DC=com" –effectivepso
Configuring Fine-Grained Password Policies (PSOs) Using PowerShell
You can manage PSO password policies using PowerShell (the Active Directory PowerShell module must be installed on your computer).
The New-ADFineGrainedPasswordPolicy cmdlet is used to create a new PSO:
New-ADFineGrainedPasswordPolicy -Name “Admin PSO Policy” -Precedence 10 -ComplexityEnabled $true -Description “Domain password policy for admins”-DisplayName “Admin PSO Policy” -LockoutDuration “0.20:00:00” -LockoutObservationWindow “0.00:30:00” -LockoutThreshold 6 -MaxPasswordAge “12.00:00:00” -MinPasswordAge “1.00:00:00” -MinPasswordLength 8 -PasswordHistoryCount 12 -ReversibleEncryptionEnabled $false
Now you can assign a password policy to a user group:
Add-ADFineGrainedPasswordPolicySubject “Admin PSO Policy” -Subjects “Domain Admins”
To change the PSO policy settings:
Set-ADFineGrainedPasswordPolicy "Admin PSO Policy" -PasswordHistoryCount:"12"
List all FGPP policies in a domain:
Get-ADFineGrainedPasswordPolicy -Filter *
Use the Get-ADUserResultantPasswordPolicy command to get the resulting password policy that applies to a specific user.
Get-ADUserResultantPasswordPolicy -Identity jsmith
The name of the PSO that applies to the user is specified in the Name field.
You can display the list of PSO policies assigned to an Active Directory group using the Get-ADGroup cmdlet:
Get-ADGroup "Domain Admins" -properties * | Select-Object msDS-PSOApplied
To show the default password policy settings from the Default Domain Policy GPO, run the command:
Get-ADDefaultDomainPasswordPolicy
In this blog post we perform a walkthrough on how to configure fine-grained password policies in Windows Server 2012.
Contents
- Determining our security requirements
- Defining the password policy
- Testing the password policy
- Conclusion
There was a time, not so long ago, in which Active Directory domains were limited to one and only one password policy. Microsoft eventually learned from its customers that this was a bad idea because some shops have different groups of domain users with different security requirements.
Service accounts are another example of security principals that are often subject to different password policies than traditional user accounts. Managed service accounts help, but again we are faced with complicated setup steps that many Windows systems administrators don’t have time to bother with.
Windows Server 2008 introduced fine-grained password policies, in which we administrators could indeed deploy more than one password policy within a single domain. However, the configuration steps are clunky and require monkeying around in ADSI Edit or Windows PowerShell 2.0.
NOTE: Third-party developers have created GUI front-ends to ease fine-grained password policy in Windows Server 2008. See this TechNet blog post for more details.
Finally, in Windows Server 2012, Microsoft has given us a truly user-friendly interface for deploying fine-grained password policy, or FGPP. As you can and should expect, we can create these policies by using either GUI tools or Windows PowerShell 3.0.
Determining our security requirements
Let’s imagine we are administrators for an Active Directory domain named 4sysopslab.com. We have used the Group Policy Management Console (GPMC) to deploy a baseline password policy by editing the Default Domain Policy Group Policy Object (GPO).
However, we have a global security group named HiSec whose members have more stringent password policy requirements than do the rest of our domain users. How can we use FGPP to accomplish this goal?
Our first step is to verify our HiSec security group membership. In Windows Server 2012 Server Manager, select Active Directory Administrative Center from the Tools menu.
Opening the ADAC from Server Manager
From the List View in Active Directory Administrative Center (ADAC), select Users and verify that the security group exists and its membership is correct. On my test system, the HiSec group contains a single user named Tim Warner.
Verifying Active Directory users for fine-grained password policies
Our next step is to actually create the FGPP.
Defining the password policy
To create the FGPP, switch to the Tree View in ADAC and navigate to System > Password Settings Container. Right-click the Password Settings Container object and select New > Password Settings.
Opening the Password Settings Container
In the Create Password Settings dialog box, we can specify all of the familiar password policy settings by using a simple, single-screen interface. In my view, this is much more intuitive way to define policy as compared to the Group Policy method. Required fields are specified with a red asterisk; you can see the interface in the following screenshot.
Defining a Fine-Grained Password Policy
You can review the meaning of the password policy settings by consulting TechNet. What we should take a closer look at is the Directly Applies To field. Click Add in the Create Password Settings dialog box to attach our newly created FGPP object to a specific Active Directory groups and/or users. You can see in Figure 4 that I attached the Hi-Sec FGPP to my HiSec global group.
An alternative method for attaching FGPP objects to Active Directory groups is to open the group’s properties page in ADAC and navigating to the Password Settings section. We can then click Assign to select a FGPP. This is shown in the following figure:
Directly assigning Fine-Grained Password Policy
In the previous two screenshots you doubtless noticed the Precedence field. What exactly does this option do? Well, although it isn’t necessarily recommended, you can apply more than one FGPP to an AD group or user. The precedence field accepts arbitrary integer values in which lower numbers denote higher priority. You can use 1 and 2, 100 and 200, or some other numbering schema—it doesn’t matter. The FGPP with the lowest integer value takes priority for that AD user or group.
Alrighty then! Now that we have created our FGPP, it is time to verify its association with our HiSec group and Tim Warner account and test the policy in practice.
Testing the password policy
In ADAC, switch the view to List View, select your domain, and locate an AD user account who we expect to be affected by our new fine-grained password policy. Right-click that account and select View resultant password settings from the shortcut menu.
NOTE: You can view the FGPP settings for an AD group by right-clicking the object, selecting Properties from the shortcut menu, and navigating to the Password Settings area in the resultant dialog box.
Checking on a user’s Fine-Grained Password Policy settings
If the selected user does have a FGPP applied, then you will see the properties page for that FGPP object appear. If the user. If the user does not have a FGPP applied, then you will see the message box shown in the following figure:
Warning if selected AD user has no Fine-Grained Password Policy settings
The following message box appears when you try to change the password for a user account with a FGPP applied to it and that password fails to meet the policy requirements:
Fine-Grained Password Policy enforcement
Conclusion
In this blog post we learned how to use the much more user-friendly fine-grained password policy feature in Windows Server 2012. You now understand how to deploy and manage more than one set of password requirements within a single Active Directory Domain Services (AD DS) domain.
Обновлено 08.09.2018
Добрый день! Уважаемые системные администраторы и просто гости крупного IT блога pyatilistnik.org. Я очень рад, что вы занялись безопасностью своей инфраструктуры, и PSO, это первый из шагов, который поможет вам в этом. Что такое PSO (гранулированные пароли) мы узнали тут, про то как это настроить в 2008R2 описано тут. Теперь давайте разберемся где в windows 2012R2 находятся настройки PSO. Вы конечно как и на примере 2008R2 можете повторить данный трюк, но к чему стока мороки. Идем в панель управления.
Щелкаем правым кликом по пуску или сочетание клавиш CTRL+X и выбираем, нужный пункт.
Как настроить гранулированные политики паролей или PSO (password setting object) в windows server 2012R2-01
Дальше Администрирование-Центр Администрирования.
Как настроить гранулированные политики паролей или PSO (password setting object) в windows server 2012R2-02
Либо можете ввести в окне «Выполнить» сокращенную аббревиатуру dsac.exe.
Как настроить гранулированные политики паролей или PSO (password setting object) в windows server 2012R2-03
У вас откроется «Центр администрирования Active Directory», как видите оснастка очень похожа, на начальную «Диспетчер серверов»
Как настроить гранулированные политики паролей или PSO (password setting object) в windows server 2012R2-04
В левом углу видим наш домен, щелкаем по нему и идем System-Password Setting Container
Как настроить гранулированные политики паролей или PSO (password setting object) в windows server 2012R2-05
Справа нажимаем создать-Параметры паролей.
Как настроить гранулированные политики паролей или PSO (password setting object) в windows server 2012R2-06
Ну а дальше все просто выбираем, что нужно, и снизу жмем кнопку Добавить, в которой можно выбрать пользователя или группу.
Как настроить гранулированные политики паролей или PSO (password setting object) в windows server 2012R2-07
Как видите Microsoft с каждым разом все упрощает и в случае с корзиной Active Directory и в плане PSO политик, думаю это правильное решение.
Сен 8, 2018 15:38
Creating Fine Grained Password Policies In this post we will see the steps for Creating Fine Grained Password Policies (FGPP). In Microsoft Windows 2000 and Windows Server 2003 Active Directory domains, you could apply only one password and account lockout policy, which is specified in the domain’s Default Domain Policy, to all users in the domain. As a result, if you wanted different password and account lockout settings for different sets of users, you had to either create a password filter or deploy multiple domains. Both options were costly for different reasons. Starting from Windows Server 2008, you can use fine-grained password policies to specify multiple password policies and apply different password restrictions and account lockout policies to different sets of users within a single domain.
In this post we will see the steps for creating fine grained password policies on Windows Server 2012 R2 domain controller. Once we create FGPP we would be applying it to a group named Laptop Users. This is a test group that consists of few users. I found it very easy to configure a FGPP on domain controller running on Windows Server 2012 R2 than Windows server 2008 R2.
To create FGPP, login to the domain controller using a domain admin account and click on Server Manager. To enable Fine-Grained Password Policies (FGPP), you need to open the Active Directory Administrative Center (ADAC), switch to the tree view and navigate to the System, Password Settings Container. Right-click the Password Settings Container object and select New and click on Password Settings.
Provide a name to the password policy. Set the Precedence attribute value to 2. For the remaining settings fill all of them with appropriate data.
[vc_row][vc_column][TS_VCSC_Info_Notice panel_type=”warning” panel_icon=”ts-awesome-hand-o-right” panel_title=”Note” font_title_family=”Default:regular” font_content_family=”Default:regular” el_file1=””]As per Microsoft, a lower value for the precedence attribute indicates that the PSO has a higher rank, or a higher priority, than other PSOs. For example, suppose an object has two PSOs linked to it. One PSO has a precedence value of 2 and the other PSO has a precedence value of 4. In this case, the PSO that has the precedence value of 2 has a higher rank and, hence, is applied to the object.[/TS_VCSC_Info_Notice][/vc_column][/vc_row]
Now you need to apply this PSO to a group called Laptop Users. Click on Add and browse the group and click OK.
To view the resultant PSO for a user open Active Directory Users and Computers. On the View menu, ensure that Advanced Features is checked. In the console tree, click Users. In the details pane, right-click the user account for which you want to view the resultant PSO, and then click Properties. Click the Attribute Editor tab, and then click Filter. Ensure that the Show attributes/Optional check box is selected. Ensure that the Show read-only attributes/Constructed check box is selected. Locate the value of the msDS-ResultantPSO attribute in the Attributes list.
You can also view the resultant PSO for a user from the command line using dsget command. Open a command prompt & type the following command, and then press ENTER.
dsget user <User-DN> -effectivepso
In the below screenshot we see that the FGPP is applied. The user tries changing the password to a simple password but he gets the error because we did specify in the policy that the password must meet complexity requirements.
Prajwal Desai is a Microsoft MVP in Enterprise Mobility. He writes articles on SCCM, Intune, Configuration Manager, Microsoft Intune, Azure, Windows Server, Windows 11, WordPress and other topics, with the goal of providing people with useful information.
Intro
Ace again! Let’s talk about FGPP!
When Active Directory was first introduced in Windows Server 2000, you can only create one password policy for the domain. That was configured in the Default Domain Policy. If you attempted to create a GPO linked to an OU with password policy settings, the Active Directory CSEs (Client Side Extensions – the client side DLLs that determine, download and run GPOs assigned to the computer or user) will ignore them.
FGGP Expanded Requirements
Therefore if an IT infrastructure design required a different password for different locations or users, the only option was to either create a password filter or create a separate child domain or a new Tree in the forest. Of course this came with design challenges, additional hardware and administrative overhead. For a number of years, this was a limitation that IT administrators had no real solution or alternative.
To provide a solution, Fine-Grained Password Policies (FGPPPs), were introduced in Windows Server 2008, continued in Windows 2008 R2. They provided administrators to create a Password Settings Policy (PSO) for a set of user accounts or groups and cannot be linked to GPOs, and the only way to create and administer PSOs and FGGPs are using low-level utilities, such as ADSI Edit.
Windows Server 2012 introduced a new GUI to ease creation and administration of PSOs and FGPPs. In this section, we will learn about the new FGPP and PSO features, and how to create administer them.
- Why would we need an FGGP?
- Understanding Password Settings Objects (PSOs)
- What’s new in Windows 2012 FGGP?
- PSO Resultant Set of Policies (RSOP)
- What’s required to implement FGGPs? PowerShell and FGGPs
Why would we need a FGGP?
You can use fine-grained password policies to specify specific password policies in a single domain by applying different restrictions settings for password and account lockout policies to different sets of users and groups in a domain.
For example, you can apply stricter settings to privileged accounts such as administrator accounts, or executive accounts, and apply less strict settings to the accounts of other users. You can also create special password policies for accounts that get their passwords synchronized with other data sources or applications.
Understanding Password Settings Objects (PSOs)
Password Settings Objects (PSOs) have identical password settings as the password policy in a GPO. These settings include password length, complexity, account lockout, password minimum and maximum age, password history settings, PSO link, and Precedence.
PSOs are not linked to an OU. PSOs are applied users or groups. To help keep track of PSOs to an OU, for example, administrators can create an Active Directory group in an OU that is identically named as the group name.
With Windows Server 2008 and Windows Server 2008 R2, ADSI Edit (Active Directory Services Editor), a low level editor, is required to create, modify and apply PSOs to users or groups. ADSI Edit is akin to a “registry editor” that allows you to modify data in the various partitions in the AD database. Using ADSI Edit requires additional knowledge and skill level by an administrator to understand the various Active Directory database partitions and how to access them.
What’s new in Windows Server 2012 FGGPs?
In Windows Server 2012, creating and managing fine-grained password policy can now be performed using a user interface, the ADAC (Active Directory Administration Center), vastly improving ease of administration.
Administrators can now visually see a specific user’s resultant set of policies (RSOP), view and sort all password policies within a given domain, and manage individual password policies.
PSO Resultant Set of Policies (RSOP)
If a user or group has multiple PSOs linked to them, possibly because they are part of multiple Active Directory groups that have different PSOs, only one PSO can be applied. Therefore, the RSOP must be evaluated to insure the correct PSO is applied.
To determine and calculate the RSOP, each PSO has an additional attribute called the msDS-PasswordSettingsPrecedence.
The msDS-PasswordSettingsPrecedence attribute has an integer value of 1 or greater. The lower the value, the higher precedence it has. In a scenario where an AD group has two PSOs linked, with one of them having a value of 2, and the a value of 4, then the PSO with a value of 2 wins, and is applied to the AD group.
RSOP msDS-PasswordSettingsPrecedence Logic:
• A PSO that is linked directly to the user object is the resultant PSO. (Multiple PSOs should not be directly linked to users.)
• If no PSO is linked directly to the user object, the global security group memberships of the user, and all PSOs that are applicable to the user based on those global group memberships, are compared. The PSO with the lowest precedence value is the resultant PSO.
• If no PSO is obtained from conditions (1) and (2), the Default Domain Policy is applied.
Additional reading on RSOP:
AD DS: Fine-Grained Password Policies
http://technet.microsoft.com/en-us/library/cc770394(v=ws.10).aspx
What’s required to implement FGGPs?
To point out, Fine-grained password policies can only be applied to global security groups and user objects (or inetOrgPerson objects, a specific attribute some third party applications may use, if they are used instead of user objects).
Requirements include:
- Only members of the Domain Admins group can set fine-grained password policies, however, the tasks can be delegated to other users.
- The domain functional level must be Windows Server 2008 or higher.
- You must use the Windows Server 2012 version of ADAC (Active Directory Administrative Center) to administer fine-grained password policies through a graphical user interface.
Server Manager can be used to install the RSAT tools (Remote Server Administration Tools) on Windows Server 2012 computers to use the correct version of Active Directory Administrative Center to manage Recycle Bin through a user interface.
- You can use RSAT on Windows® 8 computers to use the correct version of Active Directory Administrative Center to manage FGGPs.
PowerShell and FGGPs
PowerShell can also be used to create and manage FGGPs. For example, the command below will create the following settings:
- • PSO Name: TestPswd
- • Complexity: Enabled
- • Lockout Duration: 30 Minutes
- • Lockout Observation Windows: 30 Minutes
- • Lockout Threshold: 0 Minutes
- • MaxPasswordAge: 42 Days
- • Minimum Password Age: 1 Day
- • MinPasswordLength: 7 characters
- • PasswordHistoryCount: 24 passwords remembered that you can’t use
- • ProtectedFromAccidentalDeletion: Yes (prevents accidental deletion)
- • Security Principal Applied to: AD Group called “group1”
New-ADFineGrainedPasswordPolicy TestPswd -ComplexityEnabled:$true -LockoutDuration:"00:30:00" -LockoutObservationWindow:"00:30:00" -LockoutThreshold:"0" -MaxPasswordAge:"42.00:00:00" -MinPasswordAge:"1.00:00:00" -MinPasswordLength:"7" -PasswordHistoryCount:"24" -Precedence:"1" -ReversibleEncryptionEnabled:$false -ProtectedFromAccidentalDeletion:$true
Add-ADFineGrainedPasswordPolicySubject TestPswd -Subjects group1
Additional Reading:
AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide
http://technet.microsoft.com/en-us/library/cc770842(v=ws.10).aspx
Introduction to Active Directory Administrative Center Enhancements (Level 100)
http://technet.microsoft.com/en-us/library/hh831702.aspx
Creating fine grained password policies through GUI Windows server 2012 “Server 8 beta”
Microsoft Technet, by Tamer Sherif Mahmoud, Team Blog of MCS
http://blogs.technet.com/b/meamcs/archive/2012/05/29/creating-fine-grained-password-policies-through-gui-windows-server-2012-server-8-beta.aspx
============================================================
Summary
Stay tuned for more on Azure and Cloud Computing
Published 10/15/2016
Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services
![clip_image0023[2][2][2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image0023222.jpg "clip_image0023[2][2][2]"){kind=small}
![clip_image0043[2][2][2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image0043222.jpg "clip_image0043[2][2][2]"){kind=small}
![clip_image0063[2][2][2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image0063222.jpg "clip_image0063[2][2][2]"){kind=small}
![clip_image0083[2][2][2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image0083222.png "clip_image0083[2][2][2]"){kind=small}
![clip_image0103[2][2][2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image0103222.jpg "clip_image0103[2][2][2]"){kind=small}
![clip_image0123[2][2][2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image0123222.png "clip_image0123[2][2][2]"){kind=small}
![clip_image0143[2][2][2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image0143222.jpg "clip_image0143[2][2][2]"){kind=small}
![clip_image0163[2][2][2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image0163222.png "clip_image0163[2][2][2]"){kind=small}
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php
This posting is provided AS-IS with no warranties or guarantees and confers no rights.
The fine-grained password policies feature was introduced in Windows Server 2008. It allowed organizations to define more than one password and account lockout policy in a single domain, and apply those policies to different sets of users. Prior to Windows Server 2012, you had to use PowerShell, ADSI Edit or the Ldifde command-line utility to create the Password Settings Objects that are used to define fine-grained password policies. But in Server 2012 and 2012R2, you can use the GUI-based Active Directory Administrative Center to create PSOs and view resultant password settings for particular users in your environment.
Limitations of fine-grained password policies
- Can only be applied to users and global security groups, which means they can not be applied to OUs.
- Domain functional level must be Windows Server 2008
- By default only Domain Admins can set fine-grained password policies on users and groups, but this ability can be delegated to other users
1. Create and apply a PSO
Fine-grained password policies are defined by creating Password Settings Objects, and then applying those to users and groups. In Server 2012 and 2012 R2 you can use Active Directory Administrative Center and Windows PowerShell to create and apply PSOs.
It’s important to keep in mind that a user can only have one effective password and account lockout policy. So if more than one PSO is applied to a user, either directly or through group membership, the precedence value of that PSO will determine whether it will be the winning PSO or not. The PSO with the lowest precedence will have higher rank, so the PSO with the lowest precedence will be the effective PSO for a user. An exception to this rule is that PSOs directly applied to users, always prevail over PSOs applied to groups (which are again obviously applied to users through group membership).
If no PSOs are applied to a user, the Default Domain Policy will be applied to that user.
1.1 Create and apply a PSO using ADAC
1.1.1 Start Active Directory Administrative Center
1.1.2 Select Domain name → System → Password Settings Container
1.1.3 Right-click inside the Password Settings Container → New → Password Settings
1.1.4 Fill in the appropriate information on the Create Password Settings properties page
1.1.5 Click Add on the Directly Applies To section, and select the users/groups you want to apply the PSO to
1.1.6 Finally, click OK to create the PSO
1.2 Create and apply a PSO using PowerShell
1.2.1 Use the New-ADFineGrainedPasswordPolicy cmdlet to create the PSO. The following example creates a PSO named PSO2, with exactly the same settings as we defined in the PSO we created with ADAC. The parameters for the cmdlet are pretty much self-explanatory.
New-ADFineGrainedPasswordPolicy -Name “PSO2” -Precedence 5 -ComplexityEnabled $false -Description “PSO Number 2” -DisplayName “PSO2” -LockoutDuration “0.00:30:00” -LockoutObservationWindow “0.00:30:00” –LockoutThreshold 5 -MaxPasswordAge “42.00:00:00” -MinPasswordAge “1.00:00:00” -MinPasswordLength 7 –PasswordHistoryCount 24 -ReversibleEncryptionEnabled $false -protectedfromaccidentaldeletion $true
1.2.2 Use the Add-ADFineGrainedPasswordPolicySubject cmdlet to apply PSOs to users and groups. The following example will apply PSO2 to the Data and Managers groups
Add-ADFineGrainedPasswordPolicySubject PSO2 -Subjects Data,Managers
1.2.3 Feel free to verify that the settings and assignment of the PSO has been applied correctly, in Active Directory Administrative Center
2. View the Resultant PSO for a user
2.1 Viewing the resultant PSO for a user in ADAC
2.1.1 Locate the user in ADAC
2.1.2 Right-click user → View resultant password settings
2.1.3 PSO applied to the user will be displayed
2.2 Viweing the resultant PSO for a user in PowerShell
2.2.1 Use the Get-ADUserResultantPasswordPolicy cmdlet. The following example gets the resultant PSO for the same user (rjones)
Get-ADUserResultantPasswordPolicy rjones
In Windows Server 2012 or Windows Server 2012 R2, fine-grained password policy management is made much easier than Windows Server 2008/2008 R2. Windows Administrators not have to use ADSI Edit and configure complicated settings to create the Password Settings Object (PSO) in the Password Settings Container. Instead we can configure fine-grained password policy directly in Active Directory Administrative Center (ADAC).
Before you can create fine-grained password policies for a domain, you must ensure that the domain functional level is Windows Server 2008 or newer. This can be done using either ADAC or Windows PowerShell . Note that Domain Admin credentials or greater are required to raise the domain functional level for a domain.
In order to configure fine-grained password policy, go to Windows Server 2012 Server Manager, select Active Directory Administrative Center (ADAC) from the Toolsmenu.
Navigate to System container then Password Settings Container
Click on New and then select Password Settings.
In the Create Password Settings windows, you can specify all the familiar password policy settings by using a user-friendly single screen interface.
Finally, click Add, and locate the group or groups you want the policy to apply to. Then click OK to create the new policy.
Note:
You can also use Windows PowerShell to create, modify, or delete fine-grained password policies for your domain. For example, you can use the New-ADFineGrainedPasswordPolicy cmdlet to create a new fine-grained password policy. You can also use the Set-ADFineGrainedPasswordPolicy cmdlet to modify an existing fine-grained password policy. And you can use the Remove-ADFineGrainedPasswordPolicy cmdlet to delete a fine-grained password policy that is no longer needed in your environment. Use the Get-Help cmdlet to display the syntax and examples for each of these cmdlets.