2

With object auditing and directory audit settings correctly applied, all necessary file system access events are logged to the Security event log. When making changes locally (to C:\Share for example), the event logs are generated perfectly. However, when making changes through a share from a remote machine (C:\Share exposed via \\Server\Share for example), a log entry is created, but all expected values, such as Security ID and Account Name, have not been replaced correctly and only contain the placeholder fields %1, %2, %3 etc.

Screenshot of missing values for a security audit entry

Entries with missing values like this are only created when making changes from another machine on the network. Tested with multiple users coming from multiple machines on the same network and domain all with the same result, nothing else is creating entries like this. Other machines with the same object audit policy and audit settings applied to the target directory work correctly, it only happens on just one rogue Windows 2012 server.

Has anyone ever seen this before? What could cause the placeholder fields not to be set?

It seems quite critical since a failure to create a security audit entry is a big deal, especially for remote file system access.

  • When you say "Other machines with the same audit settings work correctly..." do you mean that other machines (servers I'm assuming) with shares on them that are accessed across the network vs. locally show information in these log entries? If that's the case and the server in question is not an important, mission critical server, why not take some backups of the data/shares of the server and start over with a clean install? The obvious answer to my question about your question is that it is mission critical or not easily recreate-able. I'm also looking into my sources on this one for you... – Brad Bouchard Mar 16 '16 at 16:52
  • @BradBouchard: That is correct, other servers with the exact same object audit policy configuration (File System and Handle Manipulation success events) and the exact same audit properties on the share directories have the correct info in the event log entries. The server in question that contains missing info for any remote file access is 100% a mission critical machine which is why it is audited so heavily, the other were just to test if it was machine specific. I can propose a re-install to the client, but they aren't going to like it... – BrutalDev Mar 16 '16 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.