Announcement

Collapse
No announcement yet.

Blind Drop Box Security Settings

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Blind Drop Box Security Settings

    an example of what I'm trying to accomplish except using ABE and without FTP at this time: htxp://www.iisanswers.com/Blind_drop_ftp.htm

    I have what I feel is a somewhat unique requirement and for the life of me I cannot make it work. I did numerous searches on Google to no avail and also searched this site prior to posting this.

    I'm trying to create a file share that serves as a "blind drop box". Those unfamiliar with the terminology have most certainly encountered a blind drop at some point, mostlikely on a public FTP of some sort.

    The way the blind drop box works is, a user accesses the box and sees no sub-directories or files, although there may be countless in the drop box. The user is able to "drop" files and folders into this directory and after doing so, they disappear.

    Another user with appropriate access, can visit the directory and access all of the files/folders.

    I have ABE/Access Based Enumeration running on the server and the closest I have come to success is a configuration where a user is able to drop the files into the drop box, but is still able to see them. Aparently this could be an issue in the event we grant IUSR access to a drop box, then anyone who accesses the drop box as the IUSR will see the files dropped by other anonymous users.

    I was also able to configure a share folder where files dropped became invisible, however; a directory containing files could not be copied into the drop because of inappropriate permissions. The directory would be created, however; when the OS attempted to copy the files that were contained in the directory, an access denied error was displayed.

    ANY insight whatsoever on this would be really appreciated. I'm really struggling with making this piece work. Thank you for taking the time to read this.

  • #2
    Re: Blind Drop Box Security Settings

    What NTFS permissions have you given the folder?
    I'll do some testing to see what works
    Tom Jones
    MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
    PhD, MSc, FIAP, MIITT
    IT Trainer / Consultant
    Ossian Ltd
    Scotland

    ** Remember to give credit where credit is due and leave reputation points where appropriate **

    Comment


    • #3
      Re: Blind Drop Box Security Settings

      OK, giving NTFS WRITE permission only means that you cannot open the folder but you can drop files into it and they will copy OK
      Will that do what you want?

      Note when changing default permissions, leave creator/owner and system permissions untouched
      Tom Jones
      MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
      PhD, MSc, FIAP, MIITT
      IT Trainer / Consultant
      Ossian Ltd
      Scotland

      ** Remember to give credit where credit is due and leave reputation points where appropriate **

      Comment


      • #4
        Re: Blind Drop Box Security Settings

        Ossian,

        thanks for your timely response. I've run through a few different scenarios and obviously I haven't gotten to where I want to be. Hopefully the notes I took are accurate enough to recreate where I'm at:

        The file structure would look as such:
        someShare\departmentName\%userName%\incoming (incoming being the drop box)

        someShare
        -Shared to "authenticated users" with full permission
        -Access Based Enumeration (ABE) enabled
        -NTFS PERMISSIONS: Admin, Creator Owner, System = Full Control
        -Authenticated Users = "List Folder Contents" advanced permissions applied to "this folder and subfolders": Traverse Folder / Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes and Read Permissions.

        These permission settings allow any user to map the share and view the individual departments listed.

        DepartmentName (i.e. HumanResources)
        -Not shared
        -NTFS PERMISSIONS: Admin, Creator Owner, System = Full
        -Authenticated Users: Same as above.

        These permission settings allow any user to view the users listed under each department

        %Username% (i.e. jsmith)
        -Not shared
        -NTFS PERMISSIONS: Admin, Creator Owner, System = Full
        -Authenticated users: Special Permissions (THIS FOLDER ONLY): Traverse Folder / Execute File, List Folder / Read Data, Read Attributes, Read Extended Attributes, Read Permissions.
        -%userName% (jsmith): Full Control

        These permissions allow any authenticated user to view in the %username% folder for any shares/folders that have been modified to allow them to view. BY DEFAULT any files or folders created by jsmith, will be invisible to all other users.

        incoming (not working)
        -Not Shared
        -NTFS PERMISSIONS: Admin, System, %username% (jsmith): FULL
        -Authenticated users: Special Permissions (THIS FOLDER ONLY): traverse folder / execute file, list folder / read data, read attributes, read extended attributes, create files / write data, create folders / append data, write attributes, read permission.


        This is close to where I want to be. Basically any authenticated user can access "incoming" and see nothing. Jsmith visits HIS incoming and sees everything that is inside the directory.

        Authenticated user can drag and drop files into jsmith's "incoming" and they immediately disappear as intended. The problem is with SUBDIRECTORIES.
        If anyUser tries to create a directory under jsmiths\incoming, it is created fine. But if anyUser attempts to drag/drop a directory containing subdirectories or files contained in the directory and error is reported by the server saying:

        Error Copying File or Folder (it's the file in the directory in question)
        Cannot copy %filename%: Access is denied

        Make sure the disk is not full or write-protected and that the file is not currently in user
        Now if anyUser attempts to put "folder1" that contains "file1" onto jsmiths incoming, the error appears. If you examine the folder:

        jsmith\incoming\folder1 you see the following permissions:
        -Administrator, jsmith, system: full control


        Hope this had enough information. Sorry I didn't respond back quicker I got tossed into a meeting right when I finished typing up my question. Thanks again for taking the time to assist me with my issue.

        -u

        Comment


        • #5
          Re: Blind Drop Box Security Settings

          Ossian, thanks for the idea about

          OK, giving NTFS WRITE permission only means that you cannot open the folder but you can drop files into it and they will copy
          For some reason this morning I had a slight epiphany about the creators/owners group. Yes I do realize that you said to leave this permission untouched, however; I can't accomplish what I need to without modifying them...there are certain attributes that I don't quite understand that cause ABE / access based enumeration to either show or hide the files/folders.

          If anyone was patient enough to read through my last post, you'd see my problem is that when an authenticated user writes files to jsmiths "incoming" this works. But when authenticated user writes a folder that contains a file to jsmiths incoming, it fails on the file part.

          and if I examined "new_folder" created by "authenticated user" they obviously didn't have rights to the folder to write the file.

          So this morning I put creator/owner back onto the "incoming" directory with permissions to traverse and write. And I'm able to create a folder that contains a file without error. However; I'm encountering the same problem when I attempt to drop a folder containing multiple levels of directories.

          INCOMING PERMISSIONS
          Administrators, jsmith, system: FULL
          Authenticated users: This Folder only: Traverse, List, Read Attributes, Read Extended Attributes, Create Files/Write Data, Create Folders/Append Data, Write Attributes, Write Extended Attributes, Read Permissions.

          Creator / Owner (theoretically this is the authenticated user dropping files/folders into incoming): Subfolders and Files Only (this is forced, I cannot change because it inherits this attribute from auth_users permissions): Traverse, Create Files/Write Data, Create Folders / Append Data, Write Attributes, Write Extended Attributes.

          To reiterate, these permissions are one step closer than I was before, allowing an authenticated user to drop files into jsmiths incoming. Also allowing a folder containing a file to be dropped into jsmiths incoming. But once a folder containing another folder containing a file is dropped into jsmiths incoming it breaks.

          Comment


          • #6
            Re: Blind Drop Box Security Settings

            Hi,
            It might be worth while to look into how properties are inherited. "Reset permissions on all child objects and enable propagation of inheritable permissions" should be what is needed. The one problem that may pop up would be that we don't allow the read permission higher up but testing will tell us for sure.
            I don't know anything about (you or your) computers.
            Research/test for yourself when listening to free advice.

            Comment


            • #7
              Re: Blind Drop Box Security Settings

              thanks Maebe, I'll take a look at it again today. I've got so many things happening I'm trying to juggle it all.

              Comment

              Working...
              X