ローカルシステムアカウントを使用してWindowsサービスによって開始された実行可能ファイルがネットワーク共有にアクセスできない

Question

Windowsサービスによって起動される実行可能ファイルがあります。このプログラムは顧客のマシンで実行され、特定のタスクを実行するにはリモート共有に接続する必要があります。この共有はUIを介して顧客によって指定されるため、事前にこれを知ることはできません。つまり、「ハードコーディング」することも、事前に共有することもできません。

以前は、お客様がマシンにログオンし、ログオン時に実行可能ファイルを実行する必要がありましたが、主に簡単にするために、プログラムをサービス内で実行し、ログインを必要としないことを常に望んでいましたお客様のために、誤ってログアウトしてソフトウェアがシャットダウンされるのを防ぎます。したがって、これは、顧客マシンにどのローカルユーザーアカウントが存在するかわからないことを意味するため、ローカルシステムアカウントを使用してサービスを開始する必要があります。

上記のように、実行可能ファイルを開始してさまざまなタスクを実行するラッパーサービスが用意されました。これはほとんどの場合問題なく動作し、基盤となるネットワークに正常にアクセスします。ソフトウェアの目的は主にパケットのキャプチャなどです。

ただし、ソフトウェアがWindows共有（UNC名）に接続しようとすると、接続できません。一方、実行可能ファイルが手動で起動された場合、正常に接続されます。

この種の問題を解決するために私が一般的に見た提案は、すべてシステムアカウントがネットワーク共有にアクセスできないため、ユーザーアカウントを使用するように見えますが、この場合、これは不可能です。これを機能させる方法は他にありますか？

編集：このアプリケーションはXPではなくWin2Kで実行できることを忘れていましたが、XPの前にローカルネットワークアカウントを利用できないと言うのは正しいと思いますか？

Answer 1

Windowsサービスを変更してNetwork Serviceアカウントで実行できるようにすると、実行可能ファイルはネットワーク共有にアクセスできるようになります（これがNetwork Serviceアカウントが作成された理由の1つです）。

ローカルシステムアカウントとローカルサービスアカウントにはネットワーク資格情報がないため、ネットワークで認証できません。これは仕様です。

編集： IIRC、ネットワークサービスアカウントはServer 2003で導入され、XPサービスパックの1つに追加されました。

利用可能なネットワークサービスアカウントに依存できない場合は、専用ドメインアカウントを作成し、アカウントの資格情報をどこかに保存し、サービス内から読み取り、ネットワークにアクセスする前にそのユーザーにログインして偽装することを検討できますシェア。または、Windowsサービスを専用アカウントとして直接実行することもできます。その場合、「サービスとしてログオン」が必要になります。特権。

Answer 2

NT AUTHORITY \ LOCALSYSTEM（サービスアカウントの名前）の下で実行されるサービスがある場合、ネットワークの残りの部分にはDOMAINNAME \ COMPUTERNAME $（$記号に注意）アカウントとして表示されます。つまり、Active Directoryでコンピューターのアカウントとして表示されます。 DOMAINNAME \ COMPUTERNAME $にファイルと共有のアクセス許可を付与するだけで、うまくいくはずです。

Answer 3

別のアカウントを使用できないのはなぜですか？特にネットワークアクセスが必要なサービスのために、Windowsにネットワークサービスアカウントが組み込まれています。

とにかく、サービスでexeを起動するときは非常に注意してください。

exeを含むフォルダーへの書き込みアクセスが無効になっていない場合、ユーザーはそのexeを（たとえば） cmd.exe に置き換えることができます。次回サービスがexeを起動しようとすると、voil＆＃224 ;:システム権限を持つコマンドシェル！