none
統合Windows認証を利用しているWEBアプリで、接続方式が変わると認証されない RRS feed

  • 質問

  • WAFFLE というプロダクトを利用して、統合Windows認証を利用したサーバアプリを運用しています

    いままで運用してきたLAN環境、WiFi環境では問題なく運用できていたのですが、新たに導入した、SSLVPN装置にリモート接続し、そのネットワーク環境下でWEBをアクセスすると、認証ができる端末とできない端末が出てきました

    状況としては

    ・常にうまくいく端末

    ・常にだめな端末

    ・時々だめな端末

    という区分があります

    先日常にだめな端末で、F12開発者ツールとWiresharkを利用して、ネットワークキャプチャを行い、動作を確認してみたのですが、クライアント側(IE)が未認証応答(401 Unauthoraized)を受信した後、エラーとして認識しエラーページとなり、統合Windows認証のためのリクエストを再構築して送信するという動作が起きていませんでした

    その際、F12開発者ツールで取得したログで以下の点が気になっています

    <timing><send>109</send><wait>-1</wait><receive>-1</receive><timing>

    これは応答 401 Unauthorizedを受け取ったログレコードのタイミング要素です

    この時刻でのサーバ側のWiresharkログでは、 401 Unauthorized をTCPレベルで正常に送信し、クライアントからのACKも正常に受信しているので、まったく正常に通信できているように見えます

    ※常にうまくいく端末では、この後、認証トークンをヘッダに追加したリクエストがクライアントから送信され、正常に認証が行われた後、正常なページ応答が返ります

    疑問点としては、TCPレベルではページ要求に対して401応答を正常に受信したはずなのに、F12開発者ツールでのキャプチャでは-1ミリ秒となっているので、タイムアウトしているように見えます

    ※実際の動作も、ページ要求後、タブ上のアイコンがくるくる回った数秒後に「このページは表示できません」ページに遷移します

    TCPレベルではページ応答を受信し、ACKも返しているのに、タイムアウトしたような動作になっているという点が、IEの何らかの異常動作であるという風に思えるのですが、この点に関して何らかの情報をお持ちの方はいらっしゃいませんでしょうか?

    補足)

    キャッシュが怪しいかと思って、履歴を削除したり、テンポラリファイルフォルダを掃除したりといった対応や、IEのリセットなども試してみたのですが、改善が見られなかったという状況でもあります

    クライアント環境は Windows7Pro+IE8 ですが、IE9 でも同じ現象が発生していますので、IEのバージョンに依存するという話ではないのかもしれないとも考えています


    2014年10月2日 16:45

すべての返信

  • Kerberos か NTLM 回りを調べてみては。恐らく セキュリティレベルの違いかと思われます。
    2014年10月3日 0:24
  • サーバの応答は常に WWW-Authenticate: NTLM を返しており、クライアント側は、同じネットワーク構成でありながら、それに対して正常に応答するパターンと応答しないパターン(おそらくタイムアウト)が存在しています

    今のところ、同じクライアント構成と同じサーバへのアクセスで、異なるのは、IE側の応答パターンだけという風に見えています

    仮に、セキュリティレベルが異なるのであれば、同じ端末で統合認証したり、しなかったりというのが説明しずらいと思えますが、いかがでしょうか?

    2014年10月3日 5:59
  • NTLMv2 認証で引っかかってるのでなければ、 資格情報に何か登録されているのかもしれません。

    control keymgr.dll を実行して確認してみてください。

    テストツールとして Kerberos Authentication Tester - Michel Barneveld's Blog - Michel Barneveld こういう物を試してみるのも良いかもしれません。

    2014年10月3日 6:43

  • コメントを拝見させていただくと、お詳しい方だというのが分かります。
    舌足らずなところはご容赦いただけますと幸いです。


    流れの確認からしていきたいと思います。
    まず、当該 URL にアクセスした際、匿名でアクセスするので 401 が返されます。
    次に IWA が使用できる状態であれば、NTLM の認証情報を渡しますが、
    これを渡すパケットは出ていないということですよね。
    だとすると何らかの理由で IWA が使える状況ではなかったと考えられます。

    IWA が動作しない条件としては以下の 3 点があげられると思います。
    1) サーバ側が IWA の構成をしていない
     これは LAN では動作することから考えにくいですね。
    2) クライアント側が IWA を使うよりもクレデンシャル マネージャーを優先した
     これは先の方も書かれていますね。
    3) クライアント側が IWA を使えない環境だと判断した
     ここの可能性は確認済みという事でよろしいでしょうか?


    IWA は IE 上で IWA が有効(既定で有効)であることとセキュリティ ゾーンがイントラネットと判定されないと動作しません。
    イントラネットと判断される条件としては URL がホスト名であるか、イントラネット ゾーンと判定されるように手動で FQDN が登録されている必要があると思います。
    (既に確認済みであればご容赦ください。)


    お話は変わりますが WireShark のドライバーで 401 の HTTP Response を受信していると記載されていたと認識しています。
    このドライバーが受け取ってからユーザー モードの Internet Explorer が受信するまでの処理は確認済みでしょうか?

    例えばアンチウィルス ソフトやパーソナル ファイヤーウォール系のドライバーが Drop していることにより、
    Internet Explorer まで通信が届かないという事はないでしょうか。
    (あくまでも仮説にすぎません。)

    私は WireShark よりも Network Monitor でパケット解析するのですが、Windows Firewall で引っかかっていたケースでこのような経験があります。
    事象としては Network monitor でパケットを受信しているにも関わらず、アプリケーションにデータが届かなかったというものです。
    原因はWindows Firewall でブロックの設定が入っておっただけなのですが、順番的に Windows firewall driver よりも先に NetMon driver が動作する為、実際には Drop されていたパケットがあたかも受信されているように見えていました。

    =======
    NIC  <---->  Netmon driver  <-----> Windows firewall driver  <--->  User mode application
    =======

    上述の時はフィルター ドライバーの影響を考えアンチウィルス ソフトのアンインストールを行ったにもかかわらず、解決できませんでした。
    そこで困った私は同時に WireShark でもパケットを採取してみました。
    そうした結果、Network monitor では記録されるものの、WireShark で記録されなかった為、パーソナル ファイヤーウォールを疑い、解決できました。

    =======
    NIC  <---->  Netmon driver  <-----> Windows firewall driver  <---> WireShark driver <--->  User mode application
    =======

    今回は WireShark でパケットが取れているため、Windows firewall ということはないと思うのですが、
    その間の処理にウィルスがいないかを判断する人(プログラム)や情報漏えい対策ソフトの観点でデータの中身を確認したりする人が環境によってはいるかもしれません。

    Internet Explorer の不具合の可能性も否定しませんが、セキュリティ ソフトの不具合の可能性も可能でしたら確認されても良いかと思います。
    (既に確認済みでしたら申し訳ございません。)
    参考になったら幸いです。

    長文で申し訳ございませんでした。

     

    2014年10月16日 14:18
  • 接続出来ている端末と出来ない端末で ネットワークの場所 や SNP の設定が違うのかも確認してみると良いかも。
    2014年10月17日 10:04