La différence entre le compte 'Système local' et le compte 'Service réseau'?

Question

J'ai écrit un service Windows qui lance un processus séparé. Ce processus crée un objet COM. Si le service s'exécute sous le compte 'Système Local', tout fonctionne bien, mais si le service s'exécute sous le compte 'Service Réseau', le processus externe démarre mais échoue à créer l'objet COM. L'erreur retournée lors de la création de l'objet COM n'est pas une erreur COM standard (je pense qu'elle est spécifique à l'objet COM créé).

Alors, comment puis-je déterminer les différences entre les deux comptes, 'Système Local' et 'Service Réseau'? Ces comptes intégrés semblent très mystérieux et personne ne semble en savoir beaucoup sur eux.

Answer 1

Étant donné qu'il y a une telle confusion sur la fonctionnalité des comptes de service standard, je vais essayer de fournir un bref résumé.

D'abord les comptes réels :

• compte LocalService (préféré)

  Un compte de service limité très similaire au Service réseau et destiné à exécuter des services standard privilégiés. Cependant, contrairement au Service réseau, il accède au réseau en tant qu'utilisateur Anonyme.

  • Nom : NT AUTHORITY\LocalService
  • le compte n'a pas de mot de passe (toute information de mot de passe fournie est ignorée)
  • HKCU représente le compte utilisateur LocalService
  • a des privilèges minimaux sur l'ordinateur local
  • présente des références anonyme sur le réseau
  • SID : S-1-5-19
  • a son propre profil sous la clé de registre HKEY_USERS (HKEY_USERS\S-1-5-19)

• compte NetworkService

  Compte de service limité destiné à exécuter des services standard privilégiés. Ce compte est bien plus limité que le Système local (ou même l'Administrateur) mais a tout de même le droit d'accéder au réseau en tant que machine (voir remarque ci-dessus).

  • NT AUTHORITY\NetworkService
  • le compte n'a pas de mot de passe (toute information de mot de passe fournie est ignorée)
  • HKCU représente le compte utilisateur NetworkService
  • a des privilèges minimaux sur l'ordinateur local
  • présente les références de l'ordinateur (par exemple MANGO$) aux serveurs distants
  • SID : S-1-5-20
  • a son propre profil sous la clé de registre HKEY_USERS (HKEY_USERS\S-1-5-20)
  • Si vous essayez de planifier une tâche en l'utilisant, entrez NETWORK SERVICE dans la boîte de dialogue Sélectionner un utilisateur ou un groupe

• compte LocalSystem (dangereux, ne pas utiliser !)

  Compte entièrement de confiance, plus encore que le compte administrateur. Il n'existe rien sur une seule boîte que ce compte ne peut pas faire, et il a le droit d'accéder au réseau en tant que machine (cela nécessite Active Directory et l'octroi de permissions au compte machine).

  • Nom : .\LocalSystem (vous pouvez également utiliser LocalSystem ou NomOrdinateur\LocalSystem)
  • le compte n'a pas de mot de passe (toute information de mot de passe fournie est ignorée)
  • SID : S-1-5-18
  • n'a pas de profil propre (HKCU représente l'utilisateur par défaut)
  • a des privilèges étendus sur l'ordinateur local
  • présente les références de l'ordinateur (par exemple MANGO$) aux serveurs distants

Plus haut, quand on parle d'accès au réseau, cela se réfère uniquement à SPNEGO (Negotiate), NTLM et Kerberos, et non à un autre mécanisme d'authentification. Par exemple, un processus s'exécutant en tant que LocalService peut toujours accéder à Internet.

Le problème général de l'exécution en tant que compte standard prêt à l'emploi est que si vous modifiez l'une des autorisations par défaut, vous élargissez l'ensemble des choses que tout ce qui s'exécute en tant que ce compte peut faire. Donc, si vous accordez des DBO à une base de données, non seulement votre service s'exécutant en tant que Local Service ou Network Service peut accéder à cette base de données, mais tout le reste s'exécutant en tant que ces comptes le peut aussi. Si chaque développeur fait cela, l'ordinateur aura un compte de service ayant des permissions pour faire pratiquement tout (plus spécifiquement le sur-ensemble de tous les différents privilèges supplémentaires accordés à ce compte).

Il est toujours préférable d'un point de vue de la sécurité de s'exécuter en tant que votre propre compte de service ayant précisément les permissions nécessaires pour faire ce que votre service doit faire et rien d'autre. Cependant, le coût de cette approche est de configurer votre compte de service et de gérer le mot de passe. C'est un équilibre que chaque application doit gérer.

Dans votre cas spécifique, le problème que vous voyez probablement est que l'activation de DCOM ou COM+ est limitée à un ensemble donné de comptes. Dans Windows XP SP2, Windows Server 2003, et versions ultérieures, l'autorisation d'activation était considérablement restreinte. Vous devriez utiliser le complément MMC Services de composants pour examiner votre objet COM spécifique et voir les permissions d'activation. Si vous n'accédez à rien sur le réseau en tant que compte machine, vous devriez sérieusement envisager d'utiliser Local Service (pas Local System qui est essentiellement le système d'exploitation).

---

Dans Windows Server 2003, vous ne pouvez pas exécuter une tâche planifiée en tant que

• NT_AUTHORITY\LocalService (alias le compte Local Service), ou
• NT AUTHORITY\NetworkService (alias le compte Network Service).

Cette fonctionnalité a été ajoutée uniquement avec le Planificateur de tâches 2.0, qui existe uniquement dans Windows Vista/Windows Server 2008 et versions ultérieures.

Un service s'exécutant en tant que NetworkService présente les références de la machine sur le réseau. Cela signifie que si votre ordinateur s'appelle mango, il se présenterait en tant que compte machine MANGO$ :