アイデンティティソースとしてのActive Directory

利点

• 設定手順を簡素化し、デバイスにアクセスするためのベストエフォート型セキュリティを提供します。

• 中規模ビジネスから最大中規模の導入に最適です。

• 高可用性(HA)をサポートします。

• キャプティブポータルの設定は、認証しないユーザーに対してオプションです。

アイデンティティソースとしてのActive Directoryはどのように機能しますか?

Windows Management Instrumentation Client (WMIC) とは

Active Directory を ID ソースとして構成すると、デバイスはドメイン コントローラとの Windows Management Instrumentation(WMI)/分散コンポーネント オブジェクト モジュール(DCOM)接続を確立します。デバイスは、WMI クライアント(WMIC)として機能します。デバイスは、ドメインコントローラー上のセキュリティイベントログを読み取り、監視します。デバイスはイベントメッセージを分析して、IPアドレスとユーザーのマッピング情報を生成します。

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

プラットフォームに関連する注意事項については、「 プラットフォーム固有のWMIC動作」 セクションを参照してください。

WMIC がドメイン コントローラー上のイベント ログをどのように読み取るか

WMIC は、次の方法でドメイン コントローラー上のイベント ログを読み取ります。

1. デバイスは、設定可能な間隔(デフォルトは10秒)でイベントログを監視します。

2. デバイスは、設定可能な一定時間にわたってイベントログを読み取ります。デフォルトの時間は1時間です。

3. WMICが起動するたびに、デバイスは最後のタイムスタンプと現在のタイムスパンを確認します。最後のタイムスタンプが現在のタイムスパンよりも古い場合、現在のタイムスパンが有効になります。

4. デバイスはイベントログを読み取り、IPv4アドレスとIPv6アドレスの両方を取得できます。

5. WMIC が起動すると、ファイアウォールはイベント ログから読み取ることができるイベントの最大数を持ちます。イベントの最大数を設定することはできません。

   WMICが起動すると、WMICはタイムスパン設定で最大カウントを使用します。制限に達すると、WMIC はイベント ログの読み取りを停止します。

6. フェイルオーバー後、デバイスは最新のイベントログのタイムスタンプからイベントログを読み取ります。

IPフィルターを指定してIPとユーザーのマッピングを制限する

IPフィルターを指定して、デバイスがイベントログから生成するIPアドレスとユーザーのマッピング情報を制限できます。

このようなマッピングにフィルターが役立つ場合を理解するために、次のシナリオを考えてみましょう。ある顧客が1つのドメインに10台のデバイスを展開し、各デバイスが1つのブランチを制御します。10台のデバイスすべてが、ドメインコントローラー内の10件の支社/拠点ユーザーログインイベントログをすべて読み取ります。ただし、デバイスは、制御する支社/拠点でユーザーが認証されているかどうかのみを検出するように設定されています。デバイスにIPフィルターを設定することで、デバイスはその制御下にあるIPイベントログのみを読み取ります。

フィルターを設定して、IPアドレスやプレフィックスを含めたり除外したりすることができます。各フィルターに最大20個のアドレスを指定できます。

Windowsイベントログの検証と統計

show services user-identification active-directory-access active-directory-authentication-table allコマンドを発行することで、認証テーブルがIPアドレスとユーザー情報を取得していることを確認できます。各ドメインのIPアドレスとユーザーのマッピングのリストが表示されます。LDAPが実行されるまで、テーブルにはグループ情報は含まれません。

show services user-identification active-directory-access ip-user-mapping statistics domainコマンドを発行することで、イベントログの読み取りに関する統計情報を確認できます。

WMICへのバックアップとしてのファイアウォール認証

IDソースとしてのActive DirectoryがIPアドレスとユーザーのマッピング情報を取得するための主な方法は、デバイスがWMIクライアント(WMIC)として機能することです。ただし、イベントログの読み取り機能とPCプローブ機能はどちらもWMIを使用するため、グローバルポリシーを使用してWMI-to-PCプローブを無効にすると、イベントログの読み取りに影響します。これにより、PC プローブが失敗する可能性があり、IP アドレスとユーザーのマッピングを取得するためのバックアップ方法が必要になります。その方法は、ファイアウォール認証を使用してユーザーを識別することです。

ドメインPCプローブを参照してください。

そのステートメントでドメインが設定されている場合、 fwauth はそのドメインがドメイン認証エントリ用であることを認識し、認証リクエストとともにドメイン名を fwauth プロセスに送信します。認証応答を受信した後、 fwauth はそのドメイン認証エントリを削除します。 fwauth プロセスでは、送信元 IP アドレス、ユーザー名、ドメインなどの情報が UserID プロセスに送信され、有効なドメインユーザーエントリーであることが検証されます。後続のトラフィックは、このユーザーファイアウォールエントリーにヒットします。

ドメインPCプロービングとは

ドメインPCプロービングは、イベントログの読み取りを補足する役割を果たします。ユーザーがドメインにログインすると、イベントログにその情報が含まれます。PC プローブは、イベント ログに IP からアドレスへのマッピングがない場合にのみトリガーされます。

ドメイン情報は、ユーザーがドメインPCにログインしたりログアウトするたびに絶えず変化します。IDソースプローブ機能としてのActive Directoryは、IPアドレスとユーザーのマッピング情報をドメインPCに直接プローブすることで、認証テーブル内の情報を追跡および検証するメカニズムを提供します。プローブによって特定された新規および変更された情報は、ファイアウォールの整合性を維持するために不可欠なActive Directory認証テーブルエントリーの更新に役立ちます。

IPアドレスフィルターは、PCプローブにも影響します。IPアドレスフィルターを設定すると、フィルターで指定されたIPアドレスのみがプローブされます。

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

プラットフォームに関連する注意事項については、「 プラットフォーム固有のプローブレート動作 」セクションを参照してください。

ドメインPCプローブユーザー情報

IDソースとしてのActive Directoryは、ドメインPCをプローブすることで、ユーザーのオンラインステータスを追跡します。ユーザーがオンラインでない場合、または予期されたユーザーではない場合、Active Directory認証テーブルが適宜更新されます。以下のプローブ動作が適用されます。

ドメインPCプローブの応答に基づいて、Active Directory認証テーブルが更新され、関連するファイアウォールポリシーが有効になります。90秒経過してもプローブから応答が受信されない場合、認証エントリーがタイムアウトします。タイムアウト認証エントリは、PC プローブの起動時に生成される保留状態の認証エントリです。

プローブが成功すると、認証エントリーの状態が保留から有効に更新されます。プローブが失敗した場合、認証エントリーの状態は無効としてマークされます。無効なエントリは有効なエントリと同じライフタイムを持ち、今後の fwauth(ファイアウォール認証プロセス)の認証結果またはイベント ログによって上書きされます。

ネットワーク設定やWindowsファイアウォールの問題など、何らかの理由でデバイスがドメインPCにアクセスできない場合、プローブは失敗します。

その他のプローブ応答と対応する認証テーブルアクションについては、 表2を参照してください。

プローブの設定方法

オンデマンドプローブはデフォルトで有効になっています。オンデマンドプローブを無効にするには、 set services user-identification active-directory-access no-on-demand-probe ステートメントを使用できます。プローブを再度有効にするには、このステートメントを削除してください。オンデマンドプローブが無効になっている場合、手動プローブを使用できます。

手動プローブを開始するには、 request services user-identification active-directory-access ip-user-probe address ip-address address domain domain-name コマンドを使用できます。ドメイン名が指定されていない場合、プローブはIPアドレスのために最初に設定されたドメインを調べます。範囲を指定するには、適切なネットワークアドレスを使用します。

プローブタイムアウト値は設定可能です。 wmi-timeout 間隔内にドメインPCから応答が受信されない場合、プローブは失敗し、システムが無効な認証エントリーを作成するか、既存の認証エントリーを無効として更新します。プローブされたIPアドレスの認証テーブルエントリーが既に存在し、 wmi-timeout 間隔内にドメインPCから応答が受信されない場合、プローブは失敗し、そのエントリーはテーブルから削除されます。

「 SRXシリーズファイアウォールでアクティブディレクトリをアイデンティティソースとして設定する」を参照してください。

プローブ レートと統計情報

アイデンティティソースとしてのActive Directoryの最大プローブレートはデフォルトで設定されており、変更することはできません。プローブ機能は、5000人のユーザー、またはサポートされる認証エントリーの合計数の最大10%のいずれか小さい方をサポートします。10%をサポートするということは、プローブを待機しているIPアドレスの数がいつでも10%を超えることができないことを意味します。

IDソースとしてのActive DirectoryのLDAPの用途は何ですか?

このセクションでのLDAPの使用は、特にIDソースとしてのActive Directory内のLDAP機能に適用されます。

Active DirectoryをIDソースとして実装するために必要なユーザーとグループ情報を取得するために、デバイスはLightweight Directory Access Protocol(LDAP)を使用します。デバイスは、LDAPサーバーと通信するLDAPクライアントとして機能します。Active Directory を ID ソースとする一般的な実装シナリオでは、ドメインコントローラが LDAP サーバーとして機能します。デバイス内のLDAPモジュールは、デフォルトでドメインコントローラ内のActive Directoryにクエリーを実行します。

デバイスは、LDAPサーバーからユーザーとグループのリストをダウンロードします。デバイスは、ユーザーとグループの更新についてLDAPサーバーに問い合わせます。デバイスは、第一レベルのユーザーとグループのマッピング関係をダウンロードし、ユーザーとグループの完全なマッピングを計算します。

IDソースとしてのActive DirectoryのLDAPはどのように機能しますか?

LDAPサーバーのユーザー名、パスワード、IPアドレス、ポートはすべてオプションですが、設定できます。

• ユーザー名とパスワードが設定されていない場合、システムは設定されたドメインコントローラのユーザー名とパスワードを使用します。

• LDAPサーバーのIPアドレスが設定されていない場合、システムは設定されたActive Directoryドメインコントローラのアドレスを使用します。

• ポートが設定されていない場合、システムはプレーンテキストにポート389を、暗号化テキストにポート636を使用します。

デフォルトでは、LDAP認証方法はシンプル認証を使用します。クライアントのユーザー名とパスワードは、プレーンテキストでLDAPサーバーに送信されます。パスワードは明確であり、ネットワークから読み取ることができることに注意してください。

パスワードの漏洩を回避するために、LDAPサーバーがLDAP over SSL(LDAPS)をサポートしている限り、暗号化されたチャネル[すなわち、SSL(Secure Sockets Layer)]内で簡単な認証を使用できます。SSLを有効にすると、LDAPサーバーからデバイスに送信されるデータが暗号化されます。SSLを有効にするには、 user-group-mapping ステートメントを参照してください。

デバイス識別を使用してネットワークへのアクセスを制御する理由

さまざまな理由から、ユーザーのIDではなく、ユーザーのデバイスのIDに基づいてネットワークリソースへのアクセスを制御することができます。アイデンティティ送信元デバイスとしてのActive Directory ID認証機能は、ユーザーのデバイスの属性に基づいてネットワークアクセスを制御できるようにすることで、これらおよびその他の同様の状況に対するソリューションを提供するために設計されました。

デバイスは、認証ソースに応じて、ユーザーID情報を取得するのと同じ方法で、認証ソースからデバイスID情報を受信または取得します。デバイス識別情報を取得し、デバイス識別情報テーブルに格納するプロセスでは、デバイス側で以下のアクションが発生します。

• デバイスID情報の取得。

  認証ソースに応じて、デバイスは次の2つの方法のいずれかを使用してデバイスID情報を取得します。

  • アイデンティティソースとしてのMicrosoft Active Directory—環境がMicrosoft Active Directoryを使用するように設定されている場合、ファイアウォールはActive DirectoryドメインコントローラとLDAPサービスからデバイスのIPアドレスとグループを取得します。デバイスは、ドメインコントローラーのイベントログからデバイス情報を抽出し、Active Directory LDAPサーバーに接続して、デバイスが属するグループの名前を取得できます。デバイスは、イベントログから取得した情報を使用して、LDAPディレクトリ内のデバイス情報を見つけます。

  • サードパーティ製のネットワークアクセス制御(NAC)システム—ネットワーク環境がNACソリューション用に構成されていて、このアプローチを採用する場合、NACシステムはデバイスID情報をファイアウォールに送信します。これらの認証システムは、Web API と呼ばれる RESTful Web サービス API の POST サービスを使用します。デバイスはAPIを実装し、認証システムに公開して、デバイスID情報をファイアウォールに送信できるようにします。APIには正式なXML構造と制限があり、認証ソースがこの情報をデバイスに送信する際に準拠する必要があります。

    警告:

    このアプローチを採用する場合は、NACソリューションがデバイスで動作することを確認する必要があります。

• デバイスID認証テーブルにデバイスのエントリを作成します。

  • ファイアウォールがデバイスID情報を取得した後、デバイスID認証テーブルにそのエントリーを作成します。デバイス識別認証テーブルは、アクティブディレクトリ認証テーブルや、サードパーティの認証ソースに使用されるその他のローカル認証テーブルとは独立しています。

  • また、認証ソースまたは機能に固有のローカルユーザー認証テーブルとは異なり、デバイスID認証テーブルには、すべての認証ソースのデバイスID情報が保持されます。ただし、Active Directoryなど、一度にアクティブにできる認証ソースは1つだけです。ファイアウォールでは、一度に認証ソースのみを使用することを許可することで、情報を処理するシステムへの要求を制限します。

  • デバイス情報を取得し、デバイスID認証テーブルに入力する目的は、デバイスのIDに基づいてネットワークリソースへのユーザーアクセスを制御することです。これを実現するには、指定されたデバイスIDプロファイルに基づいてデバイスを識別するセキュリティポリシーを設定し、そのデバイスから発生するトラフィックに対して実行するアクションを指定する必要もあります。

  • デバイスID認証機能は、認証ソースに関係なく、デバイスID情報を同じテーブルに格納する汎用認証ソリューションを提供します。

デバイスIDの属性とプロファイル

CLIでは「end-user-profile」と呼ばれているデバイスIDプロファイルは、IDソースデバイスID認証機能としてのActive Directoryの重要なコンポーネントです。デバイスを特定し、その属性を指定します。

デバイスID認証テーブル

デバイスIDとその属性に基づいて認証にデバイスID認証機能を使用するようにデバイスを設定すると、デバイスID認証テーブルと呼ばれる新しいテーブルが作成されます。他のローカル認証テーブルとは異なり、デバイスID認証テーブルにはユーザーに関する情報ではなく、ユーザーのデバイスに関する情報が含まれています。デバイスID認証テーブルは、認証ソースに関係なく、すべてのデバイスのデバイス認証情報のリポジトリとして機能します。例えば、アクティブディレクトリやサードパーティのNAC認証ソースによって認証されたデバイスのエントリーが含まれている場合があります。

デバイスID認証テーブルのエントリーには、以下の部分が含まれます。

• デバイスのIPアドレス。

• デバイスが属するドメインの名前。

• デバイスが関連付けられているグループ。

• デバイスID。

  デバイスIDは、実際にはデバイスIDプロファイル(CLIでは end-user-profileと呼ばれます)のIDです。このタイプのプロファイルには、特定の個々のデバイスまたは特定のデバイスグループ(例えば、特定のタイプのラップトップ)を特徴付ける属性のグループが含まれています。

ユーザーファイアウォールモジュール(UserFW)認証用のIPv6アドレスにより、IPv6トラフィックは送信元IDに設定されたセキュリティポリシーと一致することができます。IPv6アドレスは、以下の認証ソースでサポートされています。

• Active Directory 認証テーブル

• Active Directory認証によるデバイスID

• ローカル認証テーブル

• ファイアウォール認証テーブル

ネットワークアクセス制御用のWindows Active DirectoryからのデバイスID情報

デバイスID認証機能を使用すると、ユーザーIDではなく、使用するデバイスのIDと属性に基づいてネットワークリソースへのアクセスを制御できます。デバイスに関する情報は、デバイスID認証テーブルに保存されます。デバイス属性を含むデバイス識別プロファイルの名前は、セキュリティポリシーのsource-end-user-profileフィールドに指定できます。すべての条件が満たされている場合、セキュリティポリシーのアクションがそのデバイスから発行されるトラフィックに適用されます。

セキュリティポリシーでデバイスIDプロファイルを使用できるようにするには、ファイアウォールが認証済みデバイスのデバイスID情報を取得する必要があります。デバイスによって、デバイスIDエントリの格納に使用するデバイスID認証テーブルが作成されます。デバイスからトラフィックが到着すると、デバイスに一致するテーブルを検索します。このトピックでは、Active Directoryを認証元として使用する場合に従うプロセスについて説明します。

Active Directoryドメインコントローラは、ユーザーがドメインにログインしたときにユーザーを認証し、そのイベントのレコードをWindowsイベントログに書き込みます。また、ユーザーがドメインからログアウトすると、イベントログにレコードが書き込まれます。ドメインコントローラーのイベントログは、ドメインで現在アクティブな認証済みデバイスに関する情報と、それらのデバイスがいつドメインからログアウトされたかをデバイスに提供します。

UserID デーモンは、以下のアクションを実行します。

1. Active Directoryドメインコントローラのイベントログを読み取り、ドメインにログインし、Windowsによって認証されたデバイスのIPアドレスを取得します。

   デバイスルーティングエンジンのUserIDデーモンは、Microsoft Distributed COM/Microsoft RPCスタックを備えたWindows Management Instrumentation(WMI)クライアントと、Active Directoryドメイン内のWindows Active Directoryドメインコントローラと通信するための認証メカニズムを実装します。このプロセスは、Active Directoryコントローラから取得したイベントログ情報を使用して、アクティブなActive DirectoryデバイスのIPアドレスを取得します。このプロセスは、同じ WMI DCOM インターフェイスを使用して Active Directory イベント ログの変更を監視し、ローカル認証テーブル内のデバイス ID 情報を調整して、Active Directory サーバーに加えられた変更を反映します。

2. イベントログから取得したデバイスIPアドレスを使用して、デバイスが属するグループに関する情報を取得します。このグループ情報を取得するために、デバイスはこの目的のためにLDAPプロトコルを使用してActive DirectoryコントローラのLDAPサービスに接続します。

このプロセスの結果として、デバイスはデバイスID認証テーブルにデバイスのエントリーを生成できます。デバイスID認証テーブルにデバイスのエントリを生成すると、デバイスはそのエントリをローカルActive Directory認証テーブル内の適切なユーザーエントリに関連付けます。その後、セキュリティポリシーでデバイスIDプロファイルのエントリを参照して、リソースへのアクセスを制御できます。

動作と制約

• イベント ログを読み取るプロセスでは、ドメイン コントローラーの CPU リソースが消費されるため、ドメイン コントローラーの CPU 使用率が高くなる可能性があります。このため、Active Directory ドメイン コントローラーには、少なくとも 4 コアと 8 ギガバイトのメモリの高パフォーマンス構成が必要です。

• ドメインコントローラーのイベントログには、nullターミネーターを含めて、デバイスIDの最大16バイトが記録されます。そのため、デバイスがドメインコントローラーから取得するデバイスIDの最大長は15バイトです。

• ドメインコントローラーがイベントログをクリアした場合、またはイベントログに書き込まれたデータが欠落しているか遅延している場合、デバイスIDマッピング情報が不正確である可能性があります。ファイアウォールがイベントログを読み取れない場合、またはイベントログにnullデータが含まれている場合、デバイスは自身のログにエラー状態を報告します。

• デバイスID情報テーブルが容量に達すると、新しいデバイスIDエントリを追加することはできません。その場合、デバイスからのトラフィックは破棄されます。

サードパーティNAC認証システム向けのデバイスID XMLソリューション

図2は、ファイアウォールとデバイスID認証に使用されるサードパーティNAC認証ソース間の通信を示しています。ファイアウォールは、NACシステムからデバイスID情報を受け取り、ローカルデバイスID認証テーブルに保存します。デバイスIDプロファイルを指定するセキュリティポリシーは、1つ以上のデバイスに適用できます。デバイスがデバイスIDプロファイルおよびセキュリティポリシーの他の部分と一致する場合、セキュリティポリシーはそのデバイスから発行されるトラフィックに適用されます。

セキュリティポリシーでのデバイスIDプロファイルの使用はオプションです。セキュリティポリシーのsource-end-user-profileフィールドにデバイスIDプロファイルが指定されていない場合、「any」プロファイル が想定されます。ただし、セキュリティポリシーのsource-end-user-profileフィールドにキーワード「any」を使用することはできません。これは予約済みキーワードです。

プラットフォーム固有のWMIC動作

プラットフォーム固有のプローブレート動作