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