LocalSystemアカウントへのネットワークアクセスを許可する方法は？

LocalSystem（NT AUTHORITY \ SYSTEM）アカウントにネットワークリソースへのアクセスをどのように許可しますか？

バックグラウンド

ネットワークにアクセスすると、LocalSystemアカウントはネットワーク上のコンピューターとして機能します。

LocalSystemアカウント

LocalSystemアカウントは、サービスコントロールマネージャーが使用する定義済みのローカルアカウントです。

...そしてネットワーク上のコンピューターとして機能します。

または、同じことをもう一度言うと、LocalSystemアカウントはネットワーク上のコンピューターとして機能します。

ドメインメンバーであるコンピューターでLocalSystemアカウントでサービスを実行すると、そのサービスは、コンピューターアカウントまたはコンピューターアカウントがメンバーであるグループに許可されたネットワークアクセスをすべて持ちます。

共有フォルダーとファイルへの「コンピューター」アクセスをどのように許可しますか？

注：

通常、コンピューターアカウントにはほとんど権限がなく、グループに属していません。

それでは、共有の1つへのコンピューターアクセスをどのように許可しますか。「全員」が既にアクセス権を持っていることを考慮して？

注：ワークグループ

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

— イアン・ボイド
ソース

この質問は、共有への匿名アクセスを有効にすることに関する以前の質問に少し関連しています -少なくとも、匿名でアクセス可能な共有で解決できるようです。

— CodeFox

回答:

ドメイン環境では、コンピューターアカウントにアクセス権を付与できます。これは、リモートシステムに接続するときに、LocalSystemまたはNetworkService（ただしLocalService、ネットワーク上で匿名の資格情報を提示する）としてそれらのコンピューターで実行されているプロセスに適用されます。

という名前のコンピューターがある場合、という名前MANGOのActive DirectoryコンピューターアカウントがありMANGO$、アクセス許可を付与できます。

ここに画像の説明を入力してください

注：ワークグループ環境ではこれを行うことはできません。これはドメインにのみ適用されます。

— マッシモ
ソース

+1および承認済み。しかし： LocalServiceとすることができ、ネットワークへのアクセスは、それだけで（「ネットワーク上の匿名の資格情報を提示し、」msdn.microsoft.com/en-us/library/ms684188(VS.85).aspx）

— イアン・ボイド

言うまでもありませんが、これを複数のドメインで機能させるためにかなりの時間を費やしたので、それは可能だとは思いません。すなわち、\\ DOMAIN2 \ MANGO $はアクセスを許可していないようです。

— BennyB

これは、ドメインが信頼関係にある場合にのみ機能します。そうでなければ、あなたは正しい、それは動作しません。

— マッシモ

毎日のグループには、認証されたユーザーだけでなく、local_serviceアカウントとlocal_systemアカウントも含まれると思いましたか？

— kakacii

LocalSystem他のプロセスがアクセスできるものにアクセスできることに注意してください。したがって、ログオンしているユーザーの資格情報を盗むことができます。

— デミ

あなたはしません。リモートファイルまたは他のネットワークサービスに接続するサービスが必要な場合は、サービスを名前付きアカウントとして実行し、リモートマシンでその名前付きアカウントに権限を割り当てます。

あなたが何をしようとしているのかを完全に説明するのが本当に最善でしょう-そのようにして、あなたは最良の答えを得るでしょう。

— ムフィニ
ソース

完全に間違っています。ユーザーアカウントに許可するのとまったく同じ方法で、マシンアカウント（したがって、それらとして実行されるサービス）にアクセス許可を付与できます。もちろん、これが最善のソリューションではないかもしれないシナリオもありますが、完全に実行可能です。

— マッシモ

答えはまさにそのように見えました。これが私のダウン投票の理由です。また、元のポスターはユーザーアカウントとコンピューターアカウントの違いをよく知っているようです。そのため、彼の質問に「それをしないでください」と答えると、私には正しく見えませんでした。

— マッシモ

また、マシンアカウントにアクセス許可を付与する必要がある非常に正当なシナリオがあります。コンピューターのスタートアップスクリプト、またはGPOソフトウェアの展開、またはLocalSystemとして実行するだけのサービスについて考えてみてください。それについては何もできません。もちろん、これがベストプラクティスまたは「正しい」ソリューションであるとは言いません。しかし、誰かが「これをどうやってやるの？」「やってはいけない」というのは間違いなく正しい答えではないと思います。

— マッシモ

ワークグループ環境では、MachineBの権限をMachineAで定義されたユーザーアカウントに割り当てることはできません。さらに、彼は具体的にmaschineアカウントに権限を割り当てる方法を尋ねられました。また、これはドメインなしでは不可能だと言いました。

— マッシモ

Ian-もしそれがあなたが望んでいるのであれば、通常はSQL Serverエージェントとそのアカウントを使用するか、Integration Servicesを使用することをお勧めします。詳細な質問をすることでより詳細な情報を得ることができますが、それでも他の読者の状況に非常に適用できます。

— mfinni

-1

それは単純だ：

マシンのADアカウントをローカルのAdminsグループに入れると、このマシン（またはそのローカルの管理者アカウント）はネットワーク経由で宛先に完全にアクセスできます。今日テストされ、正常に動作します。

— フランク・ウルフ
ソース

これは機能的ですが、推奨またはベストプラクティスではありません。Local Systemアカウントが理由で、ローカルと呼ばれています。何かにネットワークアクセスを許可する場合は、サービスなどを別のユーザーとして実行するように変更する必要があります。これはguest、マシン管理者アクセスのアカウントを許可するようなものです。それは機能しますが、それはそれが何のために構築されたかの目的を無効にします。

— コリー