Grupos ausentes do token de acesso da conta do sistema

Question

Estou passando por um fenômeno estranho relacionado à conta do Windows SYSTEM. Olhando para estas três maneiras diferentes de iniciar um processo como SYSTEM:

• Sysinternals PSExec
• Agendador de tarefas
• Script de inicialização do GPO.

Os processos iniciados com esses métodos resultam em diferentes associações de grupos de tokens de acesso!

Os processos iniciados pelo Agendador de Tarefas têm o conjunto completo de grupos em seu token de acesso.

ProcessosiniciadospeloScriptPSExec/Startup,poroutrolado,possuemumconjuntodegruposmassivamentereduzidoemseutokendeacesso-apenasessesquatro

BUILTIN\Administrators (S-1-5-32-544)
Everyone (S-1-1-0)
NT AUTHORITY\Authenticated Users (S-1-5-11)
Mandatory Label\System Mandatory Level (S-1-16-16384)

Alguém tem uma ideia do porquê?

Para contexto:

O serviço BITS lança um erro "o usuário não efetuou logon na rede" 0x800704DD ao tentar adicionar um arquivo a uma transferência em processos iniciados com Script de inicialização ou PSExec - funciona bem com os iniciados no Agendador de Tarefas.

Todos os testes no Windows 10 1703; Associações de grupo retiradas de whoami / all e Sysinternals Process Explorer

    

Answer 1

Isso depende de como o serviço está configurado, mais especificamente no Tipo de SID de Serviço.

Se o Tipo de SID de Serviço for "nenhum", o serviço obterá um token de SYSTEM simples, o mesmo usado por outros processos do sistema, como services.exe e winlogon.exe e assim por diante. Esta é a situação do legado; de volta ao Windows XP, todos os serviços tinham esse tipo de token, a menos que estivessem configurados para serem executados como uma conta de usuário específica.

Se o Tipo de SID de serviço for "restrito" ou "irrestrito", um token mais específico será gerado para o serviço, incluindo um identificador de segurança especial específico para esse serviço, por exemplo, NT SERVICE\Schedule para o Agendador de tarefas. Isso ajuda a fornecer alguma granularidade entre os diferentes serviços. No Windows 7 e posterior, a maioria dos serviços integrados é "irrestrita". O serviço de diretiva de grupo é uma exceção; isso foi provavelmente um descuido da parte da Microsoft. (Eu teria pensado que era uma escolha deliberada para compatibilidade com versões anteriores, mas isso é prejudicado pelo fato de que, no Windows 7, ele sempre é executado em um processo de serviço compartilhado.)

Como você já observou, além de obter o identificador NT SERVICE , o token recebe vários outros identificadores. Isso não está documentado, tanto quanto eu posso ver, mas também não é especialmente surpreendente; Isso torna o token de serviço mais parecido com um token interativo, o que pode ser útil. (É particularmente importante que este seja o caso de tokens restritos, que de outra forma teriam muito pouco acesso.)

Conforme descrito na resposta automática, quando vários serviços são compartilhados por um único processo, o token de processo deve conter todos os SID que qualquer um dos serviços precisa. Portanto, se o Serviço de Diretiva de Grupo (ou qualquer outro serviço com um tipo SID de "nenhum") estiver compartilhando um processo com um serviço "irrestrito", ele obterá exatamente o mesmo token como se fosse "irrestrito".

Como as versões anteriores do Windows executavam o Serviço de Diretiva de Grupo como "irrestrito" e, mesmo que o Windows 10 o fizesse em máquinas com memória muito limitada, ele provavelmente não seria muito perigoso para reconfigurar o SID Digite para o serviço de Diretiva de Grupo se for absolutamente necessário fazê-lo . Eu não recomendo isso a não ser talvez como uma solução de curto prazo, em parte porque ainda há algum risco (particularmente em relação à compatibilidade com versões anteriores), mas principalmente porque toda vez que você atualiza para uma nova versão do Windows 10 é provável que a configuração seja revertido.

Uma solução melhor seria que um script de inicialização executasse uma tarefa agendada ou instalasse e executasse um serviço para executar qualquer trabalho necessário em nome do script de inicialização.

    

Answer 2

ENCONTREI a causa básica do problema - pelo menos para Script de inicialização.

Eu olhei para a pilha de chamadas e acontece que um script de inicialização é chamado:

svchost.exe (hosts gpsvc) > gpscript.exe > cmd.exe

Todos os três processos têm um conjunto reduzido de associações de grupo em seu token de acesso. Acontece que desde o Windows 10 1703 serviços svchost não são mais agrupados, se você tiver acima de 3,5 GB de memória. link

Cada serviço do svchost obtém seu próprio processo - com diferentes participações de grupo no token de acesso (o contexto ainda não está claro, a entrada para isso ainda é muito apreciada!). Felizmente há um opt-out:

Solução :

Adicionando o valor do registro

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gpsvc\SvcHostSplitDisable=1 [DWORD]

mantém o serviço gpsvc no processo svchost principal com o conjunto completo de associações a grupos - mesmo se acima de 3,5 GB de memória. E, portanto, o gpscript.exe e o Startup Script são chamados com o conjunto completo de associações.

Para mim, ainda não está claro por que um processo com o mesmo usuário pode ter um conjunto diferente de associações a grupos em seu token de acesso - quando nenhuma associação real foi alterada. Eu apreciaria qualquer informação sobre isso.

Infelizmente, depois de tudo isso: o serviço BITS ainda não aceita transferências de arquivos e lança "o usuário não efetuou logon na rede" 0x800704DD. Eu abri uma nova pergunta para este link