如何使服务（或系统进程）模拟用户帐户的*提升*变体？

在我的网络中，有一个带有 network name 的 Windows 2008 R2 服务器Dax。在该服务器上，我有（当然还有其他）：

• 硬盘驱动器，安装为E:\
• 一个文件夹E:\odo
• 向网络\\Dax\odo提供文件夹的 SMB 共享E:\odo
• 用户帐户Dax\Backup

用户Dax\Backup是该组的成员，另外还拥有共享和文件夹Dax\Backup Operators的完全权限。\\Dax\odoE:\odo

我还有一些运行 Windows 10 x64 Enterprise（版本 1809）的客户端 PC。每台客户端 PC 都有

• 与服务器上的用户帐户不同的多个用户帐户（即没有 AD，客户端 PC 未加入域）
• 具有精心设计的权限的复杂且深度嵌套的数据文件夹，即客户端上的每个用户都可以访问数据文件夹的不同部分（子文件夹）
• Client\Backup与服务器帐户具有相同密码的用户帐户Dax\Backup，并且也是相应客户端Client\Backup Operators组的成员。

在客户端 PC 上，我有一个软件，它能够将上面提到的整个数据文件夹复制到共享上，包括所有权限、所有者信息、备用流、连接点等\\Dax\odo。我让这个软件在用户帐户下运行，Client\Backup这样它就可以读取数据文件夹，而不管那里有效的 ACL。

实际上，复制文件夹、文件、连接等（即数据文件夹的实际内容）没有任何问题，但在目标上调整元数据（例如 ACL、所有权）失败。

我想了解原因，当然还有我能做些什么。

到目前为止，我的想法和测试是：

• 我的客户端软件在以用户身份运行时将这些文件和文件夹复制到服务器的共享上Backup。由于该用户（在服务器上）在Backup Operators组中，因此在复制时甚至在复制文件或文件夹之后更改元数据应该没有问题，因为这正是Backup Operators组应该服务的目的。

• 如果（在服务器上）我让用户Backup成为Administrators组的成员，问题仍然存在。

• 如果（在服务器上）我向用户Dax\Administrator授予共享\\Dax\odo以及相应文件夹的完全权限E:\odo，并且如果我在该帐户下运行我的客户端软件Client\Administrator（该帐户在客户端和服务器上也具有相同的密码），则问题不会持续存在，并且该过程按预期工作。

此外，我已经找到了我认为是服务器上问题的原因：使用 Sysinternals 的进程监视器，我看到显然Backup服务器上的用户，或者更准确地说，它是由网络服务/系统进程模拟的，没有足够的权限。至少，这是我从下面显示的事件属性中得出的：

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

这几天，我还了解到，对于某些组的成员（其中Administrator和Backup Operators）有两个令牌：一个普通的和一个提升的，其中只有后者启用这些组的特权。

所以（请注意，这只是天真的猜测，我不是该领域的专家）：服务器上的网络服务/系统进程能否Backup在代表处理网络流量时冒充用户帐户的非提升版本那个用户，这可能是问题的原因吗？我可以通过在代表该用户处理网络流量时以某种方式使网络服务/系统进程模拟用户帐户的提升版本来解决问题吗？Backup如果是，如何？

PS如果我的上述理论很愚蠢，这篇文章的标题会产生误导，所以请随时纠正......