ASA CX および Cisco Prime Security Manager 9.0 ユーザ ガイド
認証サービスとアイデンティティ サービスの管理
認証サービスとアイデンティティ サービスの管理
発行日;2013/04/11   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

認証サービスとアイデンティティ サービスの管理

IP アドレスではなく、アイデンティティに基づいてアクセス ポリシーを作成できます。 アイデンティティ ベースのサービスを有効にするには、ポリシーとオプションを設定してユーザ アイデンティティを取得し、アイデンティティ オブジェクトをアクセス ポリシーに使用します。 次に、認証サービスとアイデンティティ サービス、およびそれらの設定方法を説明します。

認証サービスとアイデンティティ サービスの概要

認証は、ユーザのアイデンティティを確認する動作です。 ASA CX でユーザ アイデンティティがマッピングされていない IP アドレスからトラフィック フローが届いた場合に、そのトラフィック フローを開始したユーザを、ネットワークに設定されたディレクトリで認証するかどうかを決定できます。 ユーザを正常に認証した場合、その IP アドレスは認証されたユーザのアイデンティティを持つと見なされ、そのトラフィックにアイデンティティ ベースのアクセス ポリシーを適用できます。そして、スタティック IP アドレス ベースのポリシーによってネットワーク アクセスを制御するのではなく、リソースにアクセスしようとしているユーザに基づいて制御できます。

認証サービスおよびアイデンティティ サービスの提供には、個々の多数の機能が関係しています。

  • ディレクトリ レルム:認証サービスを提供するディレクトリ レルムを定義する必要があります。 レルムには、Active Directory や OpenLDAP など、ネットワークに対するユーザ名およびユーザ グループ メンバーシップを定義する 1 つ以上のディレクトリ サーバが含まれています。 アイデンティティ ポリシーを設定する場合には、認証を提供するディレクトリ レルムを選択する必要があります。
  • アイデンティティ ポリシー:アイデンティティ ポリシーを使用すると、ユーザ名およびユーザ グループ メンバーシップを含む、ユーザ アイデンティティに基づくポリシーが可能になります。 ユーザが認証に失敗しても、アイデンティティ ポリシーがトラフィックをドロップまたはブロックすることはありません。 代わりに、ユーザ情報を収集して、アクセス ポリシーがユーザ ID に基づいてトラフィックを照合できるようにし、またレポートとイベントにユーザ ID 情報が含まれるようにします。
  • 認証設定:認証設定では、認証マッピングおよびプロンプトの管理方法が制御されます。 たとえば、ユーザに再認証を要求するまでの、ユーザ名と IP アドレスのマッピングが有効となっている期間を定義できます。 これらの設定にはシステム デフォルトが存在するため、これらの設定を調整する必要があるのは、異なる設定が必要な場合だけです。
  • アイデンティティ ポリシー オブジェクト:アクセス制御を定義する特定のユーザ名またはユーザ グループ名を定義します。 また、オブジェクトから名前を選択して除外することもできます。 たとえば、ユーザ グループ Eng を含むオブジェクトを定義し、そのグループのメンバであるユーザ Guest1 と Guest2 を除外することができます。
  • アクセス ポリシー:アイデンティティ ポリシー オブジェクトを送信元フィールドの一部としてアクセス ポリシーに指定すると、ユーザ アイデンティティに基づいて宛先リソースへのアクセスが制御されます。
  • Active Directory エージェント:(任意)。ネットワークに Active Directory エージェントをインストールすると、ユーザがデバイス経由でトラフィックを渡す前に、そのユーザがネットワークにログインした時点でユーザ アイデンティティ情報を収集することができます。 このタイプのアイデンティティは、パッシブ アイデンティティ マッピングと見なされます。 この情報を収集することにより、直接認証を行うようユーザに強制することなく、アイデンティティ ベースのアクセス制御をイネーブルにできます。
  • アイデンティティ ベースのレポート:多くのレポートにアイデンティティ情報(利用できる場合)が含まれているため、ユーザのアイデンティティに基づいてネットワークのトラフィックを分析できます。 Users レポートは、ユーザ ベースのネットワーク使用状況情報を提供するよう特別に設計されています。 これらのレポートを使用すると、ネットワークで許容される使用基準を満たしていないケースを識別できます。

サポートされる AAA サーバと認証方式

LDAP(Lightweight Directory Access Protocol)を実行する AAA サーバを使用して、認証サービスとアイデンティティ サービスを実装することができます。 それぞれで使用可能な、サポートされるサーバと認証方式を次に示します。

  • Microsoft Active Directory:次の AD サーバを使用できます。
    • Windows Server 2008 R2
    • Windows Server 2003 R2
    AD を使用している場合は、次の認証方式をアイデンティティ ポリシーで使用できます。また、ネゴシエーションにより、サポートされる最も強力な方式を選択することもできます。
    • NTLM
    • Kerberos
    • Basic
  • OpenLDAP:バージョン 2.4.21 以降。 使用できる方式は、基本認証方式のみです。

ユーザ アイデンティティのタイプ

アイデンティティ サービスをイネーブルにし、フローを開始したユーザに基づいてトラフィック フローを条件に従って処理できるようにするため、ASA CX はユーザ名をそのユーザのデバイスの IP アドレスにマッピングします。

ユーザと IP アドレスのマッピングの取得方法に基づき、ユーザは次のいずれかのアイデンティティ タイプを持つと見なされます。

  • アクティブ:ユーザは、ASA CX アクティブ認証は HTTP トラフィックのみに適用されます。 他のタイプのトラフィックが、アクティブ認証を要求または許可するアイデンティティ ポリシーに適合した場合、アクティブ認証は試行されません。 で直接認証されました。
  • パッシブ:ユーザと IP アドレスのマッピングは、主に Active Directory(AD)エージェントからの他の手段を通じて受信されました。 このタイプのアイデンティティは、ユーザが送信したトラフィックのタイプに関係なく使用できます。
  • 不明:ユーザと IP のマッピングが存在しません。 たとえば、ユーザがアクティブに ASA CX への認証を試みたが、認証に失敗した場合などです。 アクティブな認証に失敗したユーザは、ユーザ名 Realm\ANONYMOUS の下のユーザ レポートに示されます。 認証の必要がないためマッピングをもたないユーザは、IP アドレスで表示されます。

認証に関するユーザへの周知

アクティブな認証を要求または許可するようにアイデンティティ ポリシーを設定した場合は、ユーザが HTTP 要求(HTTPS 要求ではない)を行ったときに認証を求められる可能性があります。 ユーザが正しく認証できるようサポートするには、ユーザが次の点を理解していることを確認します。

  • 認証プロンプトには、ディレクトリ レルムの名前と ASA CX 管理 IP アドレスが含まれる。 この情報を含んでいる認証要求は有効な要求であり、これらに応答する必要があることを、ユーザに必ず理解してもらいます。
  • Active Directory を使用している場合、ユーザはログインに NetBIOS ドメイン名を DOMAIN\username 形式で含める必要がある。
  • OpenLDAP を使用している場合、ユーザ名のみを指定する必要がある。

認証サービスとアイデンティティ サービスの設定

次の手順では、認証サービスおよびアイデンティティ サービスを設定するプロセスの概要を示します。 この手順を使用して、一般的な設定プロセスを理解し、参照トピックで詳細な手順を確認してください。

