La différence entre le compte "Système local" et le compte "Service réseau"?
J'ai écrit un service Windows qui génère 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 correctement, mais si le service s'exécute sous le compte "Service réseau", le processus externe démarre mais la création de l'objet COM échoue. L'erreur renvoyée par la création d'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 la différence 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.
Étant donné la confusion qui règne à propos de la fonctionnalité des comptes de service standard, je vais essayer de vous en parler rapidement.
D'abord les comptes réels:
LocalService compte (préféré)
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 (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 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)
- Nom:
Compte de service limité destiné à exécuter des services privilégiés standard. Ce compte est beaucoup plus limité que Local System (ou même administrateur), mais a toujours le droit d'accéder au réseau en tant que machine (voir l'avertissement 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 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 .
( LocalSystem account (dangereux, ne pas utiliser!)
Compte complètement fiable, plus que le compte administrateur. Ce compte ne contient aucune case 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 d'autorisations de compte à la machine).
- Nom:
.\LocalSystem(peut également utiliserLocalSystemouComputerName\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
- ne possède pas de profil propre (
HKCUreprésente l'utilisateur par défaut ) - a des privilèges étendus sur l'ordinateur local
- présente les informations d'identification de l'ordinateur (par exemple
MANGO$) aux serveurs distants
- Nom:
Ci-dessus, lorsque l'on parle d'accéder au réseau, cela fait uniquement référence à SPNEGO (Négocier), NTLM et Kerberos, et à aucun autre mécanisme d'authentification. Par exemple, un traitement exécuté en tant que LocalService peut toujours accéder à Internet.
Le problème général lié à l’exécution en tant que compte prêt à l’emploi standard est que, si vous modifiez l’une des autorisations par défaut, vous développez l’ensemble des tâches exécutées par ce compte. Ainsi, si vous accordez DBO à une base de données, non seulement votre service exécuté en tant que service local ou service réseau peut-il accéder à cette base de données, mais tout le reste fonctionnant sous ces comptes peut également. Si chaque développeur effectue cette opération, l'ordinateur disposera d'un compte de service disposant de l'autorisation de faire pratiquement n'importe quoi (plus précisément le sur-ensemble 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 s’exécuter en tant que votre propre compte de service disposant précisément des autorisations nécessaires pour faire ce que votre service fait 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 acte d’équilibrage que chaque application doit gérer.
Dans votre cas spécifique, le problème que vous constatez probablement est que l'activation DCOM ou COM + est limitée à un ensemble de comptes donné. Dans Windows XP SP2, Windows Server 2003 et versions ultérieures, l'autorisation d'activation était considérablement restreinte. Vous devez utiliser le composant logiciel enfichable Services de composants MMC pour examiner votre objet COM spécifique et voir les autorisations d'activation. Si vous n'accédez à aucun élément du réseau en tant que compte d'ordinateur, vous devriez sérieusement envisager d'utiliser Service local (et non 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 comme
NT_AUTHORITY\LocalService(alias le compte de service local), ouNT AUTHORITY\NetworkService(alias le compte de service réseau).
Cette fonctionnalité n'a été ajoutée qu'avec la tâche Scheduler 2. , qui n'existe que dans Windows Vista/Windows Server 2008 et versions ultérieures.
Un service exécuté en tant que NetworkService présente les informations d'identification de la machine sur le réseau. Cela signifie que si votre ordinateur s'appelait mango, il se présenterait sous le compte de l'ordinateurMANGO$:
