The Microsoft Active Directory module includes a number of PowerShell cmdlets for working with the domain password policy.

Jeffery Hicks

Jeffery Hicks is a multi-year Microsoft MVP in Windows PowerShell, Microsoft Certified Professional and an IT veteran with 25 years of experience specializing in automation. He works today as an author, trainer and consultant.

On one hand this seems a bit unnecessary as you probably aren’t changing your domain password policy all of the time. But if you are firing up new domains often, say as part of a private cloud provisioning task, you might want to automate setting the domain policy. Or at the very least you might want to roll back to a previous policy configuration.

The first thing I would recommend is getting your current domain password policy.

As you can see, my policy is essentially the default policy we’ve had for years. If you haven’t done so, save this information to a file.

Oh, and if you are following along you are in a non-production test environment, right? Now I have a copy of my current policy. We’ll come back to this later.

To modify the policy, I bet you guessed that the cmdlet to use is Set-ADDefaultDomainPasswordPolicy. If you look at cmdlet help, you’ll notice that the parameters correspond to the property names we see from Get-ADDefaultDomainPasswordPolicy.

Set-ADDefaultDomainPasswordPolicy

Unfortunately, none of the parameters other than Identity use pipeline binding. This means you can’t pipe an object with your new values to this cmdlet. Instead you simply specify the value you want to set. Be careful though as some properties are expecting certain object types such as a TimeSpan.

Here I set the MaxPasswordAge property to 60 days. The cmdlet converted the string “60.00:00:00” into a TimeSpan object. But you may find it easier to do yourself.

Here I used a nested command, New-Timespan, to define the max age parameter value. I also went ahead and modified another parameter to require 8 character passwords. Notice too that I’m using –Passthru. By default the cmdlet doesn’t write anything to the pipeline unless you specify –Passthru. However, the cmdlet does support –WhatIf and –Confirm which is good.

Suppose at some point you realize you need to roll back to a previous policy. This is where the saved XML file comes in handy. I’ll step through the process but you could easily build a simple script around it. First, import the XML file.

Next, I’ll define an array of property names.

With this, I can build a hash table of parameters and values that I can splat against Set-ADDefaultDomainPasswordPolicy.

Because the parameter and property names match this is a pretty simple command. Here’s what the hash table looks like.

All that remains is to invoke the cmdlet with this parameters.

Just like that I’m back to a previous policy. I am unlikely to frequently change my password policy, and I trust you are the same, but should someone get in and change something they shouldn’t, assuming I’ve planned ahead, I can fix things pretty easily.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!

2+

Users who have LIKED this post:

  • avatar
Share
0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2019

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account