Kent Ickler //

As a start to a series on Windows Administration in the eyes of a security-conscious “Windows Guy” I invite you on configuring AD DS PSOs (Password Security Objects) and how they can be implemented in your environment to enforce acceptable password restrictions beyond what native AD GPO supports.

The Arbitrary: A drive for longer passwords.

About the time you’ve finished reviewing your SOX-DSS-HIPAA-Omnibus-PCI-CJIS-FBI-CIA-BYOBeer audit findings, your empathic auditor reveals the progressive requirement of a “15 character minimum password.” Possibly because last year’s policy change and enforcement of a “14 character minimum password” was too much fun to not be an annual experience, you know a headache will soon ensue.   As the Active Directory Admin, you are about to learn the crux of backwards-compatibility and how it is limiting today’s security platforms.

Backwards Compatibility Limits Security

History Lesson for the Post-Millennials

Back in Windows 95/98 days, passwords were stored using the LM Hash.  The LM hash method was secure in its day– a password would be same-cased, padded to 14 characters, broken into two 7 character halves, and each half is used to encrypt a static string.  The resulting two encryptions are put together, forming the LM Hash stored password.  Arguably LM Hash and cryptographic functions in yesteryear were sufficient mechanisms to store a password and data without the threat of a timely brute-force compromise.  Today, a lean built hashcat system will brute force 100 LM hashes in just a few moments.

While Microsoft systems eventually retired the LM Hash for more secure (yet still compromisable) hash functions, the backwards compatible cryptography remained for years following NT4, leading systems into the new millennium with  password vulnerabilities and limiting acceptable Group-Policy configurations.  Native Active Directory group-policy password settings still haven’t graduated from the 14 character stigma, this is most relevant when attempting to set a “15 character minimum password”.

Group Policy Limitation

Fear not, die-hard Windows 2012 GUI loving admins: Active Directory can natively support 15+ minimum character passwords, all from the GUI and without headaches!  Windows 2008 AD DS introduced “Fined Grained Password Policies” or Password Setting Object (PSO).  PSOs instead of using a computer-object Group Policy targeted specific Active Directory user accounts or user groups.  However, creating a PSO in Windows 2008 was still reserved for ADSI editors and PowerShell ninjas (See more information at bottom).  In Windows 2012, the feature moved from the back-end Active Directory management and into a front-end GUI buried within the seldom used Active Directory Administration Center. More importantly though, in our hunt to overcome password character limitation requirements, PSOs allow for a maximum value of the minimum password character length 255 characters, effectively preventing password changes.

PSOs in Windows 2012+

Setting up PSO’s within Windows 2012+ is easy and won’t affect users until they attempt their next password change.

Buyer beware and always test your work, however; see caveats at bottom.

Control Panel -> System and Security -> Administrative Tools -> Advice Directory Administrative Center

DomainName -> System -> Password Settings Container

Right Click -> New -> Password Settings

Complete the PSO settings and assign a User or User Group target.  To assign the policy to all users, use “Domain Users”.  Notice in this test we have specified 20 characters to be the minimum length for acceptable passwords.

Testing your work:

Changing password with a new 15 character password:

Test your work:

Changing password with a new 20 character password:

Caveats and Considerations:

There are a couple of serious considerations that should be made when using a PSO to configure a password requirement.  On Administration and troubleshooting, PSO’s don’t lend themselves nicely in an RSOP, so be sure your administrators know to check for PSOs if your support desk is hearing about password-change headaches.  Know that because the PSO is targeting domain user accounts instead of domain computer accounts, workstation/server local user accounts will not be affected, nor will domain computer accounts be affected.  It is important therefore to operate both the typical Active Directory Group Policy as well as the PSO to limit acceptable passwords.

There are other alternatives to using a PSO to set the password policy to limit acceptable passwords.  There are HKLM reg-hacks that will force submissive systems to specific password lengths.  There is also a decade’s old solution of building a custom password filter library and registering it in the system.  Regarding backwards compatibility & LM Hashing, there are solutions within Group Policy and HKLM for that too.

As Microsoft slowly closes the backward-compatibility security gap, we may eventually find that the Password Policies within native AD DS Group Policies will begin to catch up to the security standards of today and forcing a 7, 14, 15 255, 500 character minimum password that will be no headache at all– Or, we’ll all just be chiseling stone tablets.

On a last note, be sure to buy your internal auditors and pen-testers breakfast.

More Information:

Creating a PSO in Windows 2008: https://technet.microsoft.com/en-us/library/cc754461(v=ws.10).aspx

LM Hash information: https://technet.microsoft.com/en-us/library/hh994558(v=ws.10).aspx

Preventing the use of LanMan Hash: https://support.microsoft.com/en-us/kb/299656