Skip to main content

Home Directory folder creation NTFS Rights

Not planned

Comments

2 comments

  • Dana Anderson
    Product Support

    Hello, Jason.

    I did take some time to look over the ticket. From what I'm seeing this seems more like an NTFS permissions issue. 

    By default, whatever service account is running the Cerberus FTP Server Windows Service is the owner of the created directory. The created directory inherits permissions from the parent folder (your global root). It's just as any other new folder you create under an account.

    Cerberus just issues a make directory command for the user directory.  No special ACLs or permissions are applied. 

    There is one other option you might want to check the "Create Home Directory As user for AD" option on the Policy page of the User Manager.

    With this option, the AD user creates the account and is the owner. That will normally result in at least the AD user having the appropriate permissions. However, it still largely depends on the parent folder as to what overall permissions the created folder has.

    I would take another look at your permissions, you will want to make sure your parent folder has the appropriate permissions so that the child folders inherit the permissions you want.

    My recommendation is to make sure that the root folder the directories are getting created under has full control for Domain Users or some other broad group that your AD users are a member of.

    Make sure your AD users have permissions to perform the requires operations under that root folder. That will help ensure that whatever user folder is created for them also has the correct permissions. Cerberus will ensure they stay in their folder if using the Global Home\%USER% option.

    0
  • Jason Webb

    Hi Dana,

    It's absolutely NTFS permissions, but I'm hoping the product can be updated add an optional feature which will add a 'This folder, subfolders and files' Full Control ACE for the AD user to prevent admins from having to manage the issue with a workaround due to having secure, non-default NTFS permissions on their root folders.

     

    Based on my discussion with support, Cerberus tests this feature with the default permissions for Windows file systems which has <localserver>\Users (which includes Domain Users) with two ACEs and then one ACE for the user that creates the %user% folder:

    This folder, subfolders and files: Read & Execute (all domain and local users)

    This folder and subfolders: Create files / write data, Create folders / append data (all domain and local users)

    This folder only: Full Control (specific domain user)

    Because of this, your testing scenario only works by virtue of the Users group granting generic read privileges to files created by Public users. The AD user logging into Cerberus can only download a public user's uploaded files because of this, not because of their individual permissions. They actually couldn't normally delete files uploaded by public sources because of this, but I assume that the Cerberus service account actually performs the delete operation instead of utilizing the user account permissions like for a download operation. 

     

    We do not keep those default <localserver>\Users permissions in place because they over-privilege all users in every other user's private folder. Though I willingly admit it is unlikely another user would find an entry point to abuse this in a typical Cerberus scenario (baring any bugs being exploited).

    If this is not something that is likely to be considered for feature enhancement, I will write PowerShell to adjust permissions after Cerberus creates folders.

    0

Please sign in to leave a comment.