A diferença entre a conta 'Sistema local' e a conta 'Serviço de rede'?

386

Eu escrevi um serviço do Windows que gera um processo separado. Este processo cria um objeto COM. Se o serviço for executado na conta 'Sistema local', tudo funcionará bem, mas se o serviço for executado na conta 'Serviço de rede', o processo externo será iniciado, mas não será possível criar o objeto COM. O erro retornado da criação do objeto COM não é um erro COM padrão (acho que é específico para o objeto COM que está sendo criado).

Então, como determino como as duas contas, 'Sistema Local' e 'Serviço de Rede' diferem? Essas contas internas parecem muito misteriosas e ninguém parece saber muito sobre elas.

jmatthias
fonte

Respostas:

701

Como há muita confusão sobre a funcionalidade das contas de serviço padrão, tentarei dar uma olhada rápida.

Primeiro as contas reais:

  • Conta LocalService (preferencial)

    Uma conta de serviço limitada muito semelhante ao Serviço de Rede e destinada a executar serviços padrão com menos privilégios. No entanto, diferentemente do Serviço de rede, ele acessa a rede como um usuário anônimo .

    • Nome: NT AUTHORITY\LocalService
    • a conta não possui senha (todas as informações fornecidas são ignoradas)
    • HKCU representa a conta de usuário LocalService
    • possui privilégios mínimos no computador local
    • apresenta credenciais anônimas na rede
    • SID : S-1-5-19
    • possui seu próprio perfil na chave de registro HKEY_USERS ( HKEY_USERS\S-1-5-19)

     

  • Conta NetworkService

    Conta de serviço limitada destinada a executar serviços privilegiados padrão. Essa conta é muito mais limitada que o sistema local (ou mesmo o administrador), mas ainda tem o direito de acessar a rede como a máquina (consulte a observação acima).

    • NT AUTHORITY\NetworkService
    • a conta não possui senha (todas as informações fornecidas são ignoradas)
    • HKCU representa a conta de usuário do NetworkService
    • possui privilégios mínimos no computador local
    • apresenta as credenciais do computador (por exemplo MANGO$) para servidores remotos
    • SID : S-1-5-20
    • possui seu próprio perfil na chave de registro HKEY_USERS ( HKEY_USERS\S-1-5-20)
    • Se estiver tentando agendar uma tarefa usando-a, entre NETWORK SERVICEna caixa de diálogo Selecionar usuário ou grupo

     

  • Conta LocalSystem (perigosa, não use!)

    Conta totalmente confiável, mais do que a conta de administrador. Não existe nada em uma única caixa que esta conta não possa fazer e ela tem o direito de acessar a rede como a máquina (isso requer o Active Directory e a concessão de permissões à conta da máquina para algo)

    • Nome: .\LocalSystem(também pode usar LocalSystemou ComputerName\LocalSystem)
    • a conta não possui senha (todas as informações fornecidas são ignoradas)
    • SID : S-1-5-18
    • não possui nenhum perfil próprio ( HKCUrepresenta o usuário padrão )
    • possui amplos privilégios no computador local
    • apresenta as credenciais do computador (por exemplo MANGO$) para servidores remotos

     

Acima, quando se fala em acessar a rede, isso se refere apenas ao SPNEGO (Negociate), NTLM e Kerberos e não a qualquer outro mecanismo de autenticação. Por exemplo, o processamento em execução como LocalServiceainda pode acessar a Internet.

O problema geral da execução como uma conta pronta para uso padrão é que, se você modificar alguma das permissões padrão, estará expandindo o conjunto de itens que tudo o que está sendo executado como essa conta pode fazer. Portanto, se você conceder o DBO a um banco de dados, seu serviço em execução como Serviço Local ou Serviço de Rede não só poderá acessar esse banco de dados, como também todo o restante em execução como essas contas. Se todo desenvolvedor fizer isso, o computador terá uma conta de serviço com permissões para fazer praticamente qualquer coisa (mais especificamente, o superconjunto de todos os diferentes privilégios adicionais concedidos a essa conta).

É sempre preferível, do ponto de vista da segurança, ser executado como sua própria conta de serviço que possui precisamente as permissões necessárias para fazer o que seu serviço faz e nada mais. No entanto, o custo dessa abordagem é configurar sua conta de serviço e gerenciar a senha. É um ato de equilíbrio que cada aplicativo precisa gerenciar.

No seu caso específico, o problema que você provavelmente está vendo é que a ativação do DCOM ou COM + está limitada a um determinado conjunto de contas. No Windows XP SP2, Windows Server 2003 e acima da permissão de Ativação foi significativamente restringida. Você deve usar o snap-in MMC dos Serviços de Componentes para examinar seu objeto COM específico e ver as permissões de ativação. Se você não estiver acessando nada na rede como a conta da máquina, considere seriamente usar o Serviço Local (não o Sistema Local, que é basicamente o sistema operacional).


No Windows Server 2003, você não pode executar uma tarefa agendada como

  • NT_AUTHORITY\LocalService (também conhecida como conta do serviço local) ou
  • NT AUTHORITY\NetworkService (também conhecida como conta do serviço de rede).

Esse recurso foi adicionado apenas ao Agendador de Tarefas 2.0 , que existe apenas no Windows Vista / Windows Server 2008 e versões mais recentes.

Um serviço executando como NetworkServiceapresenta as credenciais da máquina na rede. Isso significa que, se seu computador foi chamado mango, ele apresentaria como a conta da máquina MANGO$ :

insira a descrição da imagem aqui

Peter Oehlert
fonte
7
Eu acho que contas de serviço gerenciado remover um pouco da dor de configurar a conta e gerenciar a senha (ou melhor passá-lo para um administrador de domínio ou delegado.)
Carl G
11
Oi, obrigado pela explicação. Porém, eu tenho uma pergunta - usando a conta local do sistema / serviço de rede, é possível adicionar / remover entradas de contêineres no diretório ativo (desde que o contêiner do diretório ativo tenha concedido permissões totais ao computador no qual esses serviços do Windows estão sendo executados). Observe que tudo está funcionando, quando eu executei o serviço como um dos usuários do domínio, mas não como um sistema local / serviço de rede (para obter mais detalhes stackoverflow.com/questions/20943436/… ) Atenciosamente
Dreamer
11
Sim, deveria. Responderei sua pergunta diretamente, pois é mais abstrata e é uma implementação específica.
Peter Oehlert
7
Observe que o usuário "anônimo" não é apenas um membro de "usuários autenticados", não é um membro de "todos" no Windows. Nas redes Windows, o 'anônimo' só tem acesso aos recursos que foram explicitamente concedidos ao 'anônimo' - por padrão, nada.
David
11
@HakamFostok Não tenho muita referência. Se bem me lembro, Dan Brown abordou algumas delas em seu livro Programming Windows Security. Há muito na ajuda do Windows e nos documentos do MSDN, mas não tenho referência específica. O (s) livro (s) de Jeff Richter sobre programação de janelas, bem como o Inside Windows (3ª ou 4ª Ed) de Soloman & Russinovich também possui alguns.
Peter Oehlert