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

J'ai écrit un service Windows qui engendre un processus distinct. Ce processus crée un objet COM. Si le service s'exécute sous le compte «Système local», tout fonctionne correctement, mais si le service s'exécute sous le compte «Service réseau», le processus externe démarre mais il ne parvient pas à créer l'objet COM. L'erreur renvoyée par la création de l'objet COM n'est pas une erreur COM standard (je pense qu'elle est spécifique à l'objet COM en cours de création).

Alors, comment puis-je déterminer en quoi les deux comptes, «Système local» et «Service réseau» diffèrent? Ces comptes intégrés semblent très mystérieux et personne ne semble en savoir beaucoup à leur sujet.

Puisqu'il y a tellement de confusion sur la fonctionnalité des comptes de service standard, je vais essayer de donner un aperçu rapide.

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 les services standard les moins 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 (toutes les informations de mot de passe que vous fournissez sont ignorées)
  • HKCU représente le compte d'utilisateur LocalService
  • a des privilèges minimaux sur l'ordinateur local
  • présente des informations d'identification anonymes 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 privilégiés standard. Ce compte est beaucoup plus limité que le système local (ou même l'administrateur) mais a toujours le droit d'accéder au réseau en tant que machine (voir la mise en garde ci-dessus).

  • NT AUTHORITY\NetworkService
  • le compte n'a pas de mot de passe (toutes les informations de mot de passe que vous fournissez sont ignorées)
  • HKCU représente le compte utilisateur NetworkService
  • a des privilèges minimaux sur l'ordinateur local
  • présente les informations d'identification 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 SERVICEdans la boîte de dialogue Sélectionner un utilisateur ou un groupe

   

• Compte LocalSystem (dangereux, ne l'utilisez pas!)

  Compte entièrement fiable, plus encore que le compte administrateur. Il n'y a 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 des autorisations de compte de machine à quelque chose)

  • Nom: .\LocalSystem(peut également utiliser LocalSystemou ComputerName\LocalSystem)
  • le compte n'a pas de mot de passe (toutes les informations de mot de passe que vous fournissez sont ignorées)
  • SID : S-1-5-18
  • n'a pas de profil propre ( HKCUreprésente l' utilisateur par défaut )
  • dispose de privilèges étendus sur l'ordinateur local
  • présente les informations d'identification de l'ordinateur (par exemple MANGO$) aux serveurs distants

   

Ci-dessus, lorsqu'il s'agit d'accéder au réseau, cela se réfère uniquement à SPNEGO (Negotiate), NTLM et Kerberos et non à tout autre mécanisme d'authentification. Par exemple, le traitement en cours d'exécution LocalServicepeut toujours accéder à Internet.

Le problème général avec l'exécution en tant que compte standard est que si vous modifiez l'une des autorisations par défaut, vous développez l'ensemble des choses que tout en cours d'exécution comme ce compte peut faire. Donc, si vous accordez DBO à une base de données, non seulement votre service s'exécutant en tant que service local ou service réseau peut accéder à cette base de données, mais tout le reste exécuté en tant que ces comptes peut également. Si chaque développeur fait cela, l'ordinateur aura un compte de service qui est autorisé à faire pratiquement n'importe quoi (plus précisément le surensemble de tous les différents privilèges supplémentaires accordés à ce compte).

Du point de vue de la sécurité, il est toujours préférable de fonctionner comme votre propre compte de service qui dispose précisément des autorisations dont vous avez besoin pour faire ce que fait votre service et rien d'autre. Cependant, le coût de cette approche est la configuration de votre compte de service et la gestion du mot de passe. C'est un jeu d'équilibre que chaque application doit gérer.

Dans votre cas spécifique, le problème que vous voyez probablement est que l'activation DCOM ou COM + est limitée à un ensemble de comptes donné. Dans Windows XP SP2, Windows Server 2003 et au-dessus, l'autorisation d'activation était considérablement restreinte. Vous devez utiliser le composant logiciel enfichable MMC Services de composants pour examiner votre objet COM spécifique et voir les autorisations d'activation. Si vous n'accédez à rien sur le réseau en tant que compte d' ordinateur, vous devriez sérieusement envisager d'utiliser le service local (pas le système local 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 de service local), ou
• NT AUTHORITY\NetworkService (alias le compte Service réseau).

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

Un service s'exécutant en tant que NetworkServiceprésente les informations d'identification de la machine sur le réseau. Cela signifie que si votre ordinateur était appelé mango, il se présenterait comme le compte d' ordinateur MANGO$: