Compte de service réseau accédant à un partage de dossiers

J'ai un scénario simple. Il existe une application sur ServerA qui s'exécute sous le compte de service réseau intégré. Il doit lire et écrire des fichiers sur un dossier partagé sur ServerB. Quelles autorisations dois-je définir sur le partage de dossiers sur ServerB?

Je peux le faire fonctionner en ouvrant la boîte de dialogue de sécurité du partage, en ajoutant un nouvel utilisateur de sécurité, en cliquant sur "Types d'objet" et en vérifiant que "Ordinateurs" est coché, puis en ajoutant ServerA avec un accès en lecture / écriture. En faisant cela, quels comptes ont accès au partage? Seul service réseau? Tous les comptes locaux sur ServerA? Que dois- je faire pour accorder l'accès au compte de service réseau de ServerA au partage de ServerB?

Remarque:
je sais que cela est similaire à cette question . Cependant, dans mon scénario, ServerA et ServerB sont dans le même domaine.

Les "autorisations de partage" peuvent être "Tout le monde / Contrôle total" - seules les autorisations NTFS importent vraiment. (Cue les arguments religieux des personnes qui ont un attachement malsain à "Partager les autorisations" ici ...)

Dans les autorisations NTFS sur le dossier sur ServerB, vous pouvez vous débrouiller avec "DOMAINE \ ServeurA - Modifier" ou "DOMAINE \ ServeurA - Écrire", selon qu'il faut ou non modifier les fichiers existants. (Modify est vraiment le préféré car votre application peut rouvrir un fichier après l'avoir créé pour écrire plus loin - Modify lui donne ce droit, mais Write ne le fait pas.)

Seuls les contextes "SYSTEM" et "Network Service" sur ServerA auront accès, en supposant que vous nommez "DOMAIN \ ServerA" dans l'autorisation. Les comptes d'utilisateurs locaux sur l'ordinateur ServerA sont différents du contexte "DOMAINE \ ServeurA" (et devraient être nommés individuellement si vous souhaitez leur accorder un accès).

En passant: les rôles des ordinateurs serveurs changent. Vous souhaiterez peut-être créer un groupe dans l'AD pour ce rôle, mettre ServerA dans ce groupe et accorder les droits du groupe. Si jamais vous changez le rôle de ServerA et le remplacez par, disons, ServerC, vous n'avez qu'à modifier les appartenances au groupe et vous n'avez plus besoin de toucher à nouveau l'autorisation de dossier. De nombreux administrateurs pensent à ce genre de chose pour les utilisateurs nommés dans les autorisations, mais ils oublient que "les ordinateurs sont aussi des personnes" et que leurs rôles changent parfois. Minimiser votre travail dans le futur (et votre capacité à faire des erreurs) est ce que signifie être efficace dans ce jeu ...

Le compte de service réseau d'un ordinateur sera mappé sur un autre ordinateur approuvé en tant que compte de nom d'ordinateur. Par exemple, si vous exécutez en tant que compte de service réseau sur ServerA dans MyDomain, cela doit correspondre à MyDomain \ ServerA $ (oui, le signe dollar est nécessaire). Vous voyez cela un peu lorsque vous avez des applications IIS en cours d'exécution en tant que compte de service réseau se connectant à un serveur SQL sur un autre serveur, comme une installation évolutive de SSRS ou Microsoft CRM.

Je suis d'accord avec Evan. Cependant, je pense que la solution idéale, si la sécurité est une préoccupation réelle pour vous, serait de créer un compte d'utilisateur spécifiquement pour cette application / service à exécuter en tant que, et d'accorder à ce compte les autorisations nécessaires sur le dossier partagé. De cette façon, vous pouvez être sûr que seule cette application / ce service accède au partage. Cela peut cependant être exagéré.