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.

"`'$Password`'"

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…

$DomainNETBIOSName = '<YourNETBIOSDOMAINNAME>'
$Password = '<VALIDPASSWORD_OR_NOT>' | ConvertTo-SecureString -AsPlainText -Force
$UserName = "$DomainNETBIOSName\<VALIDUSERACCOUNT>"

#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, `
$DomainAdministratorCredential.GetNetworkCredential().Password)

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

$prnContext.ValidateCredentials($UserName,$credential.GetNetworkCredential().Password)

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…

Ttyl,

Urv

Advertisement