Archive

Posts Tagged ‘userAccountControl’

Users not receiving email about an expiring password

February 16, 2016 2 comments

WARNING – This post deals with making bulk changes to Active Directory. Proceed at your own risk.

I’ve been using the script (with a few tweaks) from http://rlmueller.net/PasswordExpires.htm to send users an email notification when they are within the configured Prompt user to change password before expiration policy. It works great but every once in a while a user would call because their password had expired & they did not receive the email. Over time occasionally that same user or a few other ones would call with the same issue.

Finally, one day another user called describing the same thing. Time to get to bottom of this one. I took a look at the user’s Active Directory account & sure enough the pwdLastSet attribute was over 90 days old. I took my script & modified it so I could just see the results without sending any emails. Your results with the original script may vary but at a minimum comment out the line that sends the email & instead pipe the output to the console.

# SendEmail $Mail $Notice

Write-Host $Name”,”$PwdExpiresDays

Sure enough when I ran it the user reporting the issue was not showing up in the results.

The script filters the results a little as noted below.

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `

   + “(pwdLastSet>=” + $($64Bit1) + “)” `

   + “(pwdLastSet<=” + $($64Bit2) + “)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=65536)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=32)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=48))”

So I modified the filter (see below) to just show all users & ran it again. This time the user having the issue showed up.

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user))”

So at least now I know the script is working but for some reason the user is being filtered out. I add each filter back one at a time to figure out which one is causing the user to be excluded. I skip over the two pwdLastSet filters because the account is already at 0 so that could cause it to not show up. So now my filter looks like this:

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=2))”

 

The user still shows up. On to the next one.

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=65536))”

 

Still there…next.

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=65536)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=32))”

 

Bingo! The user isn’t showing up. So I do a little checking & find that !userAccountControl:1.2.840.113556.1.4.803:=32 will exclude users that aren’t required to have a password. Huh? Now why would any of my user accounts be configured to NOT require a password? So that begs the question, how many users are configured like this? I run the following Powershell command. The results will vary depending on your environment but suffice to say you do not want a lot. (Hint hint some may legitimately need to be configured like this.)

Get-ADuser -LDAPFilter “(userAccountControl:1.2.840.113556.1.4.803:=32)” | Select-Object name

You can even see this by looking at the userAccountControl attribute in AD & see that it is set to PASSWD_NOTREQD | NORMAL_ACCOUNT.

In all my years I’ve never seen this before so I did a little digging & ran across this TechNet post.

http://blogs.technet.com/b/pfesweplat/archive/2012/12/11/do-you-allow-blank-passwords-in-your-environment.aspx

Long story short, a long time ago when “someone” migrated user accounts they may have done it wrong.

But enough pointing fingers, how to fix it. Use the Set-ADUser command to set the user’s PasswordNotRequired flag to $false.

Set-ADUser -Identity jsmith -PasswordNotRequired $false

I’ll leave it up to you how you want to modify all the affected users. Just be careful as there may be a legitimate account that needs this setting. Again, proceed at your own risk. I just filtered based on OU.

Get-ADuser -LDAPFilter “(userAccountControl:1.2.840.113556.1.4.803:=32)” -SearchScope Subtree -SearchBase “OU=Company,DC=contoso,DC=com” | Set-ADUser -PasswordNotRequired $false

Advertisements
%d bloggers like this: