Event ID 5145 Explained: Fix Access Denied & Reduce Log Noise

If your Windows security log is flooded with thousands of Event ID 5145 entries every hour, you are not alone. This is one of the most common—and most misunderstood—audit events in Windows environments. It sits there in your Security log, day after day, generated by the SMB protocol every time a client attempts to access a network share. Sometimes it's harmless noise. Sometimes it's an early warning sign of an attack. The tricky part is telling the difference.

I've spent the better part of fifteen years helping organizations untangle their Windows security logs, and I can tell you this: Event ID 5145 is the event that generates more support tickets and more confusion than almost any other audit event I've encountered. In this guide, I'll walk you through what it actually means, why you're seeing "access denied" entries, how to fix them, and—perhaps most importantly—how to stop the log flood without losing the security visibility you need.

What Is Event ID 5145? A Deep Dive into the Windows Security Log

The Official Definition and Event Structure

Event ID 5145 is triggered when a network share object is checked to see whether a client can be granted desired access. In plain English: every time a user or computer tries to access a file or folder through a shared network path, Windows logs this event before the access is actually granted or denied.

That last part is crucial. The event fires during the access check itself, not after the outcome is determined. So you'll see 5145 events for both successful and failed access attempts—the event itself doesn't tell you whether access was ultimately granted.

Here's a sample raw XML log entry with the key fields annotated:

<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
  <System>
    <Provider Name='Microsoft-Windows-Security-Auditing'/>
    <EventID>5145</EventID>
    <Channel>Security</Channel>
    <Computer>FILE-SRV-01.corp.local</Computer>
  </System>
  <EventData>
    <Data Name='SubjectUserName'>jsmith</Data>          <!-- Who is trying to access -->
    <Data Name='SubjectDomainName'>CORP</Data>
    <Data Name='SubjectLogonId'>0x1a2b3c</Data>
    <Data Name='ObjectType'>File</Data>
    <Data Name='IpAddress'>192.168.1.105</Data>         <!-- Source IP -->
    <Data Name='IpPort'>50160</Data>
    <Data Name='ShareName'>\\*\Marketing</Data>          <!-- Which share -->
    <Data Name='ShareLocalPath'>\??\D:\Shares\Marketing</Data>
    <Data Name='RelativeTargetName'>Q4_Report.docx</Data> <!-- Target file -->
    <Data Name='AccessMask'>0x120089</Data>              <!-- Requested permissions -->
    <Data Name='AccessList'>%%1538 %%1541 %%4416</Data>  <!-- Human-readable access -->
  </EventData>
</Event>

The fields that matter most for troubleshooting are SubjectUserName (who's trying), ShareName (which share), RelativeTargetName (what file or folder), AccessMask (what permissions they're requesting), and IpAddress (where the request is coming from).

Event ID 5145 vs 5140 vs 4663: What's the Difference?

One of the most common sources of confusion I see is mixing up 5145 with its close cousins, 5140 and 4663. They're all related to file access, but they fire at different points in the process.

Why Am I Seeing Event ID 5145 Access Denied? Common Causes

Understanding the AccessMask Field and ACL Permissions

The AccessMask field is where the real diagnostic gold lives, but it's also where most people get stuck. It's a hexadecimal value that encodes the specific permissions being requested. Here's a lookup table for the most common values:

Here's the part that trips up even experienced admins: share permissions and NTFS permissions are evaluated separately, and the most restrictive result wins. You can have full control at the share level, but if the NTFS ACL only grants Read, the user gets Read. And vice versa.

Common Scenarios: SMB Share Access Denied and Authentication Failures

Over the years, I've seen the same few scenarios repeat themselves in almost every environment I've worked with.

Scenario 1: The Share/NTFS Permission Mismatch

This is the classic. A user can see the share, but can't open files inside it. The 5145 event shows the user requesting WriteData, but the AccessList shows "Not granted." In most cases, the share permissions allow Full Control, but the NTFS ACL on the folder only grants Read to that user or group.

Scenario 2: ANONYMOUS LOGON and Guest Access Attempts

