FGPP’s & PSO’s – translated: “Yay! More domain password control!”

I’ve previously spoken about security and password management (if you need a refresher, I’m referring to this post and this post) however I neglected to go into detail regarding one really cool and amazing thing – Fine-Grained Password Policies & Password Setting Objects…and I’ve been promising to write this post for months!

I know a lot of this can be found on the MS TechNet site, but I hope to inject a bit of real world “this is why we did things the way we did them” into this, so it gives you a better understand of how they can be applied and what the settings do.

Now, FGPP’s aren’t new. They’re not something that’s just been released. They’ve been around for quite a while – it’s just that many admins out there don’t seem to know they exist. So trust me, once you’ve played around with FGPP’s, you won’t want to go back…

FGPP’s & PSO’s

FGPP’s are, quite simply, the best thing ever for domain passwords (notice I said domain there, not local…LAPS is in a league of it’s own and I’m in the process of writing a piece on that too!) and it can make a huge difference to the security of your environment. Being able to have multiple password policies in your environment means flexibility without the need for compromising security.

For those who aren’t aware of FGPP’s (and quoting directly from Microsoft):
“You can use fine-grained password policies to specify multiple password policies within a single domain. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain.”

Yes, you read it right folks – it lets you have multiple password policies within the one domain. This makes life so much easier, especially if you’re doing the right thing and having your desktop, server and domain admin accounts have decently long and complex passwords!

Example uses

So, a few examples – and I’m actually going to pull these from my experience in setting up, as these are policies we currently have in place at the moment (or are trying to get put in place!):

• Admin Accounts – if you’re a good admin, and have set up your admin accounts the way you’re supposed to, you should have 4 distinct accounts. However, the standard admin policy may not work for your admin accounts (as mentioned above) so creating some specific password policies for this accounts would be good. Increase the character length, possibly increase the change time (or decrease depending on the paranoia of your organisation), increase the lockout duration (to prevent brute-force attacks).
• Generic Accounts – Generic accounts are great, but they’re used for such random things that it’s sometimes hard to make sure they’re being used correctly and securely. Putting in a password policy that increases the length of the password dramatically (say, to 25 characters) would increase the security of the account dramatically.
• Service Accounts – Service account password changes are always notoriously ugly, because they’re used in so many places and (most of the time) it’s not actually documented where they’re used. However, they still need to have their passwords reset on a regular basis…but maybe not quite as regular as every 30-60 days. Implementing an FGPP that states that a Service Account needs to have a minimum 30 character password but it only needs to be changed once a year does away with some of the security headaches that come with service accounts. Yes, it might be possible to use something like Managed Service Accounts or Group Managed Service Accounts but if your environment is anything like ours, you’ll find a lot of applications really *really* don’t like them. They’ll hopefully improve, but until they do FGPP’s for service accounts is a start.
• Accounts with specific password requirements – One of the biggest issues I see with Domain-wide password policies is that they’re usually catered to the lowest common denominator. You have an niche application in your organisation that says users can’t have a password that’s more than 6 characters. So the default minimum becomes 6 characters…for *everyone*. Why should everyone’s account become insecure to cater to a few? Put in an FGPP for users of that application, so their password fits the idiotic criteria of their application; while everyone else can have a decent password policy applied to them.

Use these to explain to your management why they’re a good idea and why you want to put them in place. Should hopefully help in getting traction in getting them implemented!

How to setup fine grained password settings

Honestly, they’re incredibly simple to set up, you just need a few details before you start:

• You’ll need to be an admin – You’ll be editing your PSO’s via ADSI edit (at least that’s how I do it!) and the CN=System is locked down. Depending on how your domain has been configured, this admin might require DA rights (as in our case) or Enterprise Admin rights (as this is inherited from the top). You’ll need to check to see what rights you’ll need to create these objects.
• You’ll need access to edit CN=Password Settings Container – this isn’t access, this is just usability. Either via ADSI or PowerShell (whichever floats your boat!) you’ll need some way to add objects under this CN.
• What password policies you want to implement – honestly, this should be a no brainer, but so many people go into creating these *not* knowing what they actually want them to do. I’ll go into detail a bit later down the post as what you need to know when you’re creating them, but I suggest documenting these before hand – especially if you have change procedures!
• What group of users you want to apply it to – when I say group, I mean group literally. You’ll want an AD Group to apply the settings to. This group also needs to be a Global security group. (thanks to Alicia in the comments for this tip!)

Now, onto setting them up – I’ll be giving instructions via ADSI edit because I like my point’n’click (don’t judge me…). If you want to do it via PowerShell, Microsoft’s TechNet have some great knowledge base articles on creating a PSO via PowerShell and setting a PSO via PowerShell.

You can also use ADAC or so I’m told…I never got into using ADAC because I’m stuck in my ways. Pierre Roman (lovely guy!) wrote a great post on how to set FGPP’s up using ADAC if you prefer that way.

But…I use ADSI, so onwards we proceed with that!

