Ver.9 Standard Edition Windows 版 NTLM 認証説明資料 デジタルアーツ株式会社営業部
Active Directory と連携してシングルサインオンを実現 Active Directory を全社規模で採用しており クライアント PC は Windows 端末で ドメインログオン前提利用の環境に適しています 特徴 ドメインログオンかつ対応 Web ブラウザーを使用の場合 インターネット ID/ パスワード入力不要でシングルサインオンを実現 セキュリティグループ名での一括管理が可能 ドメインコントローラー 信頼関係のある複数ドメイン環境でも運用が可能 パスワードの盗聴は事実上不可能 Active Directory クライアント PC に最も近いプロキシとして設置する必要あり クライアント PC i-filter で NTLM 認証を選択する場合には ドメインコントローラーと Active Directory は必須です ( 通常はこれらは同居ですが便宜上分かりやすくする為に別居の図としています ) 2
1 サービス起動アカウント設定 (Active Directory サーバー作業 ) 2 認証設定 2-1. NTLM 基本設定 3
1.Active Directory 上の任意のアカウントを i-filter のサービス起動用アカウントに割り当てます 2. i-filter のサービス起動アカウントにドメイン管理者権限を割り当てます ( 推奨 ) 例 :Administrator アカウントは新規作成しても既存のアカウントに割り当てても構いません 4
3. i-filter サーバー側で稼働しているサービスの中から i-filter Ver.9 を選択し Active Directory 上の任意のアカウントを i-filter のサービス起動用アカウントに割り当てます 注 : 初期状態ではローカルシステムアカウントが選択されています 5
1. メニュー >> システム設定 >> ユーザー認証 >> 基本設定 をクリックします 2. ユーザー認証方式 から NTLM 認証 を選択して [ 保存 ] します 設定の反映には i-filter の再起動が必要となります 6
グループ作成 ユーザー登録 7
1. メニュー >> グループ設定で [ 追加 ] をクリックし グループを新規作成します 2. グループ名に任意の名前を入力し [ 編集モード ] から [ 認証ユーザー参照 ] を選択します 8
1. ドメイン選択 から利用するドメインを選択します 2. [ ドメインから取得 ] をクリックすると選択した Active Directory からグループが引けます 9
< ユーザー単位で登録する場合 > ユーザーが所属するグループを選択し [ ユーザーの取得 ]-[ 追加 ]-[ 保存 ] ボタンで登録します 10
< セキュリティグループ ( 属性 ) 単位で登録する場合 > 11
認証除外設定 12
i-filter を経由する通信がユーザー認証に対応していないアプリケーションやアドオン通信等の場合 認証除外設定を行う必要があります 認証除外対象の通信は IP アドレスによるグルーピングが行われるため IP アドレスによるグループ登録をしていない場合は << 標準のグループ >> の設定によりフィルタリングが実施されます << 標準のグループ >> が インターネット OFF モード になっている場合には 認証除外した通信がブロックされます この場合は << 標準のグループ >> でも認証除外した通信を [ 共通設定 / 優先フィルタリング設定 ] で許可する必要があります 例えば以下の Windows Update 通信で利用する宛先ホストなどは 認証除外ホストへの設定が必要です ---------------------------------- c.microsoft.com update.microsoft.com download.windowsupdate.com windowsupdate.microsoft.com stats.update.microsoft.com xmlrpc.rhn.redhat.com ---------------------------------- 13
1. メニュー >> システム設定 >> ユーザー認証 >> 除外設定で 基本設定 をクリックすると以下認証除外設定が可能 除外 URL 除外ホスト ( ホスト名 ) 除外ホスト ( ホスト IP) 除外クライアント IP 除外 User-Agent 14
2. メニュー >> システム設定 >> ユーザー認証 >> 除外設定で 高度な設定 をクリックするとルールパーツを複数組み合わせて (AND 判定か OR 条件を指定 ) 認証除外設定が可能 例えばアクセス先識別名 ( ホスト名 ) と User-Agent を AND 条件で認証除外する際に使用します 15
フィルター設定 結果確認 16
ここでは i-filter Ver.9. の 基本モード を利用し URL カテゴリ を規制対象にした設定例を説明します 1. グループを新規作成し 任意のグループ名 ユーザー登録を行います 2. モード から ブラックリストモード を選択します 17
3. URL フィルター から任意のカテゴリにチェックを入れ 保存 します 18
4. ドメインユーザーでドメインにログオンし ブラウザーから規制対象カテゴリサイトにアクセスします ( この時認証画面は表示されず シングルサインオンが行われています ) 正しい認証ユーザー名でブロックされることを確認します ブラウザ起動 19
情報 192.168.xx.oo Webブラウザー起動 IP アドレスと Web 閲覧要求を送信 クライアント PC http://www.daj.jp/ IP アドレス :192.168.xx.oo AD サーバー Web サーバー 407 Proxy Access Denied IP アドレス :192.168.xx.oo に対して プロキシ認証を要求 IP アドレス NTLM 認証情報を入力 http://www.daj.jp/ Proxy Authorization : NTLM xxxxx 407 Proxy Authentication Required チャレンジを生成し 送り返すと同時に NTLM 認証を要求 チャレンジとパスワード情報を元に生成したレスポンスを送信 http://www.daj.jp/ Proxy Authorization : NTLM xxxxx AD サーバーへ問い合わせ ユーザー情報認識 (SMB 通信 ) (SMB 通信 ) IP アドレス + アカウント 閲覧完了 200 OK リクエスト http://www.daj.jp/ 200 OK コンテンツ返送 i-filter の NTLM 認証情報のキャッシュ機能により IP アドレス情報はキャッシュされます これにより赤点線枠内の処理は省略されます 20
多段プロキシ構成での注意点 NTLM 認証はチャレンジレスポンス方式のため 多段プロキシ構成において i-filter で NTLM 認証を行う場合は i-filter は必ずクライアントの要求を直接受け取る最下層に位置していなければなりません アクセス元の IP アドレスを特定できない場合 正確なフィルタリングが不可能 下記のような環境で使用する場合は 別途設定及び構成の変更が必要となります また ネットワーク負荷の増加等についても 環境ごとに慎重に検討が必要となるため 下記のような環境下での NTLM 認証設定は弊社非推奨です i-filter とクライアント PC の間に NAT 装置 他のプロキシなどがあり アクセス元の IP アドレスが i-filter で特定できない環境 Terminal Service や MetaFrame などのシンクライアント環境にて仮想 IP アドレスを使用せず 各ユーザーの使用 Web ブラウザーが親サーバー上で動作している環境 パススルー認証テスト環境などでユーザー名 パスワードが完全に共通のユーザーが存在する場合 本来の権限がないユーザーが認証を通過する場合があります 21
サーバーのドメイン参加と信頼関係 認証に使用するドメインに i-filter がインストールされているサーバーを参加させる ( 複数ドメイン内のアカウント情報を認証に使用する場合 そのいずれかに参加し 全ドメイン間に信頼関係が結ばれている事 ) 必要があります DNS 名前解決 i-filter がインストールされているサーバーで DNS の SRV レコードを参照しドメイン名からドメインコントローラーのホスト名を参照できる必要があります 複数ドメイン間でネットワークセグメントが異なる場合 信頼関係や DNS 名前解決が正常であっても i-filter はユーザー登録のグループ引きの時に 信頼先ドメインコントローラサーバーの名前解決を NetBIOS で行う為 解決手段が無い場合ブロードキャストで名前解決を行おうとします その場合ルーターを超えられない為 結果的に名前解決が出来ずグループ引きが行えないために NTLM 認証に失敗いたします 以下 2 つのいずれかの方法で対応する必要があります [1] i-filter と同一セグメント上に WINS サーバー を立て 相手先ドメインコントローラサーバーの IP アドレスを登録する方法 [2] i-filter サーバー内の LMHOST ファイル に相手先ドメインコントローラーサーバーの IP アドレスを直接記述する方法 22
弊社 FAQ サイト URL:http://www.pa-engine.net/daj/bs/faq/?DispNodeID=0&CID=0 Q A NTLM 認証で 同じ端末からログオンユーザーの切り替えをした際に 前回ログオンしたユーザー設定が残る現象が発生するのはなぜですか? i-filter には Cache Time to Live で設定した時間は認証情報をキャッシュする機能が実装されており NTLM 認証の Cache Time to Live 時間は初期値では 600 秒 (10 分 ) 間に設定されています Web ブラウザーを起動して i-filter に認証されてから 600 秒 認証情報がキャッシュされます このキャッシュ時間内に別アカウントでログオンした可能性があります 恒久対応策としては i-filter 管理 GUI にて [NTLM 認証設定 ] 箇所にある Cache Time to Live 箇所の数値を変更してください i-filter の再起動が必要な作業です Q A 弊社内ヒートランテストの結果 30 秒以下の秒数で設定した場合には認証サーバーが過負荷状態になるリスクを確認しておりますため 30 秒以下の値に設定することは推奨しておりません 一度ドメイン認証が通っているにもかかわらず 再度ドメイン認証を要求される現象が発生する場合があるのはなぜですか? NTLM 認証を経てから i-filter で認証情報がキャッシュされている時間 ( Cache Time to Live で設定している時間 ) 内に認証サーバー側でアカウント名やパスワードを変更した場合 i-filter の認証情報のキャッシュが切れた直後に再度認証を求められる可能性があります Active Directory が パスワード変更後 60 分間 のみ旧パスワードを有効とみなして認証するため 現在有効なパスワード と 現在のパスワードに変更する直前のパスワード の両方で認証可能な時間帯が発生する場合があります この現象は Active Directory の製品仕様ですのでご注意ください 23
弊社 FAQ サイト URL:http://www.pa-engine.net/daj/bs/faq/?DispNodeID=0&CID=0 Q NTLM 認証使用の際 DHCP で IP アドレスを配布している環境で想定される懸念点はありますか A 認証を経てから i-filter で認証情報がキャッシュされている時間 ( Cache Time to Live で設定している時間 ) 内に DHCP の IP アドレスのリース期間が過ぎ 別の IP アドレスが振られてしまった場合 保持している認証情報と IP アドレスが一致しないため 別グループのユーザーと誤認識されるといった意図しない挙動をとる可能性があります NTLM 認証使用時恒久対応策としては i-filter 管理 GUI にて下記メニューから [NTLM 認証 ] 設定箇所を開き Cache Time to Live の数値を変更してください メニュー >> システム設定 >> ユーザー認証 >> 基本設定 i-filter の再起動が必要な作業です 弊社内ヒートランテストの結果 30 秒以下の秒数で設定した場合には認証サーバーが過負荷状態になるリスクを確認しておりますため 30 秒以下の値に設定することは推奨しておりません 24
本書掲載内容の複写 無断転載を禁じます 進化する Web の世界 より安全に より快適にする新スタンダード 本書は 2016 年 3 月現在の情報に基づいて作成しております ( 記載内は予告無く変更される場合があります ) 本書は 弊社次期製品の導入検討のためにのみご利用いただき 他の目的のためには使用しないようご注意ください デジタルアーツ /DIGITAL ARTS ZBRAIN アイフィルター /i- フィルター /i-filter はデジタルアーツ株式会社の登録商標です その他記載されている会社名 製品名は一般に各社の商標または登録商標です デジタルアーツ株式会社 100-0004 東京都千代田区大手町 1-5-1 大手町ファーストスクエアウエストタワー 14F Tel 03-5220-3090 Fax 03-5220-1130 sales-info@daj.co.jp www.daj.jp