Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2007-08-09) Windows Server 2008 – Fine-Grained Password Policies

Posted by Jorge on 2007-08-09


In previous OSes if you wanted to create multiple password or account lockout policies you basically has two choices.

  1. Create a new domain for the accounts that need some other password or account lockout policy. This was not really a good choice, because of the additional hardware needed and the management hassle coming from such a solution.
  2. Buy third party software like for example Password Policy Enforcer from Anixis

As you can see both cost money to be able to use it. I’m not saying that W2K8 is free to use, but I’m saying the feature is by default available in the OS to create multiple password and account lockout policies within an AD domain. The name of the object is Password Settings Object (PSO) and you can create those objects in the "Password Settings Container" container. The PSO objects can be created as soon as the schema has been update to W2K8 version, but you can only use the objects when the Domain Functional Level has been configured with W2K8. This means that only W2K8 DCs understand this new feature. This is logical, because if you were able to use this feature while older DCs were available, you would experience different results depending on which DC authenticated you. You can see an example below in the picture.

image

For different purposes I created different PSOs where each PSO has its own set of values. If you look at the description you can see the purpose of each PSO.

Another thing you can see directly is that the new password and account lockout policies are not implemented using GPOs. Although it is still possible to define a GPO at domain level with password and account lockout policy settings, I strongly suggest you stop doing that and start using PSOs as soon as possible. That way you will have a consistent experience using and managing password policies.

Functionality wise nothing changed. It is as simple as that. For those of you expecting to be able to also define special complexity requirements, I’m sorry to say that is still not possible. For that you still need a custom password filter by buying one or doing it yourself.

The PSOs can only be managed (e.g. create, delete, change AND read) by the members of the Domain Admins group. Nobody else is by default able to even view the settings of some PSO. To allow the service desk people or other admins view the settings of some PSO, you need to create a group (preferred over assigning permissions to individual users) like "ALLOW-PSO-Read" and configure that group with at least ALLOW READ permissions. After configuring ALLOW READ open the Advanced Permissions Window and change the scope to "This Object and All Descendant Objects". By allowing the service desk people or other admins to view the settings of PSO, they can troubleshoot why and user’s password change is failing and telling the user what the requirements are of the PSO that he is linked to. You can the permissions configuration below.

image

And the nice thing of this is that it supports all clients and no clients changes are needed for this. All processing is done on the W2K8 DCs.

Natively, (at this moment) W2K8 does not have a nice cool GUI to create PSOs. The feature made it rather late into the OS and because of that Microsoft chose to provide the feature without a fancy GUI against providing nothing at all. I think having the feature is more important and having nothing at all because there is no GUI. The only way to create the PSO natively is to use ADSIEDIT or LDIFDE. I do understand that is not sexy to use. Besides that, it lacks some other interesting management features. Interesting though is that it is possible to manage the PSO with ADUC using the Attribute Editor after the PSO has been created.

To create a PSO with ADSIEDIT (values are EXAMPLES!!!):

a.       Start “ADSI Edit” (CMD à ADSIEDIT.MSC)

b.      Connect to the “Default Naming Context”

c.       Right-click “Password Settings Container” & create new object “msDS-PasswordSettings”

a.       cn = PSO-for-DomainUsers

b.      msDS-PasswordSettingsPrecedence = <numeric value> (e.g. 100)

c.       msDS-PasswordReversibleEncryptionEnabled = <Boolean> (e.g. FALSE or TRUE)

d.      msDS-PasswordHistoryLength = <numeric value> (e.g. 2)

e.      msDS-PasswordComplexityEnabled = <Boolean> (e.g. FALSE or TRUE)

f.        msDS-MinimumPasswordLength = <numeric value> (e.g. 3)

g.       msDS-MinimumPasswordAge = <negative integer8 vallue> (e.g. -864000000000) OR <dd:hh:mm:ss> (e.g. 01:00:00:00)

                                                               i.      64-bit large integer expressing the number of nanoseconds

                                                             ii.      Values can be entered in integer8 values (negative numbers) or dd:hh:mm:ss

                                                            iii.      Default value is “-864000000000”, which is the number of nanoseconds in 1 day

                                                           iv.      Recommended to configure a minimum age!!!

h.      msDS-MaximumPasswordAge = <negative integer8 vallue> (e.g. -36288000000000) OR <dd:hh:mm:ss> (e.g. 42:00:00:00)

                                                               i.      64-bit large integer expressing the number of nanoseconds

                                                             ii.      Values can be entered in integer8 values (negative numbers) or dd:hh:mm:ss

                                                            iii.      “-36288000000000” = 42 days

i.         msDS-LockoutThreshold = <numeric value> (e.g. 50)

                                                               i.      Number of bad attempts before lockout

                                                             ii.      Value = 0  account lockout = disabled

j.        msDS-LockoutObservationWindow = <negative integer8 vallue> (e.g. -90000000000) OR <dd:hh:mm:ss> (e.g. 00:00:30:00)

                                                               i.      Amount of time after which the bad pwd count is reset to 0

                                                             ii.      “-90000000000” = 30 minutes

                                                            iii.      64-bit large integer expressing the number of nanoseconds

                                                           iv.      Values can be entered in integer8 values (negative numbers) or dd:hh:mm:ss

k.       msDS-LockoutDuration  = negative integer8 vallue> (e.g. -90000000000) OR <dd:hh:mm:ss> (e.g. 00:00:30:00)

                                                               i.      Amount of time an account remains locked

                                                             ii.      “-90000000000” = 30 minutes

                                                            iii.      64-bit large integer expressing the number of nanoseconds

                                                           iv.      Values can be entered in integer8 values (negative numbers) or dd:hh:mm:ss

l.         msDS-PSOAppliesTo (OPTIONAL) = <distinguished Name of user or group> (e.g. CN=Domain Users,CN=Users,DC=ADCORP,DC=DEMO)

 

To create a PSO with LDIFDE (values are EXAMPLES!!!):

a.       Create a file called “Create-PSO.ldf” (integer8 values MUST be specified as negative numbers!!!)

a.       dn: <distinguished Name of user or group> (e.g. CN=Domain Users,CN=Users,DC=ADCORP,DC=DEMO)

b.      changetype: add

c.       objectClass: msDS-PasswordSettings

d.      msDS-PasswordSettingsPrecedence:<numeric value> (e.g. 100)

e.      msDS-PasswordReversibleEncryptionEnabled:<Boolean> (e.g. FALSE or TRUE)

f.        msDS-PasswordHistoryLength:<numeric value> (e.g. 2)

g.       msDS-PasswordComplexityEnabled:<Boolean> (e.g. FALSE or TRUE)

h.      msDS-MinimumPasswordLength:<numeric value> (e.g. 3)

i.         msDS-MinimumPasswordAge:<negative integer8 vallue> (e.g. -864000000000)

j.        msDS-MaximumPasswordAge:<negative integer8 vallue> (e.g. -36288000000000)

k.       msDS-LockoutThreshold:<numeric value> (e.g. 50)

l.         msDS-LockoutObservationWindow:<negative integer8 vallue> (e.g. -90000000000)

m.    msDS-LockoutDuration:<negative integer8 vallue> (e.g. -90000000000)

n.      msDS-PSOAppliesTo: distinguished Name of user or group> (e.g. CN=Domain Users,CN=Users,DC=ADCORP,DC=DEMO)

b.      Import the file called “Create-PSO.ldfà LDIFDE -i -f Create-PSO.ldf

 

However, do not fear! Two Directory Services MVPs, an employee from Quest and SpecOps have created free tools to manage PSOs.

(1)    Joe Richards from joeware.net has created PSOMGR, a command-line tool to create and manage PSOs. It also contains additional interesting management options. This product is final.

(2)    SpecOps Software provides a tool called Specops Password Policy Basic, which is the free version and allows basic usage and configuration of PSOs. This product is final

(3)    Christoffer Andersson has created the Fine Grained Password Policy Tool (x86 and x64). This is a GUI tool that can also be used through powershell. This product is in beta at the moment.

(4)    Dmitry Sotnikov from Quest has created the PowerGUI console for managing Fine Grained Password Policies. This is a GUI tool that uses Powershell. This product is final.

 

Now do these guys rock or what???!!! Of course they do, they are the only ones that provide tools like that and they’re free!

When looking at the usage of PSO and the applying order the following is true. You can link both user accounts directly to a PSO or indirectly through the usage of global groups. Between the user account and the PSO you can only have global groups. If somewhere in between you use universal groups or domain local groups, the PSO settings will not be applied to the user account and the system continues to the next level. Basically the applying order is:

  1. Check if the user account is directly linked to a PSO.
    1. If yes, stop and use that PSO
    2. If no, continue with next level
  2. Check if the user account is INdirectly linked to a PSO through the usage of a global group
    1. If yes, stop and use that PSO
    2. If no, continue with next level
  3. In the end if none of the above apply, use the password and account lockout settings in the Default Domain Policy

