統合 Windows 認証がオンの場合、ASP (クラシック) はどのアカウントで実行されますか?

統合 Windows 認証がオンの場合、ASP (クラシック) はどのアカウントで実行されますか?

同じサーバーの同じ仮想ディレクトリで実行されている ASP.NET Web サービスに Web サービス要求を送信しようとしている ASP ファイルがあります。IIS では、仮想ディレクトリは匿名アクセスを無効にするように設定されており、「統合 Windows 認証」がオンになっています。

問題は、ユーザーのマシンが ASP ページの実行を要求したり、WebService.asmx .NET ファイルを手動で実行したりすると、ユーザーの資格情報が渡されるため動作しますが、ASP ファイルが Web サービスを呼び出そうとすると、401.2 - 権限がありません: サーバー構成によりアクセスが拒否されましたというエラーが発生することです。

例えば:

  • ユーザー マシンのブラウザーから "DIRECTORY\user1" が Service.asmx を要求し、正常に動作します。
  • ユーザー マシンのブラウザーから "DIRECTORY\user1" が File1.asp を要求し、正常に動作します。
  • _________ はサーバー上の File1.asp から Service.asmx を要求し、401.2 を返します。

そのため、ASP アカウントに読み取りと実行のアクセス許可を与えるには、WebService.asmx に NTFS アクセス許可を設定する必要があると考えましたが、どのアカウントで実行されているのかわかりません。また、いくつかの応答を読んでさらに考えてみると、NTFS レベルに到達していないようで、匿名アクセスがオフになっているため、IIS が要求を完全に拒否しているようです。

これは、ASP プロセスをドメイン アカウントで実行する必要があることを示していますか?

答え1

クラシック ASP は、HTTP セッションでサーバーに認証されたユーザーを偽装して実行されます。認証するユーザーにクラシック ASP アプリケーションの実行権限を付与するか、匿名アクセスを許可する必要があります。

「認証済みユーザー」をすでに試しても機能しない場合は、ファイル権限の問題ではないと考えられます。

「...ASP ファイルは Web サービスを呼び出そうとします...」とはどういう意味ですか? ASP スクリプトがサーバーに HTTP 要求を返すということですか? そうであれば、「統合 Windows 認証」では他のサーバー (またはサーバー自体) への認証に使用するプレーンテキスト パスワードがサーバーに提供されないため、ユーザーの資格情報はその要求で渡されません。

編集:

あなたのコメントによれば、上記のように、統合 Windows 認証ではサーバーに他のサーバー (またはこの場合は別のサーバーであるサーバー自体) に渡すプレーンテキストのパスワードが与えられないため、サーバーにはユーザーを認証するための資格情報がなくなります。

試すことができる 3 つのこと:

  • WebService.asmxで匿名アクセスを許可できれば、サーバーからサーバーへのHTTP呼び出しは機能するはずです(IUSR_xxxにファイルの読み取りを許可することで、匿名アクセスを明示的に許可する必要があります)。そしてIIS 管理コンソール スナップインを使用して、ファイル自体の「匿名アクセス」の「匿名アクセスと認証制御」設定を変更します。これにより、そのファイルは、そのファイルが存在するディレクトリから、有効な「統合 Windows 認証」と無効な「匿名アクセス」の設定を継承することになります。

  • HTTP 要求のソースとして使用しているコントロールが、ログインしたユーザーの資格情報をリモート サーバーに透過的に提供することをサポートしている場合は、従来の ASP スクリプトで「基本認証」を有効にすることができます (これにより、サーバーにプレーン テキストのパスワードが提供され、他のサーバーに渡されます)。これにより、HTTP 要求コントロールは、WebService.asmx の要求時にそのプレーン テキストのパスワードを渡すことができます。その時点で、プレーン テキストのパスワードがネットワーク上に送信されないようにするには、従来の ASP スクリプトへのアクセスに SSL を必須にする必要があります。

  • 最後に、従来の ASP スクリプトにいくつかの基本認証資格情報をハードコードし、WebService.asmx ファイルで基本認証を有効にすることもできます。つまり、WebService.asmx は常に同じユーザーからのアクセスを認識することになります。

いずれもあまり良い解決策ではありません。クラシック ASP スクリプトを実行するために認証されたユーザーとしてバックエンド層 (データベースなど) に認証しようとすると、「クラシック ASP」で発生した「クラシック」な問題が発生します。

答え2

統合認証がオンになっていて、ユーザーがWindows統合認証を実行するブラウザを使用している場合そしてユーザーが Web サーバーに対応するアカウントとしてログインしている場合 (たとえば、クライアント マシンが Web サーバーと同じドメインにある場合)、スクリプトはそのユーザーのアカウントとして実行されます。

上記のいずれかが false の場合 (つまり、サーバーがクライアント ブラウザーとユーザー アカウントを一致させることができない)、匿名のユーザーとして設定した内容がIUSR_<machine>デフォルトで使用されます。匿名ブラウジングが無効になっている場合は、ユーザーに 401.* エラーが返されます。

これは、他の認証オプションがオフになっていることを前提としています。Windows 統合認証スキームと基本認証スキームの両方を同時に有効にした場合、何が優先されるかはわかりません。

reqeust.servervariables コレクションを照会し、関連する値 (ユーザー名はそこに含まれています) を出力するスクリプトをドロップすると、Web サーバーが特定の領域へのリクエストに現在使用しているユーザーを確認できます。

答え3

「ダブルホップ」認証を行おうとしているようです。通常、これはバックエンド SQL サービスのコンテキストで発生しますが、同じサーバーで実行されている別のサービスにも適用される可能性があります (100% 確信はありませんが)。MSKB で「ダブルホップ」という用語を検索すると、委任を設定してこれを機能させる方法を説明したドキュメントがいくつか見つかります。まずは、次のドキュメントをご覧ください。http://support.microsoft.com/kb/326985

必要なのは、IIS サーバーを「委任を許可する」に設定することです。ユーザーが Windows 統合認証で認証されると、Kerberos チケットが取得されます (NTLM 認証を取得している場合は、これは機能しません)。

委任を行うには、サーバーに SPN を追加する必要があります。ユーザーが、AD でサーバーが SPN を持っている実際の FQDN を使用して Web ページにアクセスしていることを確認します。サービス プリンシパル名 (SPN) は、ユーザーの Kerberos エージェントが適切な Kerberos チケットを作成するために使用するもので、これにより、IIS サーバーは、次のサービスに要求を渡すときにユーザーを偽装できます。

答え4

Web サービスがログインしたユーザーの資格情報を使用することは重要ですか? MSXML2.ServerXMLHTTPRequest などを使用して Web サービスを呼び出す場合、.Open メソッドで資格情報を提供するだけで、Web サービスに固定の資格情報セットを提供できますか?

関連情報