「i-FILTER」Ver.9Windows版NTLM認証説明資料

Size: px

Start display at page:

Download "「i-FILTER」Ver.9Windows版NTLM認証説明資料"

ゆりかいりぐら
5 years ago
Views:

1 Ver.9 Standard Edition Windows 版 NTLM 認証説明資料デジタルアーツ株式会社営業部

2 Active Directory と連携してシングルサインオンを実現 Active Directory を全社規模で採用しておりクライアント PC は Windows 端末でドメインログオン前提利用の環境に適しています特徴ドメインログオンかつ対応 Web ブラウザーを使用の場合インターネット ID/ パスワード入力不要でシングルサインオンを実現セキュリティグループ名での一括管理が可能ドメインコントローラー信頼関係のある複数ドメイン環境でも運用が可能パスワードの盗聴は事実上不可能 Active Directory クライアント PC に最も近いプロキシとして設置する必要ありクライアント PC i-filter で NTLM 認証を選択する場合にはドメインコントローラーと Active Directory は必須です ( 通常はこれらは同居ですが便宜上分かりやすくする為に別居の図としています ) 2

3 1 サービス起動アカウント設定 (Active Directory サーバー作業 ) 2 認証設定 2-1. NTLM 基本設定 3

4 1.Active Directory 上の任意のアカウントを i-filter のサービス起動用アカウントに割り当てます 2. i-filter のサービス起動アカウントにドメイン管理者権限を割り当てます ( 推奨 ) 例 :Administrator アカウントは新規作成しても既存のアカウントに割り当てても構いません 4

5 3. i-filter サーバー側で稼働しているサービスの中から i-filter Ver.9 を選択し Active Directory 上の任意のアカウントを i-filter のサービス起動用アカウントに割り当てます注 : 初期状態ではローカルシステムアカウントが選択されています 5

6 1. メニュー >> システム設定 >> ユーザー認証 >> 基本設定をクリックします 2. ユーザー認証方式から NTLM 認証を選択して [ 保存 ] します設定の反映には i-filter の再起動が必要となります 6

7 グループ作成ユーザー登録 7

8 1. メニュー >> グループ設定で [ 追加 ] をクリックしグループを新規作成します 2. グループ名に任意の名前を入力し [ 編集モード ] から [ 認証ユーザー参照 ] を選択します 8

9 1. ドメイン選択から利用するドメインを選択します 2. [ ドメインから取得 ] をクリックすると選択した Active Directory からグループが引けます 9

10 < ユーザー単位で登録する場合 > ユーザーが所属するグループを選択し [ ユーザーの取得 ]-[ 追加 ]-[ 保存 ] ボタンで登録します 10

11 < セキュリティグループ ( 属性 ) 単位で登録する場合 > 11

12 認証除外設定 12

13 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

14 1. メニュー >> システム設定 >> ユーザー認証 >> 除外設定で基本設定をクリックすると以下認証除外設定が可能除外 URL 除外ホスト ( ホスト名 ) 除外ホスト ( ホスト IP) 除外クライアント IP 除外 User-Agent 14

15 2. メニュー >> システム設定 >> ユーザー認証 >> 除外設定で高度な設定をクリックするとルールパーツを複数組み合わせて (AND 判定か OR 条件を指定 ) 認証除外設定が可能例えばアクセス先識別名 ( ホスト名 ) と User-Agent を AND 条件で認証除外する際に使用します 15

16 フィルター設定結果確認 16

17 ここでは i-filter Ver.9. の基本モードを利用し URL カテゴリを規制対象にした設定例を説明します 1. グループを新規作成し任意のグループ名ユーザー登録を行います 2. モードからブラックリストモードを選択します 17

18 3. URL フィルターから任意のカテゴリにチェックを入れ保存します 18

19 4. ドメインユーザーでドメインにログオンしブラウザーから規制対象カテゴリサイトにアクセスします ( この時認証画面は表示されずシングルサインオンが行われています ) 正しい認証ユーザー名でブロックされることを確認しますブラウザ起動 19

20 情報 xx.oo Webブラウザー起動 IP アドレスと Web 閲覧要求を送信クライアント PC IP アドレス : xx.oo AD サーバー Web サーバー 407 Proxy Access Denied IP アドレス : xx.oo に対してプロキシ認証を要求 IP アドレス NTLM 認証情報を入力 Proxy Authorization : NTLM xxxxx 407 Proxy Authentication Required チャレンジを生成し送り返すと同時に NTLM 認証を要求チャレンジとパスワード情報を元に生成したレスポンスを送信 Proxy Authorization : NTLM xxxxx AD サーバーへ問い合わせユーザー情報認識 (SMB 通信 ) (SMB 通信 ) IP アドレス + アカウント閲覧完了 200 OK リクエスト OK コンテンツ返送 i-filter の NTLM 認証情報のキャッシュ機能により IP アドレス情報はキャッシュされますこれにより赤点線枠内の処理は省略されます 20

21 多段プロキシ構成での注意点 NTLM 認証はチャレンジレスポンス方式のため多段プロキシ構成において i-filter で NTLM 認証を行う場合は i-filter は必ずクライアントの要求を直接受け取る最下層に位置していなければなりませんアクセス元の IP アドレスを特定できない場合正確なフィルタリングが不可能下記のような環境で使用する場合は別途設定及び構成の変更が必要となりますまたネットワーク負荷の増加等についても環境ごとに慎重に検討が必要となるため下記のような環境下での NTLM 認証設定は弊社非推奨です i-filter とクライアント PC の間に NAT 装置他のプロキシなどがありアクセス元の IP アドレスが i-filter で特定できない環境 Terminal Service や MetaFrame などのシンクライアント環境にて仮想 IP アドレスを使用せず各ユーザーの使用 Web ブラウザーが親サーバー上で動作している環境パススルー認証テスト環境などでユーザー名パスワードが完全に共通のユーザーが存在する場合本来の権限がないユーザーが認証を通過する場合があります 21

22 サーバーのドメイン参加と信頼関係認証に使用するドメインに i-filter がインストールされているサーバーを参加させる ( 複数ドメイン内のアカウント情報を認証に使用する場合そのいずれかに参加し全ドメイン間に信頼関係が結ばれている事 ) 必要があります DNS 名前解決 i-filter がインストールされているサーバーで DNS の SRV レコードを参照しドメイン名からドメインコントローラーのホスト名を参照できる必要があります複数ドメイン間でネットワークセグメントが異なる場合信頼関係や DNS 名前解決が正常であっても i-filter はユーザー登録のグループ引きの時に信頼先ドメインコントローラサーバーの名前解決を NetBIOS で行う為解決手段が無い場合ブロードキャストで名前解決を行おうとしますその場合ルーターを超えられない為結果的に名前解決が出来ずグループ引きが行えないために NTLM 認証に失敗いたします以下 2 つのいずれかの方法で対応する必要があります [1] i-filter と同一セグメント上に WINS サーバーを立て相手先ドメインコントローラサーバーの IP アドレスを登録する方法 [2] i-filter サーバー内の LMHOST ファイルに相手先ドメインコントローラーサーバーの IP アドレスを直接記述する方法 22

23 弊社 FAQ サイト URL: 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

24 弊社 FAQ サイト URL: 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

25 本書掲載内容の複写無断転載を禁じます進化する Web の世界より安全により快適にする新スタンダード本書は 2016 年 3 月現在の情報に基づいて作成しております ( 記載内は予告無く変更される場合があります ) 本書は弊社次期製品の導入検討のためにのみご利用いただき他の目的のためには使用しないようご注意くださいデジタルアーツ /DIGITAL ARTS ZBRAIN アイフィルター /i- フィルター /i-filter はデジタルアーツ株式会社の登録商標ですその他記載されている会社名製品名は一般に各社の商標または登録商標ですデジタルアーツ株式会社東京都千代田区大手町大手町ファーストスクエアウエストタワー 14F Tel Fax sales-info@daj.co.jp

「i-FILTER」Ver.9Linux版NTLM認証説明資料

「i-FILTER」Ver.9Linux版NTLM認証説明資料 Ver.9 Standard Edition Linux 版 NTLM 認証説明資料デジタルアーツ株式会社営業部 Active Directory と連携してシングルサインオンを実現 Active Directory を全社規模で採用しておりクライアント PC は Windows 端末でドメインログオン前提利用の環境に適しています特徴ドメインログオンかつ対応 Web ブラウザーを使用の場合