Archive

Posts Tagged ‘Active Directory’

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

Quick Post: Get Login Script for Users

February 12, 2015 Leave a comment

Get-ADUser -Filter * -SearchBase “DC=domainname,DC=com” -properties ScriptPath | select Name,ScriptPath

Quick Post: Count users in an OU structure in AD

February 5, 2015 Leave a comment

Get-ADUser -Filter * -SearchBase “OU=Users,OU=Company,DC=domain,DC=com” | Measure

You’ll get something like this.

Count    : 377
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

Quick Post: Get a user’s group membership via PowerShell

February 4, 2015 Leave a comment

Get-ADPrincipalGroupMembership -Identity USERNAME | select name

or

Get-ADUser -Identity USERNAME -Properties MemberOf | Select -ExpandProperty MemberOf

Change the Case of a User Logon Name

August 21, 2012 2 comments

I need to change the case of a user’s logon name from TUser to tuser. Seems simple enough but turns out there’s a little trick.

I open up the properties of the user & select the Account tab.

I change both fields to tuser & click OK.

I open the properties again to double check & notice that the User logon name (pre-Windows 2000) changed but User logon name did not.

The trick is to rename the account without actually renaming it. Right click the account & select Rename.

Now retype the name exactly how it currently is & press Enter. So in my case I just type Test User & press Enter. That will bring up the Rename User dialog box. From there change the case in the User logon name textbox (& pre-Windows 2000 if not already done) & click OK.

Look at the properties of the account & the case had been changed.

Categories: Computers Tags:

Quickpost: Users & Phone Numbers

Get-QADUser -SearchRoot "abc.com/Company/Users" | Select DisplayName,title,department,physicalDeliveryOfficeName,telephoneNumber | Export-Csv C:Tempphonebook.csv
Categories: Computers Tags:

No Certificate Templates Could Be Found Error

February 14, 2012 10 comments

I was doing a little Active Directory Certificate Services (AD CS) testing in the lab. I came across the following error when browsing to the web enrollment page, “No certificate templates could be found. You do not have permission to request a certificate from this CA, or an error occurred while accessing the Active Directory.”

Searching around online I found plenty of articles & posts on this error but none of the solutions fixed my issue. After three days of troubleshooting here’s what worked for me.

Being a lab at some point I had changed the Authentication settings in IIS on both CertEnroll & CertSrv to Anonymous Authentication Enabled & Windows Authentication Disabled.

When I changed them back to the defaults which are Anonymous Authentication Disabled & Windows Authentication Enabled I stopped getting the error.

Update Fax Numbers in AD Using PowerShell

January 4, 2012 Leave a comment

Just a quick post on how to change the fax number for several users who use 555-555-1234 to 555-555-4321.

 Get-QADUser -SearchRoot "abc.com/ABC/Users" -LdapFilter '(facsimileTelephoneNumber=555-555-1234)' | Foreach-Object{Set-QADuser -Identity $_ -ObjectAttributes @{facsimileTelephoneNumber='555-555-4321'}} 

Making AD Changes using PowerShell (Company Attribute)

Note – This post deals with making bulk changes to Active Directory. If you’re not careful you could really screw things up. Always test in a lab before making such changes in production.

This is just a quick post for a little something I had to do today. I’ve been doing some Active Directory cleanup & noticed we have some users that have the Company attribute populated & some that don’t.

Using the Quest ActiveRoles Management Shell for Active Directory (http://www.quest.com/powershell/activeroles-server.aspx) I ran the following cmdlet to add the correct company name to all users in a specific OU & all sub-OUs who do not have the Company attribute populated.

Get-QADUser -SearchRoot "abc.com/ABC/Users" -Company "" | ForEach-Object{Set-QADUser -Identity $_ -Company "ABC Company"}
%d bloggers like this: