Discover Inactive Person Accounts In Your Area

Energetic Listing is a listing service that maintains details about customers, computer systems and associated objects. It’s a database of relational info that wants periodic upkeep to stay helpful and related. A listing may have accounts now not used. Discovering these accounts in Energetic Listing isn’t as simple because it sounds at first look. Let’s stroll via discovering inactive person accounts and automating eradicating them.

Desk of Contents:

Outline search standards

We have to outline what we’d like for our course of. Our aim is to find worker accounts that haven’t logged into the community for an prolonged interval. I’ve all the time used 90 or 120 days as measure to question inactivity by. You may go as little as 30 days earlier than the outcomes change into not related, however greater values are higher. That you must resolve what is true on your group. 90 days provides a sufficiently big cushion to permit for folks out of the workplace for trip, household emergencies, or prolonged medical leaves. As soon as the accounts attain 90 days of inactivity, we need to disable these accounts and transfer them to a separate OU.

Defining what we’re on the lookout for first permits us to construct a easy rule set to observe. Our rule set seems to be like this:

• Discover and disable energetic accounts that haven’t any logon exercise for 90 days.
• Transfer every disabled account into the Disabled-Customers OU
• Mark every disabled person with a remark that an automatic course of disabled it.

Discover account inactivity properties

Every person account has a number of attributes containing login info. We need to discover attributes that present final login time. If we are able to discover these attributes, we are able to use them to question for accounts not logged in since a sure date. We’ll use PowerShell to show all of the attributes and choose an attribute to work with.

Get-ADUser is essentially the most used cmdlet for displaying person info. You may use Get-ADObject or Search-ADAccount, however Get-ADUser is what I’ve selected to make use of this activity. To indicate all of the person properties, we have to add -properties * to the cmdlet syntax. Depart that syntax out, and AD will solely return the ten default properties.

Get-ADUser Michael_Kanakos -Properties *

We return an extended listing of fields from our question (over 150!). We will seek for attributes include specific phrases through the use of wildcards. This helps us find attributes that could be helpful for our activity. We need to discover logon info, so let’s seek for attributes containing the phrase Logon.

As soon as PowerShell returns all properties, we must always restrict the listing of properties to solely those that the match phrase Logon. Choose-Object gives the power to do a wild-card match and limits our outcomes. The | character (referred to as “the pipe”) takes the outcomes on the left and passes them to Choose-Object. Choose-Object then performs the wild-card matching after which limits the outcomes primarily based on our wild-card standards.

Get-ADUser username -Properties * | Choose-Object *logon*

BadLogonCount          : 0
lastLogon              : 132181280348543735
LastLogonDate          : 11/11/2019 9:08:45 PM
lastLogonTimestamp     : 132179981259860013
logonCount             : 328
LogonWorkstations      :
MNSLogonAccount        : False
SmartcardLogonRequired : False

We return an extended listing of fields from our question (over 150!). We will seek for attributes include specific phrases through the use of wildcards. This helps us find attributes that could be helpful for our activity. We need to discover logon info, so let’s seek for attributes containing the phrase Logon.

As soon as PowerShell returns all properties, we must always restrict the listing of properties to solely those that the match phrase Logon. Choose-Object gives the power to do a wild-card match and limits our outcomes. The | character (referred to as “the pipe”) takes the outcomes on the left and passes them to Choose-Object. Choose-Object then performs the wild-card matching after which limits the outcomes primarily based on our wild-card standards.

The | character (referred to as “the pipe”) takes the outcomes on the left and passes them to Choose-Object. Choose-Object then performs the wild-card matching after which limits the outcomes primarily based on our wild-card standards.

Get-ADUser username -Properties * | Choose-Object *logon*

BadLogonCount          : 0
lastLogon              : 132181280348543735
LastLogonDate          : 11/11/2019 9:08:45 PM
lastLogonTimestamp     : 132179981259860013
logonCount             : 328
LogonWorkstations      :
MNSLogonAccount        : False
SmartcardLogonRequired : False

Your outcomes could range primarily based on what your Energetic Listing area practical stage is. My search returns eight attributes, three look promising: LastLogon, LastLogonDate and LastLogonTimeStamp. Some values could look a bit bizarre if you’re unfamiliar with how Energetic Listing shops date/time info in sure attributes. Some date data is conventional date-time data, and others are are saved as “ticks”.

PowerShell reveals the precise worth for the tick that represents the date/time. The ticks are transformed to a extra time-date pleasant format in AD Customers and Computer systems or AD Administrative Middle.

Logon attributes defined

Our search discovered a number of properties that present date/time logon info. One property has a distinct time stamp than the others.

