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 \\Dax\odo which provides the folder E:\odo to the network
  • a user account Dax\Backup

The user 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 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 Client\Backup which has the same password as the server's account Dax\Backup, and which also is member of the respective client's Client\Backup 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 \\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 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 Dax\Administrator full permission for the share \\Dax\odo as 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
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 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.



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.

|improve this answer|||||
  • Accepted and +1. Actually, this answer is ingenious, and I would give you 20000 reputation if I could. Heck, I have spent more than a whole day with the UI going through every group policy to identify the relevant one, not knowing if my theory could be correct, and then they hide it and you only can change this via registry. Great. – Binarus May 6 '19 at 11:42
  • And furthermore, even I had found the page you linked, I wouldn't have noticed that this was the solution to my problem, because this page is plain wrong in talking only about the Administrators group (I added my Backup user to that group for test purposes only, but wouldn't have accepted this as a permanent solution). But fortunately, that registry change also elevates accounts which belong to the Backup Operators group (and probably those belonging to other certain groups which have split tokens, but I didn't test). – Binarus May 6 '19 at 11:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.