Active Directory visibility as a security control

Hello,

Welcome back to Authentication Insights.

Last time, we talked about hardening your Active Directory (AD). Today, we state the obvious: if you want to know what's working, you have to be able to see what's happening.

Visibility on authentication activity is the mechanism that tells you whether your AD hardening is actually working. It's also the only way to catch it when it isn't.

You can restrict NTLM, enforce Kerberos AES, tighten ACLs, and still have no idea whether any of it is working. And the missing layer isn't another control, it's the ability to see what's actually happening in your environment.

Fun fact: Microsoft didn't design Windows Event Viewer for auditing. That will surprise no one who has tried to use Windows Event Viewer for auditing. But really, Microsoft actually built it as a centralized application for viewing data.

With over 200 different event logs, finding the information you need can be manual and time-consuming. Windows audit policy is not configured for authentication visibility.

And while PowerShell can help ease the pain of auditing, most organizations can't use it at scale to get the visibility they need in real time.

Another problem is that many of these subcategories aren't fully enabled by default (particularly Failure auditing), and confirming the exact baseline in your environment is essential. These are subcategories like Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Credential Validation, etc.

There's also the issue of how long the logs survive. Default Security event log sizes can fill and overwrite within hours on a busy DC. The events that would let you detect a Kerberoasting attempt or an NTLM relay are already gone before anyone takes the time to look.

In hybrid AD environments, authentication logs live in three or four different places that don't talk to each other: DC Security event logs, Defender for Identity if deployed, your SIEM, and potentially network-level captures. Each has a partial view, but they don't all talk to each other to give you what you need: who authenticated, with what credential, how, from where, to what.

Hybrid identity creates security gaps that attackers exploit, and a Zero Trust approach to security relies heavily on visibility and strong, precise configuration.

Microsoft Certified Master Sean Metcalf, in an interview with Petri IT, noted that no customer has fully reached the end of a Zero Trust journey, but cleanup and visibility are always the first steps. That includes knowing what assets exist, how authentication paths work, and which legacy configurations must be eliminated before enforcing stricter policies.

When AD hardening fails, that failure is often silent. Residual NTLM after a restriction policy, a 4769 event with RC4 encryption type against a service account, logons outside normal hours from an account that never travels: these signals are already being generated by the controls you've built. The question is whether you're reading them. Visibility itself requires some initial assumptions about what to monitor. But once in place, it's what lets you confirm your controls are applying correctly, consistently, and completely, rather than simply assuming they are. It's also how you catch when they're being bypassed.

The argument isn't "buy a SIEM." It's: the hardening work you've already done produces data. Visibility is what helps you turn that data into a smart decision.

In our next issue, we'll talk about the future of AD authentication: usability and security in tandem.

Looking to go deeper on AD authentication visibility? These reads can help:

• Microsoft Certified Master Sean Metcalf Reveals the Top 3 Fixes to Secure Active Directory

• How the gap between on-premises Active Directory and the cloud became hybrid identity security's blind spot

• A guide to Windows logon auditing

Until next time,

The Authentication Insights team