Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Active Directoryをアイデンティティソースとして設定する

SRXシリーズファイアウォールで、Active Directoryをアイデンティティソースとして設定する方法をご覧ください。

例:SRXシリーズファイアウォールでアイデンティティソースとしてActive Directoryを設定する

この例では、Windows Active Directoryドメイン、LDAPベース、キャプティブポータルに誘導される認証されていないユーザー、およびソースIDに基づくセキュリティポリシーを設定して、統合ユーザー ファイアウォール機能を実装する方法を示します。この例のキャプティブポータルの設定はすべて、トランスポート層セキュリティ(TLS)上で行われます。

必要条件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • 1台のSRXシリーズファイアウォール

  • Junos OS リリース 12.1X47-D10 以降(SRXシリーズ ファイアウォール向け)

この機能を設定する前に、デバイス初期化以外の特別な設定を行う必要はありません。

証明書を登録する方法については、「 証明書の登録」を参照してください。

概要

統合型ユーザー ファイアウォール機能の一般的なシナリオでは、ドメイン ユーザーと非ドメイン ユーザーは、SRXシリーズ ファイアウォールを介してインターネットにアクセスしたいと考えています。SRXシリーズファイアウォールは、ドメインに設定されているドメインコントローラーのイベントログを読み取り、分析します。そのため、SRXシリーズファイアウォールは、Active Directoryドメインコントローラー上のドメインユーザーを検出します。Active Directoryドメインは、統合ユーザー ファイアウォールのActive Directory認証ソースとして認証テーブルを生成します。SRXシリーズファイアウォールは、この情報を使用してポリシーを適用し、ユーザーベースまたはグループベースのアクセス制御を実現します。

非ドメインユーザーまたは非ドメインデバイス上のドメインユーザーの場合、ネットワーク管理者は、キャプティブポータルを指定して、ユーザーにファイアウォール認証への服従を強制できます(SRXシリーズファイアウォールが トラフィックタイプのキャプティブポータルをサポートしている場合)。たとえば、HTTP など)。ユーザーが名前とパスワードを入力してファイアウォール認証に合格すると、SRXシリーズファイアウォールはLDAP サーバーからファイアウォール認証ユーザーツーグループマッピング情報を取得し、それに応じてユーザー ファイアウォール ポリシーによる制御をユーザーに適用できます。

Junos OS リリース 17.4R1 以降では、IPv4 アドレスに加えて、IPv6 アドレスを Active Directory ドメイン コントローラーに使用できます。このサポートを説明するために、この例では、ドメイン コントローラーのアドレスとして 2001:db8:0:1:2a0:a502:0:1da を使用します。

プライマリ グループは、既定の名前である [Domain Users] でも、その他の名前 (変更した場合) でも、統合ユーザー ファイアウォール構成では使用できません。

Active Directory(AD)で新しいユーザーが作成されると、そのユーザーはグローバルセキュリティグループプライマリグループ(デフォルトではドメインユーザー)に追加されます。プライマリグループは、すべてのユーザーが所属しているため、ADで作成された他のグループよりも具体性が低くなります。また、非常に大きくなる可能性があります。

構成

プロシージャ

CLIクイック構成

この例を素早く設定するには、以下のコマンドをテキストファイルにコピーし、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストし、設定モードから commit を入力してください。

手順

次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、CLIユーザー ガイド設定モードにおけるCLIエディターの使用を参照してください。

Windows Active Directory ドメインの確立、キャプティブポータルの設定、および別のセキュリティ ポリシーの設定を行うには、このセクションの手順を実行します。

設定後、トラフィックが到着すると、SRXシリーズファイアウォールはユーザー ファイアウォールプロセスに問い合わせます。このプロセスはアクティブディレクトリ認証ソースに問い合わせて、そのソースが認証テーブルにあるかどうかを判断します。ユーザー ファイアウォールが認証エントリーにヒットすると、SRXシリーズ ファイアウォールはステップ 4 で設定されたポリシーを確認して、さらなるアクションを求めます。ユーザー ファイアウォールが認証エントリーにヒットしない場合、SRXシリーズ ファイアウォールはステップ 3 で設定されたポリシーをチェックして、ユーザーにキャプティブポータルの実行を強制します。

  1. LDAPベースの識別名を設定します。

  2. ドメイン名、ドメインのユーザ名とパスワード、およびドメイン内のドメインコントローラの名前とIPアドレスを設定します。

  3. アクセスプロファイルを設定し、認証順序とLDAPオプションを設定します。

    no-tls-certificate-check オプションが設定されている場合、SRXシリーズ ファイアウォールはサーバーの証明書の検証を無視し、確認せずに証明書を受け入れます。

  4. source-identity「unauthenticated-user」および「unknown-user」のポリシーを設定し、ファイアウォール認証キャプティブポータルを有効にします。認証ソースが設定されていない場合、ソースIDの設定は不要で、切断されます。

  5. 特定のユーザーを有効にするために 2 つ目のポリシーを設定します。

    policies ステートメントで送信元 ID を指定する場合は、ドメイン名を先頭に追加し、グループ名またはユーザー名にバックスラッシュを付けます。組み合わせを引用符で囲みます。

  6. 統合型ユーザー ファイアウォール情報取得の認証元に Active Directory 認証テーブルを設定し、ユーザー情報テーブルを確認する順序を指定します。

    統合ユーザー ファイアウォール情報取得の認証ソースとしてActive Directory認証テーブルを設定し、コマンド set security user-identification authentication-source active-directory-authentication-table priority valueを使用してユーザー情報テーブルをチェックする順序を指定する必要があります。

    このオプションのデフォルト値は 125 です。すべての認証ソースのデフォルトの優先度は次のとおりです。

    • ローカル認証:100

    • 統合型ユーザー ファイアウォール:125

    • ユーザー ロール ファイアウォール:150

    • ユニファイドアクセスコントロール(UAC):200

    priorityフィールドは、Active Directory 認証テーブルのソースを指定します。値セットによって、サポートされているさまざまな認証テーブルを検索してユーザーロールを取得する順序が決まります。これらは現在サポートされている唯一の値であることに注意してください。0 から 65,535 までの任意の値を入力できます。Active Directory 認証テーブルのデフォルトの優先度は 125 です。つまり、優先度の値を指定しない場合でも、Active Directory 認証テーブルは値 125 (統合ユーザー ファイアウォール) のシーケンスから検索されます。

    各認証テーブルには、一意の優先度値が割り当てられます。値が小さいほど、優先度が高くなります。例えば、優先順位 120 の表は、優先順位 200 の表の前に検索されます。テーブルの優先度値を 0 に設定すると、テーブルが無効になり、検索シーケンスから優先度値が除外されます。

    詳細については、「 Active Directory 認証テーブルについて 」を参照してください。

業績

設定モードから、 show services user-identification active-directory-access コマンドを入力して、統合された ユーザー ファイアウォール の設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show security policies コマンドを入力してポリシーの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show access profile profile1 コマンドを入力して、アクセス プロファイルの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定モードから commit を入力します。

検証

設定が正常に機能していることを確認します。

ドメイン コントローラーへの接続の確認

目的

少なくとも 1 つのドメイン コントローラーが構成され、接続されていることを確認します。

アクション

動作モードから、 show services user-identification active-directory-access domain-controller status コマンドを入力します。

意味

ドメイン コントローラーが接続または切断されていることが表示されます。

LDAP サーバーの検証

目的

LDAP サーバーがユーザーとグループのマッピング情報を提供していることを確認します。

アクション

動作モードから、 show services user-identification active-directory-access user-group-mapping status コマンドを入力します。

意味

LDAP サーバーのアドレス、ポート番号、ステータスが表示されます。

認証テーブルエントリーの検証

目的

ユーザーが属するグループと、ドメイン内のユーザー、グループ、IPアドレスを確認します。

アクション

動作モードから、 show services user-identification active-directory-access active-directory-authentication-table all コマンドを入力します。

意味

各ドメインの IP アドレス、ユーザー名、およびグループが表示されます。

IP-to-User マッピングの検証

目的

イベント ログがスキャンされていることを確認します。

アクション

動作モードから、 show services user-identification active-directory-access statistics ip-user-mapping コマンドを入力します。

意味

クエリと失敗したクエリの数が表示されます。

IP プローブ カウントの確認

目的

IP プローブが発生していることを確認します。

アクション

動作モードから、 show services user-identification active-directory-access statistics ip-user-probe コマンドを入力します。

意味

IP プローブと失敗した IP プローブの数が表示されます。

ユーザーからグループへのマッピングクエリの検証

目的

ユーザーとグループのマッピングが照会されていることを確認します。

アクション

動作モードから、 show services user-identification active-directory-access statistics user-group-mapping コマンドを入力します。

意味

クエリと失敗したクエリの数が表示されます。

例:SRXシリーズファイアウォールでActive Directoryをアイデンティティソースとして設定し、認証されていないユーザーや不明なユーザーにWebリダイレクトを使用する

この例では、認証されていないユーザーや不明なユーザーが http 経由で認証ページにリダイレクトするために web-redirect を使用する方法を示しています。

必要条件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • 1台のSRXシリーズファイアウォール

  • Junos OS リリース 15.1X49-D70 以降(SRXシリーズ ファイアウォール向け)

この機能を設定する前に、デバイス初期化以外の特別な設定を行う必要はありません。

概要

fwauth アクセス プロファイルは web-redirect パススルー トラフィックの要求を HTTP webauth(JWEB httpd サーバ内)にリダイレクトします。認証が成功すると、fwauth はユーザー ファイアウォールのファイアウォール認証を作成します。

構成

CLIクイック構成

この例を迅速に設定するには、以下のコマンドをテキストファイルにコピーし、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを[edit]階層レベルでCLIにコピーアンドペーストして、設定モードから commit を入力します。

プロシージャ

手順

次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、 設定モードでのCLIエディターの使用を参照してください。

HTTPベースのリソースへのアクセスを要求する認証されていないユーザーに対してWebリダイレクトを使用するように統合ユーザー ファイアウォールを構成するには:

  1. HTTP トラフィックの Web 管理サポートを有効にします。

  2. インターフェイスを設定し、IPアドレスを割り当てます。ge-0/0/1インターフェイスでWeb認証を有効にします。

  3. source-identityとしてunauthenticated-userまたはunknown-userを指定するセキュリティポリシーを設定します。

    Junos OS 17.4R1以降では、送信元アドレスを設定する際に、IPv4アドレスに加えてIPv6アドレスを割り当てることができます。IPv6送信元アドレスを設定するには、 any または any-IPv6 コマンドを[edit security policies from-zone trust to-zone untrust policy policy-name match source-address]階層レベルで発行します。

  4. アクションとして web-redirect があるユーザー ファイアウォールのファイアウォール認証を許可し、ユーザー向けに事前に設定されたアクセスプロファイルを指定するセキュリティポリシーを設定します。

  5. ドメイン名を指定するセキュリティポリシーを設定します。

業績

設定モードから、 show system services コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show interfaces コマンドを入力して、統合されたユーザー ファイアウォールの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show security policies コマンドを入力して、統合されたユーザーファイアウォールの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show security policies コマンドを入力してポリシー設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定モードから commit を入力します。

検証

設定を確認します。

目的

設定が正しいことを確認します。

アクション

動作モードから、 show security policies コマンドを入力します。

サンプル出力
意味

Webリダイレクトをアクションとするユーザー ファイアウォールのファイアウォール認証を許可するセキュリティポリシーを表示します。

例:SRXシリーズファイアウォールでActive Directoryをアイデンティティソースとして設定し、Web-Redirect-to-HTTPSを使用して未認証のユーザーや不明なユーザーを認証する

この例では、HTTPSサイトにアクセスしようとする未認証のユーザーや不明なユーザーに対してweb-redirect-to-httpsを使用して、SRXシリーズファイアウォールの内部Web認証サーバーを介して認証できるようにする方法を示しています。

また、web-redirect-https を使用して、HTTP サイトにアクセスしようとするユーザーを認証することもできますが、この例では示されていません。

必要条件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • 1台のSRXシリーズファイアウォール

  • Junos OS リリース 15.1X49-D70 以降(SRXシリーズ ファイアウォール向け)

概要

web-redirect-https機能を使用すると、ユーザーのブラウザーをSRXシリーズサービスゲートウェイの内部HTTPS Web認証サーバーにリダイレクトして認証することで、HTTPまたはHTTPSリソースにアクセスしようとする未知のユーザーや認証されていないユーザーを安全に認証できます。つまり、Web認証サーバは、ユーザ認証のためにWeb認証サーバに接続するようにブラウザをリダイレクトするHTTPS応答をクライアントシステムに送信します。クライアントの要求が到着したインターフェイスは、リダイレクト応答が送信されるインターフェイスです。 この場合、HTTPSはユーザーのトラフィックではなく、認証プロセスをセキュリティで保護します。

ユーザーが認証されると、認証が成功したことをユーザーに通知するメッセージが表示されます。ブラウザーは、ユーザーが URL を再入力しなくても、HTTP サイトか HTTPS サイトかに関係なく、ユーザーの元のリンク先 URL を起動するようにリダイレクトされます。次のメッセージが表示されます。

ユーザーのターゲット・リソースが HTTPS URL に対する場合、このプロセスを成功させるには、該当するセキュリティー・ポリシーで参照される SSL ターミネーション・プロファイルが構成に含まれている必要があります。ターゲットが HTTP URL の場合、SSL 終端プロファイルは必要ありません。

この機能を使用すると、より優れたユーザーログインエクスペリエンスが可能になります。たとえば、ユーザー名とパスワードの入力を求めるポップアップ プロンプトの代わりに、ブラウザーにログイン ページが表示されます。web-redirect-https を使用すると、ユーザーがクライアント ブラウザーで Web 認証 IP アドレスを入力した場合と同じ効果があります。その意味で、web-redirect-httpsはシームレスな認証エクスペリエンスを提供します。ユーザは Web 認証元の IP アドレスを知る必要はなく、アクセスしようとしているリソースの IP アドレスだけを知ることができます。

統合型ユーザー ファイアウォールの場合、セキュリティ ポリシーの設定ステートメントに source-identity タプルが含まれているため、セキュリティ ポリシーが適用されるユーザーのカテゴリ(この場合は、認証されていないユーザーと不明なユーザー)を指定できます。送信元アドレス タプルの値として "any" を指定すると、送信元 ID タプル値で一致を制御できます。

セキュリティ上の理由から、認証には web-redirect ではなく web-redirect-https を使用することを推奨します(これもサポートされています)。Web リダイレクト認証機能は、認証プロセスに HTTP を使用します。この場合、認証情報はクリアテキストで送信されるため、読み取り可能です。

この例では、ユーザーが https://mymailsite.com などのHTTPSリソースにアクセスしようとしていることを前提としています。

構成

プロシージャ

CLIクイック構成

この例を迅速に設定するには、以下のコマンドをテキストファイルにコピーし、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、[edit]階層レベルでCLIにコマンドをコピーアンドペーストし、設定モードから commit を入力します。

手順

次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、 設定モードでのCLIエディターの使用を参照してください。

HTTPS ベースのリソースへのアクセスを要求する認証されていないユーザーまたは不明なユーザーに対して web-redirect-to-https を設定するには、次のステートメントを入力します。

  1. HTTPS トラフィックの Web 管理サポートを有効にします。

    この例はHTTPSユーザートラフィックに適用されますが、Web-redirect-to-https認証は、トラフィックがHTTP URLサイトへのものである認証済みユーザーに対してもサポートされていますが、その特定のシナリオはここでは示されていません。その場合、SSL 終端プロファイルは必要ありません。

  2. インターフェイスを設定し、IPアドレスを割り当てます。ge-0/0/1インターフェイスでWeb認証を有効にします。

  3. unauthenticated-user と unknown-user を source-identity タプル値として指定するセキュリティ ポリシーを設定します。

    Junos OS 17.4R1以降では、送信元アドレスを設定する際に、IPv4アドレスに加えてIPv6アドレスを割り当てることができます。IPv6送信元アドレスを設定するには、 any または any-IPv6 コマンドを[edit security policies from-zone trust to-zone untrust policy policy-name match source-address]階層レベルで発行します。

  4. セキュリティポリシーを設定して、 web-redirect-to-https をアクションとし、ユーザー向けに事前設定されたアクセスプロファイルを指定するユーザー ファイアウォールのファイアウォール認証を許可します。

  5. セキュリティポリシーのドメイン名を設定します。

  6. 使用する SSL ターミネーションプロファイルを参照するようにセキュリティポリシーを設定します。

    実装に必要なサービスを提供する適切な SSL 終端プロファイルが既存の場合は、それを使用できます。それ以外の場合は、手順 7 に従って作成します。

  7. SSL ターミネーション・サービスに使用するプロファイルを指定します。

  8. TLSタイプを定義して、StartTLS上のLDAPを設定します。

  9. 認証するピアホスト名を設定します。

  10. TLS ハンドシェイクのタイムアウト値を指定します。3 秒から 90 秒まで入力できます。

  11. TLS バージョン (v1.1 と v1.2 がサポートされています) を、接続で有効な最小プロトコル バージョンとして指定します。

