Validating a user’s password

I blogged about Random Complex passwords in the past, here’s a follow up.

The first time around I only needed to generate a random password. Now I was also in charge of setting the password as well. Let’s just say I was in for a little surprise… 🙂 Generating the passwords wasn’t the issue. I noticed that when applying the password, I got errors about the complexity. Here’s where color coding can be your friend.

Just a quick refresh:

Complexity Password Dictates that it must:

Contain characters from three of the following four categories:
1: English uppercase characters (A through Z)
2: English lowercase characters (a through z)
3: Base 10 digits (0 through 9)
4: Non-alphabetic characters (for example, !, $, #, %)

Did you see it? No? In the Non-alphabetic  category, characters $ and # are valid Password characters but in PowerShell they’re reserved.

So a random password like JikLO$02 is valid, however $02 could be misinterpreted depending on how it’s called. Same goes for MnqTy#98.

I generated random plaintext (Yeah I know right? Shame on me… But that’s another discussion) saved the UserName and Password in a csv file for later use.

Now all I need to do is loop through my csv file do a

get-user -id $username | Set-ADAccountPassword -reset -NewPassword (ConvertTo-SecureString -AsPlainText $Password -force)

and I’m good to go right? Well if your password has a # or $ it will generate an error.

So at this point I had a few options:

Option 1
Get rid of $ and #, so no Non-alphabetical category . To be a valid Complex password I only need three out of the four categories. It will still be random but as a scripter my  honor is at stake here… 🙂

Option 2
Make the string literal! Until recently I’d never given it much thought when it comes to single or double quotation strings. At the time I was under pressure, so I went with Excel and did a concatenate to get the single quote around the $Password value.


I know…

So that was how I ended up solving that issue. It worked. I had a few users that locked out because they didn’t know if it was a zero or the letter O (Yes I told them that could be an issue) Mission accomplished! Still, I had my reservations, I need to be certain in the future that the username-password pair is accurate & valid.

Now the easiest way to verify this is by logging on. As a test, not a problem for one account. All accounts isn’t an option. Besides we also flagged the accounts to change the password at logon, so there’s that as well.

I found some nifty stuff in the DSC Resoucekit wave 6 MSFT_xADUser.psm1 script.

It turns out you can validate credentials without having to logon! Say what now? Yup!
So no more wondering if the username-password pair matches? Yes indeed!!!

So here’s the code to verify for just one but you get the idea…

$Password = '<VALIDPASSWORD_OR_NOT>' | ConvertTo-SecureString -AsPlainText -Force

#It's possible to change your AD Context

$DomainAdministratorCredential = Get-Credential

Add-Type -AssemblyName 'System.DirectoryServices.AccountManagement'

$credential = New-Object System.Management.Automation.PSCredential($UserName,$password)

$prnContext = new-object System.DirectoryServices.AccountManagement.PrincipalContext(
'Domain', $DomainNETBIOSName, $DomainAdministratorCredential.UserName, `

#Validate user password. this will return a $true if valid or $false if not


Bonus: It doesn’t change the “User must set password at next logon” flag

So there you have it. Setting Complex Random passwords and confirming it!!!

Gotta love PowerShell… So much to explore…




Leave a Reply

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

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

Facebook photo

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

Connecting to %s