Comment accorder un accès réseau au compte LocalSystem?

Comment accordez-vous l'accès aux ressources réseau au compte LocalSystem(NT AUTHORITY \ SYSTEM)?

Contexte

Lors de l'accès au réseau, le compte LocalSystem agit comme l'ordinateur sur le réseau :

Compte LocalSystem

Le compte LocalSystem est un compte local prédéfini utilisé par le gestionnaire de contrôle de service.

... et agit en tant qu'ordinateur sur le réseau.

Ou pour répéter la même chose: le compte LocalSystem agit comme l’ordinateur sur le réseau :

Lorsqu'un service s'exécute sous le compte LocalSystem sur un ordinateur membre du domaine, l'accès au service est autorisé, quel que soit l'accès réseau, au compte d'ordinateur ou aux groupes dont ce compte est membre.

Comment accorder à un " ordinateur " l'accès à un dossier et à des fichiers partagés?

Note :

Les comptes d'ordinateur ont généralement peu de privilèges et n'appartiennent pas à des groupes.

Alors, comment pourrais-je accorder à un ordinateur l'accès à l'une de mes actions? considérant que " Tout le monde " a déjà accès?

Note : groupe de travail

| Account        | Presents credentials |
|----------------|----------------------|
| LocalSystem    | Machine$             |
| LocalService   | Anonymous            |
| NetworkService | Machine$             |

— Ian Boyd
source

Cette question est légèrement liée à la question précédente relative à l’activation de l’accès anonyme à un partage - il semble au moins qu’il puisse être résolu avec un partage accessible anonymement.

— CodeFox

Réponses:

Dans un environnement de domaine, vous pouvez accorder des droits d'accès aux comptes d'ordinateur. cela s'applique aux processus s'exécutant sur ces ordinateurs en tant que LocalSystemou NetworkService(mais pas LocalService, ce qui présente des informations d'identification anonymes sur le réseau) lorsqu'ils se connectent à des systèmes distants.

Ainsi, si vous avez un ordinateur appelé MANGO, vous aurez un compte d’ordinateur Active Directory appelé MANGO$, auquel vous pouvez accorder des autorisations.

entrez la description de l'image ici

Remarque : vous ne pouvez effectuer aucune opération dans un environnement de groupe de travail. cela s'applique uniquement aux domaines.

— Massimo
source

+1 et accepté. Mais: LocalService peut accéder au réseau, il "présente simplement des informations d'identification anonymes sur le réseau" ( msdn.microsoft.com/en-us/library/ms684188(VS.85).aspx )

— Ian Boyd le

Juste pour mentionner, après avoir passé un temps non négligeable à essayer de faire fonctionner cela dans plusieurs domaines, je ne pense pas que ce soit possible. Par exemple, \\ DOMAIN2 \ MANGO $ ne semble pas autoriser l’accès.

— BennyB

Cela ne fonctionne que si les domaines sont dans une relation de confiance; sinon, vous avez raison, cela ne fonctionne pas.

— Massimo

Je pensais que les groupes de tous les jours incluent des utilisateurs authentifiés ainsi que des comptes local_service et local_system?

— Kakacii

Notez que LocalSystempeut également accéder à tout ce que tout autre processus peut. Il peut donc voler les informations d'identification des utilisateurs connectés.

— Demi

Vous pas. Si vous avez besoin d'un service pour vous connecter à des fichiers distants ou à d'autres services réseau, vous souhaitez que le service s'exécute sous un compte nommé et, sur la machine distante, attribuez des droits à ce compte nommé.

Ce serait vraiment mieux si vous expliquez complètement ce que vous essayez de faire - de cette façon, vous obtiendrez les meilleures réponses.

— Mfinni
source

Totalement incorrect. Vous pouvez accorder des autorisations aux comptes d’ordinateur (et donc aux services qui les exécutent) de la même manière que vous pouvez les accorder aux comptes d’utilisateur. Il y a bien sûr des scénarios dans lesquels ce n'est peut-être pas la meilleure solution, mais c'est parfaitement faisable.

— Massimo

La réponse ressemblait exactement à ça, c'est la raison de mon vote négatif; de plus, l'affiche originale semble bien connaître la différence entre un compte d'utilisateur et un compte d'ordinateur. Répondre à sa question par "ne fais pas ça" ne me semblait pas juste.

— Massimo

En outre, il existe des scénarios très légitimes dans lesquels l’octroi d’autorisations aux comptes d’ordinateur est nécessaire. Pensez simplement aux scripts de démarrage de l'ordinateur, au déploiement de logiciels de GPO ou aux services qui veulent simplement être exécutés en tant que LocalSystem et vous ne pouvez rien y faire. Je ne dis pas que c'est une pratique exemplaire ou "la" bonne solution, bien sûr; mais si quelqu'un demande "comment faire cela?" Je pense que "ne le fais pas" n'est certainement pas une bonne réponse.

— Massimo

Dans un environnement de groupe de travail, vous ne pouvez pas attribuer des droits sur MachineB à un compte défini sur MachineA ... D' ailleurs, on lui a demandé précisément comment attribuer des droits à un utilisateur maschine compte, de sorte que ce que je répondais à; et j'ai également dit que cela n'était pas possible sans un domaine.

— Massimo

Ian - si c'est ce que vous recherchez, il est généralement préférable d'utiliser l'agent SQL Server et son compte ou d'utiliser Integration Services. Vous pouvez obtenir plus de détails lorsque vous posez une question détaillée, qui peut toujours être très applicable aux situations des autres lecteurs.

— Mfinni

-1

C'est simple:

Placez le compte AD de la machine dans le groupe d’administrateurs local pour que cette machine (ou son compte administrateur local) puisse accéder pleinement à la destination sur le réseau. Testé aujourd'hui, fonctionne bien.

— Frank Wolf
source

Bien que cela soit fonctionnel, ce n'est PAS recommandé ni la meilleure pratique. Le Local Systemcompte est appelé local pour une raison. Si vous voulez que quelque chose ait un accès réseau, le service ou autre devrait être changé pour être exécuté comme un autre utilisateur. Ce serait comme accorder le guestcompte sur un accès administrateur de la machine. Cela fonctionnerait, mais cela irait à l'encontre du but pour lequel il a été construit.

— Cory Knutson