i-FILTER@Cloud
m-FILTER@Cloud
Deskシリーズ
i-FILTER Ver.9/Ver.10/Reporter
i-FILTER ブラウザー&クラウド
m-FILTER Ver.4/Ver.5
m-FILTER MailAdviser
FinalCode
D-SPA
StartIn
f-FILTER
お知らせ
トラブルシューティングガイド


URLをクリップボードにコピーしました
FAQ_URL：https://www.pa-solution.net/daj/bs/faq/Detail.aspx?id=2736
  最終更新日  2020/12/10 FAQ_ID：2736
Business > i-FILTER Ver.9/Ver.10/Reporter > システム構成
 
「i-FILTER」 シンクライアント(ターミナルサービス)環境に『i-FILTER』を導入する場合に注意点はありますか
対応バージョン： i-FILTER Ver.9 / Ver.10
対応OS： すべてのOS

「i-FILTER」の【NTLM認証】では、認証ユーザー情報をIPアドレスと紐付けて
キャッシュしています。

そのため、下記図において「リクエスト【1】」がどの端末からのアクセスで
あっても「リクエスト【2】」が同一のソースIPアドレスで実施される場合には、
ユーザー情報の識別ができなくなることが想定されます。




■問題発生のシーケンス
----------------------------------------------------------------------
（1） [A]がシンクライアントサーバー経由でアクセス

（2） リクエスト【2】のソースIPアドレスが「192.168.10.200」のため、
　 「i-FILTER」は「192.168.10.200」と[A]を紐付けて 認証キャッシュを保持
　 (キャッシュTTLはデフォルト600秒)

（3） 認証キャッシュTTL時間内に[B]がシンクライアントサーバー経由でアクセス

（4） ソースIPアドレスが「192.168.10.200」のため、認証キャッシュにより
　 [A]からのアクセスとしてグルーピングやログ出力を実施
　 ※キャッシュ保持中は意図しないブロックやアクセスが可能となり、次回アクセスで
　　 異なる結果となる可能性があります。
----------------------------------------------------------------------


■対応方法
上記問題に対する回避方法として以下の3点が挙げられます。

**********************************************************
（1） 仮想IPアドレス機能を使用 　 (推奨)
　 (シンクライアントサーバー側の対応)
**********************************************************
シンクライアントサーバーでリクエスト【2】のソースIPアドレスがクライアント端末ごとに
割り振られるように設定(仮想IPアドレス機能)します。

詳細については以下のMicrosoft社サイトの情報等を参照して下さい。

Windows Server 2019 および Windows Server 2022 のリモート デスクトップ IP 仮想化

※IP仮想化はWindowsServer2008R2より使用することが可能です。

※弊社では、VMware社のVMware HorizonおよびVmware Horizon Air、
    Citrix社のXenDesktop、XenAppで検証しています。

※その他のシンクライアントサーバー製品をご利用の場合は、
    シンクライアントサーバー製品のサポート窓口に問い合わせてください。

▽仮想IPアドレス機能利用のイメージ



**********************************************************
（2） IPアドレスキャッシュを行わない認証方式にする
**********************************************************
LDAP認証や独自認証はブラウザのBASIC認証を利用するため、IPアドレスによる認証キャッシュを
行わないため、本問題は発生しません。

この場合、シングルサインオン環境ではなくなるためブラウザ起動ごとに
ユーザー名パスワードの入力が必須となります。

▽LDAP認証や独自認証を選択
 
  　　　　　　　　
※Ver.10管理画面
「i-FILTER」Ver.10.40R01 以降で「Kerberos認証」が利用可能になりました。


**********************************************************
（3） 認証キャッシュTTLを「0」に設定する
**********************************************************
[システム設定 / ユーザー認証 / 基本設定]にて「Cache Time to Live」を
【0】に設定することで認証キャッシュを保持しない設定にします。
※Ver.10では[システム / ユーザー認証 / 基本設定]です。

認証キャッシュを保持しない場合、リクエストごとにActiveDirectoryへ
認証を行うため、通信トラフィックやドメインコントローラーへの負荷が
増加します。

同設定画面内の「Keep-Alive中は再認証しない」を有効にすることで
ActiveDirectoryへの認証タイミングがリクエストごとからセッションごとに
変更されるため、必ずこちらも有効にしてください。

※Keep-Aliveはひとつのセッション内で複数リクエストを行うための技術です。

▽認証設定を変更
  　　　　　　　　

























※Ver.9管理画面

【注意点】
「Cache Time to Live」=「0」や「Keep-Alive中は再認証しない」は
シンクライアント環境を想定した設定や機能ではありません。

弊社環境にてシンクライアント環境における動作検証は行っていないため、
正常動作を保証するものではありません。

本FAQ記載内容は2016年の動作確認に基づくものとなります。

認証キャッシュを保持しないことで、ActiveDirectoryへのアクセスが
多発する点には変わりはないため、必ず利用環境での動作テストを実施してください。

※ 弊社内ヒートランテストの結果では、“Cache Time to Live”の値を「30」以下に設定した
　 場合に、認証サーバーが過負荷状態になるリスクを確認しているため、30秒以下の
　 設定値は非推奨となります.




 
 
「i-FILTER」 DHCP環境であるため、ユーザー単位でのIPアドレスの固定...
「i-FILTER」『NTLM認証』を利用の環境で、認証サーバ(ドメインコントロ...
「i-FILTER」動作に必要なポート番号を教えてください
「i-FILTER」コンテンツキャッシュの設定を有効にした場合、キャッシュされた...
「i-FILTER」 透過プロキシ環境の構成例、設定方法および制限事項を教えてく...
 

役に立った
役に立たなかった