So, we want to know who logged on where, when and from what workstation. Lets assume that out of a handful of reasons we just need to do it to establish a good level of user auditing in our corporate network. How do we do that using tools native to Windows and more specifically in environments based on Microsoft Active Directory?
First let’s remember how Active Directory authenticates its users. Today it still uses two main authentication protocols: NTLM and Kerberos. The former has been deemed outdated for a long time now but it still comes with every install of the Windows OS. It uses RC4 cryptography and as such does not comply with regulations like FIPS. What is worse it is more vulnerable to all kinds of attacks with “Pass the hash” topping the charts.
I think it gives enough reasons to focus on more secure Kerberos but wait… How do you turn off NTLM? Luckily, there is a quick solution for that. To disable the NTLM authentication use the following policy on all domain controllers in the domain: Network Security: Restrict NTLM: Audit NTLM authentication in this domain. Setting it to “Deny All” will do the trick.
Be careful with this setting though. There might be applications that still use NTLM as their only way to authenticate users. Disabling NTLM will certainly prevent them from functioning properly. If you are unsure if such applications exist in your domain read this article that talks about detecting those.
How to intercept Kerberos authentications
We are not going to take a deep dive into the guts of the Kerberos protocols. After all, there are articles that do a great job with this. Instead assuming a basic knowledge of Kerberos we are going to see how we can use the footprints of Kerberos to track logons of real users.
It is domain controllers that authenticate users in Active Directory based networks. It is quite logical to think that those very domain controllers can be a good place to intercept the authentications as they happen. It turns out there are two possible ways to do it.
- Use native audit policies to write events about Kerberos auths into the Windows Security Log and then pull up Event Viewer to inspect them. This sounds like a low hanging fruit but let’s save that thought for a minute.
- Hack into LSASS. Yes, as brutal as it sounds some 3rd party tools inject their code into this system critical process that among other things hosts Kerberos. The goal would be to intercept Kerberos protocol functions to obtain information about Kerberos tickets being issued to users as they authenticate. Obviously this method comes with some implications:
- There is no documented and supported API to intercept Kerberos. Any code injection into LSASS might lead to unexpected behavior and destabilize the operating system. What happens if this happens on each DC where this intrusive code is running? Admins worst dream…
- In order to install this “hook” to LSASS you will have to use Administrator credentials on domain controllers. Moreover, the same level of credentials will be required by the “hooking” service for the entire time of its operation.
- You antivirus software running on domain controllers will at least complain about this “potentially” malicious software opening up the memory of the system critical process. Worst case scenario it will break or even bring down the domain controller itself.
- Every system update, major or minor, can break the “hooking” code and leave you without crucial audit events until the 3rd party developers will release a patch to their software.
So, lets rule out the “hacking” method as dangerous and very unreliable and take a closer look at what we can get out of the Security Log and Event Viewer.
How to set up auditing of Kerberos authentications
In order to turn on logging of Kerberos authentication on domain controllers we refer to the well known tool – Group Policy Editor. Open up the policy that will be applied to all domain controllers (Default Domain Controllers Policy by default) and enable auditing of account logon events.
Here is a path to the policy setting in the GPE console and the screenshots of what exactly needs to be turned on:
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy -> Audit account logon events
Since we are going to track both successful logons and failed logon attempts we have to enable both sides of the auditing policy:
Lastly for scripting fans here is a one liner that leads to the same effect.
auditpol /set /category:”account logon” /subcategory:”kerberos Authentication Service” /success:enable /failure:enable
What events to look for in the Event Viewer
Once the policy has been enabled and applied to all domain controllers you will see a myriad of authentication events flood the Security log.
Two of those events are worth our particular attention:
- 4769. A Kerberos service ticket was requested. This event gets logged every time a TGS ticket is requested to be presented to the authenticating party: service on the network, terminal server, desktop user is interactively logging on to.
- 4771. Kerberos pre-authentication failed. This event signifies failed authentication attempt when for example user types in a wrong combination of the user name and password.
Here is how both events look like in the Event Viewer:
Relying on these two events you can get a good understanding of who is authenticating and where on the network. Unlike with “the LSASS injection” method we use only documented tools and processes. Also this method, once configured through the native audit policy, does not require Admin rights on domain controllers to inspect the events of interest. Being a member of the “Event Log Readers” group will suffice.
Now let’s see where the catch is.
First of all, it does require some set up and planning. Not only you have to turn on the auditing policy and apply it to all DCs but you also have to allocate enough disk space and CPU power to make sure that DCs will cope up with the increased overhead when performing their main function – authenticating users which as we know happens all the time.
Second of all, our ultimate goal is to track occurrences of users logging on to desktops and servers on the network and we can only wish there was an easy correlation between Kerberos auths and user logons. Besides, it is really hard to imagine anyone in the good state of mind sifting through tens of thousands of 4769 and 4771 events a day, ruling out all the unnecessary noise and decrypting the text of the seemingly legitimate events to draw a picture who logs on where on the network.
How to subscribe to events in the Security log
There is got to be a better way to manage this….
At first glance you might think that in the world of scripted remote APIs like PowerShell this is a no brainer. Indeed here is another PowerShell one liner that can pipe through 4769 and 4771 events from a specified domain controller and get the names of user accounts that show up in those events:
Get-Eventlog -Logname Security -ComputerName ‘dc01’ | ? {$_.EventID -eq ‘4769’ -or $_.EventID -eq ‘4771’} | % {$_.ReplacementStrings[0]}
$_.ReplacementStrings[0] is the much needed account name stripped out from the event log text.
Will that technically yield the names of users that logged on? Read on..
From domain authentications to user logons
What 4769 and 4771 really capture is domain authentications. Domain authentications occur every time when something or somebody (the authentication subject) presents their credentials to a network service in order to prove its identity and ask the service to do the same. This is the essence of mutual authentication implemented in the Kerberos protocol.
The authentication subject does not always equal a user. It can be a computer account authenticating on a domain controller before reading the contents of its SYSVOL share. It can be a service account authenticating on a server at startup. It can be system acting on behalf of the logged on user refreshing an outdated TGS ticket that was issued when logging on to the user desktop.
So, if you were to rely on the domain auth events for tracking logons of real users you would run into the following issues:
- You would have to waste your time on analyzing events that do not represent real user logons. Think of computer account logons and other “white noise”.
- You would get a lot of duplicates. For example, every time a real user logs into the domain a bunch of 4769 events get generated and all of them would count as separate logons.
- You would not get all the data you need. For example, domain auth events might give you the IP address of the user workstation but not its computer name.
Managing the events volume
It gets worse when you start thinking how all this will work on the scale of the entire corporate network. There is more than one domain controller on your network and there will certainly be more events than can fit in the memory of your desktop where the script runs. Here is an incomplete list of other issues you will need to do something about:
- It would be very inefficient to query the entire Security log every time you run a script. You would have to remember which event the script retrieved last.
- Logons that have been previously read from the Security log would have to be saved in some centralized location. Otherwise your would have to analyze audit data collected from each DC one by one before you can be sure that you know all about logons of a particular user.
- Security log has a fixed size limit and it gets rewritten every time when that limit is reached. In order to not lose any events the script would have to be invoked often enough but not too often to avoid putting too much overhead on your domain controllers.
- And the list goes on and on…
Still trying to build “a script that pulls user logons”?
At this point you have realized that this is a bad idea. It goes way beyond developing a simple script. And why bother if there are 3rd party products that do that all for you?
Check out SecureHero Logon Reporter – a friction free way of tracking logons of real users.
Lightweight and yet reliable, purpose built product that use only documented API, does not require admin access on domain controllers and gives you full visibility into user logons eliminating all the noise you don’t want to see.
If you wonder how it works check out here.
Oh, and did I say it has a free trial?!