Otdfbt

In my network, there is a Windows 2008 R2 server with network name Dax. On that server, I have (among others, of course):

• a hard disk drive, mounted as E:
  


• a folder E:odo
  


• an SMB share \Daxodo which provides the folder E:odo to the network


• a user account DaxBackup
  

The user DaxBackup is member of the DaxBackup Operators group and additionally has full permissions on the share \Daxodo as well as on the folder E:odo.

I also have some client PCs running Windows 10 x64 Enterprise (version 1809). Each client PC has

• multiple user accounts which are different from the user accounts on the server (i.e. there is no AD, the client PCs are not joined to a domain)


• a complex and deeply nested data folder with carefully crafted permissions, i.e. every user on a client has access to different parts (subfolders) of the data folder


• a user account ClientBackup which has the same password as the server's account DaxBackup, and which also is member of the respective client's ClientBackup Operators group.

On the client PCs, I have a software which is able to copy the whole data folder mentioned above, including all permissions, owner info, alternate streams, junctions and so on onto the share \Daxodo. I let this software run under user account ClientBackup so that it can read the data folder regardless of the ACLs which are in effect there.

Indeed, folders, files, junctions and so on (i.e. the actual contents of the data folder) are copied without any problem, but adjusting the metadata (e.g. ACLs, ownership) on the destination fails.

I would like to understand why, and of course what I can do about it.

My thoughts and tests so far are:

• My client software is copying those files and folders onto the server's share while running as user Backup. Since that user (on the server) is in the Backup Operators group, there should be no problem with changing the metadata while copying or even after having copied a file or folder, because that's exactly the purpose the Backup Operators group should serve.




• If (on the server) I make the user Backup a member of the Administrators group, the problem persists.




• If (on the server) I give the user DaxAdministrator full permission for the share \Daxodo as well as for the respective folder E:odo, and if I run my client software under the account ClientAdministrator (that account also has the same password on the clients and the server), the problem does not persist, and the process works as intended.

Furthermore, I have tracked down what I believe is the cause of the problem on the server: Using Sysinternals' process monitor, I have seen that obviously the user Backup on the server, or more precisely, its impersonation by the network service / system process, does not have sufficient privileges. At least, this is what I would make out of the event properties shown below:

High Resolution Date & Time: 04.05.2019 09:27:37,2077520
Event Class: File System
Operation: IRP_MJ_CREATE
Result: PRIVILEGE NOT HELD
Path: E:Odod-LSEdtemptest - 2019-05-04 09-27-40bla.txt
TID: 2812
Duration: 0.0000581
Desired Access: Generic Write, Read Attributes, Write DAC, Write Owner, Access System Security
Disposition: OpenIf
Options: Complete If Oplocked
Attributes: n/a
ShareMode: Read
AllocationSize: 0
Impersonating: DAXBackup

In the past few days, I also have learned that for members of certain groups (among them Administrator and Backup Operators) there are two tokens: a normal one and an elevated one, where only the latter enables the special privileges of such groups.

So (please note that this is just naive guessing and that I am not an expert in this field): Could the network service / system process on the server impersonate the non-elevated version of the user account Backup when handling the network traffic on behalf of that user, and could this be the reason for the problem? Could I solve the problem by somehow making the network service / system process impersonate the elevated version of the user account Backup when handling the network traffic on behalf of that user? If yes, how?

P.S. If my above theory is silly, the title of this post will be misleading, so feel free to correct it ...

Your theory is correct. This behaviour can be changed via a registry setting.

In

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem

find or create the DWORD value LocalAccountTokenFilterPolicy and set it to 1. You may then need to reboot.

This will allow remote connections to have unrestricted administrator access.