I’m considering making a tool for tracking/auditing user logons, as this is something people often ask me to make, but there’s one thing I want to get your opinions on first.
Recently I’ve been asked by quite a few people if I have any tools that can report on which computers a user is logged on to and that would provide an audit trail of when they have logged on (not just the last logon time). I’ve responded to most of these requests by asking the question that I’m about to ask here, but I very rarely get a reply so I figured I would post it here and see if I get any more feedback.
Basically the question is about how the tool should collect the logon information (e.g the date/time a user logged on and which computer they logged on to). As far as I can see there are 2 practical ways of doing this, I will describe each below:
Method 1: DC Event Logs
If you enable logon auditing on your domain, every time a user authenticates with a DC then an event log entry will be written to that DC’s security event log. So one way of tracking user logons would be to have a central service running on a server that periodically checks the event logs of each DC and parses the relevant log entries to get the logon information from them and store it in its own database. However, there are several problems with this method in my opinion and that’s what led me to thinking of the second method. Some of the problems I can see are:
- This won’t catch any offline logons. Users logging on to a computer that is not currently connected to the network at the moment they log on will not authenticate with a DC so there will be no log entry for them. You might think that’s not such a big deal as all of your users connect to the company network, but there are an awful lot of VPN solutions in use for remote users now that require the user to log on first before they connect the VPN so none of these logons would be captured.
- Event log entries are not designed to be parsed. From my tests and research so far I’ve not actually been able to find a good single event log entry that gets logged on the DC when a user logs on to a PC that actually has the user’s name and the computer’s name in it. There seem to be several entries that get logged during logon: some from the kerberos system that give good information but I’m not sure they would be logged in all cases as I don’t think kerberos is always used for logons in every domain (also it might be hard to differentiate the entries from user computer logons from other services that use kerberos), some general authentication entries that only give you the IP address of the computer the user is logging on to, some entries that also get logged every time the user does a network logon to access any file servers, etc etc. The format of these event log entries (and even their event IDs) also change between different versions of Windows Server. It can’t be impossible to successfully parse these log entries to get the required information because I know some other tools do it but it is certainly not easy and that means more chance of problems and reliability issues. EDIT: Turns out the tool I was thinking of might have the same problem of struggling to get workstation logons purely from the DC event logs as well, as it only seems to be showing me logons from the DC itself and not the workstations.
- Requires periodic polling. The central service for the tool would need to poll the event logs on each DC at a configured interval. This means you would either have to set it to a very short interval so that you get up to date information whenever you use the tool and hope there’s no noticeable performance impact from this, or you would have to set it to just poll once a day or something and accept that your reports won’t ever be completely up to date. Personally I don’t like either of these options, especially as in a large domain with lots of DCs this would either take a long time (especially for DCs separated from the central service by slow WAN links) or would require an agent to be installed on some DCs.
Method 2: Workstation Agent
So to avoid all of the problems mentioned above, I thought of having a service that runs on each computer that can log whenever a user account logs on to that PC and then send this information to a central server instantly (or the next time the user is connected to the company network). I’ve already written a basic proof of concept service that logs all of the required information successfully every time someone logs on. This also has the benefit of being able to capture logoffs and locks/unlocks of the PC, and it can capture local account logons, not just domain accounts.
Of course there are disadvantages to this method as well, even though it gets around each of the problems mentioned above with the DC event log method. The main problem with this workstation agent method is the actual installation of the agent on every machine – I’m conscious that some organisations might not like the idea of having to push out extra software on to each of their machines, which is why I’m looking for feedback on how much of an issue this would be for people. The agent installation would be quick and easy, and you would be able to do it remotely by just selecting an OU from AD to push it out to all of the computers in there or you could manually enter a list of computer names to have it pushed out to. There would be no manual configuration required on each machine or anything like that.
What do you think?
So if you were looking at a system like this that let you audit logons and run queries and reports to see who is logging on at what times and which computers etc, what would your preference be? Would you consider using a tool that required an agent to be pushed out to each workstation or would that be a deal breaker for you?
EDIT: To clarify – I’m not asking which you would prefer out of the 2 options, as I know everyone would prefer just one central service that collects info from DCs if that could be just as reliable and useful as the other option. Unfortunately that’s not really the choice. If no one would use a system that required an agent pushing out to each workstation then I probably just won’t make this tool at all, because the DC event log parsing method has too many issues that would make it painful for me to develop and would make the system not particularly useful or reliable.