When is Event ID 5145 logged?

event id 5145 is one of the most useful Windows audit events for understanding file share access attempts because it records the share-level check itself, not just the final file-system result. For a practitioner, that means the event is most valuable when you need to see who tried to reach a share, from where, and whether the share layer allowed or denied the request.

It is commonly logged for each share access when detailed file share auditing is enabled, so volume can be high on busy servers. That makes the event a strong source for triage, but also a noisy one if auditing is turned on broadly without a filtering strategy. The event is less about content inspection and more about access-path visibility at the network share boundary.

When you are investigating, the fields that usually matter most are Share Name, Relative Target Name, Source Address and Accesses. Those values help distinguish routine access from suspicious enumeration, lateral movement, or access from an unexpected host. The event is especially useful when the share layer denies access, because that tells you the attempt failed before NTFS permissions were evaluated.

By itself, the event does not prove malicious activity, but repeated denied access to sensitive shares, especially from unusual source addresses or with broad requested permissions, can be a strong lead. The event becomes more valuable when you can correlate it with logon activity, account usage, and other file access events on the same host.

What Event ID 5145 Actually Tells You

Event ID 5145 captures a network share object access check, which is the moment Windows evaluates whether the client can be granted the requested access at the share layer. That makes it different from NTFS object auditing, because the share can block the request before file-system permissions are even consulted. In practice, this helps you answer a very specific question: did the request reach the share, what access was asked for, and was it permitted at that layer?

This distinction matters in troubleshooting because a share denial and an NTFS denial can point to different permission models. If you only inspect file-system ACLs, you can miss the fact that the share permission set was the actual blocker. For incident work, the event also helps establish whether a host is probing available shares or repeatedly requesting access that it should not need.

Share-level auditing is usually most useful when you are trying to understand access paths across SMB shares, especially on file servers that host sensitive data, administrative shares, or application file stores. Windows Event Log Guide covers adjacent Windows audit events and helps place 5145 in the wider logging picture.

Because the event is generated per access attempt, it can provide a detailed trail, but it can also generate substantial log volume. That means the event is best used with a clear audit objective, such as detecting unexpected share access, validating share permission changes, or investigating whether a host accessed a share from an unusual network location.

How to Use 5145 for Investigation and Triage

When you review 5145, start with the requested access and the share name, then move to the source address. Those three values tell you whether the action was consistent with normal business use, a legitimate administrative workflow, or something more suspicious. Relative Target Name is especially helpful when the share hosts many subfolders and you need to narrow down which path was being requested.

For failed accesses, the practical question is whether the denial was expected. A denied request from a user who routinely works with the share may indicate a permissions drift or a broken application dependency. A denied request from an unrecognized host, by contrast, can indicate reconnaissance, credential misuse, or a lateral movement attempt that was stopped at the share boundary.

Teams that rely on this event should also think about event tuning. If detailed file share auditing is enabled everywhere, the result may be too much data to review manually. Correlation rules in a SIEM are usually more effective when they focus on sensitive shares, privileged hosts, or repeated failures from the same source.

When you need to compare share-layer behavior with broader Windows telemetry, Sysmon Guide is useful for building host and network context around the access attempt, while PowerShell Security Guide helps when share access is part of a scripted administrative workflow or suspected abuse.

For authoritative logging strategy, Windows audit policy guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with the need to collect auditable access evidence, and the NIST Cybersecurity Framework 2.0 provides the broader governance lens for identifying, protecting, detecting, responding and recovering around file share telemetry.

Why 5145 Matters When Share Access Is the Weak Point

Share-level visibility becomes important when access control is split across multiple layers. A user may have NTFS permission but still be blocked at the share, or the reverse may be true. Event ID 5145 shows you the share side of that decision, which is often where administrators discover misconfiguration, overbroad access, or an unexpected access path that never reaches the file object.

The event is also useful for detecting patterns that look operational at first glance but are actually security-relevant. Repeated denied share checks can reflect misconfigured applications, but they can also reveal credential stuffing against file shares, discovery activity, or attempts to reach administrative or staging locations. If the same source repeatedly probes different shares, that pattern deserves more attention than a single isolated failure.

Detailed share auditing works best when it is scoped to the assets that matter most. On high-value servers, combine it with a clear review process for who should be accessing the share, from where, and at what times. That approach keeps the event useful instead of turning it into an unmanageable log stream.

Practitioner Guidance

What to verify: Confirm whether the share permission model, not NTFS, is the layer actually making the decision. If a request is denied and the file system permissions look correct, the share ACL and the requested access mask are the first things to inspect.

What to prioritise: Focus on sensitive shares, repeated failures, unexpected source addresses, and access attempts that ask for more than the normal workflow requires. Those conditions are the fastest way to separate ordinary noise from meaningful exposure.

Common mistake: Treating 5145 as a generic file-access event instead of a share-layer check. That misread leads to incorrect troubleshooting and can hide configuration problems that are only visible at the SMB share boundary.

Practitioner takeaway: Use Event ID 5145 as a boundary signal, not just a log line. It is most valuable when you need to prove who touched a share, where the request came from, and whether the share layer itself was the control that allowed or blocked access.

Related resources from NHI Mgmt Group

• When is Event ID 4624 logged?
• When is Event ID 4648 logged?
• When is Event ID 4625 logged?
• When is Event ID 4663 logged?