手順
    ステップ 1   ディレクトリ レルムの設定の説明に従って、ディレクトリ レルムを設定します。

    ディレクトリ レルムでは、ユーザとユーザ グループの情報が格納されたディレクトリ サーバが定義されます。 ユーザはこれらのサーバに対して認証を行い、ユーザ ID を提供します。次に、ユーザ ID を使用して、ID ベースのアクセス制御およびレポーティングを提供できます。

    ステップ 2   (任意)Active Directory エージェントの識別の説明に従って、Active Directory エージェントを設定します。

    ディレクトリ レルムで Active Directory を使用している場合は、Active Directory エージェントをインストールして、Windows ログイン認証に基づいてパッシブなユーザと IP アドレスのマッピングを提供できます。

    ステップ 3   (任意)認証設定の指定の説明に従って、必要に応じて認証設定を変更します。

    認証設定には、大部分のネットワークに該当するデフォルト値があります。

    ステップ 4   アイデンティティ ポリシーの設定の説明に従って、ディレクトリ レルムごとに少なくとも 1 つのアイデンティティ ポリシーを作成します。

    アイデンティティ ポリシーによって、アクティブ認証またはパッシブ マッピングでユーザが提供すべきアイデンティティのタイプが決まり、認証を不要にした場合は何も提供する必要がなくなります。 各レルムに少なくとも 1 つのポリシーが必要です。ない場合は、レルム内で定義されたユーザのユーザ アイデンティティ マッピングを取得できません。

    (注)     

    アクティブ認証を使用する場合は、トラフィックを ASA から ASA CX SSP にリダイレクトするポリシーによって、認証プロキシがイネーブルになることも確認する必要があります。 認証プロキシをイネーブルにしない場合は、パッシブ認証に制限されます。 詳細については、アクティブ認証のイネーブル化を参照してください。

    ステップ 5   (任意)Active Directory を使用する場合、透過的なユーザ認証のイネーブル化の説明に従ってクライアント ブラウザを設定し、NTLM または Kerberos に透過的な認証を提供できます。

    透過的な認証を提供するように設定されている場合、ブラウザは、ユーザにプロンプトを表示することなく Windows ログイン情報を提供することにより、信頼できる送信元からの認証要求に応答することができます。 つまり、アクティブ認証が実行されますがユーザは認証が行われたことを意識しないため、ユーザが予期しない認証プロンプトを不便に感じたり、混乱することがありません。

    ステップ 6   (任意)コンテキスト対応アクセス ポリシーの設定の説明に従って、アイデンティティ ベースのアクセス ポリシーを作成します。

    アクセス ポリシーの送信元定義内のアイデンティティ ポリシー オブジェクトを使用して、宛先へのアクセスを制御できます。 アイデンティティ オブジェクトは、宛先へのアクセスを許可または拒否されるユーザ名またはユーザ グループ名を定義します。 アイデンティティ ポリシー オブジェクトの詳細については、アイデンティティ オブジェクトを参照してください。

    ステップ 7   レポートおよびイベント内のアイデンティティ情報を使用して、ネットワーク トラフィックを分析します。

    Users レポートなどの多くのレポートには、ID ベースのトラフィック分析が含まれています。 また、ポリシーにヒットしたレポートでポリシーを検索することにより、ID ベースのアクセス ポリシーに関連するレポートにもアクセスできます。 この情報を使用して、ポリシーの有効性を判断し、アクセプタブル ユース ポリシーに違反しているユーザを識別します。 レポートについては、レポートとダッシュボードの表示を参照してください。

    レポートに加えて、Event Viewer にはイベントのユーザ名情報(取得可能な場合)が含まれます。 Event Viewer については、イベントの表示を参照してください。


    ディレクトリ レルムの概要

    ディレクトリ レルムは、ディレクトリ サーバの名前付きリストです。 ディレクトリ レルムは、ASA 上の AAA サーバ グループに類似しています。

    ディレクトリ レルムは、次で使用されます。

    • アイデンティティ ポリシー。ユーザが認証する必要のあるディレクトリを識別します。 アクセス ポリシー内のレルムで定義された ID を使用するために、各レルムに対してアイデンティティ ポリシーが存在する必要があります。
    • [Users] ページ。Web インターフェイスへのアクセスを付与するリモート ユーザを含むディレクトリを識別します。

    レルムおよびレルムに含まれるディレクトリ サーバの追加、編集、削除、またはレルム内でディレクトリ サーバを並べ替える [Directory Realm] ページを開くには、[Device] > [Directory Realm] を選択します。

    [Directory Realm] ページには、次の項目が含まれています。
    • [Filter]:ディレクトリ レルムを見つけやすくするため、ビューをフィルタする場合があります。 文字列を入力すると、リストがフィルタリングされて、その文字列を含むレルムのみが表示されます。 入力する文字列は、一致と見なされるレルムのレルム名内のどこにあってもかまいません。 つまり、文字列がレルム名の先頭に一致している必要はありません。 フィルタを削除するには、ボックスから削除します。
    • [I want to]:次のコマンドが含まれています。
      • [Add Realm]:新しいディレクトリ レルムを追加します。 名前、説明、およびディレクトリ タイプの入力を求められます。 レルム名は、Realm\username 形式でユーザ名とともにレポートに表示されます。 したがって、ユーザ名の文字列が予期した NetBIOS ドメイン名を含むようにするため、レルム名に NetBIOS ドメイン名を使用する場合があります。
    • [List of directory realms and their directory servers]:すべてのディレクトリ レルムがリストに表示され、各レルム内には、レルムに含まれているディレクトリ サーバの順序付きリストがあります。 使用不可にならない限り、リストに表示されている最初のサーバが常に使用されます。使用不可になった場合、応答を受信するまで、リストに表示されている次のサーバの使用が試行されます。 Active Directory レルムの数は 1 つですが、標準 LDAP レルムの数は任意です。 Active Directory にバインドする場合、レルムの最初の AD サーバが使用されます。

      (注)  


      [Pending Commit] アイコンが右側に表示されている場合、そのディレクトリ レルムはまだ設定データベースに保存されていません。


      ディレクトリ レルムまたはサーバに関連するコマンドを表示するには、ディレクトリ レルムのヘッダーまたはディレクトリ サーバの行にマウスを置きます。 使用可能なコマンドは次のとおりです。
      • ディレクトリ レルムには次のコマンドがあります。
        • [Add New Directory]:新しいディレクトリ サーバをレルムに追加します。 サーバは、最初のエントリとしてレルムの先頭に追加されます。 ディレクトリを追加したら、変更をコミットする前にそのポリシーを目的の位置に移動します。
        • [Delete Realm]:レルムを削除します。 ポリシーやポリシー オブジェクト、またはシステム ユーザのグローバル レルムとしてレルムが使用されている場合、レルムを削除できます。
        • [Edit Real]:レルムのプロパティを編集します。
      • ディレクトリ サーバには次のコマンドがあります。
        • [Delete Directory]:ディレクトリ サーバを削除します。
        • [Edit Directory]:ディレクトリ サーバのプロパティを編集します。
        • [Move Up]、[Move Down]:ディレクトリ サーバを目的の位置まで移動します。 この上下移動コマンドでは、ディレクトリが 1 行ずつ移動されます。 ディレクトリをクリックし、目的の位置までドラッグすることもできます。

    ディレクトリ レルムの設定

    ディレクトリ レルムは、ディレクトリ サーバの名前付きリストです。 ディレクトリ レルムは、ASA 上の AAA サーバ グループに類似しています。

    ディレクトリ レルムを設定するには、レルムを作成し、レルムにディレクトリ サーバを追加する必要があります。 次の手順では、この両方について説明します。


    ヒント


    シングル デバイス モード)。最初のディレクトリ レルムを作成すると、デフォルトのアイデンティティ ポリシーがそのレルムに自動的に作成されます。 ポリシーを編集して、ニーズに合わせてポリシーの特性を変更できます。 マルチ デバイス モードでは、デフォルトのポリシーは作成されません。


    手順
      ステップ 1   [Device] > [Directory Realm] を選択します。

      ディレクトリ レルムはリストに編成され、個々のディレクトリ レルムには、ディレクトリ サーバの優先順位のリストが含まれます。 最初のサーバが使用不可になっていない限り、それが常に使用されます。使用不可の場合は、後続のサーバが使用されます。 レルムに関連したコマンドを参照するには、そのレルムの名前にマウスを置きます。ディレクトリ サーバに関連したコマンドを参照するには、そのサーバの名前にマウスを置きます。 これで目的のコマンドを選択できます。

      既存のディレクトリ レルムまたはサーバについて処理する必要がある場合、フィルタ コントロールを使用すると、項目を簡単に見つけることができます。

      ステップ 2   ディレクトリ レルムを設定します。
      1. ディレクトリ レルムを作成または編集するためのフォームを開くには、次のいずれかを実行します。
        • 新しいレルムを作成するには、[I want to] > [Add Realm] を選択します。
        • 既存のレルムを編集するには、レルム名の上にマウスを置いて [Edit Realm] をクリックします。
      2. ディレクトリ レルムのプロパティを入力します。
        • [Name]:レルムの名前。 この名前は、Realm\username 形式でユーザ名とともにレポートに表示されます。 したがって、ユーザ名の文字列が予期した NetBIOS ドメイン名を含むようにするため、レルム名に NetBIOS ドメイン名を使用する場合があります。 ユーザに認証を要求する場合があるレルムのアイデンティティ ポリシーを作成すると、その名前はエンド ユーザにも表示されます。
        • [Description]:レルムの説明。
        • [Directory Type]:LDAP サーバのタイプ。Microsoft [Active Directory] または [Standard LDAP] のいずれか。
          (注)     

          Active Directory レルムは 1 つ作成できますが、標準 LDAP レルムは 2 つ以上作成できます。

        • [Primary Domain]:(AD のみ)デバイスが参加する必要のある、完全修飾 Active Directory ドメイン名。 たとえば、example.com のように指定します。
        • [Join Username]、[Join Password]:(AD のみ)デバイスが AD ドメインに参加する際、またはドメインを脱退する際に使用する Active Directory の sAMAccountName または User Principal Name。 これらのクレデンシャルには、デバイスをドメインに参加または脱退させるための AD 内の権限が必要です。
      3. (AD のみ)。[Test Domain Join] リンクをクリックして、AD レルムにデバイスが参加できることを確認します。

        テストが失敗した場合は、問題を解決する必要があります。 CLI にログインして show dns コマンドを使用し、デバイスに対して正しい DNS ドメインが設定されており、ドメイン検索リストにドメインが含まれていることを確認します。 別の可能性として、介在するファイアウォールで、ドメインへの参加に必要なすべてのポートが開かれていない場合があります。セットアップでの特定のポート要件に関して、ドメインおよび信頼に対するファイアウォールの設定方法の詳細については、Microsoft Support サイトを参照してください。

      4. [Save] をクリックして変更を保存します。
      ステップ 3   レルム内のディレクトリ サーバを設定します。
      1. ディレクトリ サーバを追加または編集するためのフォームを開くには、次のいずれかを実行します。
        • ディレクトリ サーバを追加するには、レルム名の上にマウスを置き [Add New Directory] をクリックします。
        • 既存のディレクトリ サーバを編集するには、サーバ名の上にマウスを置き [Edit Directory] をクリックします。
      2. ディレクトリ サーバのプロパティを入力します。 詳細については、ディレクトリのプロパティを参照してください。
        ヒント   

        プロパティを入力する場合は、必ず [Test Connection] リンクをクリックしてください。 これにより、これらのプロパティを使用してディレクトリに接続できるかどうかがテストされます。 接続に失敗したが、プロパティが確実に正しい場合は、デバイスとディレクトリ サーバ間にネットワーク パスがあることを確認します。 必要に応じて、CLI にログインして ping および traceroute などのコマンドを使用します。

      3. [Save] をクリックして変更を保存します。

        ディレクトリを追加するプロセスを繰り返して、レルム内で使用されているすべてのサーバを識別できます。

      ステップ 4   必要に応じてサーバ エントリを移動し、リストの先頭にプライマリ サーバが位置するように、ディレクトリ レルム内でプライオリティ順に並べます。

      サーバ エントリをドラッグ アンド ドロップするか、サーバ エントリにマウスを置くと表示される [Move Up] リンクまたは [Move Down] リンクを使用してサーバ エントリを移動できます。


      ディレクトリのプロパティ

      次の表で、ディレクトリ レルムに含まれるディレクトリのプロパティについて説明します。 指定されている場合、いくつかのプロパティは特定のディレクトリ タイプにのみ適用されます。 LDAP プロパティおよびその構文の詳細については、RFC 2253 を参照してください。

      表 1 ディレクトリのプロパティ

      プロパティ

      説明

      Directory Hostname/IP

      ディレクトリ サーバの DNS 名または IP アドレス。

      Port

      サーバとの通信に使用するポート番号。 デフォルトは 389 です。

      (注)     

      サポートされているポートは、ポート 389 のみです。このポートは、標準 LDAP(プレーン テキスト)接続を提供します。 ポート 636 でセキュア LDAP(LDAP over SSL)を使用することはできません。また、ポート 3268 で Active Directory グローバル カタログ サーバを指定することもできません。

      LDAP Login Name

      (LDAP のみ)。

      認証バインディングに使用される LDAP 階層内のディレクトリ オブジェクトの識別名。 LDAP ログイン名は、管理者がバインディングに使用する LDAP サーバ内のユーザ レコードを表します(そのユーザには管理者特権が不要です)。 たとえば、cn=Administrator,dc=example,dc=com となります。 この文字列では大文字と小文字が区別され、英数字を使用します。 特殊文字も使用できます。

      名前を指定しないと、システムはユーザおよびグループ情報のクエリーのために LDAP への匿名のバインドを試行します。

      AD Login Name

      (AD のみ)。

      たとえば、username@example.com など、AD サーバによる認証バインディングに使用されるユーザ名。

      Active Directory の場合、ユーザ特権の要件は、アイデンティティ ポリシーで許可する認証のタイプに基づいて異なります。 必ず、必要な特権を持つユーザを指定してください。
      • NTLM、基本:すべての有効なユーザ アカウントが可能です。
      • Kerberos:ユーザ アカウントには、「Service Principle Name への検証済み書き込み」権限が必要です。 SPN を修正する権限の委任に関する詳細については、Active Directory のマニュアルを参照してください。

      AD/LDAP Password

      AD/LDAP ログイン名で指定されたユーザのパスワード。 標準 LDAP の場合、匿名のバインドに関するパスワードを空白のままにしておくことができます。

      User Search Base

      LDAP ディレクトリで認証中の完全修飾ユーザ名に使用される、LDAP 検索ベースの識別名。 このフィールドは、LDAP と AD の両方のユーザ情報を検索またはクエリーする LDAP 階層内の位置も定義します。 たとえば、cn=users,dc=example,dc=com となります。 最大長は 128 文字です。 文字列では、大文字と小文字が区別されます。 スペースは使用できませんが、他の特殊文字は使用できます。

      ユーザ検索ベースを指定しなかった場合、ディレクトリ名のドメイン コンポーネント全体で構成される汎用的な識別名が作成されます。 たとえば、ディレクトリ名が ad.example.com の場合、構成される修飾子は dc=example,dc=com となります。 汎用名はネットワークで機能する場合と機能しない場合があるため、修飾子を明示的に入力する方法が最適です。 標準 LDAP の場合は、修飾子を常に明示的に入力することが必要になる場合があります。

      Group Search Base

      LDAP ディレクトリに対する認証のため、個別のグループでユーザ メンバーシップを検索するために使用する LDAP 検索ベースの識別名。 このフィールドは、LDAP と AD の両方のユーザ グループ情報を検索またはクエリーする LDAP 階層内の位置も定義します。 たとえば、ou=groups,dc=example,dc=com となります。 最大長は 128 文字です。 文字列では、大文字と小文字が区別されます。 スペースは使用できませんが、他の特殊文字は使用できます。

      グループ検索ベースを指定しなかった場合、ディレクトリ名のドメイン コンポーネント全体で構成される汎用的な識別名が作成されます。 たとえば、ディレクトリ名が ad.example.com の場合、構成される修飾子は dc=example,dc=com となります。 汎用名はネットワークで機能する場合と機能しない場合があるため、修飾子を明示的に入力する方法が最適です。

      (注)     

      ユーザとグループの検索ベースを同じ文字列にする必要はありませんが、同じ文字列にすることは可能です。

      Group Membership Attribute

      グループに属するすべてのユーザをリストする LDAP 属性。 次のいずれかを選択します。
      • [member]:Active Directory の通常のグループ属性。
      • [uniqueMember]:OpenLDAP の通常のグループ属性。
      • [Custom]:ディレクトリに UserInGroup などのカスタム グループ属性を作成した場合はこのオプションを選択し、表示されたフィールドに属性値を入力します。

      Test Connection link

      入力したプロパティが正常にディレクトリ サーバに接続されるかどうかをテストします。 接続に失敗した場合は、設定を確認してください。 正しいことが確実な場合は、デバイスとディレクトリ間にネットワーク パスが存在するか確認します。

      ナビゲーション パス
      • ディレクトリをレルムに追加するには、[Device] > [Directory Realm] を選択し、レルムの名前にマウスを置いて関連するコマンドを表示し、[Add New Directory] をクリックします。
      • ディレクトリを編集するには、[Device] > [Directory Realm] を選択し、ディレクトリ(レルム内)の名前にマウスを置いて関連するコマンドを表示し、[Edit Directory Configuration] をクリックします。

      ディレクトリ レルムまたはディレクトリの削除

      レルム内のディレクトリを削除したり、ディレクトリ レルム全体を削除することができます。 ただし、現在、ポリシーまたはポリシー オブジェクト内で使用されているか、またはシステム ユーザのグローバル レルムとして使用されている場合は、そのディレクトリ レルムを削除できません。

      手順
        ステップ 1   [Device] > [Directory Realm] を選択します。
        ステップ 2   次のいずれかを実行します。
        • ディレクトリ レルムからディレクトリ サーバを削除するには、レルム内のサーバ名にマウスを置いて [Delete Directory] をクリックします。
        • ディレクトリ レルムを削除するには、レルムの名前にマウスを置いて、[Delete Realm] をクリックします。

        アイデンティティ ポリシーの設定

        アイデンティティ ポリシーを使用して、ユーザ名およびユーザ グループ メンバーシップを含む、ユーザ ID に基づくポリシーをイネーブルにします。 ユーザが認証に失敗しても、アイデンティティ ポリシーがトラフィックをドロップまたはブロックすることはありません。

        代わりに、アイデンティティ ポリシーは、一致基準と認証アクションに従って、宛先への接続を試行する際に、ユーザに対してユーザ名/パスワードの提供を要求できます。 ユーザが認証に失敗した場合、そのユーザのトラフィックがアクセス ルールで評価され、それらのルールに基づいて許可または拒否されます。 ユーザが使用しているワークステーションの IP アドレスに対して、パッシブ認証マッピングを使用できない場合、マッチングのためにユーザの IP アドレスのみ使用されるため、作成したアイデンティティ ベースのルールは適用されません。

        したがって、UserA に関する ServerA へのトラフィックを許可し、ServerA に対するその他すべてのアクセスを許可しないアイデンティティ ベースのアクセス ルールを使用する場合があります。 UserA が正常に認証された場合はアクセス ルールが適用され、UserA は ServerA へのアクセスを許可されます。 UserA が認証に失敗し、パッシブ マッピングが存在しない場合は、アクセス ルールが適用されず、UserA は ServerA へのアクセスを許可されません。

        ヒント
        • アクティブ認証またはパッシブ認証により、トラフィック フローに関連付けられているユーザが既知であることを確認して、アイデンティティ ベースのアクセス ルールが正しく機能できるようにし、さらにレポートおよびイベント内にユーザ情報を提供できます。
        • アクティブ認証は HTTP トラフィックのみに適用されます。 他のタイプのトラフィックが、アクティブ認証を要求または許可するアイデンティティ ポリシーに適合した場合、アクティブ認証は試行されません。したがって、非 HTTP トラフィック用に [Do Not Require Authentication] ポリシーを作成する必要はありません。 同様に、たとえば、ICMP を唯一のサービス タイプとして指定するサービス グループを選択することによって、HTTP トラフィックを除外するトラフィック一致基準に [Get Identity via Active Authentication] アクションを適用するポリシーを作成することには意味がありません。
        • アイデンティティ ポリシーは、トラフィック一致基準に対する最初の一致に基づいて適用されます。 使用するディレクトリ レルムを含む目的のアクションが各トラフィック クラスに適用されるようにするため、一致基準が正確に定義されていることを確認します。
        はじめる前に

        レルムのアイデンティティ ポリシーを設定するには、その前にディレクトリ レルムを作成する必要があります。

        シングル デバイス モード のみ)。最初のディレクトリ レルムを作成すると、デフォルトのアイデンティティ ポリシーがそのレルムに自動的に作成されます。 必要に応じて、デフォルトのポリシーを編集または削除できます。

        手順
          ステップ 1   [Policies] > [Policies] を選択します。

          ポリシーはポリシー セットに編成され、各ポリシー セットは、ポリシーが別個の順序付きリストになっています。 ポリシー セットに関連したコマンドを参照するには、そのポリシー セットの名前にマウスを置きます。 個々のポリシーに関連したコマンドを参照するには、そのポリシーの名前にマウスを置きます。 これで目的のコマンドを選択できます。

          既存のポリシーについて処理する必要がある場合、フィルタ コントロールを使用すると、変更するポリシーを簡単に見つけることができます。

          ステップ 2   次のいずれかを実行します。
          • リストの先頭に新しいポリシーを作成するには、アイデンティティ ポリシー セット名の上にマウスを置き、[Add New Policy] をクリックします。
          • 新規ポリシーをリスト中に挿入するには、目的の位置の直下のアイデンティティ ポリシーの上にマウスを置き、[Add Above] をクリックします。
          • 既存のポリシーを編集するには、アイデンティティ ポリシー名の上にマウスを置き、[Edit Policy] をクリックします。
          • 類似した既存のポリシーを基に新規ポリシーを作成するには、アイデンティティ ポリシー名の上にマウスを置き、[Duplicate Policy] をクリックします。

          アイデンティティ ポリシーのプロパティとともに、フォームが開きます。 これらのプロパティの詳細については、アイデンティティ ポリシーのプロパティを参照してください。

          ステップ 3   [Source]、[Destination]、および [Service] フィールドを使用して、トラフィックの一致基準を定義します。

          基準に基づいてトラフィックを制限しない場合は、フィールドをブランクのままにします。

          ステップ 4   [Realm] フィールドのディレクトリ レルムを選択します。
          ステップ 5   必要に応じて、認証タイプとユーザ エージェントを含めて、一致するトラフィックに適用するアクションを定義します。
          アクションに関連する設定の詳細については、アイデンティティ ポリシーのプロパティを参照してください。 次のヒントを考慮してください。
          • 使用可能なオプションは、ディレクトリのタイプと、ユーザが AD エージェントを設定したかどうかに基づいて異なります。
          • アクティブ認証を許可するオプションである [Get Identity via Active Authentication] または [Get Identity Using AD Agent] のいずれかを選択し、アクティブ認証の質問に対して [Yes] を選択した場合は、アクティブ認証からユーザ エージェントを除外することができます。 たとえば、ソフトウェア アップデート アプリケーションなど、アクティブ認証プロンプトに応答できないエージェントを除外します。
          • アクティブ認証を持つ AD レルムの場合は、基本、NTLM、Kerberos または Advanced の各認証方式を選択できます。 サーバによってサポートされている方式を選択します。2 つ以上の方式をサポートする場合は、Advanced を選択します。
          ステップ 6   [Save Policy] をクリックして変更を保存します。
          ステップ 7   ポリシー セット内の優先順位に収まるように、必要に応じて [Policies] ページでポリシーを移動します。

          ポリシー セット内のポリシーは、最初に一致したものから順に適用されるため、限定的なトラフィック一致基準を持つポリシーは、同じトラフィックに適用され、汎用的な基準を持つポリシーよりも上に置く必要があります。

          ポリシーをドラッグ アンド ドロップしたり、ポリシーにマウスを移動すると表示される [Move Up]、[Move Down] 各リンクを使用することができます。


          アイデンティティ ポリシーのプロパティ

          ASA CX 上でアイデンティティ ポリシーを使用して、トラフィックのマッチングに関するユーザ認証要件を定義します。 アイデンティティ ポリシーによってトラフィックがブロックされることはありません。 その代わりに、トラフィック フローに関連付けられたユーザが既知になるように、ユーザが認証(ログイン)を求められるかどうかを決定します。 認証を要求することで、ユーザ ID に基づいてアクセス ポリシーを設定できるようになり、またユーザ ベースの使用状況情報をレポートに提供します。

          アイデンティティ ポリシーには、次のプロパティがあります。

          Policy Name

          ポリシーの名前。 この名前は、このポリシーと一致するトラフィックによって生成された認証イベントの Event Viewer に表示されます。したがって、イベント データの分析に役立つ名前を選択してください。

          Enable Policy:On/Off

          ポリシーがイネーブルかどうかを示します。 ポリシーをオフにすると、ポリシーを削除せずに一時的にディセーブルにできます。 ディセーブルに設定されたポリシーはトラフィックに適用されません。

          Traffic Matching Criteria

          ポリシーが適用されるトラフィックを特定するトラフィックの一致基準。 ポリシーと一致するためには、フローは指定したすべてのプロパティと一致する必要があります。つまり、プロパティの間には AND 関係があります。 条件に基づいてポリシーを制限しない場合は、デフォルトの [Any] を選択します。 考えられるすべてのトラフィック フローを照合するには、すべてのフィールドをデフォルトの [Any] のままにします。

          以下のすべての基準が使用されて、ポリシーが適用されるトラフィックが判別されます。
          • [Source]:ネットワーク グループのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、送信元条件を満たしていると見なされます。
          • [Destination]:ネットワーク グループのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、送信元条件を満たしていると見なされます。
          • [Service]:プロトコルとポートの組み合わせを定義するサービス グループのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、サービス条件を満たしていると見なされます。

          (注)  


          マルチ デバイス モード)。PRSMマルチ デバイス モード で使用する際には、送信元基準または宛先基準には、ASA で定義されているネットワーク オブジェクトまたはグループを使用し、サービス基準には、ASA サービス オブジェクトを使用することもできます。 ネットワーク グループ オブジェクトには 2 つのタイプがあります。1 つは ASA と ASA CX の両方で使用できます。もう 1 つは ASA CX でのみ使用でき、特に ASA CX ネットワーク グループと呼ばれます。


          項目の追加、編集、削除方法などの項目の選択方法、選択リストのフィルタリング方法、オブジェクトの作成または編集方法、オブジェクト内容の表示方法については、項目の選択を参照してください。

          Realm

          トラフィックの認証に使用されるディレクトリ レルム。 ユーザが認証を要求された場合、ユーザが提供するクレデンシャルの確認に、このレルムのサーバが使用されます。

          Action
          トラフィック フローの一致に必要な認証のタイプ。 オプションは、ディレクトリのタイプと、ユーザが AD エージェントを設定したかどうかに基づいて異なります。 使用可能な、次のいずれかのオプションを選択します。
          • [Get Identity Using AD Agent]:(AD エージェントが設定されている AD のみ)。AD エージェントからユーザと IP アドレスのパッシブなマッピングを取得した場合には、それを使用します。 [Do you want to use active authentication if AD agent cannot identify the user?] に対して [Yes] または [No] を選択します。 [Yes](デフォルト)を選択し、AD エージェントからユーザの IP アドレスのパッシブ マッピングが取得されなかった場合、システムは透過的に(NTLM、Kerberos のみ)またはユーザに認証を要求することによって、クライアントを通して ID の取得を試みます。 [No] を選択したが、パッシブ マッピングを入手できなかった場合は、ユーザの IP アドレスがユーザ名に関連付けられず、ID ベースのアクセス ルールがユーザのトラフィックに適用されません。
          • [Get Identity via Active Authentication]:(すべてのディレクトリ タイプ)。ユーザに対するパッシブ マッピングが存在する場合であっても、ID 情報を取得します。 NTLM または Kerberos を使用し、クライアントが正しく設定されている場合は、ID が透過的に取得されます。その他の場合には、ユーザが認証を要求されます。 認証が終わると、ユーザの IP アドレスはユーザを代理するものと考えられ、ユーザはそれ以降のすべての接続で再認証を求められません。 認証済みセッションの設定期間を超過した場合は、再認証が必要になります。
          • [Do Not Require Authentication]:(すべてのディレクトリ タイプ)。ユーザ ID を取得しません。 ユーザ トラフィックに、ID ベースのアクセス ルールは適用されません。

          (注)  


          アクティブ認証は HTTP トラフィックのみに適用されます。 他のタイプのトラフィックが、アクティブ認証を要求または許可するアイデンティティ ポリシーに適合した場合、アクティブ認証は試行されません。


          Authentication Type
          (AD のみ)。アクティブ認証を要求または許可するオプションを選択した場合、アクティブ認証中に使用する認証方法を選択します。 この設定は、AD レルムにのみ適用されます。LDAP レルムは、常に基本認証を使用します。 次の認証方法を使用できます。ユーザの AD サーバの設定に合わせて選択してください。
          • [NTLM](NT LAN Manager)。
          • [Kerberos]。
          • [Basic]。 これがデフォルトです。
          • [Advanced]。 このオプションを選択すると、ASA CX に、ユーザ エージェント(トラフィック フローの開始にユーザが使用しているアプリケーション)と Active Directory サーバ間で方式のネゴシエートを許可します。 ネゴシエーションの結果は、Kerberos、NTLM、基本の順に、共通にサポートされ、使用されている最も強力な方式の順になります。

          NTLM または Kerberos を許可する場合には、透過的なユーザ認証のイネーブル化で説明するように、クライアントは、透過的な認証を許可するようにブラウザを設定できます。 その他の場合、ユーザはディレクトリ ユーザ名とパスワードの入力を要求されます。

          Exclude User Agent

          アクティブ認証を要求または許可するオプションを選択する場合、ソフトウェア アップデート アプリケーションなど、認証要求に応答できないユーザ エージェント(アプリケーション)は除外できます。 認証を要求しないユーザ エージェントを識別する、ユーザ エージェント ポリシー オブジェクトを選択します。

          Tags

          この項目の識別に役立つ語とフレーズ。 たとえば、同じタグを複数の項目に割り当てると、検索での表示が容易になります。 タグでは、ユーザが選択した使用例、目的、またはその他の特性を識別できます。 これらのタグは、ユーザの目的にのみ対応しています。システムやポリシーの機能には影響しません。 複数のタグを入力(または選択)できます。

          Ticket ID

          ご使用のサポート システム(Remedy など)からのケース ID またはチケット ID。 ネットワーク サポート ケースに関連する変更を行う場合、トラッキング用にここにチケット ID を入力できます。 新しい ID を入力するか、保留中の変更に使用されている既存の ID から選択することができます。必要なだけの ID を指定します。 (すでにコミットされている変更で使用した ID は、このリストに表示されません)

          ナビゲーション パス
          • アイデンティティ ポリシーを作成するには、[Policies] > [Policies] を選択してから、アイデンティティ ポリシー セットの名前の上にマウスを置いて、[Add New Policy] をクリックします。
          • アイデンティティ ポリシーを編集するには、[Policies] > [Policies] を選択してから、ポリシーの上にマウスを置いて、[Edit Policy] をクリックします。

          アクティブ認証のイネーブル化

          アクティブ認証を使用する場合、次の要件に対応する必要があります。
          • ASA 上のトラフィック リダイレクション ポリシーに対するクラス マップには、たとえば cxsc fail-open auth-proxy など、認証プロキシ キーワードが含まれる必要があります。 PRSM を使用してリダイレクションを設定する場合、キーワードが自動的に含まれます。
          • アクティブ認証用に ASA が使用するデフォルト ポートは tcp/885 です。 ASA CLI を使用して、cxsc auth-proxy port number コマンドで別のポートを設定できます。 デフォルト以外のポートは、1024 よりも大きくする必要があります。 show run all cxsc コマンドを使用すると、現在設定されているポートを表示できます。
          • ASA とユーザ間にファイアウォールが存在する場合、これらのファイアウォールで認証ポートを開く必要があります。
          • ディレクトリ サーバ、ASA CX、およびクライアント間で、時刻設定が一致していることを確認します。 これらのデバイス間で時刻にずれがあると、ユーザ認証が成功しない場合があります。 「一致」とは、別のタイム ゾーンを使用できるが、たとえば、10 AM PST = 1 PM EST など、それらのゾーンに対して相対的に同じになっている必要があることを意味しています。
          • Kerberos 認証で Active Directory を使用する場合、ドメイン コントローラ、ASA CX、およびクライアントはすべて同じドメインに存在する必要があり、それ以外の場合には認証が失敗します。 NTLM および基本認証では、デバイスがドメイン内に存在している必要がありますが、同じドメイン内に存在しない場合でも認証が機能します。 認証が成功する可能性を向上させるには、認証方式として [Advanced] を選択することを検討してください。 これにより、システムは、クライアントとサーバの両方でサポートされる最も強力な方式をネゴシエートできるようになり、また 1 つが失敗した場合には別の方式を試行できるようになります。
          • Active Directory で Kerberos または NTLM を使用する場合、アクティブ認証要求に透過的に応答するようにブラウザを設定できます。 詳細については、透過的なユーザ認証のイネーブル化を参照してください。

          透過的なユーザ認証のイネーブル化

          [Get Identity via Active Authentication] または [Get Identity Using AD Agent] を [Yes] に設定してアクティブ認証を許可するようにレルムのアイデンティティ ポリシーを設定すると、ユーザ アイデンティティの取得に次の認証方式を使用できます。
          基本認証(Active Directory および LDAP)

          基本認証では、ユーザは常に自分のディレクトリ ユーザ名とパスワードを認証するように要求されます。 パスワードはクリア テキストで送信されます。 そのため、基本認証はセキュアな認証形式とは見なされません。

          基本はデフォルトの認証メカニズムであり、LDAP ディレクトリ レルムで使用可能な唯一のものです。

          統合 Windows 認証(Active Directory のみ)

          統合 Windows 認証では、ユーザがドメインにログインしてワークステーションを使用するという事実が利用されます。 ブラウザは、サーバにアクセスするとき、または ASA CX では ASA CX で保護されたネットワークにアクセスするときに、このドメイン ログインの使用を試行します。 パスワードは送信されません。 認証が成功すると、ユーザは透過的に認証されます。ユーザは、何らかの認証チャレンジが実行され、それが満たされたことを意識しません。

          ブラウザがドメイン ログイン クレデンシャルを使用して認証要求を満足できない場合、ユーザは、ユーザ名とパスワードの入力を要求されますが、これは基本認証と同じユーザ エクスペリエンスとなります。 したがって、統合 Windows 認証を設定すると、同じドメイン内のネットワークまたはサーバにアクセスするときに、ユーザはクレデンシャルを提供する必要がなくなります。

          トランスペアレント認証を可能にするためには、統合 Windows 認証をサポートするようにクライアント ブラウザを設定する必要があります。 次に、設定について説明します。

          認証ポリシーを設定するときには、ネットワーク内で使用する特定タイプの認証方式を選択します。 次のオプションがあります。
          • NTLM
          • Kerberos
          • [Advanced] では、Active Directory サーバとユーザ エージェントの両方で許可される最も強力な方式が使用されます。 (ユーザ エージェントは、通常、ユーザがトラフィック フローを開始する Web ブラウザです)。強度の順序は、Kerberos、NTLM、基本の順になります。

          次の各項では、一般に使用されるいくつかのブラウザに関して、統合 Windows 認証の一般的な要件と基本設定について説明します。ソフトウェア リリースによって技術が異なる可能性があるため、詳細については、ブラウザ(または他のユーザ エージェント)のヘルプを参照してください。

          トランスペアレント認証に対する要件

          トランスペアレント認証を実装するには、ユーザ ブラウザまたはユーザ エージェントを設定する必要があります。 これは、個別に実行することも、そのための設定を作成し、ソフトウェア配布ツールを使用してその設定をクライアント ワークステーションにプッシュすることもできます。 この作業をユーザが自分で実行する場合は、ネットワークで機能する具体的な設定パラメータを提供する必要があります。

          ブラウザまたはユーザ エージェントに関係なく、次の一般的な設定を実装する必要があります。
          • ユーザがネットワークへの接続に使用する ASA インターフェイスを [Trusted Sites] リストに追加します。 IP アドレス、または使用可能な場合には完全修飾ドメイン名(たとえば、asa_inside.example.com)を使用できます。 また、ワイルドカードまたはアドレスの一部を使用して、汎用化された信頼済みサイトを作成できます。 たとえば、典型的には *.example.com または単に example.com を使用してすべて内部サイトを網羅し、ネットワーク内のすべてのサイトを信頼することができます。 ASA インターフェイスの特定アドレスを追加する場合には、信頼済みサイトに複数のアドレスを追加して、ネットワークへのすべてのユーザ アクセス ポイントに対処することが必要な場合があります。
          • 統合 Windows 認証は、プロキシ サーバ経由で機能しません。 したがって、プロキシを使用しないか、またはプロキシを通過しないアドレスに ASA インターフェイスを追加する必要があります。 プロキシを使用する必要がある場合、ユーザは NTLM 方式または Kerberos 方式を使用する場合であっても認証を要求されます。

          ヒント


          トランスペアレント認証の設定は必須ではありませんが、エンド ユーザにとって便利です。 トランスペアレント認証を設定しなかった場合、ユーザはすべての認証方式に対するログイン チャレンジを提示されます。


          トランスペアレント認証用の Internet Explorer の設定

          Internet Explorer を NTLM および Kerberos の両方のトランスペアレント認証用に設定するには、次の手順を実行します。
          1. [Tools] > [Internet Options] を選択します。
          2. [Security] タブを選択し、[Local Intranet] ゾーンを選択した後、次の手順を実行します。
            1. [Sites] ボタンをクリックして、信頼済みサイトのリストを開きます。
            2. 少なくとも次のオプションの 1 つが選択されていることを確認します。
              • [Automatically detect intranet network]。 このオプションを選択すると、他のすべてのオプションがディセーブルになります。
              • [Include all sites that bypass the proxy]。
            3. [Advanced] をクリックして [Local Intranet Sites] ダイアログボックスを開き、次に信頼する URL を [Add Site] ボックスに貼り付けて [Add] をクリックします。 複数の URL が存在する場合は、このステップを繰り返します。 ワイルドカードを使用して、http://*.example.com のように URL の一部を指定するか、または単に *.example.com と指定します。 このダイアログボックスを閉じて、[Internet Options] ダイアログボックスに戻ります。
            4. [Local Intranet] が選択されたままの状態で、[Custom Level] をクリックして [Security Settings] ダイアログボックスを開きます。 [User Authentication] > [Logon] 設定を探して、[Automatic logon only in Intranet zone] を選択します。 [OK] をクリックします。
          3. [Internet Options] ダイアログボックスで [Connections] タブをクリックし、次に [LAN Settings] をクリックします。
            [Use a proxy server for your LAN] が選択されている場合、ASA インターフェイスがプロキシをバイパスすることを確認する必要があります。 必要に応じて、次のいずれかを実行します。
            • [Bypass proxy server for local addresses] を選択します。
            • [Advanced] をクリックして、アドレスを [Do not use proxy server for addresses beginning with] ボックスに入力します。 たとえば、*.example.com のようにワイルドカードを使用できます。

          トランスペアレント認証用の Firefox の設定

          Firefox には、NTLM 認証用と Kerberos 認証用に別のプロパティがあります。 次の手順では、両方の方式に対する設定を説明します。 両方の方式のいずれかをサポートしていない場合は、サポートしていない方式の手順をスキップしてください。
          1. [about:config] を開きます。 フィルタ バーを使用して、修正する必要のあるプリファレンスを検索します。
          2. NTLM をサポートするには、次のプリファレンスを修正します(network.automatic でフィルタリング)。
            • [network.automatic-ntlm-auth.trusted-uris]:プリファレンスをダブルクリックし、URL を入力して [OK] をクリックします。 カンマで区切って複数の URL を入力できます。プロトコルを含めるかどうかは任意です。 次に例を示します。 http://host.example.com, http://hostname, myhost.example.com URL の一部を使用することもできます。 Firefox は、ランダムに部分文字列と照合するのではなく、文字列の末尾と照合します。 したがって、ドメイン名のみ指定することにより、内部ネットワーク全体を包含することができます。 次に例を示します。 example.com
            • [network.automatic-ntlm-auth.allow-proxies]:値が、デフォルトの [true] であることを確認します。 値が [false] になっている場合は、ダブルクリックして変更します。
          3. Kerberos をサポートするには、次のプリファレンスを修正します(network.negotiate でフィルタリング)。
            • [network.negotiate-auth.allow-proxies]:値が、デフォルトの [true] であることを確認します。 値が [false] になっている場合は、ダブルクリックして変更します。
            • [network.negotiate-auth.delegation-uris]:ダブルクリックして http://,https:// と入力します。
            • [network.negotiate-auth.gsslib]:値が、デフォルトの空白であることを確認します。 このプリファレンスに値が存在する場合、その値を右クリックして、[Reset] を選択するか、またはダブルクリックして値を消去します。
            • [network.negotiate-auth.trusted-uris]:ダブルクリックして http://,https:// と入力します。
            • [network.negotiate-auth.using-native-gsslib]:値が、デフォルトの [true] であることを確認します。 値が [false] になっている場合は、ダブルクリックして変更します。
          4. HTTP プロキシ設定を確認します。 これは、[Tools] > [Options] を選択し、次に [Options] ダイアログボックスで [Network] タブをクリックすると見つかります。 [Connection] グループで、[Settings] ボタンをクリックします。
            • [No Proxy] が選択されている場合は、何も設定する必要がありません。
            • [Use System Proxy Settings] が選択されている場合、[about:config] 内の [network.proxy.no_proxies_on] プロパティを修正して、[network.automatic-ntlm-auth.trusted-uris] に含めた(または Kerberos のみ設定した場合には含めた可能性のある)信頼済み URI を追加する必要があります。
            • [Manual Proxy Configuration] が選択されている場合、これらの信頼済み URI を包含するように [No Proxy For] リストを更新します。
            • 他のオプションの 1 つが選択されている場合、これらの設定で使用するプロパティから同一の信頼済み URI が除外されていることを確認します。

          トランスペアレント認証用の Chrome の設定

          この項の作成時点で、Chrome は統合 Windows 認証をサポートしていません。 ユーザはユーザ名とパスワードの入力を要求されます。 使用しているバージョンにサポートが追加されているかどうかを確認するには、Chrome のマニュアルを参照してください。

          トランスペアレント認証用の Safari の設定

          この項の作成時点で、Safari は統合 Windows 認証をサポートしていません。 ユーザはユーザ名とパスワードの入力を要求されます。 使用しているバージョンにサポートが追加されているかどうかを確認するには、Safari のマニュアルを参照してください。

          Active Directory エージェントの識別

          Cisco Active Directory Agent は、それを使用するように設定されているすべてのデバイスに対して、ユーザと IP アドレスのマッピングを提供します。 標準(VPN 以外)ネットワーク上のネットワーク ドメインにログインするユーザに対して、AD エージェントは、AD サーバとの通信で、ログイン情報を取得し、またユーザと IP アドレスのマッピング テーブルを作成します。 この情報は、ASA などネットワーク内の他のデバイスによって補強でき、VPN および直接の送信元から取得されたマッピングを提供することができます。 AD エージェントから取得された ID マッピングは、パッシブ マッピングと見なされます。

          ASA および ASA CX デバイスの両方が同じ AD エージェント設定を使用して、アイデンティティ対応ファイアウォール サービスが可能になります。


          ヒント


          AD エージェントの設定はオプションです。 パッシブ マッピングをサポートする場合にのみ設定します。 パッシブ マッピングをサポートしない場合は、アイデンティティ ポリシーでアクティブ認証を使用する必要があります。そうしない場合、アクセス コントロールにユーザ名を使用できず、イベントおよびレポートにユーザ情報が含まれません。


          はじめる前に

          AD エージェントは、ネットワーク内にインストールする必要がある独立したソフトウェアです。 Active Directory サーバ、およびそのクライアントとなっているネットワーク デバイスと連携するよう、これを設定する必要があります。 この作業を完了する前に、AD エージェント ソフトウェアをインストールして設定します。

          AD エージェント ソフトウェアを http:/​/​www.cisco.com/​go/​asa から入手します。 AD エージェントのセットアップと設定の詳細については、次の URL にある『Installation and Setup Guide for the Active Directory Agent』を参照してください。http:/​/​www.cisco.com/​en/​US/​products/​ps6120/​prod_​installation_​guides_​list.html

          ASA CX デバイスをクライアントとして追加する必要があります。追加は、この手順を実行する前でも、後でもできます。 AD エージェント上の ASA CX クライアントに対して設定された RADIUS 共有秘密と、ここで設定する共有秘密は、同じにする必要があることに注意してください。 AD エージェント上にクライアントを作成するコマンドは、次のようになります。

          adacfg client create -n client-nickname -ip mgmt_IP -secret RADIUS_secret
          それぞれの説明は次のとおりです。
          • client_nickname は、AD エージェントが ASA CX クライアントを参照するために使用する名前です。
          • mgmt_IP は、ASA CX 管理インターフェイスの IP アドレス、またはそのアドレスが含まれるサブネットです(10.100.10.1 または 10.100.10.0/24 など)。
          • RADIUS_secret は、ASA CX でも設定する RADIUS 共有秘密です。 これによって、ASA CX と AD エージェントの通信が暗号化され、保護されます。
          設定の確認またはトラブルシューティングには、次の AD エージェント コマンドが役に立ちます。
          • adacfg dc list。AD エージェントと AD サーバの接続を確認します。
          • adacfg cache list。エージェントがユーザと IP のマッピングを取得していることを確認します。
          • adacfg client list。AD エージェントが現在サービスを行っているクライアントのリストを表示します。
          手順
            ステップ 1   [Device] > [AD Agent] を選択します。
            ステップ 2   次の情報を入力します。
            • [Hostname or IP]:AD エージェント サーバの DNS 名または IP アドレス。
            • [Password]:このクライアント デバイスで使用するために、AD エージェント上に設定される RADIUS 共有秘密。
            ステップ 3   [Test] をクリックして、提供された情報を使用して AD エージェントに接続できるかどうか確認します。

            接続に失敗した場合は、設定を確認してください。 正しいことが確実な場合は、デバイスと AD エージェント間にネットワーク パスが存在するか確認します。

            マルチ デバイス モード)。すべての管理対象 ASA CX と AD エージェント間の接続を確認します。

            ステップ 4   [Save] をクリックして変更を保存します。

            次の作業

            AD エージェント マッピングは、AD エージェントのクライアントにもなっている AD サーバを含むレルムに対するアイデンティティ ポリシー内で、パッシブ マッピングを許可する場合のみ使用されます。 したがって、[Get Identity Using AD Agent] を指定したことを確認するため、アイデンティティ ポリシーを確認する必要があります。 ポリシーで [Get Identity via Active Authentication] が使用されている場合、パッシブ マッピングは使用されません。

            認証設定の指定

            認証タイムアウトを設定して、失敗した認証の処理方法、およびユーザが認証済みと見なされる時間の長さを制御できます。 これらの設定は、ユーザのアイデンティティ ポリシーが機能する方法に関連します。

            手順
              ステップ 1   [Device] > [Authentication] を選択します。
              ステップ 2   必要に応じて以下のオプションを変更します。
              • [Authenticated session duration]:ユーザと IP アドレスのマッピングが維持される時間。 マッピングは、この経過時間に達すると削除され、ユーザのアイデンティティ ポリシー設定に基づいて新しいマッピングが取得されます。 たとえば、ユーザの IP アドレスと一致するレルムに対してアクティブ認証を使用する場合、ユーザは次回の接続試行中に認証されます。 しかし、ユーザのポリシーでパッシブ マッピングが使用され、アクティブ認証が許可されない場合、ユーザは認証されません。

              • [Failed authentication timeout]:アクティブ認証中にユーザが正常に認証されず、最大認証試行回数を超過した場合、ユーザの IP アドレスが認証失敗したと見なされます。 このタイムアウト値により、その IP アドレスのユーザがもう一度認証を要求されるまでの時間が分単位で定義されます。 この時間の間、その IP アドレスからのトラフィックは IP アドレスにのみ基づいて評価され、ユーザまたはユーザ グループ ベースのルールはトラフィックに適用されません。 したがって、この失敗したタイムアウト期間中は、ユーザが正常に認証された場合に許可されるリソースへのアクセスを禁止される可能性があります。

              • [Maximum authentication attempts]:ASA CX から認証を要求された場合に、ユーザが認証を再試行できる回数。 試行回数は、ユーザが正常に認証されるとリセットされます。 ユーザは、認証に失敗すると、失敗した認証のタイムアウトが経過するまで、再び認証を要求されません。

              • [Group refresh interval]:ユーザ グループ メンバーシップがディレクトリ サーバから更新される頻度(時間数)。 デフォルトは 24 時間ごと(1 日に 1 回)です。 ユーザをグループに追加した場合、そのユーザは次回の更新までグループのメンバとして認識されません。 グループのメンバーシップは、ポリシー内でそのグループを使用する場合にのみ取得されます。

              ステップ 3   [Save] をクリックして変更を保存します。