Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
Ask a Question

Access to sub-folders based on Active Directory group / Windows NTFS rights

0 votes
360 views
in CompleteFTP by (200 points)

For Windows users, I want to have access to one main folder which has 7 different sub-folders for each country that would be using my SFTP server.

Folder structure is like this:

Main_Folder
--Sub-Folder-Country-1
--Sub-Folder-Country-2
--Sub-Folder-Country-3
--Sub-Folder-Country-4
--Sub-Folder-Country-5
--Sub-Folder-Country-6
--Sub-Folder-Country-7

Now, I have 7 different AD Groups (one for each sub-folder) and I have set the rights of the folders so that:

  • All AD groups access the main folder with Read & Execute NTFS rights
  • Each AD group has Write access to it's specific Sub-folder

However, when the users log on from one group (e.g Country 1), they are still able to upload and delete files in other AD groups' sub-folders (e.g Country 2, Country 3, etc). According to my understanding, this shouldn't be possible but it is...

Can you give me some insight as to what I should do to solve this? I do not want to start managing the folder rights of each individual user, as I want to have as little administration effort as possible; only change in AD groups should change your access to folders.

1 Answer

0 votes
by (51.1k points)
selected by
 
Best answer

This should work fine.  CompleteFTP uses impersonation, which has proven to be pretty bullet-proof over the years, so unexpected errors like this are usually because of configuration problems.  For example, one error someone had recently was that when she was testing it, she was inadvertently logging into local Windows accounts rather than equivalently named AD accounts.  In any case, a good place to start diagnosing the problem is a diagnostic log file (DEBUG level), but this shouldn't be uploaded to this public forum.  Can you instead please open a ticket at our helpdesk and attach the log file there?

by (200 points)
I enabled DEBUG config on the server and took a look at the logs. I have obfuscated all sensitive data in the paste below. What I see is that my AD account is being impersonated by 'NT AUTHORITY\SYSTEM' when I am opening folders and uploading files - could that be the issue?

2018-11-02 10:13:17,166 DEBUG ImpersonationContext [Session.1138:eSIM AT Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Impersonation begin -> 'Domain\MyDomainAccount'
2018-11-02 10:13:17,166 DEBUG SFTPServerMessageFactory [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Received message (type=11,len=31)
2018-11-02 10:13:17,166 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Received message (SSH_FXP_OPENDIR,id=38923)
2018-11-02 10:13:17,166 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] OnOpenDir(/Site/MainFolder)
2018-11-02 10:13:17,166 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Handle 1865685928 creTested for /Domain Home Folder/Site/MainFolder
2018-11-02 10:13:17,166 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Sending SSH_FXP_HANDLE (requestid= 38923)
2018-11-02 10:13:17,166 DEBUG SSHServerChannel [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Transmit 23 bytes (max = 16384)
2018-11-02 10:13:17,166 DEBUG ChannelDTestaWindow [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Remote window size decreased to 2147483490
2018-11-02 10:13:17,166 DEBUG SFTPConnection [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Sequence: 13
2018-11-02 10:13:17,166 DEBUG SFTPConnection [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Sending 80 bytes
2018-11-02 10:13:17,166 DEBUG ImpersonTestionContext [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] ImpersonTestion end -> 'NT AUTHORITY\SYSTEM'


Here is log paste from uploading the file to the server
2018-11-02 10:13:22,901 DEBUG ImpersonTestionContext [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] ImpersonTestion begin -> 'Domain\MyDomainAccount'
2018-11-02 10:13:22,901 DEBUG SFTPServerMessageFactory [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Received message (type=3,len=67)
2018-11-02 10:13:22,901 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Received message (SSH_FXP_OPEN,id=42243)
2018-11-02 10:13:22,901 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] OnOpenFile(Name=SSH_FXP_OPEN,Type=3,RequestID=42243
2018-11-02 10:13:22,901 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] absolutePTesth=/Site/MainFolder/CountryBasedSubfolder/in/test.txt
2018-11-02 10:13:22,901 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] flags=58
2018-11-02 10:13:22,901 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Testtributes=Valid flags=1, US=, G=, D=False, F=False, LI=False, R=False, W=False, Test=0, AD=1970-01-01 00:00:00, MT=0, MD=1970-01-01 00:00:00, P=0, S=31, U=)
2018-11-02 10:13:22,901 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] file '/Domain Home Folder/Site/MainFolder/CountryBasedSubfolder/in/test.txt' does not exist
2018-11-02 10:13:22,901 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Handle 500592728 creTested for /Domain Home Folder/Site/MainFolder/CountryBasedSubfolder/in/test.txt
2018-11-02 10:13:22,901 INFO SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Opened /Domain Home Folder/Site/MainFolder/CountryBasedSubfolder/in/test.txt for writing
2018-11-02 10:13:22,901 DEBUG SFTPSubsystemServer [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Sending SSH_FXP_HANDLE (requestid= 42243)
2018-11-02 10:13:22,901 DEBUG SSHServerChannel [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Transmit 22 bytes (max = 16384)
2018-11-02 10:13:22,901 DEBUG ChannelDTestaWindow [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Remote window size decreased to 2147482211
2018-11-02 10:13:22,901 DEBUG SFTPConnection [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Sequence: 26
2018-11-02 10:13:22,901 DEBUG SFTPConnection [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Sending 80 bytes
2018-11-02 10:13:22,901 DEBUG SFTPConnection [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] Sent 80 bytes
2018-11-02 10:13:22,901 DEBUG ImpersonTestionContext [Session.1138:Site Test SFTP Site:Domain\MyDomainAccount:127.0.0.1] ImpersonTestion end -> 'NT AUTHORITY\SYSTEM'

If this does not help solve this case, I will create a helpdesk ticket.
by (51.1k points)
All Windows API operations within the block that starts

  Impersonation begin -> 'Domain\MyDomainAccount'

and ends with

  Impersonation end -> 'NT AUTHORITY\SYSTEM'

are executed under the Windows account, Domain\MyDomainAccount.

This block includes

  Opened /Domain Home Folder/Site/MainFolder/CountryBasedSubfolder/in/test.txt for writing

which should only be possible if Domain\MyDomainAccount has write-permission for the Windows directory that /Domain Home Folder/Site/MainFolder/CountryBasedSubfolder/in maps to.

As I understand it, you're saying that this Windows account does not in fact have write permission to this directory.  There are a couple of ways to verify that that's correct: (1) Use the 'Effective Access' tab in the Advanced Security Settings of the Properties dialog that you can open from the Windows File Explorer, and (2) log into the machine as Domain\MyDomainAccount and try to write to a file in that directory.  Have you tried these?
by (200 points)
Unfortunately, I work for a very large company with a very large domain/AD and I do not have direct access to the user's roles.
That being said, the issue was solved when the AD admin removed some incorrect roles from the user. Thanks for the help!
by (51.1k points)
That's great.  Thanks for following up.

Categories

EnterpriseDT 2020
...