Understanding Where Windows Authentication Logs Actually Live — From AD to Entra ID

Okay, let’s get one thing straight — Windows logging is not centralized by default.

Each system—your laptop, your DC, your file server—logs its own stuff. That means if you’re doing forensics or threat hunting, you’ve got to know exactly which system has what evidence.

If you pull the wrong logs, you might completely miss the attacker’s authentication trail.

-------------------------------------------------------------------------------------------------------------

1. Clients, Domain Controllers, and Member Servers — Who Logs What?

Think of these three as different witnesses in your investigation. Each one saw a different part of the crime.

System Type	What It Logs	Example Event IDs
Client Systems	Logon events when someone accesses the client, and Account Logon events if local accounts are used.	4624, 4625 (logon), 4776 (local account auth)
Domain Controllers (DCs)	Account Logon events for all domain accounts (Kerberos & NTLM). Logon events for when they themselves are accessed.	4768, 4769, 4776, 4624
Member Servers	Logon events for access to the server, and Account Logon events if local accounts exist.	4624, 4625, 4776

Now, here’s the simple rule you should always remember:

Authentication happens where the account lives.

Authorization happens where the access happens.

Let’s decode that in plain language 👇

Authentication = Account Logon Events

These tell you who tried to prove their identity (i.e., “is this password/ticket valid?”).So if it’s:

• A local account → it’s stored on that machine → you’ll find 4776 on that system.

• A domain account → stored on the Domain Controller → you’ll find 4768/4769/4776 on the DC.

Authorization = Logon Events

These tell you who actually got access to the system. So:

• If someone connects to a file server using SMB, you’ll see 4624 (Type 3) on the file server.

• If someone RDPs into a system, it’s 4624 (Type 10).

• If someone logs in locally (keyboard/console), it’s 4624 (Type 2).

Every system generates its own logon events for whoever touches it.

2. Domain Controllers — The Authentication Powerhouse

Every Domain Controller (DC) in the domain is an equal partner. So when a domain account authenticates, the event could appear on any DC that handled the request.

That’s why, during incident response, you often need logs from all DCs, not just one.

DCs will be buzzing with:

• 4768 → Kerberos AS Request (TGT issued)

• 4769 → TGS Request (Service ticket)

• 4776 → NTLM authentication

• 4624 (Type 3) → Network logon to the DC

If you ever wonder “where did this user authenticate?”, start your hunt on the DCs.

3. Member Servers — Your Quiet Evidence Keepers

Member servers behave just like clients. If someone accesses them (say, via SMB or RDP), the Logon events (4624/4625) appear right there.

If they have local accounts (which attackers love creating as backdoors), then you’ll also see:

• 4776 — Local NTLM authentication

• 4720 / 4732 — Local account creation or group modification

Attackers often create local “shadow” admin accounts, so these logs are pure gold during lateral movement investigations.

4. The Cloud Era — Welcome Entra ID (formerly Azure AD)

Now things get interesting.Microsoft’s Modern Authentication changed the game. We’re no longer bound to traditional AD — you can join your machines directly to Entra ID (Azure AD).

Here’s how it shifts things:

What changes:

• Authentication moves to the cloud (Entra ID).

• Logs for that authentication now live in Entra ID’s portal, not in your local Security event logs.

• Passwordless login (Windows Hello / Hello for Business) becomes standard — it uses certificates and key pairs, not NT hashes.

What stays the same:

• Logon events (4624, 4625) still happen on the local system being accessed.

• Network logon (Type 3) → for SMB or remote shares

• RDP (Type 10) → for Remote Desktop

• Local logon (Type 2, 7, or 11) → for local or interactive access

Even in a pure Entra ID world, your endpoints are still the final witnesses.

5. Passwordless Authentication (Windows Hello / Hello for Business)

Instead of using passwords or timestamps, Windows Hello uses certificates and keys. But here’s the key takeaway: Even though the authentication method changes, the same event IDs are generated.

So:

• 4768 → Still logged on the DC when a TGT is requested.

• 4624 → Still recorded on the system granting access.

The difference?

You’ll see extra certificate details in the log, showing which cert/key pair was used during authentication.

6. Hybrid Entra ID + Active Directory — The Real-World Mix

This is where most companies are today — hybrid mode.

• On-prem AD for internal stuff.

• Entra ID for cloud apps like Office 365, SharePoint, or Teams.

Here’s how that works under the hood:

• Authentication may happen in the cloud, but your DCs still issue TGTs for on-prem access.

• Service tickets (4769) still exist.

• Logon events (4624) still show up locally.

So from an incident response perspective, the log locations don’t change much — you just add one more layer (Entra ID logs in the cloud).

7. Watching for Account Management Activity

Alright, authentication is one thing — but what about account creation or privilege escalation?

Here’s where attackers love to play.

Action	Event ID	Description
User account created	4720	New account made (local or domain)
User account deleted	4726	Account removed
Account enabled/disabled	4722 / 4725	Account activation changes
Password reset	4724	Admin reset user password
Added to global group	4728	Domain Admins, etc.
Added to local group	4732	Local Administrators, etc.
Added to universal group	4756	Forest-wide access group
Account changed	4738	Username, password, or attribute updated

If you ever see 4720 followed by 4732 close together — that’s a dead giveaway. It often means:

An attacker created a new user and immediately added it to the Administrators group.

Quick Recap for DFIR Analysts

• 4776 / 4768 / 4769 → Authentication (Account Logon events)

• 4624 / 4625 → Authorization (Logon events)

• 4720–4756 → Account and group management

• DCs = domain accounts, Clients/Servers = local accounts

• Entra ID shifts authentication to the cloud but not logon visibility

And most importantly — logs are decentralized. Unless you have log forwarding or a SIEM, you’ll need to collect from each endpoint manually.

-------------------------------------------------------------------------------------------------------------

Final Word

If you’re doing threat hunting or forensics, think of authentication events like breadcrumbs. Each one tells a small part of the story — but together, they paint the attacker’s entire movement.

Once you know where each event lives, you’ll never look at “just another 4624” the same way again.

---------------------------------------------Dean--------------------------------------------------