0

I have a 3rd party app that "makes a call" to write files to a file share on our network using the currently logged in credentials of the Windows domain user. Meaning the 3rd party app doesn't pass the apps credentials but simply issues a behind the scenes copy command to take a source file specified and copy/move it to the destination "repository" on the file share. The basic premise is that it keeps revisions/approvals for Document Control (think svn/git I guess, similar to this question: Lock down Windows folder to only be updatable by SVN).

This all works fine...but here's my issue:

I need a way to lock down the file share from being accessed/modified outside of using the 3rd party app (meaning prevent explorer/word/excel/etc from getting to that share).

I know I can do the following:

  • make the share a hidden share ($) - this definitely helps. Most users would have zero clue on how to get to such a share. Solves probably 95% of my issue.
  • go one step further and set the "Hidden" attribute on the folders in the hidden share - this would go a little further in that even if a user knows the path to the hidden share like \\server\hidden$ they still won't see folders in that share without changing their explorer options to "show hidden files/folder

Any other ideas on how I can lock this down? The users still need modify rights to this share/folders since the 3rd party app relies on their Windows permissions to that location when copying the files into it. I can't really use 3rd party tools to password protect the folder/share without causing the 3rd party app functions to fail.

1
  • 1
    Could you remove the "List folder contents" permission on the folder? If your script knows the file names of what to copy already, it may not need it.
    – Derrick
    Jun 27, 2013 at 15:37

1 Answer 1

0

You could set the permissions on the top-level folder only that the user needs access to, that "authenticated users" have "create files/write data" (and "create folders" if needed) and no other permissions.

What actual problem are you trying to solve?

6
  • Regulatory issues. The 3rd party system is great for record auditing, revision control, e-signatures, etc. required for compliance but part of the regulation states that there shouldn't be a way to manipulate the record/file without these "trails". NTFS auditing won't suffice for the reg, so I need a way to lock down the share to an extent that we can prove that it would have to be malicious/intentional that a user went directly to the file instead of through the 3rd party app.
    – TheCleaner
    Jun 27, 2013 at 15:55
  • I don't think that will work. How won't NTFS auditing work? You really can't prove, ever, that a file was written/edited by a user vs a program, when they use the same credentials and come from the same IP.
    – mfinni
    Jun 27, 2013 at 16:04
  • NTFS auditing won't tell me what changed inside the file. The 3rd party software does.
    – TheCleaner
    Jun 27, 2013 at 16:14
  • Then you're looking for something like File Integrity Monitoring, which is generally accomplished via 3rd party tools to begin with. If you already know what user and IP touched a file (with NTFS auditing) and what changes were made (via this tool), what gaps are you trying to fill?
    – mfinni
    Jun 27, 2013 at 17:01
  • I guess I'm being to vague. The 3rd party tool does EVERYTHING I need it to regulatory wise. The problem is that users can intentionally circumvent the software by using Explorer and browsing directly to the files it creates (Office docs for instance) and change them outside of the 3rd party software. Just looking for additional countermeasures besides what I listed in my OP that might deter a user from even trying that method.
    – TheCleaner
    Jun 27, 2013 at 18:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .