IIS 8.5、権限、監査に関して特定の問題が発生しています。KanboardPool ID で PHP アプリケーションを実行しており、アプリケーションの「データ」フォルダーの権限を「IIS APPPOOL\KanboardPool」にフル コントロールとして適切に設定しています。
さらに、親を含む同じフォルダーで IIS_IUSRS を読み取り、実行、および一覧表示するように設定しました。それにもかかわらず、アクセス許可が拒否されるエラーが引き続き発生します。
ファイル アクセスの失敗を監査しようとしましたが、あまりうまくいきませんでした。まず、GPO ドメイン ポリシー -> コンピューターの構成 -> Windows の設定 -> セキュリティの設定 -> 高度な監査 -> ファイル アクセスの成功と失敗の監査を実行しました。監査の失敗は記録されませんでした。同じ手順をドメイン コントローラー ポリシーで実行し、最後に何らかの理由でローカル ポリシーを実行しました。監査ポリシーの変更が追加され、その後、順番に削除されます。
ACL を通じて、選択したプリンシパル 'IIS APPPOOL\KanboardPool' に対して有効なアクセス テストを実行し、見事に合格しました。今、私は困惑しています。
答え1
この問題の診断が特に困難だったのは、これが再現できなかったことです。デフォルトの Web サイト同じアプリケーションをIDC:\inetpub\wwwroot\subfoldeer\phpapplicationの下に配置したとき。DefaultAppPool
私にとっては、単にフルコントロールにC:\inetpub\wwwroot\subfolder\phpapplication\data、DefaultAppPoolそしてそれは単純に機能しました。
読んだあとhttp://www.iis.net/learn/get-started/planning-for-security/secure-content-in-iis-through-file-system-aclsfcgi.impersonate;をオンにするとphp.ini、認証されたユーザーになりすますようになります。 Viola、この機能をオフにすると、PHP プロセスは AppPoolIdentity を想定し、期待どおりに動作します。
これは、KanboardPoolのファイルアクセスエラーが発生しなかった理由を説明しています。ただし、fcgi.impersonateそれがオンになっている間は説明されていません。デフォルトの Web サイト最初は同じ動作を再現していませんでした。