3

I want to enable file auditing on a shared network drive specifically in order to track who creates and deletes files (in the event of a catastrophe). Somehow I don't have permission to change or view the directory's auditing settings, despite being both owner and a domain administrator with full control.

More details: I'm the administrator for a small office running a server with Windows Server 2016. I'm trying to enable file auditing on the shared network drive, so that we can track who deletes files (in the event of catastrophe). I've followed the steps in this how-to from Microsoft up to the point where you edit the auditing entry for a particular directory. When I go to the "Auditing" tab of "Advanced Security Settings" for the desired directory, I get a message that says "You do not have permission to view or edit this object's audit settings." Auditing is working to the extent that I can see the login/logout audit in the event log.

I am logged in as the domain administrator. I have full control of this directory. I took ownership of the directory both as all administrators and later as just this domain administrator. I had to do this using takeown in PowerShell because everything else kept throwing ownership errors. Now I'm also worried that this was a mistake, and that I shouldn't have taken ownership of all of those files.

A little background: I do not have a background in IT, I have a master's in computer science and have become the network administrator because I'm the one who's "good with computers." Any help on this problem (or reassurance on the ownership issue) would be greatly appreciated!

Eliza Bennet
  • 71
  • 1
  • 7
  • 1
    I don't have an answer to your issue, but I would make sure you look at your back-up plan for these files and ensure you have any easy way to recover. At a minimum enable shadow copies so you can restore previous versions and make sure you have a good off-disk backup of the data. Auditing is great, but it only tells you who broke it - it won't help you get it back. – pxed Feb 02 '18 at 19:38
  • 1
    Thanks, @pxed, I do have a good backup plan (shadow copies for the individual file restoration and an external backup of the whole server - this gets updated daily and is swapped with another drive weekly, the off drive being kept off-site). I know that I can _restore_ any files that get deleted, I'd just also like to potentially know who deleted them, because if someone messes up that badly, they're probably not going to admit it. – Eliza Bennet Feb 02 '18 at 19:52
  • Are you sure the file explorer is running as an elevated account? I never use Windows File Explorer to perform file security operations. UAC is just too much in the way. Either do it from an elevated PowerShell or use a third party file management tool which runs elevated. – Peter Hahndorf Feb 03 '18 at 01:15
  • @PeterHahndorf I couldn’t figure out how to set it within powershell (that was my first plan), because I’m not familiar with powershell scripting. I’ll look up accessing the elevated file explorer, I assumed that with an admin account it was admin access. Thanks! – Eliza Bennet Feb 03 '18 at 22:46

2 Answers2

4

I was using a filepath that used a mapped drive in it. When I switched to a direct filepath, the issue disappeared.

That is, I needed to go to \\servername\Shared Folders\MyFolder instead of S:\MyFolder (where \\servername\Shared Folders\ has been mapped to the S drive). Posting this as an answer in case it helps anyone else who gets stuck for a silly reason!

Eliza Bennet
  • 71
  • 1
  • 7
  • If this drive maps to a DFS path, then this might explain why it happened: https://support.microsoft.com/en-us/help/842604/permissions-are-not-correctly-inherited-in-a-dfs-topology-on-windows-2 Basically, if you edit ACLs from the DFS path rather than the actual underlying share or drive path, it can lead to situations where the inheritance comes from the DFS namespace root as the parent object instead of the real parent object. – GuitarPicker Jul 02 '18 at 19:01
  • This also applies to the inverse - if you are *on* the local server using the Shared Folder, you need to use the local path instead – Coruscate5 Dec 17 '18 at 22:00
1

The technical aspect of your question aside, your statement gives me pause:

I know that I can restore any files that get deleted, I'd just also like to potentially know who deleted them, because if someone messes up that badly, they're probably not going to admit it.

Why is deleting something considered a bad "mess up"? Users are human beings, prone to the occasional goof (just like you yourself are). Why such a negative tone toward making mistakes? Why would your users be reticent about taking responsibility for their mistakes? Is there a culture of fear at your company? Are employees chastised and/or punished for making mistakes?

One of the reasons you have backups is because users will invariably delete things by mistake. Barring a disgruntled employee, nobody does this on purpose. Looking to assign blame and chastise employees for making mistakes is never productive.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • To be honest, I was actually thinking of the unlikely possibility of a disgruntled employee, but I didn't want to say it outright (I don't know why not). A worst case scenario kind of deal, basically. – Eliza Bennet Feb 05 '18 at 13:33