Windows Server 2012 R2 では、IIS は通常の条件下で Web サーバーとして実行されています。ただし、Web コンテンツは他のフォルダーからのものではなく、c:\inetpub\wwwroot\他のフォルダーからのものです。Web アプリケーションは、defaultAppPool からの独自のユーザーで引き続き実行されています。
IIS_IUSRS実は、 Web コンテンツ フォルダーに読み取り/実行権限を与えるのを忘れていました。ただし、フォルダーにはアクセス権が与えられています。サブフォルダーを書き込み可能にする必要がある場合にのみ、読み取り/実行/書き込み権限usersを追加しました。IIS_IUSRS
セキュリティを少し強化したかったので、Web コンテンツ フォルダーのアクセス権を確認したところ、試行錯誤の結果、現在アクセス権がIIS_IUSRS失われていることが分かりましたusers。グループへのアクセス権がないと、すべてが機能しません。グループへのアクセスを削除するとusers、アプリケーションが動作しなくなるためです。
他のアカウント/グループにアクセス権を付与しようとしたところ、両方に個別にアクセス権を付与するとアプリケーションが実行されることがわかりました。 にアクセス権を付与するだけではusers機能しません。ただし、特定のアプリケーション プール ユーザー (EG ) にアクセス権を付与すると機能します。そして、この最後の部分こそが、あるアプリケーションが他のアプリケーションのファイルにアクセスできないようにしたいので、私が望んでいることです。IIS_IUSRSIIS APPPOOL\IISAPPPOOL\nl-x-homepage
しかし、疑問に思ったことがあります... IIS のようなアカウントは正確にはどのように機能するのでしょうか? アクセス権の付与が、usersWeb コンテンツ フォルダーにアクセスするためにアプリケーション プールにも機能するのはなぜですか? lusrmgr で特定のアプリケーション プール ユーザーを確認できませんが、特定のアプリケーション プール ユーザーはグループ内users、またはグループ内の他のグループ内にあると思われますusers。誰かこれを確認できますか?
この件に関する最後の質問ですが、特定のフォルダを「パスワードで保護」するために、Windows で通常のユーザーを作成し、そのユーザーをグループから削除しusers、IIS マネージャーでそのフォルダに移動して [認証] -> [基本認証] -> [有効] を実行し、認証規則で新しく作成した Windows ユーザー アカウントの許可規則を設定しました。これでうまくいきました。しかし、読み取り/書き込みアクセスを分析すると、アプリケーションはアプリケーション プール ユーザーで実行されているものの、アプリケーション プール ユーザーに必要なのは読み取り権限のみ (書き込み権限は不要) であり、新しく作成した Windows ユーザーにはその上に読み取り権限と書き込み権限の両方がないとフォルダを書き込み可能にできないことに驚きました。なぜこのように動作するのか説明してくれる人はいませんか?
答え1
あなたが遭遇している動作は、私には非常に論理的に思えます。
IIS_IUSRS はアカウントではなくグループであり、その唯一の目的はメンバーをアプリ プール ID として割り当てることを可能にすることです。そのため、これを単独で追加するだけでは不十分です (お分かりのとおり)。
Users グループには、Web サイトが動作するために十分な権限を持つ ASPNET アカウントが含まれているため、これを追加するだけで既定の権限として十分でした。ASPNET アカウントは、DefaultAppPool として使用されているアカウントであると考えています。
ユーザーが作成したファイルまたはフォルダには、作成者が所有者であり、すべての権限を持っているため、常に読み取り権限が与えられます。別のユーザーがファイルまたはフォルダを作成した場合、Windows では、書き込み権限のみを与えて読み取り権限を与えないことは機能しません。これは、書き込み権限や使用可能なスペースなどをチェックしてから書き込みを行う必要があるためです。
答え2
IIS_IUSRS は IIS ワーカー プロセス アカウント グループです。この組み込みグループは必要なすべてのファイルおよびシステム リソースにアクセスできるため、このグループに追加されたアカウントはアプリケーション プール ID としてシームレスに機能できます。
ドメインを右クリックして「権限の編集」を開くと、リストされたグループと権限が表示されます。「セキュリティ」タブの下に、MACHINE_NAME\IIS_IUSRS と /Users が表示されます。IIS は、ディレクトリに対して自動的に読み取り専用権限を持ちます。
作成するすべてのアプリケーション プールについて、新しいアプリケーション プールの Identity プロパティは既定で ApplicationPoolIdentity に設定されます。IIS 管理プロセス (WAS) は、新しいアプリケーション プールの名前で仮想アカウントを作成し、既定でこのアカウントでアプリケーション プールのワーカー プロセスを実行します。新しいアプリケーション プールが作成されるたびに、IIS 管理プロセスは、アプリケーション プール自体の名前を表すセキュリティ識別子 (SID) を作成します。たとえば、"MyFirstPool" という名前のアプリケーション プールを作成すると、Windows セキュリティ システムに "MyFirstPool" という名前のセキュリティ識別子が作成されます。この時点から、この ID を使用してリソースを保護できます。ただし、このIDは実際のユーザーアカウントではないため、Windowsユーザー管理コンソールにユーザーとして表示されません。これは通常の動作です。特定のフォルダーへのアクセスを許可する場合は、アクセス許可を編集してフォルダーに追加するだけです。ただし、デフォルトの認証構成 (匿名 ID) をチェックして適切な選択が利用可能かどうかを確認するか、アクセス エラーを回避するように構成する必要があります。
この郵便受け残りの質問に答えます。継承。
当然、ここで追加する Windows ユーザーには権限が必要です。アカウントは必要なグループから権限を継承する必要があるためです。ここでの読み取り権限は重要です。ただし、これはローカル リソースにアクセスするためのものです。