業績

設定モードから、 show system services コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show services ssl コマンドを入力して、統合されたユーザーファイアウォールの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show interfaces コマンドを入力して、統合されたユーザー ファイアウォールの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show security policies コマンドを入力して、統合されたユーザー ファイアウォールの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

設定モードから、 show access profile profile1 コマンドを入力して、アクセス プロファイルの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定モードから commit を入力します。

例:デバイス アイデンティティ認証機能の設定

この例では、デバイス アイデンティティ認証機能を設定して、ユーザーではなく、認証されたデバイスの ID に基づいてネットワーク リソースへのアクセスを制御する方法を示します。この例では、認証ソースとして Microsoft Active Directory を使用しています。デバイスまたはデバイスのセットを特徴付けるデバイス アイデンティティ プロファイルの設定方法と、セキュリティ ポリシーでそのプロファイルを参照する方法について説明します。デバイスがデバイスIDとセキュリティポリシーのパラメータに一致する場合、セキュリティポリシーのアクションがそのデバイスから発行されるトラフィックに適用されます。

さまざまな理由から、リソースのアクセス制御にデバイスの ID を使用したい場合があります。たとえば、ユーザーの ID がわからない場合があります。また、企業によっては、802.1をサポートしていない古いスイッチを使用している場合や、ネットワークアクセス制御(NAC)システムを備えていない場合もあります。デバイスID認証機能は、デバイスIDに基づいてネットワークアクセスを制御できるようにすることで、このような状況やその他の同様の状況に対するソリューションを提供するように設計されています。デバイス アイデンティティの仕様に適合するデバイスのグループ、または個々のデバイスのアクセスを制御できます。

必要条件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • Junos OS リリース 15.1X49-D70 以降を搭載する SRXシリーズ サービスゲートウェイ デバイス。

  • ドメイン コントローラーとライトウェイト ディレクトリ アクセス プロトコル (LDAP) サーバーを備えた Microsoft Active Directory

    Active Directory ドメイン コントローラーは、4 コアと 8 ギガバイトのメモリの高パフォーマンス構成です。

    手記:

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

  • 社内ネットワーク上のサーバー。

概要

Junos OS リリース 15.1X49-D70 および Junos OS リリース 17.3R1 以降、SRXシリーズは、Active Directory またはサードパーティー製のネットワーク アクセスコントロール(NAC)システムによって認証されたデバイスの ID に基づいて、ネットワーク リソースへのアクセスを制御するサポートを提供します。この例では、認証ソースとして Active Directory を使用しています。

手記:

この機能を動作させるには、認証ソースを設定する必要があります。

この例では、次の構成部分をカバーしています。

  • ゾーンとそのインターフェイス

    セキュリティ ポリシーで指定された送信元と宛先のエンティティが属するゾーンを設定する必要があります。設定しなかった場合、デバイス アイデンティティ プロファイルを参照するセキュリティ ポリシーは無効になります。

  • デバイス アイデンティティ プロファイル

    デバイス アイデンティティ プロファイルは、セキュリティ ポリシーとは別に設定します。セキュリティポリシーから参照しますデバイス アイデンティティ プロファイルは、1 つ以上のデバイスで照合できるデバイス ID を指定します。Active Directory の場合、プロファイルで device-identity 属性のみを指定できます。

    この例では、デバイス ID 属性の仕様は company-computers です。

    手記:

    デバイス アイデンティティ プロファイルは、CLI では end-user-profile と呼ばれます。

  • セキュリティ ポリシー

    セキュリティ ポリシーを設定し、そのアクションは、デバイス アイデンティティ プロファイル属性およびセキュリティ ポリシーの残りのパラメータに一致する任意のデバイスから発行されるトラフィックに適用されます。

    手記:

    デバイス アイデンティティ プロファイルの名前は、セキュリティ ポリシーの source-end-user-profile フィールドに指定します。

  • 認証ソース

    デバイスの認証に使用する認証ソースを設定します。この例では、デバイス アイデンティティの認証ソースとして Active Directory を使用しています。

    Active Directoryが認証ソースである場合、SRXシリーズはActive Directoryドメインのイベントログを読み取ることで、認証済みデバイスのID情報を取得します。次に、デバイスは Active Directory の LDAP インターフェイスにクエリを実行し、クエリにデバイスの IP アドレスを使用して、デバイスが属するグループを識別します。

    この目的のために、デバイスは、Microsoft 分散 COM/Microsoft RPC スタックを備えた Windows Management Instrumentation (WMI) クライアントと、Active Directory ドメイン内の Windows Active Directory コントローラーと通信するための認証メカニズムを実装します。これは、Active Directory ドメインのイベントログからデバイス情報を抽出するデバイス wmic デーモンです。

    また、wmic デーモンは、同じ WMI DCOM インターフェイスを使用して Active Directory イベント ログの変更を監視します。変更が発生すると、デバイスはその変更を反映するようにローカルデバイスアイデンティティ認証テーブルを調整します。

    Junos OS リリース 17.4R1 以降、Active Directory ドメインコントローラと LDAP サーバーに IPv6 アドレスを割り当てることができます。Junos OS リリース 17.4R1 より前のバージョンでは、IPv4 アドレスのみを割り当てることができました。

位相幾何学

この例では、marketing-zone ゾーンに属するユーザーが、社内サーバー上のリソースにアクセスしようとしています。アクセス制御は、デバイスの ID に基づきます。この例では、デバイス ID として company-computers が指定されています。したがって、セキュリティポリシーアクションは、その仕様に適合し、セキュリティポリシーの基準に一致するデバイスにのみ適用されます。これは、サーバーリソースへのアクセスを許可または拒否されるデバイスです。ユーザーの識別に基づいてアクセスが制御されることはありません。

2つのSRXシリーズゾーンが確立されます。1つはネットワークデバイスを含むゾーン(marketing-zone)で、もう1つは内部サーバーを含むゾーン(servers-zone)です。IPアドレスが192.0.2.18/24のSRXシリーズファイアウォールインターフェイスge-0/0/3.1は、marketing-zoneゾーンに割り当てられています。IPアドレスが192.0.2.14/24のSRXシリーズファイアウォールインターフェイスge-0/0/3.2は、servers-zoneゾーンに割り当てられています。

この例では、次のアクティビティについて説明します。

  1. SRXシリーズファイアウォールは、WMI DCOMインターフェイスを使用してActive Directoryドメインコントローラーに接続し、Active Directoryによって認証されたデバイスに関する情報を取得します。

    ユーザーがネットワークにログインして認証されると、ユーザーのデバイスに関する情報がイベントログに書き込まれます。

  2. SRXシリーズは、Active Directoryドメインコントローラのイベントログからデバイス情報を抽出します。

  3. SRXシリーズは、抽出された情報を使用して、デバイスが属するグループのリストをActive Directory LDAP サーバーから取得します。

  4. SRXシリーズは、ローカル デバイス ID 認証テーブルを作成し、ドメイン コントローラーから取得したデバイス ID 情報とLDAP サーバーテーブルに格納します。

  5. デバイスからのトラフィックがSRXシリーズファイアウォールに到着すると、SRXシリーズはデバイスアイデンティティ認証テーブルで、トラフィックを発行したデバイスに一致するエントリーがないか確認します。

  6. SRXシリーズは、アクセスを要求しているデバイスに一致するエントリーを見つけると、セキュリティ ポリシー テーブルをチェックして、アクセス を要求しているデバイスの仕様と一致するデバイス アイデンティティ 仕様を持つデバイス アイデンティティ プロファイルを source-end-user-profile フィールドに指定しているセキュリティ ポリシーを探します。

  7. 一致するセキュリティポリシーは、デバイスから発行されるトラフィックに適用されます。

図 1 は、この例のトポロジーを示しています。

図 1: Active Directory を認証ソースNetwork security setup with Windows Active Directory Domain Controller authenticating devices. Tablet access denied, laptop access allowed by SRX Series Device, connecting to internal servers.とするデバイス アイデンティティ機能のトポロジー

構成

Active Directory 環境でデバイス アイデンティティ機能を設定するには、以下のタスクを実行します。

CLIクイック構成

この例を素早く設定するには、以下のコマンドをテキストファイルにコピーし、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストし、設定モードから commit を入力してください。

Active Directory 環境での統合型ユーザーファイアウォール デバイス アイデンティティ認証機能の設定

手順

この手順には、Active Directory環境でデバイスアイデンティティ認証機能をサポートするようにSRXシリーズファイアウォールを設定するために必要な設定ステートメントが含まれています。

  1. marketingゾーンとservers-zoneに使用するインターフェイスを設定します。

  2. marketing-zone と servers-zone を設定し、インターフェイスを割り当てます。

  3. Microsoft Active Directory を指定するように認証ソースを構成します。デバイス アイデンティティ機能を動作させるには、認証ソースを指定する必要があります。これは必須値です。

  4. デバイス アイデンティティ プロファイル( end-user-profileとも呼ばれる)のデバイス アイデンティティ仕様を設定します。

  5. marketing-west-coast というデバイス アイデンティティ プロファイルを参照する mark-server-access というセキュリティ ポリシーを設定します。セキュリティー・ポリシーは、marketing-zone ゾーンに属する (かつ、デバイス・アイデンティティー・プロファイル仕様に一致する) すべてのデバイスに、ターゲット・サーバーのリソースへのアクセスを許可します。

  6. Active Directoryと通信し、LDAPサービスを使用するようにSRXシリーズファイアウォールを設定します。

    デバイスID認証機能を実装するために必要なグループ情報を取得するために、SRXシリーズファイアウォールはLDAP(ライトウェイトディレクトリアクセスプロトコル)を使用します。SRXシリーズは、LDAP サーバーと通信するLDAPクライアントとして機能します。通常、Active Directory ドメイン コントローラは LDAP サーバーとして機能します。デバイスの LDAP モジュールは、既定では、ドメイン コントローラー内の Active Directory にクエリを実行します。

業績

設定モードで show interfaces を入力します。

設定モードで show security zones を入力します。

設定モードで show services user-identification device-information end-user-profile を入力します。

設定モードで show services user-identification device-information authentication-source を入力します。

設定モードで show security policies を入力します。

設定モードで show services user-identification active-directory-access を入力します。

設定モードで show services user-identification active-directory-access domain example-net を入力します。

検証

デバイスアイデンティティ認証テーブルの内容の確認

目的