Discover how the delayed replication info might have an effect on our question. The LastLogonTimeStamp is definitely two days behind on this instance. Each time a person interactively logs in, touches a community file share, or performs different actions they’re authenticated, and that knowledge is saved in Energetic Listing. Nevertheless, our DC’s could possibly be overwhelmed in a big setting in the event that they replicated logon time stamps EVERY TIME somebody touched one thing on the community. Microsoft solves this drawback by retaining a number of units of logon info. Among the logon info is correct however not replicated, and a few logon info replicates, however solely often.

For our necessities, we do not want the EXACT logon time stamp. We solely want to search out accounts that have not been utilized in awhile. Any worth works, so long as the worth is bigger than 90 days. If we use my logon dates for instance, the time queried could possibly be 11/11 or 11/13 relying on the worth we use.

Quick ahead three months and assume I by no means logged on once more. One date would flag as inactive for being over 90 days and one discipline wouldn’t. But when I arrange this course of to run month-to-month, I’d catch the account the subsequent time we test. That is the essential half. If we do that repeatedly, we are able to use both discipline so long as we persistently test.

Constructing the Automation

I used the LastLogonDate property for 2 causes. First, it is already a date worth, so I haven’t got to take care of changing the worth. Second, it is a replicated worth, and that makes my life simpler. This in not the case if I used LastLogon. The time stamp is not replicated usually and never correct for folks authenticating in opposition to a number of area controllers.

I would wish to question each DC an my community and test each person. Then I want correlate the outcomes to finish up with the most recent outcomes for every person. That may be a very time consuming and time-intensive activity that I need to keep away from if potential. To get the data on a single account utilizing LastLogonDate, the code is easy.

get-aduser Michael_Kanakos -properties LastLogonDate | Choose-Object Title, LastLogonDate

Title     LastLogonDate
----     -------------
mkanakos 11/11/2019 9:08:45 PM

It takes a bit extra code to do that for all my customers. We have to use a filter to question all person accounts.

Get-ADUser -filter * -properties LastLogonDate | Choose-Object Title, LastLogonDate

Let’s discover solely the accounts with a logon date higher than 90 days. We’d like the present date saved to make use of as a comparability operator.

$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Choose-Object Title, LastLogonDate

This code retrieves all customers who have not logged in over 90 days. We save the date 90 days in the past to a variable. We will create an AD filter to search out logons lower than that date. Subsequent, we have to add on the requirement to question solely energetic accounts. On this instance, I’m utilizing splatting to make the code readable.

$date = (get-date).AddDays(-90)

$paramhash = @{
    Filter =        "LastLogonDate -lt $date -and Enabled -eq $true"
    Properties="LastLogonDate"
}

$SelectProps="Title",'LastLogonDate','Enabled','DistinguishedName'

$InactiveUsers = Get-Aduser @paramhash | Choose-Object $SelectProps

$InactiveUsers = Get-ADUser -Filter {LastLogonDate -lt $date -and Enabled -eq $true} -properties LastLogonDate, DistinguishedName | Choose-Object Title, LastLogonDate, Enabled, DistinguishedName

This offers us our inactive customers who’re enabled. We save the outcomes to a variable for re-use. The DistinguishedName property is required in a while. As soon as we discover the customers, we are able to work on our subsequent step: disabling the accounts. We use the Set-ADUser cmdlet to make AD person account adjustments.

$At present = Get-Date
$DisabledUsers = (
    $InactiveUsers | Foreach-object {
        Set-Person $_.DistinguishedName -Enabled $false -Description "Acct disabled on $At present through Inactive Customers script"}
    )

Now we have disabled our person accounts. It is time to transfer them to a brand new OU. For our instance, we’ll use the OU named Disabled-Customers. The Distinguished Title for this OU is “OU=Disabled-Customers,DC=Contoso,DC=Com”. We use the Transfer-ADObject cmdlet to maneuver customers to the goal OU

$DisabledUsers | ForEach-Object {
    Transfer-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Customers,DC=Contoso,DC=Com"}

In our remaining step, we use the Transfer-ADObject to maneuver customers into a brand new OU. We now have the core code wanted to make a dependable, repeatable automated activity.

So what’s subsequent?

That will depend on your particular person necessities. This could possibly be achieved each month. You may create a Scheduled Job to run the code on a schedule. We might add extra code to make it higher. Code for error checking and extra person info fields could be two helpful additions.

Most groups operating a majority of these duties generate a report of what they disabled for somebody to evaluate, so the extra fields will range. You may embrace extra fields from Energetic Listing to make a report extra helpful. We might take this activity one step additional by creating one other activity to delete these disabled person after 6 months.

Wrapping all of it up

Fixing difficult automation requests is far simpler when the duties are divided into manageable items. We began with necessities and constructed up our syntax in small steps; confirming that every step works earlier than making an attempt so as to add in one other variable. By doing this, we made this activity simple to know and hopefully an awesome studying expertise.

Thanks for studying, I might like to know what you assume. Depart me a message within the remark part on the backside of the web page.