Finding Expired User Accounts in AD and Resetting Their Passwords with PowerShell

June 2, 2014 at 4:01 pm

The Setup

I came into the office today and was bombarded with users not being able to access our TFS server. Now, before I get too far into this story, you have to understand: Technically I’m only responsible for client-facing infrastructure. However, over the years I’ve started wearing more of a devops hat because, apparently, I’m quite good at it. That means TFS is now largely my problem. Funny how that works, eh? Anyway, back to TFS.

There were a few odd things about this issue: the oddest being that some of our off-shore developers were having no problems and others just couldn’t get in. The users with issues also couldn’t access the web portal. We (at least me) hadn’t made any changes to TFS in about a month, so I started to investigate.

After a brief panic about SharePoint not being installed properly (Hey, I didn’t set up this system, I’m just its current keeper) I managed to trace the issue to network logons. Thank you Security log! Wait, what’s this? Turns out many, many users recently had their accounts marked as expired… Turns out we just implemented mandatory password rotation and guess what? Today – 90 days was the day that a large batch of offshore development accounts were created! So now I had to reset credentials on 35+ accounts, and I’ll be damned if I’m going to do that manually!

Enter PowerShell!

List all accounts in an OU that have expired passwords

Get-ADUser -searchbase "ou=contractors,dc=example,dc=com" -filter {Enabled -eq $True} -Prop PasswordExpired | Where {$_.PasswordExpired } |select-object -property SAMAccountName,Name,PasswordExpired |format-table

Get-ADUser

SearchBase tells the Get-ADUser command to limit the search to a specific OU. This is very handy since I only have admin access to the one OU anyway. I filtered only for enabled accounts since trying to filter on PasswordExpired here didn’t work for some reason. I also explicitly called out the PasswordExpired property.  This output was piped to the where-object commandlet.

Where-Object

This was where I filtered on the current object group. Since passwordExpired is a bool, no fanciness needed here. Then I piped the output to Select-Object.

Select-Object

I only cared about some specific data for the output. I used this to select the properties I needed. Finally, I piped to Format-Table to make everything display nicely.

Reset passwords for accounts in an OU with expired passwords

Get-ADUser -searchbase "ou=contractors,dc=example,dc=com" -filter {Enabled -eq $True} -Prop PasswordExpired | Where {$_.PasswordExpired } | ForEach-Object {Set-ADAccountPassword -Identity $_.SAMAccountName -NewPassword (ConvertTo-SecureString -AsPlainText "Changeme1" -Force) }

Get-ADUser & Where-Object

These are the same as in the section above. We are filtering for enabled accounts in the contractors OU. This was piped to one of my favorite commands on earth: ForEach-Object.

ForEach-Object

This is, hands down, one of the handiest commands in PowerShell. Or any language for that matter. In this particular instance, we are running the Set-ADAccountPassword option for each object that we pass in. We pass the object’s SAMAccountName as the identity. We then create a new secure string password and pass that to -NewPassword. Then you hit enter and the magic runs!

 

Monitors and Caching DNS

June 20, 2013 at 4:53 pm

Had an interesting issue today. One of the production systems suddenly went dark, and we found out about it from the client. This is never a good way to start a Thursday. It turns out that the client was having DNS issues and the domain was no longer valid. Relatively simple fix, crisis averted…

But why didn’t the monitoring system pick it up?

We use Dotcom-Monitor to check each of our sites on a regular basis. The monitor actually logs in to each website to verify functionality. What in the DNS world could cause this issue in such a scenario? How about a caching nameserver? Turns out, to limit the stress on their nameserver, Dotcom Monitor set up a standard caching nameserver that keeps a record in cache until the record expires. So even though DNS was no longer working for this site, the monitor thought everything was A-OK.

What can we do to fix this issue? Not much unfortunately. Dotcom Monitor will have to implement a change in their infrastructure which will likely increase the load on their DNS servers significantly. Since that’s not likely, it looks like I’ll have to build a service into our internal monitor (Zabbix based) to check for the domain against the SOA for it.

PageSpeed score of 96/100!

June 12, 2013 at 5:21 pm

PageSpeed Insights ScreenshotAfter configuring W3 Total Cache and playing around with google’s free PageSpeed Insights tool, I was able to increase The End of the Tunnel’s score from 49 to 96! This is impressive to me because this site currently runs on the basic DreamHost shared environment plan. No dedicated servers, no fancy configurations, just good cache management. Fantastic!

Flush DNS Cache for a Single Domain

June 11, 2013 at 10:13 am

I was working on the site today and ran into an issue: Our caching DNS server (Windows 2008) was holding on to the old webserver’s IP. This wasn’t a problem for me locally as I used the old hosts file trick to point to the new server. However, this meant I couldn’t show other folks the site until either the cache was completely flushed or the record expired.

A little googling later, and I found this little command from ServerFault.

dnscmd dnsserver.local /NodeDelete ..Cache whatever.com [/Tree] [/f]

/tree    Specifies to delete all of the child records.

/f       Executes the command without asking for confirmation.

This allows you to clear just a small portion of the cache, as you define it. Pretty handy!