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
- a folder
- an SMB share
\\Dax\odowhich provides the folder
E:\odoto the network
- a user account
Dax\Backup is member of the
Dax\Backup Operators group and additionally has full permissions on the share
\\Dax\odo as well as on the folder
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
Client\Backupwhich has the same password as the server's account
Dax\Backup, and which also is member of the respective client's
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
\\Dax\odo. I let this software run under user account
Client\Backup 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 Operatorsgroup, 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 Operatorsgroup should serve.
If (on the server) I make the user
Backupa member of the
Administratorsgroup, the problem persists.
If (on the server) I give the user
Dax\Administratorfull permission for the share
\\Dax\odoas well as for the respective folder
E:\odo, and if I run my client software under the account
Client\Administrator(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:\Odo\d-LSE\d\temp\test - 2019-05-04 09-27-40\bla.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: DAX\Backup
In the past few days, I also have learned that for members of certain groups (among them
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 ...