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:
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… 🙂
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.
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…