☰

IUSRを選択してサービスを実行することはできません

tag-icon • tag-icon windows-server-2008-r2 iis-7.5 windows-service iusr
IUSRを選択してサービスを実行することはできません

IIS 7.5 を実行している Windows 2008 R2 ボックスがあり、セキュリティ要件により、World Wide Web Publishing Service を IUSR で実行するように設定する必要があります。IUSR フォルダーのアクセス許可を問題なく付与できます。しかし、World Wide Web Publishing Service を実行するアカウントとして IUSR を選択しようとすると、ユーザーが見つからないというメッセージが表示されます。現在、サービスは「ローカル システム アカウント」で実行されています。ご助力いただければ幸いです。

答え1

IUSR は、匿名の訪問者が Web サイトを閲覧するときに使用されるセキュリティ コンテキストです。WWW サービスには使用しないことをお勧めします。

IIS7.5 より前では、ローカル IUSR アカウントに加えて、ローカル アカウントであるサービス アカウント (IWAM) が作成されていました。新しいモデルでは、異なるアプリケーション プール ID を使用して実行されるため、サイトが侵害されても、1 つの Web サイトがボックス上の別の Web サイトに影響を与えることはありません。資格情報をその特定のボックスに限定するために、WWW サービス用の権限のないローカル アカウントを検討するでしょう。

WWW と Windows プロセス アクティブ化サービスにローカル ユーザーを使用してテストしたところ、Windows プロセス アクティブ化サービスに対して「このアカウントには十分な権限がありません」というエラー メッセージが繰り返し表示されました。そこで、ローカル アカウントを IIS_IUSRS とその他の IIS 関連グループに追加し、ローカル セキュリティ ポリシーに移動して、ローカル セキュリティ ポリシーのユーザー権利の割り当てに権限を追加しました。

  • プロセスレベルトークンを置き換える
  • プロセスのメモリクォータを調整する
  • セキュリティ監査を生成する
  • バッチジョブとしてログオンする

それは機能しなかったので、Google で役立つかもしれないという情報を見つけて、「グローバル オブジェクトの作成」を追加しました。効果はありませんでした。しかし、家に帰る時間になったので、すべてを元に戻しました (テスト環境であったにもかかわらず)。

私はその後

  • 認証後にクライアントになりすます

残念です。サービスはローカルシステムとして実行され、私が作業していたリンク言う、

ローカル システム アカウントは、コンピューターへのフル アクセスを持ち、ネットワーク上のコンピューターとして機能する強力なアカウントです。サービスがローカル システム アカウントを使用してドメイン コントローラーにログオンする場合、そのサービスはドメイン全体にアクセスできます。一部のサービスは、デフォルトでローカル システム アカウントを使用するように構成されており、これを変更しないでください。ローカル システム アカウントには、ユーザーがアクセスできるパスワードはありません。

申し訳ありませんが、試してみましたが、残念ながらダメでした。アカ​​ウントにリストされている権限を付与してみるのもよいでしょう。ここ:

  • SE_ASSIGNPRIMARYTOKEN_NAME (無効)
  • SE_AUDIT_NAME (有効)
  • SE_BACKUP_NAME (無効)
  • SE_CHANGE_NOTIFY_NAME (有効)
  • SE_CREATE_GLOBAL_NAME (有効)
  • SE_CREATE_PAGEFILE_NAME (有効)
  • SE_CREATE_PERMANENT_NAME (有効)
  • SE_CREATE_TOKEN_NAME (無効)
  • SE_DEBUG_NAME (有効)
  • SE_IMPERSONATE_NAME (有効)
  • SE_INC_BASE_PRIORITY_NAME (有効)
  • SE_INCREASE_QUOTA_NAME (無効)
  • SE_LOAD_DRIVER_NAME (無効)
  • SE_LOCK_MEMORY_NAME (有効)
  • SE_MANAGE_VOLUME_NAME (無効)
  • SE_PROF_SINGLE_PROCESS_NAME (有効)
  • SE_RESTORE_NAME (無効)
  • SE_SECURITY_NAME (無効)
  • SE_SHUTDOWN_NAME (無効)
  • SE_SYSTEM_ENVIRONMENT_NAME (無効)
  • SE_SYSTEMTIME_NAME (無効)
  • SE_TAKE_OWNERSHIP_NAME (無効)
  • SE_TCB_NAME (有効)
  • SE_UNDOCK_NAME (無効)