デバイス アイデンティティ認証テーブルに、予期されるエントリーとそのグループが含まれていることを確認します。

アクション

この場合、デバイス アイデンティティ認証テーブルには 3 つのエントリが含まれています。次のコマンドは、3 つのエントリすべての広範な情報を表示します。

オペレーションモードで show services user-identification device-information table all extensive コマンドを入力すると、テーブルの内容が表示されます。

サンプル出力
コマンド名
意味

テーブルには、認証されたすべてのデバイスとそれらが属するグループの情報を含むエントリが含まれている必要があります。

例:送信元ゾーンに基づくセッションログへのユーザ識別情報の設定

この例では、セキュリティ ポリシーで設定された送信元ゾーン(from-zone)に基づいてユーザ アイデンティティ情報をログに記録するようにシステムに指示する、統合ユーザー ファイアウォールのゾーンベース ユーザ アイデンティティ機能を設定する例を示します。ゾーンベースのユーザー ID 機能では、セキュリティ ポリシーに一致するトラフィックを持つゾーンに属するすべてのユーザーを含むように、ID 情報がログに書き込まれるユーザーの範囲が広がります。

必要条件

この機能は、Junos OS 15.1X49-D60およびJunos OS リリース17.3R1以降でサポートされています。この機能は、Junos OS 15.1X49-D60以降、現在サポートされているすべてのSRXシリーズファイアウォールで設定して実行できます。

概要

この例では、統合ユーザー ファイアウォールを設定して、セキュリティ ポリシーの送信元ゾーンに基づいてセッション ログにユーザー ID 情報をログに記録する方法を示します。これを実現するには、送信元ゾーンとして指定されたゾーンを、ソース ID ロギング用に構成する必要があります。ゾーンベースのユーザ アイデンティティ ロギングの場合、セキュリティ ポリシーのアクションにセッション作成(session-init)イベントとセッション クローズ(session-close)イベントを含める必要があります。

すべての条件が満たされると、セッションの開始時(またはセッションの初期化時)とセッションの終了時(またはセッションの破棄)に、ユーザー名がログに書き込まれます。セキュリティ・ポリシーによってリソースへのユーザー・アクセスが拒否されている場合、ユーザーを名前で識別するエントリーがログに書き込まれます(つまり、セッション・クローズが構成されている場合)。

ゾーンベースのユーザ アイデンティティ機能を使用する場合、ユーザ アイデンティティ ロギング イベントを開始するのは、セキュリティ ポリシー内の送信元ゾーン(from-zone)です。

この機能が導入される前は、セキュリティ ポリシーにソース ID タプル (source-identity) を含めて、ユーザー ID 情報(ユーザー名またはグループ名)をログに書き込むようにシステムに指示する必要がありました。ユーザーのトラフィックに一致するゾーンペアのいずれかのポリシーにsource-identityタプルが設定され、セッションクローズログが設定されている場合、ユーザーIDがログに書き込まれました。

ただし、送信元アイデンティティ機能は、個々のユーザーまたはユーザーのグループに固有のものであり、その点でセキュリティポリシーの適用を制限します。

これは、ローカルの Active Directory テーブルに格納されるユーザー名であり、ポリシーの送信元ゾーンがユーザー ID ログ用に構成されているときに、システムがログに書き込みます。SRXシリーズファイアウォールは、ドメインコントローラのイベントログを読み取ることで、事前にユーザーID情報を取得しています。SRXシリーズファイアウォールは、その情報をActive Directoryテーブルに保存しました。

source-identity タプルは、ユーザー ID ログ用に構成されたゾーンを送信元ゾーンとして指定するセキュリティ ポリシーで使用できます。統合 ユーザー ファイアウォール は、統合 ユーザー ファイアウォール がソース ID タプルに依存している場合にのみ、ユーザーが属するグループの名前を Microsoft ドメイン コントローラーから収集するため、source-identity を構成せずにゾーンベースのユーザー ID ログ機能を使用すると、ログにはアクセスを要求しているユーザーの名前のみが含まれ、ユーザーが属するグループは含まれません。

送信元アイデンティティ・ロギングをサポートするようにゾーンを構成すると、そのゾーンは、ユーザ・アイデンティティ情報を記録するセキュリティ・ポリシーのfrom-zone指定として再利用できます。

要約すると、次の場合にユーザー名がログに書き込まれます。

  • ユーザは、ソース ID ロギング用に構成されたゾーンに属します。

  • ユーザーが、生成されたトラフィックが、送信元ゾーン(from-zone)タプルが適格なゾーンを指定するセキュリティポリシーと一致するリソースアクセスリクエストを発行します。

  • セキュリティ ポリシーには、そのアクションの一部として、セッション初期化(session-init)およびセッション終了(session-close)イベントが含まれます。

ソース・アイデンティティ・ログ機能には、以下の機能があります。

  • 1 つの仕様で幅広いユーザ、つまり、ソース アイデンティティ ロギング用に設定されたゾーンに属するすべてのユーザをカバーします。

  • ユーザー ID ロギングを失うことなく、セキュリティ ポリシーの送信元アドレスにアドレス範囲を引き続き使用します。

  • 複数のセキュリティポリシーで、ソースアイデンティティのログ記録用に設定されたゾーンを再利用します。

    セキュリティポリシーとは無関係に設定されるため、1つ以上のポリシーで送信元ゾーンとしてゾーンを指定できます。

手記:

ゾーンベースのユーザ アイデンティティ ロギング用に設定されたゾーンを、送信元ゾーンとしてではなく宛先ゾーンとして指定すると、ユーザ アイデンティティはログに記録されません。

