Using AD to determine whether or not people are still working for the company and are allowed to logon to the systems is not the ideal, and account management should happen based on knowing what accounts should and should not be use, and not by figuring out which haven’t been used. Realistically, if a fired employee is still logging on to the system we are not going to pick up the account that is stale and disable/delete it like actually needs to be done.
That said, in the real world things aren't always quite that easy. As such, regardless of whether the account is a user account or computer account we have several attributes that are stored with the account that help us determine if it is used recently. Unfortunately they all are potentially inaccurate in one fashion or another. These attributes are pwdLastSet, lastLogon, and lastLogonTimeStamp (as of Windows 2003 DFL).
Essentially you can determine if the account is stale by ensuring all of the attributes are over a designated threshold. A starting threshold for users is 3 times the maximum user password age and for computers is also 3 times the maximum computer password age. In short, if both pwdLastSet and lastLogonTimeStamp are greater than the threshold, it is pretty safe to delete the account, unless you are in academia and the faculty member may be on sabbatical.
If you don’t have both of those, it gets a little more questionable as to whether or not the account is still in use, as each attribute can incorrectly report how recently the account was used in the following fashions:
Also, when pulling this data you could also run into null values and these cause the following concerns:
Be careful with place holder computer accounts for non-Windows OSs prior to as they may behave differently. If you look at the operatingSystem attribute on the computer object you can determine if it needs more attention. Examples: