Sponsored: Active Directory Cleanup – Removing Stale Objects

adaxes-active-directory-cleanup

Editor’s Note: This blog post is the second in a four-part blog series from Adaxes.

Due to the nature of the tasks Active Directory (AD) performs as an identity management solution, inactive objects are not only an inconvenience, cluttering the directory with outdated and unused objects, but also pose a security risk.

User and computer accounts have passwords, so they can authenticate with AD, and like any object with credentials, provide a means of entry to your systems. Although other AD objects, such as Organizational Units (OUs) and groups, can also pose security and operational risks if not properly managed.

Prevention is better than cure, so managing the full lifecycle of user objects so that they are added, updated, and removed in a timely manner can reduce security concerns. But as organizations tend to have more devices than employees, there might not be a one-to-one relationship between devices and users, so managing the lifecycle of machine accounts isn’t always so simple.

Computers accounts authenticate to AD using a password, with the only difference from user accounts being that the password is changed every 30 days and this process is initiated by the computer, not AD, so the computer must be turned on and connected to a domain controller at least once a month. Additionally, computer account passwords don’t expire, so a password that’s older than 30 days can still be used until a password change is initiated by the client device.

Removing Stale Objects Using PowerShell

Although prevention is better than cure, it’s inevitable, especially in the case of machine accounts, that you will end up with stale objects in AD. And because of the security risk that these objects pose, you should have a strategy to deal with them.

The most common way to handle this issue is to use a PowerShell script to parse AD that flags computer accounts that haven’t had a password change in 30 days, and user accounts that haven’t logged in for a determined period of time.

Using the Get-AdComputer and Get-Date cmdlets, plus a simple filter, I can return a list of machine accounts in AD that haven’t had a password reset in more than 30 days.

$date = (Get-Date).adddays(-30)

Get-AdComputer -Filter {passwordlastset -lt $date} -Properties passwordlastset | Select name, passwordlastset | sort passwordlastset

And if I’m happy with the results, I can then remove the accounts from AD by piping the results of Get-AdComputer to the Remove-AdObject cmdlet:

Get-AdComputer -Filter {passwordlastset -lt $date} -Properties passwordlastset | Remove-AdObject -Recursive -Verbose -Confirm:$false

If you have a Windows Server 2003 functional domain level or higher, you can use the Search-ADAccount cmdlet to return a list of inactive users by looking at the LastLogonTimeStamp attribute, which unlike the LastLogon attribute, gets replicated between domain controllers. Although it’s worth noting that AD updates the LastLogonTimeStamp attribute only about once every 12 days, to reduce network replication traffic, so it has limited accuracy but might be fine if you want to search for who hasn’t logged on in the past few months. The following command returns a list of users that haven’t logged in for the past 90 days:

Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00

AD groups that are assigned permissions to sensitive data or systems might provide a way for an attacker to elevate privileges. Similarly, PowerShell can also be used to scan AD for empty groups using the Get-AdGroup and Get-AdGroupMember cmdlets:

Get-AdGroup -Filter * | Where {-Not($_ | Get-AdGroupMember)} | Select Name

If AD isn’t cleaned up on a regular basis, the chances of a security breach increase, so a regular review of objects needs to be undertaken. And the most thorough way to perform this task is using some form of automation, as it’s easy to miss something if you rely on a manual effort. It’s also wise to move objects to a dedicated OU where they can be reviewed and then deleted after a period of time.

Softerra Adaxes

Administrators are often reluctant to use PowerShell scripts alone for removing stale objects for fear of breaking critical systems. Third-party AD management solutions, such as Softerra Adaxes, can take much of the risk out of the process by first focusing on prevention (i.e., managing the full lifecycle of user accounts) and adding the ability to run scheduled tasks that are based on rules, which can then be integrated into a workflow that requires approval. So rather than blindly deleting accounts that have been automatically identified as inactive, approval can be required from a manager to establish that the object is no longer needed.

Adaxes also uses a more intelligent approach to determining a user’s last logon date by applying its own algorithm to provide more accuracy than AD’s LastLogonTimeStamp. The flexible nature of Adaxes lets system administrators create rules for dealing with empty security groups and OUs, plus the ability to archive inactive Exchange mailboxes and run reports on stale objects, among many other AD automation tasks that a critical for maintaining a healthy and secure directory.