この機能を動作させるには、以下の情報を設定する必要があります。

  • 意図されたセキュリティポリシーで送信元ゾーン(from-zone)として使用されるゾーンに設定された送信元アイデンティティログステートメント。

  • 以下を指定するセキュリティ ポリシー:

    • 送信元ゾーンとして適格なゾーン。

    • アクションの一部としての session-init イベントと session-close イベント。

構成

ソースアイデンティティロギング機能を設定するには、次のタスクを実行します。

CLIクイック構成

この例を迅速に設定するには、以下のコマンドをコピーして、テキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを [edit] 階層レベルで CLI にコピー アンド ペーストして、設定モードから commit を入力します。

ソースアイデンティティのロギングをサポートするゾーンの設定とセキュリティポリシーでの使用

手順

次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、 設定モードでのCLIエディターの使用を参照してください。

  1. trustゾーンのソースアイデンティティロギングを設定します。このゾーンをセキュリティ ポリシーの送信元ゾーンとして使用すると、システムはセキュリティ ポリシーが適用されるすべてのユーザーのセッション ログにユーザー ID 情報を書き込みます。

  2. 送信元ゾーンの条件としてゾーンの信頼を指定する appfw-policy1 というセキュリティポリシーを設定します。送信元アイデンティティのロギングは、トラフィックがセキュリティポリシーのタプルに一致するすべてのユーザーに適用されます。

    このセキュリティ ポリシーにより、ユーザーは junos-ftp サービスにアクセスできます。ユーザーのセッションが確立されると、ユーザーの ID がログに記録されます。また、セッションの終了時にもログに記録されます。

  3. セッション開始イベントとセッション終了イベントのログ記録を含めるように、appfw-policy1セキュリティポリシーのアクションを設定します。

    手記:

    ソース アイデンティティ ログ機能を有効にするには、セッション開始イベントとセッション終了イベントをログに記録するようにセキュリティ ポリシーを設定する必要があります。ユーザー ID 情報は、これらのイベントと連動してログに書き込まれます。

業績

設定モードから、 show security zones コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

検証

このセクションには、ユーザーセッションに対して生成されたセッションログが表示されます。ログ出力:

  • ユーザー名user1が表示されます。このユーザー名は、セッションを開くときに表示され、セッションを閉じるときに再び表示されます。

    ユーザー名がログに書き込まれる原因となったセキュリティ ポリシーの構成では、ゾーンの信頼がソース ゾーンとして指定されています。ゾーンの信頼は、ソース ID ログ用に構成されています。

  • ユーザーのリクエストトラフィック、ポリシーポリシーの一致基準を定義、NAT設定から取得した情報を含みます。

  • Active Directory データベースから取得される、ユーザーに関する ID 情報を格納します。この情報には、ユーザーが属するグループを示す "MyCompany/Administrator" の role パラメーターが含まれます。

このシナリオでは、ユーザーがジュニパーネットワークスのjunos-ftpサービスへのアクセスを要求しました。このサービスもログに記録されます。 表 1 は、ソース ID ログ機能設定に固有のログの部分を示しています。

表 1:送信元アイデンティティログ機能に固有のセッションログコンポーネント

セッション作成

これは、セッション設定情報を記録するログの最初のセクションを開始するセッション開始です。

ユーザー名 user1 は、セッション作成ログ記録の開始時に表示されます。

user1 RT_FLOW_SESSION_CREATE

セッション作成の後には、セキュリティ ポリシーのタプルに一致するユーザーのトラフィックに基づいてセッションを定義する標準情報が続きます。

送信元アドレス、送信元ポート、宛先アドレス、宛先ポート。

source-address ="198.51.100.13/24" source-port =" 635" destination-address =" 198.51.100.10 / 24" destination-port =" 51"

アプリケーションサービス

これは、ユーザーがアクセスを要求し、セキュリティ ポリシーで許可されたアプリケーション サービスです。

service-name="junos-ftp"

送信元ゾーン、宛先ゾーン

ログのさらに下には、定義された送信元ゾーンとして信頼を示し、宛先ゾーンとして信頼されていないことを示すゾーン仕様があります。

source-zone-name="trust" destination-zone-name="untrust"

セッションを閉じる

これはセッション・クローズの開始であり、セッションのティアダウンとクローズをカバーするログ・レコードの 2 番目の部分を開始します。

ユーザー名 user1 は、セッション終了レコードの先頭に表示されます。

user1 RT_FLOW - RT_FLOW_SESSION_CLOSE

ユーザー ID 情報がログに記録されていることを確認する

目的

統合ユーザー ファイアウォールは、ソース ID として構成されたグループを Microsoft ドメイン コントローラーからのみ収集することに注意してください。送信元アイデンティティを設定せずにゾーンベースのユーザアイデンティティ機能を使用する場合、ログにはユーザ名のみが含まれ、グループ情報は記録されません。その場合、ログの「roles=」セクションには「N/A」と表示されます。次の例では、source-identity タプルが使用され、"roles=" セクションにユーザー "Administrator" が属するグループの長いリストが表示されていることを前提としています。

アクション

ログ情報を表示します。

サンプル出力
コマンド名

ファイアウォールの ID ソースとして Active Directory を構成する

表 2 に、ファイアウォールで Active Directory を ID ソースとして設定する手順を示します。

表 2:Active Directoryをアイデンティティ ソースとして設定する

設定のステップ

命令

ステップ1:認証テーブルを設定する

Active Directory認証テーブルを設定できます。

プライオリティオプションを設定することができます。

認証テーブル

[edit security user-identification authentication source]

user@host# set active-directory-authentication-table

認証テーブルの優先度

[edit security user-identification authentication source active-directory-authentication-table]

