Na minha rede, há um servidor Windows 2008 R2 com nome de rede Dax
. Nesse servidor, tenho (entre outros, claro):
- uma unidade de disco rígido, montada como
E:\
- uma pasta
E:\odo
- um compartilhamento SMB
\\Dax\odo
que fornece a pastaE:\odo
para a rede - uma conta de usuário
Dax\Backup
O usuário Dax\Backup
é membro do Dax\Backup Operators
grupo e, além disso, tem permissões totais no compartilhamento \\Dax\odo
e na pasta E:\odo
.
Também tenho alguns PCs clientes executando o Windows 10 x64 Enterprise (versão 1809). Cada PC cliente tem
- várias contas de usuário que são diferentes das contas de usuário no servidor (ou seja, não há AD, os PCs clientes não estão associados a um domínio)
- uma pasta de dados complexa e profundamente aninhada com permissões cuidadosamente elaboradas, ou seja, cada usuário em um cliente tem acesso a diferentes partes (subpastas) da pasta de dados
- uma conta de usuário
Client\Backup
que tenha a mesma senha da conta do servidorDax\Backup
e que também seja membro do respectivo grupo de clientesClient\Backup Operators
.
Nos PCs clientes, tenho um software capaz de copiar toda a pasta de dados mencionada acima, incluindo todas as permissões, informações do proprietário, fluxos alternativos, junções e assim por diante no compartilhamento \\Dax\odo
. Eu deixo este software rodar sob a conta do usuário Client\Backup
para que ele possa ler a pasta de dados independentemente das ACLs que estão em vigor lá.
De fato, pastas, arquivos, junções e assim por diante (ou seja, o conteúdo real da pasta de dados) são copiados sem nenhum problema, mas o ajuste dos metadados (por exemplo, ACLs, propriedade) no destino falha.
Gostaria de entender o porquê e, claro, o que posso fazer a respeito.
Meus pensamentos e testes até agora são:
Meu software cliente está copiando esses arquivos e pastas no compartilhamento do servidor enquanto executa como user
Backup
. Como esse usuário (no servidor) está noBackup Operators
grupo, não deve haver problema em alterar os metadados durante a cópia ou mesmo após ter copiado um arquivo ou pasta, pois é exatamente para isso que oBackup Operators
grupo deve servir.Se (no servidor) eu tornar o usuário
Backup
membro doAdministrators
grupo, o problema persiste.Se (no servidor) eu der ao usuário
Dax\Administrator
permissão total para o compartilhamento\\Dax\odo
, bem como para a respectiva pastaE:\odo
, e se eu executar meu software cliente sob a contaClient\Administrator
(essa conta também tem a mesma senha nos clientes e no servidor), o o problema não persiste e o processo funciona conforme o esperado .
Além disso, rastreei o que acredito ser a causa do problema no servidor: Usando o monitor de processos da Sysinternals, vi que obviamente o usuário Backup
no servidor, ou mais precisamente, sua representação pelo serviço de rede / processo do sistema, não tem privilégios suficientes. Pelo menos, isso é o que eu faria com as propriedades do evento mostradas abaixo:
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
Nos últimos dias, também aprendi que para membros de determinados grupos (entre eles Administrator
e Backup Operators
) existem dois tokens: um normal e um elevado, onde apenas o último habilita os privilégios especiais de tais grupos.
Então (observe que isso é apenas uma suposição ingênua e que não sou especialista neste campo): O serviço de rede / processo do sistema no servidor pode representar a versão não elevada da conta de usuário Backup
ao lidar com o tráfego de rede em nome de esse usuário, e isso poderia ser o motivo do problema? Eu poderia resolver o problema fazendo com que o serviço de rede/processo do sistema personifique a versão elevadaBackup
da conta de usuário ao lidar com o tráfego de rede em nome desse usuário? Se sim, como?
PS Se minha teoria acima for boba, o título deste post será enganoso, então sinta-se à vontade para corrigi-lo ...
Sua teoria está correta. Esse comportamento pode ser alterado por meio de uma configuração de registro.
Dentro
localize ou crie o
DWORD
valorLocalAccountTokenFilterPolicy
e defina-o como 1. Pode ser necessário reinicializar.Isso permitirá que as conexões remotas tenham acesso irrestrito de administrador.