このアプリケーションは、.NET 4.5、IIS 7.5、およびWindows Server 2008 R2で実行されているASP.NET Webサービスを使用して、UNCフォルダーにファイルを書き込もうとしています。ただし、目的の場所にファイルを保存すると、アクセス拒否の例外が発生します。
タスクは簡単に思えますが、私と私のチームはしばらくの間これをトラブルシューティングしており、エラーの原因については困惑しています。以下に、セットアップの詳細と、これまでに試みて発見したものを示します。無実の人を保護するために名前が変更されました。
Webサーバーmywebserverには、My.Site.Comという名前のWebサイトがあり、My.Siteという名前の対応するアプリケーションプールがあります。 Com。アプリケーションプールは次のように構成されます。
.NET Framework Version : v4.0
Enable 32-bit Applications : False
Managed Pipeline Mode : Integrated
Name : My.Site.Com
Identity : ApplicationPoolIdentity
Load User Profile : False
書き込もうとしているUNCパスは\ myotherserver\mydirectories\outputです。mydirectoriesは実際の共有です。この共有では、mygroup-wwwという名前のドメイングループに、共有とすべてのサブフォルダーへの完全なアクセス許可が付与されています。マシンアカウント(つまり、mywebserver)は、このmygroup-wwwグループのメンバーです。
注:現時点では、このUNCパスは実際には同じマシンmywebserver上にあります。ただし、テスト環境および本番環境では、準備ができたら最終的にmywebserver以外のマシンに移動します。現在、トラブルシューティングするテスト環境は1つだけです。
エラーは、次のコードを実行することで再現できます。
[WebMethod]
[ScriptMethod(UseHttpGet = false, ResponseFormat = ResponseFormat.Json)]
public string ExportReport(int reportId)
{
try
{
string output = ConfigHelper.OutputPath + "test.html"; // UNC path
string url = ConfigHelper.VirtualPath + "test.html";
string[] lines = { "Hello", "World!" };
File.WriteAllLines(output, lines); // Access Denied!
return url;
}
catch (System.Exception ex)
{
Logger.ErrorException("Error exporting report", ex);
throw;
}
}
フォルダーに対するグループ/ユーザーのアクセス許可のさまざまな組み合わせを試してみました(以下を参照)。これらのテストを実行するときに、プロセスモニターも実行しました。構成ごとに同じ結果が見られました。 w3wp.exeプロセスは、目的の場所にファイルを作成しようとしましたが、ACCESS DENIEDの結果を報告しました。各構成のユーザーは、IIS APPPOOL\My.Site.Comでした。
注:また、\ myotherserver\mydirectories\outputから単純なファイルをreadになるようにコードを変更しようとしました。ファイルをreadしようとすると、ファイルの書き込み時に行ったように、プロセスはACCESS DENIEDメッセージで失敗します。
また、機能するいくつかの構成を試しました。
動作する最初の構成は、IIS APPPOOL\My.Site.Comに\ myotherserver\mydirectoriesへのフルパーミッションを付与することでしたが、ファイルは正常に書き込まれましたプロセスのユーザーは、まったく予期せず、別のWebサイトの同じマシン上のWebアプリケーション用に設定されたドメインアカウントでした。これは非常に複雑なままですが、「他の」アカウントには共有への書き込み権限もあるため、機能しました。
ローカルアカウントを使用してネットワークリソースへのアクセスを許可することはできないため、これは運用環境では機能しませんが、それでも興味深いデータポイントです。
2番目に機能した構成は、My.Site.ComアプリケーションプールのIDを、\ myotherserver\mydirectoriesへの完全なアクセス許可を持つドメインアカウントに変更することでした。これは、私たちが手動で作成した「バニラ」ドメインアカウントでした。プロセスのユーザーが何であるかをキャプチャしませんでしたが、それは別の有用なデータポイントかもしれません。
このオプションは可能かもしれませんが、IIS 7.5でベストプラクティスから外れており、かなり厳しいITポリシーのために運用環境で許可されない場合があります。
3番目のテストは、開発マシンでサイトをローカルに実行することでしたmydevmachine。私のローカルIIS構成は、Windows Server 2008ではなくWindows 7を実行していることを除き、mywebserverと同じです。mydomain\mydevmachineを\ myotherserver\mydirectoriesに移動し、アプリケーションを実行しました。ファイルは正常に書き込まれました。ProcessMonitorによると、プロセスのユーザーは正しく設定されています。 IIS APPPOOL\My.Site.Com。
mywebserverのマシンアカウントを使用して設計された書き込みアクセスを有効にします。読みました ApplicationPoolIdentityユーザーはWindows Server 2008の共有フォルダー内のファイルを変更できません および IIS 7ドメイン全体のアプリケーションプールID)の共有フォルダーのアクセス許可 =および アプリケーションプールID 。
この情報によると、マシンアカウントを使用して、UNCパスなどのネットワークリソースへの読み取りおよび書き込みアクセスを許可する必要があります。実際、開発マシンからWebサイトを実行しているときに、希望する方法でこれを行うことができます。
思い浮かぶいくつかの考えがあります。テストWebサーバーのマシンアカウントに何か問題がある可能性があります。あるいは、その「他の」ソフトウェアが何らかの形でプロセスを妨害しているのかもしれません。
この問題の原因について考えていることはありますか?トラブルシューティングのために他に何をすべきですか?
「mywebserver」を再起動します。
今や神秘的に機能するApplicationPoolIdentityに驚嘆してください。
MS HotFix KB254585 をインストールし、このバグに関する詳細を KB2672809 で学習します。これは、この明らかにランダムな問題を再現および実証する手順も示しています。直接ダウンロードリンク こちら 。
修正プログラムが公開されてから3年間、Microsoftがこのための通常のWindows更新プログラムをリリースできなかった理由を推測してください。このあいまいな問題のために、人々はまだ走り続けて髪を抜いています。
MSからこの贈り物を共有し、楽しんでいる他の人々について学びましょう。
サーバーよりも頻繁に再起動するため、Windows 7開発マシンはおそらく正常に動作しました。非常によく書かれた完全なバグレポートおめでとうございます。ここではほとんど見かけません。
ASP.NETアプリケーションでAppPoolIdentityを使用してネットワーク共有にアクセスする際に同様の問題が発生しました(アクセス拒否)。 NetworkServiceアカウントまたは他のドメインアカウントを使用しても機能しましたが、これらは最良のソリューションではありませんでした。私はあなたがしたほとんどすべてのテストを実行しましたが、最終的には機能する何かを見つけました。
あなたがしたように、共有にアクセスするときにネットワークサービスアカウントが使用されなかったことがわかりました(私は予想されるdomain\machine $アカウント)
IIS Webサイトで、[認証]に移動し、匿名認証項目を[アプリケーションプールID]に変更します。デフォルトでは[IUSR]に設定されています。これにより問題が解決しました。
また、ASP.NETの偽装(まだ認証メニューにあります)をアクティブ化すると役立つ場合があります。
ティボー
同じ問題に直面しましたが、環境(QA、STAGE、PRODUCTION)ごとに1つのドメインアカウントを作成することで解決しました。アプリケーションプールIDでは、カスタムアカウントを設定し、それぞれのアカウントにドメインユーザーを使用しました。これで、UNCパスからファイルを読み書きできるようになりました。