user@host# set priority

ステップ 2: タイムアウトを構成する

認証テーブル内のエントリーに対して、有効な認証エントリーと無効な認証エントリーのタイムアウトを設定できます。デフォルトの authentication-entry-timeout 間隔は 30 分です。タイムアウトを無効にするには、間隔を 0 に設定します。

認証テーブル エントリのタイムアウト情報を表示できます。

有効な認証エントリー

[edit services user-identification active-directory-access]

user@host# set authentication-entry-timeout minutes

無効な認証エントリ

[edit services user-identification active-directory-access]

user@host# set invalid-authentication-entry-timeout minutes

タイムアウト情報の表示

[edit show services user-identification active-directory-access active-directory-authentication-table]

user@host# set all extensive

手順 3: Windows イベント ログの検証と統計を構成する

認証テーブルがIPアドレスとユーザー情報を取得していることを確認できます。

イベント ログの読み取りに関する統計を確認できます。

WMIC のバックアップとしてファイアウォール認証を設定できます

Windows イベント ログの検証

[edit show services user-identification active-directory-access active-directory-authentication-table]

user@host# set all

Windows イベント ログの統計情報

[edit show services user-identification active-directory-access ip-user-mapping]

user@host# set statistics domain

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

[edit security policies from-zone trust to-zone untrust policy <policy-name> then permit

user@host# set firewall-authentication user-firewall domain <domain-name>

手順 4: ドメイン PC のプローブを構成する

オンデマンドプローブはデフォルトで有効になっています。オンデマンドプローブを無効にすることができます。オンデマンド・プローブが無効になっている場合、手動プローブを使用できます。

プローブのタイムアウト値を設定できます。デフォルトのタイムアウトは 10 秒です。

プローブの統計情報を表示できます。

オンデマンドプローブの無効化

[edit services user-identification active-directory-access]

user@host# set no-on-demand-probe

手動プローブを有効にする

[edit services user-identification active-directory-access ip-user-probe address ip-address address]

user@host# set domain domain-name

プローブタイムアウト値

[edit services user-identification active-directory-access]

user@host# set wmi-timeout seconds

プローブ統計情報の表示

[edit show services user-identification active-directory-access]

user@host# set statistics ip-user-probe

ステップ 5: LDAP サーバーの状態と統計を構成する

LDAP接続ステータスを確認できます。

LDAP サーバーに対して行われたクエリの数を確認できます。

LDAP サーバーの状態

[edit show services user-identification active-directory-access]

user@host# set user-group-mapping status

LDAP サーバー統計情報

[edit show services user-identification active-directory-access]

user@host# set statistics user-group-mapping

NFX デバイス上のアイデンティティ ソースとしての Active Directory の設定

統合ユーザー ユーザー ファイアウォール機能の一般的なシナリオでは、ドメイン ユーザーは NFX デバイスを介してインターネットにアクセスしたいと考えています。デバイスは、ドメインで構成されているドメイン コントローラーのイベント ログを読み取って分析します。したがって、デバイスは Active Directory ドメイン コントローラー上のドメイン ユーザーを検出します。Active Directoryドメインは、統合ユーザー ファイアウォールのActive Directory認証ソースとして認証テーブルを生成します。デバイスはこの情報を使用してポリシーを適用し、ユーザーベースまたはグループベースのアクセス制御を実現します。

Active Directory(AD)で新しいユーザーが作成されると、そのユーザーはグローバルセキュリティグループプライマリグループ(デフォルトではドメインユーザー)に追加されます。プライマリグループは、すべてのユーザーが所属しているため、ADで作成された他のグループよりも具体性が低くなります。また、非常に大きくなる可能性があります。

プライマリ グループは、既定の名前である [Domain Users] でも、その他の名前 (変更した場合) でも、統合ユーザー ファイアウォール構成では使用できません。

Windows Active Directoryドメインを確立し、別のセキュリティポリシーを設定するには、次の手順に従います。

  1. LDAPベースの識別名を設定します。
  2. ドメイン名、ドメインのユーザ名とパスワード、およびドメイン内のドメインコントローラの名前とIPアドレスを設定します。
  3. 特定のユーザーを有効にするために 2 つ目のポリシーを設定します。

    policies ステートメントで送信元 ID を指定する場合は、ドメイン名を先頭に追加し、グループ名またはユーザー名にバックスラッシュを付けます。組み合わせを引用符で囲みます。

  4. 統合型ユーザー ファイアウォール情報取得の認証元に Active Directory 認証テーブルを設定し、ユーザー情報テーブルを確認する順序を指定します。

設定が正常に機能していることを確認するには、次の手順に従います。

  1. show services user-identification active-directory-access domain-controller status コマンドを入力して、少なくとも 1 つのドメイン コントローラーが構成され、接続されていることを確認します。

  2. show services user-identification active-directory-access user-group-mapping status コマンドを入力して、LDAP サーバーがユーザーとグループのマッピング情報を提供していることを確認します。

  3. show services user-identification active-directory-access active-directory-authentication-table all コマンドを入力して、認証テーブルのエントリーを確認します。各ドメインの IP アドレス、ユーザー名、およびグループが表示されます。

  4. show services user-identification active-directory-access statistics ip-user-mapping コマンドを入力して、IP からユーザー へのマッピングを確認します。クエリと失敗したクエリの数が表示されます。

  5. show services user-identification active-directory-access statistics ip-user-probe コマンドを入力して、IP プローブが発生していることを確認します。

  6. show services user-identification active-directory-access statistics user-group-mapping コマンドを入力して、ユーザーとグループのマッピングが照会されていることを確認します。