Print Spooler Service Nightmares for Domain Controllers
Compromised Domain Controllers are every Active Directory admin’s nightmare. However, Domain...
Once a business begins to use Active Directory more and more, depending on how large the organization is, objects have the tendency to become "stale." Every employee typically has an Active Directory user account. They are assigned one the day they are hired. At the same time, if they received a computer, that computer was probably joined to the Active Directory domain. Now, let's say they were assigned to a personal printer and they need to share that printer with “Bob” down the hall. “Susie's” printer could now go into Active Directory. What about Susie's computer's DNS record? Many companies choose to integrate DNS with Active Directory as well which is yet another object in Active Directory! You get the point.
The most common Active Directory objects are users and computers. Let's say Susie's in a multi-national company with tens of thousands have user accounts and computers and employees that are all getting hired, fired, laid off or face job role changes that don't require Active Directory objects anymore. Her company has had an Active Directory domain for 10 years now but has never really planned a proper process to manage Active Directory changes when job roles change. Imagine what you'd find if you lifted the covers in that AD environment! You'd probably see thousands of accounts that weren't being used anymore that are simply forgotten. They might be disabled but not where unnecessary attack vectors are open to the bad guys.
How does a company figure out which computers and user accounts are "stale" and how to responsibly remove them? Notice how I said responsibly? As a careful Active Directory engineer you're not going to simply remove them immediately, right? Even though a user or computer account may show up as inactive for a year, chances are, if you've got enough of them, someone is going end up wanting to use that account the minute you remove it. I'll show you how to prevent that.
I'll be using Powershell for all the scripts I'm about to show you. I prefer you have at least Powershell v4 which requires you to have at least Windows 7. Version 3 will work too but there's no reason to go to v3 if you've got Windows 7; just get up to v4 while you're at it. So, without further ado let's get down to business!
Step 1 - Installing the Powershell Active Directory Module and any Prerequisites
If you’re not doing any kind of Active Directory maintenance, this is a one-time step. If your domain is still on Windows Server 2008, you will need to download and install the Active Directory Management Gateway Service. The Scripting Guys blog has a great article on how to do that. Once you've got that installed on a domain controller or you're already up to a Windows Server 2012 domain you'll need to get the Remote Server Administration Tools. I'm assuming you'll be running these scripts on an admin workstation of yours. If you're on Windows 8 or higher you’ll just need to use the Add Features control panel applet.
Step 2 - Defining "Inactive"
Before you get started scripting it's important that you don't just “wing it.” Especially when you're most likely going to be potentially modifying hundreds or thousands of accounts! Once our Powershell environment is setup I now need to figure out exactly what "inactive" means. I'm talking about inactivity periods. I recommend a minimum of 8 weeks. The reason I recommend 8 weeks is because this accounts for normal inactivity periods such as vacations, some medical leave, FMLA, etc. If I'm deathly sick or I've got 30 years with the company and have 5 weeks of vacation I would not want to come back to no account! This goes for both user and computer accounts.
This will be different in every organization so please be conservative here. Don't go crazy and think 2 weeks is more than enough time to indicate when something is no longer necessary and axe it.
Step 3 - Discovering and Removing Inactive Accounts with Powershell
We are discussing computer and user accounts in this article so let's break this down by each one.
Inactive computer accounts tend to build up after a while. This typically happens when computers are removed from the domain but are not removed from Active Directory. Even if a computer is actually disjoined from the domain the computer account remains but remains disabled. In my experience though, this is rarely done. Turning it off and reformatting it is what I typically see. So how do we find and remove them?
The Active Directory module has made it very easy to find and remove disabled computer accounts. Search-AdAccount -AccountDisabled -ComputersOnly | Remove-AdComputer -Confirm:$false
Here's a couple ways I've used it in the past to find inactive computer accounts older than 60 days inactive. These use both the LastLogonDate and PasswordLastSet attributes. Search-AdAccount -AccountInactive -ComputersOnly -Timespan 60.00:00:00 | Remove-AdComputer -Confirm:$false
Get-AdComputer -Filter * -Properties LastLogonDate | where {$_.LastLogonDate -lt (Get-Date).AddDays(-60)} | Remove-AdComputer -Confirm:$false Get-AdComputer -Filter * -Properties PasswordLastSet | where {$_.PasswordLastSet -lt (Get-Date).AddDays(-60)} | Remove-AdComputer -Confirm:$false
Finding all disabled user accounts Search-AdAccount -AccountDisabled -UsersOnly
Finding all user accounts that haven't been used into in 60 days or more. Search-AdAccount -AccountInactive -UsersOnly -Timespan 60.00:00:00 | Remove-AdUser -Confirm:$false Get-AdUser -Filter * -Properties LastLogonDate | where {$_.LastLogonDate -lt (Get-Date).AddDays(-60)} | Remove-AdUser -Confirm:$false
As you can see, both account types are very similar to work with when using the Powershell Active Directory module. If you want to simply discover these accounts and not actually remove anything all you need to do is remove the | Remove-AdComputer and| Remove-AdUser pieces.
Managing an Active Directory domain can be a daunting task at first. However, as you begin to get used to Powershell and the Active Directory module it gets easier. I highly suggest after cleaning up Active Directory for the first time to schedule this maintenance on a regular basis. This is a task that could be easily automated via a scheduled task so you won't even have to think about it again!
Compromised Domain Controllers are every Active Directory admin’s nightmare. However, Domain...
Brace yourselves! In the coming months, Microsoft is planning another round of Windows server...