しかし、Microsoft から、そうしないようにという文書を受け取る方が簡単かもしれません。

答え2

私もそれを実行する方法を検討しています。OP も私と同じ要件を持っているのではないかと思います。それは国防総省の JITC 要件です。これがそれです:

Check Content: 
1. Go to Start, Administrative Tools, then Services.
2. Right click on service name World Wide Web Publishing Service, Select Properties, then select the Log On tab.
3. The username next to this account is the web service account ID.  If any other user than IUSR is listed, continue to step 4.  If the service account IUSR is used to run the service, this is not a finding.
4. Open a command prompt and enter Net User [service account ID], press Enter.
5. Verify the values for Password last set and Password expires to ensure the password has been changed in the past year, and will be required to change within the coming year.

Fix Text: 
Configure the service account ID, used to run the web-site, to have its password changed at least annually or use the service account IUSR.

答え3

非常に多くのここには間違いのレベルがあります。本当に短いバージョン:そんなことしないで！

セキュリティ要件を誤解しているか、IIS の設計を考慮せずに記述されているのではないかと強く疑っています。

WAS はローカル システムとして実行する必要があります。完全に停止します。リモートからアクセスできないため、攻撃対象領域は非常に限られています (つまり、ローカル コンピューターの管理者)。

ローカル システムとして実行される理由の 1 つは、applicationhost.config を各アプリケーション プールごとに個別の部分に分割し、Inetpub\Temp\AppPools に独自の分離されたコピーを取得するためです。

もう 1 つは、Web 管理者によって構成された特定の ID を使用してアプリケーション プール ワーカー プロセス (W3WP) を起動することです。つまり、アプリケーション プールに ApplicationPoolIdentity という基本 ID がある場合、それは他のユーザーになりすましていないときに基本プロセス ID として使用される、権限の低い一意のアカウントです。

さらに、WAS の ID の変更はサポートされておらず、ローカル システムとして実行されるように設計されているという点も挙げられます。これは特権プロセスです。

WWW サービスは InetInfo であり、昔はページ処理をサポートしていましたが (最近では Windows 2000 の時代)、現在はサポートされていません。この WWW サービスは、この推奨事項の対象になる可能性があります。

ただし、これはページ処理には関与しなくなり (IIS 6 以降)、W3WP による将来の使用のために HTTP.SYS を構成するだけになります。

したがって、アプリケーション プール (具体的には、関連付けられたワーカー プロセス) が実際の作業を実行し、アプリケーション プール タブで基本 ID を構成し、認証 -> 匿名設定で匿名作業に使用する特定のアカウントを構成できます。

実際のテキストを見たり、そのソースを理解したりしない限り、どこかに不正な形式があるように思えます。あるいは、標準の Win32 サービスについては多少知っているが、IIS についてはあまり知らない人によって書かれたようにも思えます。

IIS サイトを保護および分離し、ガイダンスの意図 (記載されている内容ではない場合) を実現するには、次の手順を実行するだけです。

  • アプリケーション プール ID を匿名アカウントとして使用します (ポリシーで必要な場合は IUSR を使用しますが、セキュリティが低下します (サイトごとに固有のアカウントではなく、共通の共有アカウントであるため))。
  • コンテンツに対する権限を設定し、IIS AppPool\AppPoolName のみがコンテンツ フォルダーに対する読み取り権限を持つようにします。

これで完了です。

関連情報