This one deserves your attention. When you see SubjectUserName: ANONYMOUS LOGON in a 5145 event, it's worth investigating. In some cases, it's a misconfigured application trying to access a share without proper credentials. In other cases—like the PetitPotam attack that made headlines a few years back—it's an attacker attempting forced authentication.

I recall a client who had thousands of these events pointing to their SYSVOL share. We initially dismissed it as noise, but a deeper investigation revealed an attacker using PetitPotam to coerce authentication from domain controllers. The 5145 events were the earliest indicator in their logs.

Scenario 3: Kerberos Failures and NTLM Fallback

When Kerberos authentication fails—due to time skew, SPN issues, or misconfigured DNS—Windows falls back to NTLM. This isn't inherently bad, but it generates additional 5145 events and can cause access issues if NTLM is restricted on the target server.

How to Fix Event ID 5145: A Step-by-Step Troubleshooting Guide

Step 1: Identify the Source Share and User

Before you can fix anything, you need to know what you're dealing with. Open Event Viewer, navigate to Windows Logs > Security, and use the Filter Current Log option to filter for Event ID 5145.

Once you've got your filtered view, extract the ShareName and SubjectUserName from the event details. Then cross-reference with active sessions using the net session command on the file server:

net session

This shows you who's currently connected to the server and from which IP address. Match that against the IpAddress field in your 5145 events to confirm the source.

Step 2: Verify Share and NTFS Permissions

Now that you know the share and the user, it's time to check permissions. Start with the share permissions using the Shared Folders snap-in (fsmgmt.msc) or PowerShell:

Get-SmbShare -Name "Marketing" | Get-SmbShareAccess

Then check NTFS permissions with icacls:

icacls "D:\Shares\Marketing" /T

Compare the two. If the user has Full Control at the share level but only Read at the NTFS level, you've found your problem. The fix is to align the permissions—ideally by granting the minimum necessary at both levels.

One thing I always tell clients: apply the principle of least privilege. Don't just grant Full Control everywhere to make the problem go away. You'll regret it later when an auditor asks why a marketing coordinator has delete access to the finance share.

Step 3: Fix Authentication Issues (Kerberos and NTLM)

If permissions look correct but access is still being denied, the problem might be authentication. Check for Kerberos-related errors in the System log around the same time as the 5145 events.

Verify that Service Principal Names (SPNs) are correctly registered for the file server:

setspn -L FILE-SRV-01

You should see entries for host/FILE-SRV-01 and cifs/FILE-SRV-01. If they're missing, the server can't properly authenticate Kerberos requests, forcing clients to fall back to NTLM.

Also check for time skew between the client and server. Kerberos has a default tolerance of 5 minutes—anything beyond that and authentication will fail. The Windows Time service usually handles this, but misconfigured firewalls or virtual machine clock drift can cause problems.

How to Reduce Event ID 5145 Log Noise via Group Policy

Configuring Audit Policy for Network Share Access

If you've determined that the 5145 events are mostly benign noise, you can tune your audit policy to reduce the volume. The relevant settings live in the Advanced Audit Policy configuration:

Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object Access

Two settings matter here:

Using Advanced Audit Policy to Filter Specific Shares

Sometimes you need to keep auditing for most shares but silence a particularly noisy one. The "Audit Detailed File Share" policy doesn't support per-share filtering directly, but you can use a workaround.

One approach I've used successfully: create a separate GPO for the noisy share's server, and configure the audit policy to exclude specific users or groups using security filtering. This requires some planning, but it's worth it for high-traffic shares like home directories or redirected folders.

Here's a PowerShell command to set the audit policy via GPO:

auditpol /set /subcategory:"Detailed File Share" /failure:enable /success:disable

Remember to run gpupdate /force on the affected servers after applying changes.

Is Event ID 5145 a Security Threat? Mapping to MITRE ATT&CK

How Attackers Exploit Network Share Access Events

Event ID 5145 itself isn't malicious—it's just a log entry. But it can be a valuable indicator of malicious activity when you know what to look for.

Threat Hunting Queries for Event ID 5145 (Splunk and KQL)

Here are some copy-paste ready queries I've used in real engagements.

