Tool to Toggle Active Directory Accounts in an OU using PowerShell

Inactive AD Accounts? Why are they a Problem?

I have not found many consistent ways to offboard users into an Organizational Unit, then persistently check to see if the accounts are disabled. Sometimes an account slips by into an OU containing disabled accounts. Inactive AD accounts are usually compiled from a lack of communication between departments, usually HR and IT. Employees that were recently promoted or let go might still have an inactive account floating around the organization’s domain. This blog post by Lepide explains in-depth why this is a major (and preventable) security concern. In this post I will quickly explain a way to remediate this issue via a GPO, and also provide a PowerShell script that runs as a scheduled task on your Domain Controller.

Prevent Inactive AD Accounts with GPO

GPO to Disable Accounts (kinda)

I have not found many consistent ways to offboard users into an Organizational Unit, then persistently check to see if the accounts are disabled. Sometimes an account slips by into an OU containing disabled accounts. You would think they have a Group Policy to set the Enable attribute to False, but I could not find it. The best way I found to disable accounts in an OU was to set the Maximum Password Age to 0. You can do this by

• Opening Group Policy Management and Creating a new GPO
• Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policies
• Set the Maximum Password Age policy to 0
• Link the GPO to the Organizational Unit with the user account you want to disable

Why This Isn’t a Great Solution

Imagine you have a car, and you want to prevent someone from driving it. One way to do this might be to take out the key and hide it somewhere. Now, without the key, nobody can start the car and drive it. This is like directly disabling the car from being used.

Now, let’s consider another approach. Instead of taking out the key, you decide to make a rule that says every time someone tries to start the car, they have to change the seat covers inside the car. And not just once, they have to change them every single day. This makes it so inconvenient to use the car that nobody bothers trying to drive it.

The first approach is like directly disabling the car. It’s straightforward and does exactly what you want. The second approach, however, is like setting the maximum password age to 0 days. It’s not directly disabling the car (or the user account), but it’s making it so inconvenient to use that it might as well be disabled.

So, while setting the maximum password age might make the user account effectively unusable, it’s not the most straightforward or clear way to accomplish the task. It’s like using a workaround when a direct solution is available.

Disabling AD Accounts in an OU with PowerShell

Defining Parameters and variables

When you’re calling the script, you need to pass in arguments. Let’s define these parameters and declare a few variables to use in our script.

param (
    [Parameter()]
    [Alias("OrganizationalUnit")]
    [String] $ou = ($($env:USERDNSDOMAIN).Split(".") | %{"DC=$($_)"}) -join ",",

    [switch] $enableAccounts
)

$currentDate = $(Get-Date -f yyyyMMdd)
$enableVal = $enableAccounts.IsPresent
$action = if($enableVal){"Enabled"} else {"Disabled"}
$taskName = "$action AD accounts task"

The parameters are OU and enableAccounts. The default argument is the root domain name, so don’t make the mistake of disabling every account in your environment. This was good practice to parse the Distinguished Name of the domain before the ActiveDirectory Module was imported by using the Automatic Variable $ENV. We get the current date, detect if the switch enabledAccounts is present, use the equivalent of a ternary operator in PowerShell to determine the action (Enable or Disable) and declare the scheduled task name.

Validate the ActiveDirectory Module is Imported

Start-Transcript -Path "$((Get-Location).Path)\$action-accounts-$currentDate.txt"

if($null -eq (Get-Module ActiveDirectory -ListAvailable)){
    try {
        Import-Module ActiveDirectory
    }catch {
        Write-Error $_.Exception.Message; exit 1
    }
}

Enable or Disable AD Accounts in an OU with PowerShell

Now, using the switch and the OU parameters passed in, we are going to use the Get-ADuser cmdlet, then loop through the users in the OU that are NOT $enabledVal. This throws me off a bit but look at it and notice the boolean logic works in our favor. Maybe some of you are good at identifying recursive techniques. Leave a comment or Contact Me if you are!

$allADUsersInOU = Get-ADUser -Filter "Enabled -eq '$(-not $enableVal)'" -SearchBase $ou -Properties *
foreach( $user in $allADUsersInOU){

    try{
        $desc = "$action by $env:username on $currentDate"
        Write-Output "$($user.SamAccountName) currently $($user.Enabled) - Enabled $enableVal - $desc"
        Set-ADUser -Identity $user.SamAccountName -Enabled $enableVal -Description $desc
    }catch{
        Write-Output $_.Exception.Message
    }
}

Since we used Start-Transcript, all of our output will be captured and placed in the text file we created, so I decided to leave the write cmdlets. We parse a nice description and use the Set-ADUser cmdlet to pass in the Boolean value for the Enabled property.

Schedule the Script to Run Using PowerShell

Ok, we learn something new every day, and this was one PowerShell technique I learned and want to implement more at work. Scheduling tasks with PowerShell is great. Scheduling our own PowerShell scripts is even better!

if($null -eq (Get-ScheduledTask -TaskName $taskName -ErrorAction SilentlyContinue)){
    Write-Output "Creating task"
    $enabledAcctArg = if($enableAccounts.IsPresent){ '-enableAccounts' }else{ '' }
    $arg = "-NoProfile -NonInteractive -ExecutionPolicy Bypass -File `"$($MyInvocation.MyCommand.Path)`" -ou `"$ou`" $enabledAcctArg"
    $trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At 7pm

    $triggerAction = New-ScheduledTaskAction -Execute "PowerShell" `
        -Argument $arg `
        -WorkingDirectory $PSScriptRoot `

    Register-ScheduledTask -TaskName $taskName -Action $triggerAction -Trigger $trigger
}

Stop-Transcript

We

We test if the scheduled task exists using Get-ScheduledTask and if it’s $null, we create the task, this is fairly straightforward and there is documentation on this, but notice our $args variable? It’s important to parse the string properly. So, this task will

• Execute a PowerShell Process
• Use the arguments “-NoProfile -NonInteractive –ExecutionPolicy Bypass
• Use the additional arguments -File `”$($MyInvocation.MyCommand.Path)`” -ou `”$ou`” $enabledAcctArg”
• The working directory is the path the script runs from, or $PSScriptRoot

*Note, I mentioned the $MyInvocation Auto Variable Here. When you call the script, it would look something like this:

.\disableAccountsInOU.ps1 -ou "OU=Disabled Accounts,DC=testing,DC=local"
#---- or to enable accounts in OU-----------------------
.\enableAccountsInOU.ps1 -ou "OU=Domain Users,DC=testing,DC=local" -enableAccounts

You can modify the intervals in New-ScheduledTaskTrigger and make it run when you want. Check Task Scheduler to be sure the task was created, and you can also edit it from here. Check the tabs including General, Triggers, Actions, etc.

Conclusion

I learned a lot during this small project, and I hope you did too. We covered some ActiveDirectory cmdlets and also learned to schedule our own task using PowerShell. Furthermore, there was some string manipulation and parsing that was good practice. In conclusion, this post can help you in other projects or endeavors with a better understanding of toggling Active Directory accounts and task scheduling using PowerShell. You can modify the existing code and make it fit your needs or leave a comment and I can try to assist you!