• Open ADSI edit (these instructions assume you’ve used ADSI edit before…)
• Ensure you’ve opened “Default naming context”
• Expand out your domain e.g. DC=domain,DC=com
• Expand out ‘CN=System’
• Open the ‘CN=Passowrd Settings Container’
• Right-click (either on the container or in the container display) and select ‘New’ -> ‘Object’
• Click ‘Next’
• Give your PSO a name – make it something that is descriptive so you know what’s being used for!
• Click ‘Next’
• Now comes to the fun part I mentioned above – the settings you should know *ahead of time*
  • Password Settings Precedence – (Integer) Ideally, set this to 1 because you want this to be the password setting that applies. If you have overlapping PSO’s, that’s where this gets a bit trickier.
  • Password reversible encryption status for user accounts – (Boolean) True or False. For the love of all you hold holy, set it to False.
  • Password History Length for user accounts – (Integer) 0-1024, this is the number of passwords that are “remembered” by the system. We tend to go with at least a few (6-24, depending) so that the same password can’t be reused within a decent span of time.
  • Password complexity status for user accounts – (Boolean) True or False. In the opposite vein to the encryption boolean, set this one to True. Because you’re smart.
  • Minimum Password Length for user accounts – (Integer) Should be obvious – minimum password length. This is probably the important one for different account types e.g. 14 for a standard user account, 20 for an admin account, 30 for a service account (because I’m mean like that…)
  • Minimum Password Age for user accounts – (Duration) The minimum age of a password. This one can be fun, especially if you have a third-party IDM system (like we do). Ours is set to ‘(none)’ so our IDM system can control passwords. However, this has given us a few difficulties with some users changing their passwords n+1 (to beat the password history length) many times in order to roll back to their old password. So be careful with this one.
  • Maximum Password Age for user accounts – (Duration) Pretty obvious, this is when your password expires! We’ve got this tied to minimum password length – the longer the length of the password, the longer the maximum password age is. This cannot be set to 0 (for obvious reason) but you can set it to never expire – the value for that is: -9223372036854775808.
  • Lockout threshold for lockout of user accounts – (Integer) How many times a user needs to mistype their password for it to lock. Depending on the account this could be pretty high, say 10 times for a standard user; or it could be pretty low, say 3 times for a service account.
  • Observation Window for lockout of user accounts – (Duration) Hopefully I can explain this correctly – this is the time bracket in which the above number of incorrect passwords need to be entered e.g. You set this to 5 minutes, this means a service account needs to have the passwords enter incorrectly 3 times in 5 minutes for the lockout to occur. Make sense?
  • Lockout duration for locked out user accounts – (Duration) How long an account is locked out for.
  • Disclaimer about ‘Duration’ fields – these have to be in a specific format:
    #:##:##:##
    Days:Hours:Minutes:Seconds
• Click ‘Next’ after you’ve set each one to what you want it to be
• Once you’ve set the above attributes (these are what Microsoft refer to as the “mustHave” attributes), click ‘Finish’

“But,” I hear you cry “I’ve created it but I didn’t apply it to anything!” – well, yes. That’s what we’re going to do now. Calm down, it’ll be fine!

• If you’ve done the right thing, you should have a group created with users in it ready to have this setting applied to it; if you haven’t, go create that now
• Double-click on the PSO you just created
• In the ‘Attribute Editor’ tab, scroll under you find ‘msDS-PSOAppliesTo’
  • If you can’t see this, you might need to change your filter so that you can view attributes that don’t have values
• Double click on this attribute
• In the window that appears, click ‘Add Windows Account…’
  • Now, yes, that does mean you can apply a PSO to an individual account. I would *STRONGLY* recommend against doing this (no matter how much your CEO wants his password to never expire >.<) and instead target group rather than individual accounts.
• Type in the name of the group you want to apply the PSO to, or search for it in your domain and then click ‘OK’
• Click ‘OK’ again
• Click ‘Apply’ then ‘OK’ and you’re done!

Well…you’re *almost* done.

Documenting your FGPP’s

For me, the biggest part of having these password settings is making sure you have them documented. I recommend documenting at least the ‘mustHave’ attributes for each PSO and who the policy applies to.

This documentation should be shared amongst everyone who has anything to do with resetting passwords so that they are aware of which password policy is in affect and can provide the correct advice.

I tend to stick with this kind of format:

• Name of the PSO
• Who it’s applied to
• Why it’s applied, especially if there’s a change or incident related to it – this seems to be the part a lot of people miss!
• The settings contained in the PSO
• Review date – because these settings need to be reviewed regularly. Sometimes they may require amending, sometimes they may no longer be required!

So that’s it – my rundown on FGPP’s/PSO’s. Shout out to Microsoft, as some of the information from this post came from their indepth guide which goes into a lot more detail surrounding FGPP’s & PSO’s if you’re still wanting to know more!

Did I miss something? Get something wrong? Want to say I’m awesome? Feel free to leave me a comment!