Finding which accounts are active should be simple, however, there are numerous ways to define if an account is active or not. There is the simple method of checking if the accounts are enable or not, however, things get more complicated quickly after that, i.e. when was the account last used, has the account expired, has the account ever been used.
This article provides a number of sample LDAP queries that can be used to determine if accounts are active or not, or you can combine these queries to generate a more complex query to meet your requirements. The first part of the article shows fragment of the query and the last section shows how to combine these to create the final query.
Account Enabled
With AD an account is active based on a value stored in UserAccountControl attribute, however, the attribute uses bit logic to represent a number of different values, so you can't check for a specific value. Details of the attribute can be here. The second bit of the UserAccountControl indicates if the account is enabled or not, when not set (0) the account is active, when set (2) the account is disabled. Using Matching Rule OID we can check the status of the individual bits in the attribute. i.e. (useraccountcontrol:1.2.840.113556.1.4.802:=2). The NetTools substitutions simplifies the entry of matching rules with a single character. See Substitutions.
Account is disabled (useraccountcontrol|=2)
Account is enabled (!useraccountcontrol|=2)
Account Expired
Accounts can be set to automatically expire after a specified date, after which point the user will no longer be able to logon. The date is stored in the AccountExpires attribute, this attribute uses a 64 bit integer to store the date. To add to the complexity the attribute can contain more than just a date, it might not be set, or contains a 0 (zero), or 9223372036854775807 then account is not set to expire. So a query check for expiry has to check for all the possible values to confirm if the account is active or not. Again the use of substitutions can simplify the entry of the Int64 date.
Account Expired (&(!accountExpires={-1:})(!accountExpires=0)(accountExpires<={idate:now}))
Account not Expired (|(!accountExpires=*)(accountExpires={-1:})(accountExpires=0)(accountExpires>={idate:now}))
Last Logon
Most account audits state that if an account has not been used to a set period of time, the account should be consider inactive. The last time the user logs on is stored in the LastLogon attribute, however this attribute is not replicated between domain controllers, so using this attribute you have to collect the LastLogon attribute from all domain controllers to determine the last logon. There is another attribute that is replicated between domain controllers called LastLogonTimeStamp, however this attribute has a specific replication cycle which means that it may not contain the most recent logon date (more details here), but is usually close enough for most cases. Again this attribute uses a 64 bit integer to store the date.
Not logged on for 60 days (lastlogontimestamp<={idate:now-60})
Logged on in the last 30 days (lastlogontimestamp>={idate:now-30})
Password Changes
In some cases the logonTime or the LastLogonTimeStamp will not be updated when a users logs on, these are normally associated to LDAP Simple binds or access through SharePoint. another method to determine if an account is still being used to check the last time the user's password was changed, this assumes that an account password expires.
Password change in the last 60 days (pwdlastset>={idate:now-60})
Unused New Accounts
In this scenario an account is created but has not used since it was created. The queries that is used to find these accounts depends on user provisioning process and which query should be used, if the user is required to change their password at first logon (scenario 1), or not (scenario 2). If the user is required to change their password, then we check to see when the password was changed, if not, we check if the lastlogontimestamp has been set.
Scenario 1
Not used in the last 60 days (&(whencreated>={zdate:now-60})(pwdlastset=0))
has been used in the last 60 days (&(whencreated>={zdate:now-60})(pwdlastset>={idate:now-60}))
Scenario 2
Not used in the last 60 days (&(whencreated>={zdate:now-60})(!lastlogontimestamp=*))
Created in the last 60 days and been used (&(whencreated>={zdate:now-60})(lastlogontimestamp=*))
Type of Accounts and indices
When creating queries it's best to create a query that limits the number of object that need to be searched and the number of attributes that are returned. Building a query using attributes that are indexed will increase the performance of the query, reduce the load on the server executing the query, and reduce the amount of network traffic generated (See this Microsoft article for details). Some of the queries shown above use attributes that are not indexed, so using these queries in the format show could be very inefficient. Limiting the queries to only search for specific object types will significantly increase the performance of the query, i.e only look at user account or computer accounts and the more indices that are used the better.
Users account (&(objectCategory=user)(objectclass=user))
Computer Accounts (&(objectCategory=computer)(objectclass=computer))
Combined Queries
This section shows a number of the above query fragments combination to create the full query:
Find active user accounts:
(&(objectCategory=user)(objectclass=user)(!useraccountcontrol|=2))
Find disabled user accounts
(&(objectCategory=user)(objectclass=user)(useraccountcontrol|=2))
Find active accounts, that have not expired
(&(objectCategory=user)(objectclass=user)(!useraccountcontrol|=2)(|(!accountExpires=*)(accountExpires={-1:})(accountExpires=0)(accountExpires>={idate:now})))
Find all inactive accounts, including expired, password not changed or logon in the last 60 days
(&(objectCategory=user)(objectclass=user) (!useraccountcontrol|=2)(lastlogontimestamp<={idate:now-60})(pwdlastset>={idate:now-60})(&(!accountExpires={-1:})(!accountExpires=0)(accountExpires<={idate:now})))
NetTools includes a number of predefined queries covering user accounts, see Predefined Queries
See Favorites for more examples