Feature #11037

SMB File access audit logging

Added by Gordon Ross 8 days ago. Updated 3 days ago.

In Progress
Start date:
Due date:
% Done:


Estimated time:


Customers want to be able to audit file access over SMB.

Access log entries should contain information including:
Who (User ID and/or SID, and client IP when remote),
When, Where (directory+file), What (action: READ/WRITE, ...)

Control over audit logging should (ideally) use the "System
Access Control List" (SACL), which is the part of the ACL that
contains "Audit" Access Control Entries (ACEs). An Audit ACE
has flags that allow for auditing only failed access (logging all
attempts to access something where the specified access was
not allowed) or successful access (logging every instance where
someone opened a file with the specified access) or both.

Enabling auditing does have some cost, so we'll probably want
some or all of the following audit controls:
a: system-wide enable, that causes the C2 audit daemon to run.
b: per-share or per data set (TBD) audit enable flag
(It may be that the presence of a SACL in any data set is a
sufficient configuration control for "b". This is also how
Windows handles auditing: global enable, then SACLs).

Steps to Reproduce:
a: Enable auditing at the system level. (interface TBD)
b: Set a SACL on all directories and files in some hierarchy,
where some SACLs have an "Audit Success" ACE with
access mask "read+write".
c: Set a SACL on all directories nad files in some other
hierarchy where some SACLs have an "Audit Failure" ACE
with access mask "read".
d: Read and modify the files created in "b".
e: Attempt to read the files creded in "c".

Expected Results:
Step "d" should produce logged successful access,
including Who, What, When, etc.
Step "e" should produce logged failed access,
including Who, What, When, etc.

Actual Results:
No access logs.



Updated by Gordon Ross 3 days ago

  • Status changed from New to In Progress
  • Description updated (diff)

Questions have come up about how to configure SMB auditing.

The best answer for "How can customers select what is subject to audit?" is to edit the security properties from a windows client. To do that (as usual) they should right click on a directory in Windows Explorer, select the security tab, then add an "audit success" or "audit failure" ACE to the "system ACL". Typically that ACE should be inherited (shown as "applies to: this folder, sub-folders, and files").
Note that one must be authenticated as a user with administrative privileges to examine or modify the system ACL.
(The "system ACL" is a protected part of the ACL.)

Here's a link to an MS doc describing the above:

The good news about this approach is that the only configuration item we need to handle on the server side is the system-wide "enable auditing" control.

Also available in: Atom PDF