Be aware that a user can only have ONE PSO applied and the settings specified for the passwords and the account lockout are therefore applied. It is not possible to apply ONE PSO with only password settings and another PSO with only account lockout settings. You can see the usage and applying order in the picture below.

image

A user account (see picture below – box 1) or a global group (see picture below – box 2) can be linked to multiple PSO. However multiple user accounts and multiple global groups (see picture below – box 3) can be linked to a single PSO

image

When the system determines the user account is directly linked to multiple PSOs it checks each the "Precendence" value (or better: COST) of each PSO. The PSO with the lowest "Precendence" value is applied. If for some reason multiple PSOs have the same "Precendence" value, the system determines the PSO to apply by looking at the objectGUID in octet format (alphabetical order). To notify you of this the system logs a message in the event log so that you can solve this.

This also applies at the second level if the system needs to determine which PSO to use when a user is indirectly linked to a PSO through a global group.

In the pictures below you can find additional information about the attributes used and how it really works underneath the hood. For an explanation of the attributes I suggest you visit Ulf’s blog.

image

Picture above: one the right you can see the users or groups that are linked to the PSO

image

Picture above: you can see the PSOs that are linked directly to a user or group (in this case a group)

image

Picture above: you can see the PSO that will be applied to the user account. If <not set> is specified, the settings from the default domain policy will be applied.

Best practices IMHO:

  • Determine the overall password and account lockout policy requirements for the whole company. Create a PSO with a name that shows for whom it is (in this case all users within the company) and link the global group "Domain Users" to it. For the precedence value assign the largest possible value being 2147483647. This way all users within the company that have not got another PSO assigned, directly or indirectly, will get this one
  • Determine for different groups of people in the company (departments, teams, subsidiaries, etc.) if they have requirements for other password and account lockout policies create a PSO for each configuration. For each PSO create a single global group and link it to the corresponding PSO. Put everyone that needs to match the configuration of a certain PSO in the corresponding global group. You can put users directly in the PSO global groups or use group nesting (remember: global groups only in the chain between the PSO and the user!), but be careful with that. What I’m trying to say is that everyone that should manage PSO configuration and must decide who gets what PSO configuration must be trusted. You will weaken the security of the domain if someone that is not trusted enough has permissions to change the membership of the groups that are used in the chain between the PSO and the user.
  • Determine for different groups of admins (domain admins, delegated admins, service desk, etc.) in the company if they have requirements for other password and account lockout policies create a PSO for each configuration. For each PSO create a single global group and link it to the corresponding PSO. Put everyone that needs to match the configuration of a certain PSO in the corresponding global group. The same issue applies when using group nesting
  • Determine for different groups of service accounts (with domain admins permissions, with permissions on very security sensitive computers, etc.) in the company if they have requirements for other password and account lockout policies create a PSO for each configuration. For each PSO create a single global group and link it to the corresponding PSO. Put everyone that needs to match the configuration of a certain PSO in the corresponding global group. The same issue applies when using group nesting

Additional interesting links:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

10 Responses to “(2007-08-09) Windows Server 2008 – Fine-Grained Password Policies”

  1. Jorge

    Dont forget the work Dimitry from Quest is doing at http://dmitrysotnikov.wordpress.com/2007/06/19/free-ui-console-for-fine-grained-password-policies/

    I haven’t tried it but looks like it serves the same purpose😉

    Cheers

    M@

  2. pbbergs said

    Very nice work Jorge! I like the diagrams and pictures you have provided.

    Paul

  3. How about this – we need to modify our PSO complexity requirements to remove the need to use special characters (!£$%*& etc) – can this be done with a PSO?  If so, does it need those horrible password filters from 2003?

  4. Jorge said

    BY default it is not possible to change/configure the complexity requirements. If you need to change those you need to implement a custom Password Filter.
    Jorge

  5. […] Windows Server 2008 – Fine-Grained Password Policies […]

  6. […] "Windows Server 2008 – Fine-Grained Password Policies" I explain the new password and account lockout feature/concept in Windows Server 2008. When […]

  7. […] Windows Server 2008 – Fine-Grained Password Policies […]

  8. […] or not you are using Password Settings Objects (PSO). For more information about PSOs, click here and […]

  9. […] Account Lockout Policies within a single AD domain. This cool feature is explained in the post “(2007-08-09) Windows Server 2008 – Fine-Grained Password Policies”. Although the feature is available there is no nice GUI provided by the OS to manage Password […]

  10. […] For more information about this see the blog post: https://jorgequestforknowledge.wordpress.com/2007/08/09/windows-server-2008-fine-grained-password-po&#8230; […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: