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

利点

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

• 中規模ビジネスから中規模までの展開に最適です。

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

• 認証しないユーザーの場合、キャプティブポータルの設定は任意です。

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

Windows Management Instrumentation Client (WMIC) とは何ですか?

Active Directory をアイデンティティ ソースとして構成すると、デバイスはドメイン コントローラとの Windows Management Instrumentation(WMI)/Distributed Component Object Module(DCOM)接続を確立します。デバイスは WMI クライアント (WMIC) として機能します。デバイスは、ドメイン コントローラー上のセキュリティ イベント ログを読み取って監視します。デバイスはイベントメッセージを解析し、IPアドレスからユーザーへのマッピング情報を生成します。

Feature Explorerを使用して、特定の機能に対するプラットフォームとリリースのサポートを確認します。

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

WMIC はドメイン コントローラーのイベント ログをどのように読み取りますか?

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

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

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

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

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

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

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

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

IP フィルターを指定して、IP からユーザー へのマッピングを制限します

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

このようなマッピングにフィルターが役立つ場合を理解するには、次のシナリオについて考えてみます。ある顧客が1つのドメインに10台のデバイスを導入し、各デバイスが支社/拠点を制御しているとします。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へのバックアップとしてのファイアウォール認証

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

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

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

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

ドメイン PC のプローブは、イベント ログの読み取りを補完する役割を果たします。ユーザーがドメインにログインすると、イベント ログにその情報が記録されます。PC プローブは、イベント ログに IP-to-address マッピングがない場合にのみトリガーされます。

ドメイン情報は、ユーザーがドメイン PC にログインまたはログアウトすると、常に変化します。アイデンティティ ソース プローブとしての Active Directory は、IP アドレスからユーザへのマッピング情報についてドメイン PC を直接プローブすることで、認証テーブル内の情報を追跡および検証するメカニズムを提供します。プローブによって識別された新しい情報と変更された情報は、ファイアウォールの整合性を維持するために重要な Active Directory 認証テーブル エントリを更新する役割を果たします。

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

Feature Explorerを使用して、特定の機能に対するプラットフォームとリリースのサポートを確認します。

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

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

アイデンティティ ソースとしての 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をアイデンティティソースとして設定するを参照してください。

プローブレートと統計

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

アイデンティティ ソースとしての Active Directory の LDAP の用途は何ですか。

この項でのLDAPの使用は、アイデンティティ・ソースとしてのActive Directory内のLDAP機能に特に適用されます。

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

デバイスは、LDAP サーバーからユーザーリストとグループリストをダウンロードします。また、デバイスは LDAP サーバーに対してユーザーおよびグループの更新を照会します。デバイスは、第 1 レベルのユーザーとグループのマッピング関係をダウンロードしてから、完全なユーザーとグループのマッピングを計算します。

アイデンティティ・ソースとしてのActive DirectoryのLDAPの仕組み

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

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

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

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

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

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

デバイス インテリジェンスを使用してネットワークへのアクセスを制御する理由

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

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

• デバイス識別情報の取得

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

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

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

    警告：

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

• デバイス アイデンティティ認証テーブルにデバイスのエントリを作成する。

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

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

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

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

デバイス アイデンティティの属性とプロファイル

CLI では end-user-profile と呼ばれるデバイス アイデンティティ プロファイルは、アイデンティティ ソース デバイス アイデンティティ認証機能としての Active Directory の主要コンポーネントです。デバイスを識別し、その属性を指定します。

デバイス アイデンティティ認証テーブル

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

デバイス アイデンティティ認証テーブル エントリには、次の部分が含まれています。

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

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

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

• デバイス ID。

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

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

• Active Directory 認証テーブル

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

• ローカル認証テーブル

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

ネットワーク アクセス コントロールのための Windows Active Directory からのデバイス ID 情報

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

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

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

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

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

   デバイス ルーティングエンジンの UserID デーモンは、Microsoft 分散 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 サービスに接続します。

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

動作と制約

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

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

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

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

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

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

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

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

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