- - PR -
[IIS6.0+ASP]特定のクライアントでHTTPエラー401.3が発生する
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-10-20 19:09
こんばんは、サトと申します。
現在下記のようなサイトを構成しています [サーバ] WindowsServer2003 SP1 IIS6.0 ASP [クライアント] WindowsXP proSP2 クライアントでサーバのWebサイトにアクセスした場合は 正常に表示することが出来ますが特定のクライアントからアクセスすると 「HTTP エラー 401.3 - 権限がありません : 要求したリソースに設定された ACL によりアクセスが拒否されました。」 というエラーが発生します。 ・エラーが発生するユーザーからエクスプローラーでサーバにアクセス可能 ・統合Windows認証以外の認証の場合、パスワード要求画面が表示しログオン可能 ・IISの設定で匿名アクセスを無効に設定すると401.3エラー発生 また、サイトのルートフォルダのNTFS権限からUsersグループを削除すると401.3エラー発生 ※匿名アクセスを禁止するのはASPでログオンユーザー名を取得したいため 上記のことから統合Windows認証がうまく動作していないように感じます しかし、エラーが出ているクライアントに新しくローカルアカウントを作成し、 そのアカウントでクライアント起動した場合にサイトにアクセスすると パスワード要求画面が表示されてログオン可能となります。 つまり、クライアントにログオンしているユーザアカウントになにか原因があるのでしょうか？ 調べてみましたが有効な記事を見つけることが出来ませんでした。 何卒ご教授願います | ||||||||
|
投稿日時: 2006-10-22 15:46
”匿名アクセスを禁止するのはASPでログオンユーザー名を取得したいため” って ＡＳＰをアクセスするのには匿名アクセスで無い限り普通のアクセス認証を要求されますが。 ＡＳＰが動いて初めてＡＳＰでのログオンユーザー名入力が出来るのでは？ | ||||||||
|
投稿日時: 2006-10-22 18:16
プライベートな環境でファイルやプリンタを共有してる場合、クライアント側でログオンしてるアカウントと同名のアカウントがサーバ側に存在すると同じようにACLではじかれる場合があります。（クライアント側でWindowsが勝手にユーザとパスを送ってはじかれている）
IISで匿名アクセスを禁止した場合も、ファイルへのアクセス権はACLで管理されているので、クライアントとサーバのアカウント名をちょっと調べてみてはどうでしょう。 | ||||||||
|
投稿日時: 2006-10-23 11:41
wojisanさん、がんふぃーるどさん
レスありがとうございます。 言葉足らずな面があったように思いますので 段階を詳しく書いてみようと思います。 １．ＩＩＳでディレクトリセキュリティの認証とアクセス制御 ・匿名アクセスを有効 ・統合Windows認証のみチェック ２．http://hogehoge/test/getuser.aspにアクセス →ログオン名：空白 ※ログオン名取得には Request.ServerVariables("LOGON_USER") を記述 ３．匿名アクセスを無効 または、getuser.aspのNTFS権限からUsersグループを削除 ４．http://hogehoge/test/getuser.aspにアクセス ユーザ名、パスワード要求画面表示され有効なアカウントを入力してログオン →ログオン名：ログオンユーザ名 上記の流れでテストした場合、 特定のクライアントでのみ４の場面でユーザ名、パスワード要求画面が 表示されずにHTTPエラー401.3が発生する状態です。 しかし、エラーが出ているクライアントに新しくローカルアカウントを作成し、 そのアカウントでクライアント起動した場合、 ４の場面でユーザ名、パスワード要求画面が表示されてログオン可能となります。 >wojisanさん >>”匿名アクセスを禁止するのはASPでログオンユーザー名を取得したいため” って >ＡＳＰをアクセスするのには匿名アクセスで無い限り普通のアクセス認証を要求されますが。 >ＡＳＰが動いて初めてＡＳＰでのログオンユーザー名入力が出来るのでは？ ＡＳＰで作ったページでログオンユーザー名を入力させるのではなく アクセス認証でログオンしたユーザ名を取得しています。 >がんふぃーるどさん >プライベートな環境でファイルやプリンタを共有してる場合、 >クライアント側でログオンしてるアカウントと同名のアカウントが >サーバ側に存在すると同じようにACLではじかれる場合があります。 ACLではじかれる場合があるということは、はじかれない場合もあるということでしょうか？ 現在クライアント側のアカウントとサーバ側のアカウントは同じ名前を使用しています。 同じにしていても401.3エラーが発生するクライアントと発生しないクライアントが存在します。 また、クライアントでログオンしているユーザ名、パスワードと同じアカウントが サーバに存在した場合、自動的にログオンできます。 このことから同名のアカウントを使用しても問題ないと思うのですが… 的外れな回答でしたらすみませんです。 引き続き、皆様からのレスをお待ちしております。 [ メッセージ編集済み 編集者: サト 編集日時 2006-10-23 11:42 ] | ||||||||
|
投稿日時: 2006-10-23 12:24
がんふぃーるどです。お世話様です。
この現象はWindowsのNTLM認証（NTチャレンジ-レスポンス）の設定が原因だと思うのですが…
まずは、[インターネットオプション]→[セキュリティ]→[イントラネット]→[レベルのカスタマイズ]から[セキュリティの設定]を開いてください。 この[セキュリティの設定]の一番下にある[ユーザ認証]→[ログオン]の項目を調べてください。 この項目の設定値が「イントラネットゾーンのみ自動的にログオンする」もしくは「現在のユーザ名とパスワードで自動的にログオンする」になっているか確認してください。 自動的にログオンする設定になってる場合、クライアントがサーバのファイルへアクセスしようとすると、まずはクライアントでログオンしているアカウント名とパスワードでサーバへのアクセスを試みます。 アカウント名がサーバにない場合は、認証ダイアログが出るのですが、たまたまクライアント側と同じアカウント名がサーバに存在し、さらにパスワードが不一致ですと（例えばAdministrator）、認証ダイアログを表示せずに、アクセス拒否の通知が来ます。 おそらく、この動作に引っかかっているものと思われます。 対策としては、サトさんがやられたようにサーバ側に存在しないローカルアカウントをクライアント側に作成し、それを使用するか、[ユーザ認証]→[ログオン]の項目の設定値を「ユーザ名とパスワードを入力してログオンする」にすれば良いです。 （サーバ側のセキュリティオプションを変更すれば動作を変更できるかもしれませんが、試したことがありません…） [ メッセージ編集済み 編集者: がんふぃーるど 編集日時 2006-10-23 12:28 ] [ メッセージ編集済み 編集者: がんふぃーるど 編集日時 2006-10-23 12:45 ] | ||||||||
|
投稿日時: 2006-10-23 17:55
がんふぃーるどさん
レスありがとうございます。
今回の現象はお客様の会社で起こっている現象ですのでご指摘の設定を確認していただいてる状態です。 私の会社でも同様の動作環境がありHTTPエラー401.3は発生しておりませんが設定を確認してみました。 設定値は「イントラネットゾーンのみ自動的にログオンする」となっておます。 アカウント名がサーバに存在し、パスワードは不一致ですが、 認証ダイアログが表示されログオン可能です。 認証ダイアログで「パスワードを記録する」にチェックをつけてログオンすると 次回から認証ダイアログは表示されずに自動ログオンできます。 実際に現象が発生している環境での設定確認・動作テストではないのではっきりいえませんが クライアントのアカウント名がサーバに登録されていても問題ないのではないでしょうか？ 認証の設定状態が気になります。 この設定はなにかのソフトによって変更されるものなのでしょうか？
対策案まで書いていただきありがとうございます。 現在サーバに接続する際は一時的にユーザを切り替えて接続してもらっています。 [ユーザ認証][ログオン]の項目の設定値を変更してみるのもいいかもしれませんね。 あと、サーバ側のセキュリティオプションを変更とあるのですが、これはどの設定のことでしょうか？ IISでディレクトリの認証方法を変更するということですか？ | ||||||||
|
投稿日時: 2006-10-24 17:32
自己レスです
HTTPエラー401.3が発生するクライアントで イントラネット上のユーザ認証の設定を確認した結果です。 HTTPエラー401.3が発生するクライアントは４台あり １台だけ「現在のユーザー名とパスワードで自動的にログオンする」、 他３台は「イントラネットゾーンでのみ自動的にログオンする」 となっていました。 試しに「ユーザ名とパスワードを入力してログオンする」に変更してみましたが 現象変わらずHTTPエラー401.3が発生しました。 手詰まりな感がありますが 引き続き、皆様からのレスをお待ちしております。 | ||||||||
|
投稿日時: 2006-10-24 22:39
実際にどんな認証情報を送っているのか(あるいは送っていないのか)確認のため、
パケットキャプチャをしてみたらどうでしょう。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。