簡単なシナリオがあります。 ServerA には、組み込みのネットワーク サービス アカウントで実行されるアプリケーションがあります。 ServerB のフォルダー共有でファイルを読み書きする必要があります。 ServerB のフォルダー共有にはどのようなアクセス許可を設定する必要がありますか?
共有のセキュリティ ダイアログを開き、新しいセキュリティ ユーザーを追加し、「オブジェクトの種類」をクリックして「コンピューター」がチェックされていることを確認し、読み取り/書き込みアクセス権を持つ ServerA を追加することで、これを機能させることができます。これを行うと、どのアカウントが共有にアクセスできるようになりますか? ネットワーク サービスのみですか? ServerA のすべてのローカル アカウントですか?すべきServerA のネットワーク サービス アカウントに ServerB の共有へのアクセスを許可するにはどうすればよいですか?
注記：
これは似ていると思いますこの質問ただし、私のシナリオでは、ServerA と ServerB は同じドメインにあります。
答え1
「共有アクセス許可」は「Everyone / フル コントロール」にすることができます。実際に重要なのは NTFS アクセス許可だけです。(ここで、「共有アクセス許可」に異常な執着を持つ人々からの宗教的な議論が始まります...)
ServerB のフォルダの NTFS アクセス許可では、既存のファイルを変更する必要があるかどうかに応じて、「DOMAIN\ServerA - 変更」または「DOMAIN\ServerA - 書き込み」のいずれかで済みます。(アプリケーションは、ファイルを作成した後にそのファイルを再度開いてさらに書き込む可能性があるため、実際には「変更」が推奨されます。「変更」ではその権限が与えられますが、「書き込み」では与えられません。)
権限に「DOMAIN\ServerA」という名前を付けると、ServerA の「SYSTEM」および「Network Service」コンテキストのみがアクセスできます。ServerA コンピューターのローカル ユーザー アカウントは、「DOMAIN\ServerA」コンテキストとは異なります (何らかの方法でアクセスを許可する場合は、個別に名前を付ける必要があります)。
余談ですが、サーバー コンピューターの役割は変わります。この役割のグループを AD に作成し、ServerA をそのグループに入れて、グループ権限を付与するといいでしょう。ServerA の役割を変更して、たとえば ServerC に置き換える場合は、グループ メンバーシップを変更するだけでよく、フォルダーのアクセス許可を再度変更する必要はありません。多くの管理者は、アクセス許可に名前が付けられているユーザーについてこのようなことを考えますが、「コンピューターも人間である」ということを忘れており、役割が変わることもあります。将来の作業 (およびミスを犯す可能性) を最小限に抑えることが、このゲームで効率を上げるためのすべてです...
答え2
コンピューターのネットワーク サービス アカウントは、コンピューター名アカウントとして別の信頼されたコンピューターにマップされます。たとえば、MyDomain の ServerA でネットワーク サービス アカウントとして実行している場合、MyDomain\ServerA$ (はい、ドル記号が必要です) としてマップされます。これは、SSRS または Microsoft CRM のスケール アウト インストールなど、別のサーバー上の SQL Server に接続するネットワーク サービス アカウントとして実行されている IIS アプリがある場合によく見られます。
答え3
私も Evan さんの意見に賛成です。ただし、セキュリティが本当に懸念事項である場合、理想的な解決策は、そのアプリケーション/サービスを実行するためのユーザー アカウントを作成し、そのアカウントに共有フォルダーへの必要なアクセス許可を付与することだと思います。こうすることで、そのアプリケーション/サービスだけが共有にアクセスしていることを確信できます。ただし、これはやりすぎかもしれません。