Splunk: Detect ANONYMOUS LOGON attempts

index=windows EventCode=5145 SubjectUserName="ANONYMOUS LOGON"
| stats count by ShareName, RelativeTargetName, IpAddress, _time
| sort - count

KQL: High-frequency access to SYSVOL share

SecurityEvent
| where EventID == 5145
| where ShareName contains "SYSVOL"
| summarize AccessCount = count() by IpAddress, Account, bin(TimeGenerated, 5m)
| where AccessCount > 50

The key to effective threat hunting with 5145 is baselining. You need to know what "normal" looks like in your environment before you can spot anomalies. I recommend collecting 30 days of baseline data before setting any alerts.

How to Disable Event ID 5145 Auditing (When Appropriate)

When It Makes Sense to Disable Auditing

Let me be clear: I don't recommend disabling 5145 auditing in most environments. But there are legitimate cases where it makes sense.

• High-volume non-critical shares: If you have a share that generates thousands of 5145 events per hour and contains nothing sensitive, the noise might be hiding real alerts.
• Performance impact: On busy domain controllers or file servers, excessive auditing can impact performance. The Security log has size limits, and when it fills up, you can lose events that actually matter.
• Compliance requirements: Some compliance frameworks don't require share-level auditing. If your auditors don't need it, you can disable it.

Step-by-Step: Disabling via GPO and Registry

Method 1: Disable via GPO

Navigate to the same Advanced Audit Policy path as before, and set "Audit Detailed File Share" to No auditing. This is the cleanest method and applies to all affected servers via Group Policy.

Method 2: Registry modification

If you need to disable auditing on a single server without GPO, you can use the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Value name: AuditDetailedFileShare
Value type: DWORD
Value data: 0

After making changes, run gpupdate /force and verify in Event Viewer that new 5145 events are no longer being generated.

FAQ

What is event ID 5145 in Windows?

Event ID 5145 is a security audit event that logs when a network share object is checked to see whether a client can be granted desired access. It appears in the Windows Security log and is generated by the SMB protocol whenever a user or computer attempts to access a file or folder through a network share. The event fires before access is granted or denied, making it a rich source of information about both successful and failed access attempts.

How do I fix event ID 5145 access denied?

To fix Event ID 5145 access denied errors, follow these steps: (1) Identify the source share and user from the event details, (2) Verify that the user has appropriate permissions at both the share level and the NTFS level—remember, the most restrictive permission wins, (3) Check for authentication issues like Kerberos failures or SPN misconfigurations, and (4) Resolve any permission conflicts by applying the principle of least privilege. For a detailed walkthrough, see the troubleshooting section above.

Is event ID 5145 a security threat?

Event ID 5145 itself is not malicious—it's an audit log entry. However, it can indicate reconnaissance activity (MITRE ATT&CK T1135) or forced authentication attempts like PetitPotam (T1187). You should monitor for anomalies such as ANONYMOUS LOGON access to SYSVOL, unusual patterns of share enumeration, or access to administrative shares from unexpected sources.

How to reduce event ID 5145 log noise?

To reduce Event ID 5145 log noise, use Advanced Audit Policy to set "Audit Detailed File Share" to Failure only or No auditing for high-noise shares. You can also use GPO security filtering to exclude specific users or groups from auditing. For most environments, I recommend keeping Failure auditing enabled—it captures access denied events without the volume of success events.

Conclusion

Event ID 5145 is a double-edged sword. On one hand, it's an essential source of visibility into who's accessing your network shares—and who's trying to. On the other hand, it can flood your Windows security log with thousands of entries per hour, making it difficult to spot the signals that actually matter.

The key takeaway from this guide: don't just disable 5145 auditing to make the noise go away. Take the time to understand what's generating the events, fix any underlying access issues, and tune your audit policy to balance security visibility with operational sanity. In my experience, the environments that handle this well are the ones that treat audit logs as a security tool, not a compliance checkbox.

If you're struggling with Event ID 5145 in your environment, start with the troubleshooting steps above. And if you want to automate the analysis of your 5145 logs—identifying top offending users and shares in minutes instead of hours—download our free PowerShell script that does exactly that.