Wednesday, November 17, 2010

How to determine true last logon times in your Active Directory to find unused / stale domain user accounts

As I had covered in my previous post, the process of determining the true last-logon time for a domain user or computer account requires obtaining and comparing the values of the lastLogon attribute from all domain controllers (DCs) in the user's domain.

Thus, depending on the number of DCs in the domain, this could be an easy or a difficult task. If you basically have only one or two DCs, then you could simply inspect the values and make the determination, but if you have more than a few DCs, you really cannot and should not rely on doing this manually.

A Note about lastLogonTimeStamp

Now if your Active Directory domain us on Windows Server 2003 functional level, there is an attribute called lastLogonTimeStamp that is replicated and thus could be used, but it is only updated if the old value is more than 14 days old. In other words, it is only partly helpful, in that it is only helpful if you don't care about including recent lastLogon values in your assessment, i.e. if you don't wish to include all data related to who may logged on in the last 14-days. It might work for you, but most IT admins don't rely on it.

Your Options -

In terms of being able to automate the process of querying and comparing the lastLogon values from multiple domain controllers, we basically have 3 choices here -

  • Option 1: Write you own script - The advantage of writing your own scripts (if you can that is) is that you do not need to spend any money on licensing a tool to do so. The disadvantage is that the time and effort involved in writing, testing and maintaining your own scripts is usually not worth it, in that in the long run, it turns out to be more expensive than just buying a tool to do so.

  • Option 2: Use someone else's script - The advantage of using someone else's script is that you neither have to buy a tool, nor do you have to write your own script, as someone's already done it for you. The disadvantage of this however is that you have no idea as to how reliable and accurate their script might be, and you're also relying on them for any support or technical assistance should you need it.

  • Option 3: Use an automated tool - The advantage of using an automated tool is that you can reliably and efficiently determine true-logon times without having to worry about accuracy or about writing and maintaining scripts. The slight disadvantage however is that they are not free and you might need to spend anywhere from $200 to $500 to obtain a reliable tool that can generate true last-logon reports for you.

I should mention that I was planning on sharing details on how to write your own scripts, but that would take too much time to write and too much time for you to try out, so I thought I would just summarize our options.

It is not that I am biased towards a tool, it is just that I have tried writing scripts and I can tell you that is not as easy as it seems, because not only do you have to account for the success case i.e. all DCs available and returning values, but you also account for lots of failure cases, such as - DC not available, insufficient account not found, permissions to view lastLogon attribute, etc. etc. It is just not that as easy and not worth the time.

My Advice -

My personal advice, based on my experience, is to use an automated tool. That's because, as an IT admin, (y)our time is valuable, and I for one would rather spend it on more important things than on writing and maintaining scripts to do so. For most companies, $400 is peanuts, relative to the valuation of the company and our IT budgets, to automate what constitutes an important security analysis report.

The one other advantage of using an automated tool is that most tools provide numerous other identity and access management reports as well, which can save you a lot of valuable time and not only make determining true last-logon times easier but also make managing and maintaining Active Directory easier.

A Helpful Tip -

One thing to note though (from experience again) is that when looking for a tool, in addition to evaluating the tool's reporting capabilities, also do try to find out where the tool was built and by whom. There are some really good tools out there, but there are also some that are built in Romania or some foreign country, or the like, by who knows whom.

If you are going to use them (i.e. as an admin,) even if using an alternate account, I would be wary of using a tool built by some unknown company from some foreign land. Remember, you get what you pay for, so don't just fall for the cheapest tool out there. Do your homework, and you'll save yourself a lot of time and hassle.

How to find out a Good Active Directory True Last Logon Reporting Tool -

The best advice I can give you in this regard is to let Google do the work for you i.e. the best starting point for finding a good reporting tool for true last logons is well, just Googling "true last logon reports"

Tuesday, May 18, 2010

Active Directory Last Logon

The ability to determine when a specific user may have last logged on can be helpful for a variety of reasons, such as to maintain security, audit usage, detect stale or inactive accounts and generate security reports.

In MS Windows Server based networks, Active Directory is the repository in which domain user accounts are stored, and specific information about when a user last logged on is also stored along with the domain user account.

The only problem is that (as you may know), Active Directory is a replicated system, but for efficiency reasons not all attributes get replicated to all domain controllers, and unfortunately, the attribute that stores a user's last logon time is NOT a replicated attribute.

Because of this, if we need to determine when a user may have last logged on, we need to query the value of this attribute on all domain controllers in a domain and then figure out the latest one.

In addition, we need to take into account the syntax of the attribute and do some mathematical calculations to convert dates to and from a 64-bit integer value.

All in all, it makes for a complicated and less-than-straightforward method to actually determine when a user may have last logged on. In addition, if we are trying to find this out to many users, we need to be able to repeat the same steps for all user accounts of interest.

In this blog we'll take a look at some ways to accomplish this, so we can easily and correctly determine when a user may have last logged on using their domain user account.