ASA CX および Cisco Prime Security Manager 9.3 ユーザ ガイド
認証サービスとアイデンティティ サービスの管理
認証サービスとアイデンティティ サービスの管理

目次

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

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

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

認証は、ユーザのアイデンティティを確認する動作です。 ユーザの ID をパッシブまたはアクティブに取得できます。

パッシブ認証では、ユーザ ID は CDA または AD エージェント アプリケーションによって収集されたユーザ ID への IP アドレスのマッピングをチェックすることによって取得されます。 ユーザにクレデンシャルを入力するよう求めるプロンプトが表示されないため、この認証はパッシブです。

アクティブ認証を使用すると、HTTP または復号化された HTTPS トラフィック フローがユーザ ID のマッピングがない ASA CX の IP アドレスから送られてきたときに、ネットワークに設定されたディレクトリを使用して、トラフィック フローを開始したユーザを認証するかどうかを決定できます。 ユーザが正常に認証された場合、IP アドレスは、認証されたユーザのアイデンティティがあると見なされます。

パッシブまたはアクティブ ユーザ マッピングがあるトラフィックでは、アイデンティティ ベースのアクセス ポリシーを適用し、スタティック IP アドレス ベースのポリシーによって制御するのではなく、リソースにアクセスしようとしているユーザに基づいてネットワーク アクセスを制御できます。

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

  • ディレクトリ レルム:認証サービスを提供するディレクトリ レルムを定義する必要があります。 レルムには、Active Directory や OpenLDAP など、ネットワークに対するユーザ名およびユーザ グループ メンバーシップを定義する 1 つ以上のディレクトリ サーバが含まれています。 アイデンティティ ポリシーを設定する場合は、認証を提供するディレクトリ レルムを選択する必要があります。

  • アイデンティティ ポリシー:アイデンティティ ポリシーを使用すると、ユーザ名およびユーザ グループ メンバーシップを含む、ユーザ アイデンティティに基づくポリシーが可能になります。 ユーザが認証に失敗しても、アイデンティティ ポリシーがトラフィックをドロップまたはブロックすることはありません。 代わりに、ユーザ情報を収集して、アクセス ポリシーがユーザ ID に基づいてトラフィックを照合できるようにし、またダッシュボードとイベントにユーザ ID 情報が含まれるようにします。

  • 認証設定:認証設定では、認証マッピングおよびプロンプトの管理方法が制御されます。 たとえば、ユーザに再認証を要求するまでの、ユーザ名と IP アドレスのマッピングが有効となっている期間を定義できます。 これらの設定にはシステム デフォルトが存在するため、これらの設定を調整する必要があるのは、異なる設定が必要な場合だけです。

  • アイデンティティ ポリシー オブジェクト:アクセス制御を定義する特定のユーザ名またはユーザ グループ名を定義します。 また、オブジェクトから名前を選択して除外することもできます。 たとえば、ユーザ グループ Eng を含むオブジェクトを定義し、そのグループのメンバであるユーザ Guest1 と Guest2 を除外することができます。

  • アクセス ポリシー:アイデンティティ ポリシー オブジェクトを送信元フィールドの一部としてアクセス ポリシーに指定すると、ユーザ アイデンティティに基づいて宛先リソースへのアクセスが制御されます。

  • CDA または Active Directory エージェント:(任意)。ネットワークに CDA または AD エージェントをインストールすると、ユーザがデバイス経由でトラフィックを渡す前に、そのユーザがネットワークにログインした時点でユーザ アイデンティティ情報を収集することができます。 このタイプのアイデンティティは、パッシブ アイデンティティ マッピングと見なされます。 この情報を収集することにより、直接認証を行うようユーザに強制することなく、アイデンティティ ベースのアクセス制御をイネーブルにできます。

  • アイデンティティ ベースのダッシュボード:多くのダッシュボードにアイデンティティ情報(利用できる場合)が含まれているため、ユーザのアイデンティティに基づいてネットワークのトラフィックを分析できます。 ユーザ ダッシュボードは、ユーザ ベースのネットワーク使用状況情報を提供するよう特別に設計されています。 これらのダッシュボードを使用すると、ネットワークで許容される使用基準を満たしていないケースを識別できます。

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

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

  • Microsoft Active Directory:次の AD サーバを使用できます。 Active Directory サーバ上の LDAP 署名を無効にすることを確認します。
    • Windows Server 2008 R2

    • Windows Server 2003 R2

    AD を使用している場合は、次の認証方式をアイデンティティ ポリシーで使用できます。また、ネゴシエーションにより、サポートされる最も強力な方式を選択することもできます。
    • NTLM(すべての Windows プラットフォーム)

    • Kerberos(Windows XP のみ)

    • 基本と形式(制限なし)。

  • OpenLDAP:バージョン 2.4.21 以降。 基本と形式の認証方式を使用できます。

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

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

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

  • アクティブ:ユーザが CX デバイスによって直接認証されました。 アクティブ認証は HTTP または復号化されない HTTPS トラフィックのみに適用されます。 他のタイプのトラフィックが、アクティブ認証を要求または許可するアイデンティティ ポリシーに適合した場合、アクティブ認証は試行されません。

  • パッシブ:ユーザと IP アドレスのマッピングが Context Directory Agent(CDA)または Active Directory(AD)エージェントから受信されました。 このタイプのアイデンティティは、ユーザが送信したトラフィックのタイプに関係なく使用できます。

  • 不明:ユーザと IP のマッピングが存在しません。 たとえば、ユーザがアクティブに CX デバイスへの認証を試みたが、認証に失敗した場合などです。 実行中の認証に失敗したユーザはユーザ名の領域でユーザのダッシュボードにユーザ名がゲストのゲスト アクセスがイネーブルになっていない場合、\匿名表されます。 認証の必要がないためマッピングをもたないユーザは、IP アドレスで表示されます。

  • ゲスト:ユーザが、実行中の認証失敗し、アイデンティティ ポリシーのゲスト アクセスが可能になりました。 その担当者のユーザ名はダッシュボードおよびイベントのゲストです。

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

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

  • 認証プロンプトには、ディレクトリ レルムの名前と ASA CX 管理 IP アドレスが含まれる。 この情報を含んでいる認証要求は有効な要求であり、これらに応答する必要があることを、ユーザに必ず理解してもらいます。

  • Active Directory を使用した NTLM または Kerberos 認証を使用する場合は、ユーザは次のいずれかの形式で自分の名前を入力することができます。username、username@domain、DOMAIN\username。 たとえば、user1、user1@example.com、ENG\user1。

  • 基本認証を使用する場合、ユーザは、username@domain 形式(たとえば、user1@example.com)で自分の名前を指定する必要があります。

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

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

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

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

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

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

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

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

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

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

    (注)     

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

    ステップ 5   アクティブ認証を使用していて、HTTPS 要求の認証を強制する場合は、認証する送信元からのセキュアなトラフィックを復号化するように復号化ポリシーを設定します。

    復号ポリシーは [Decrypt Everything] アクションを適用する必要があります。

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

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

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

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

    ステップ 8   ダッシュボードおよびイベント内のアイデンティティ情報を使用して、ネットワーク トラフィックを分析します。

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

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


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

    ディレクトリ レルムは、ディレクトリ サーバの名前付きリストです。 Active Directory (AD) に、レルムに AD ドメインと同じです。 LDAP に、レルムは LDAP サーバと冗長サーバの同じトップ レベルの Distinguished Name (DN) により、つまり、すべてのサーバです。

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

    • アイデンティティ ポリシー。ユーザが認証する必要のあるディレクトリを識別します。 アクセス ポリシー内のレルムで定義された ID を使用するために、各レルムに対してアイデンティティ ポリシーが存在する必要があります。

    • [Users] ページ。Web インターフェイスへのアクセスを付与するリモート ユーザを含むディレクトリを識別します。

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

    [Directory Realm] ページには、次の項目が含まれています。

    I want to

    次のコマンドが含まれます。

    • [Add Realm]:新しいディレクトリ レルムを追加します。 名前、説明、およびディレクトリ タイプの入力を求められます。 レルム名は、Realm\username 形式でユーザ名とともにダッシュボードに表示されます。 したがって、ユーザ名の文字列が予期した NetBIOS ドメイン名を含むようにするため、レルム名に NetBIOS ドメイン名を使用する場合があります。

    List of directory realms and their directory servers

    すべてのディレクトリ レルムがリストに表示され、各レルム内には、レルムに含まれているディレクトリ サーバの順序付きリストがあります。 使用不可にならない限り、リストに表示されている最初のサーバが常に使用されます。使用不可になった場合、応答を受信するまで、リストに表示されている次のサーバの使用が試行されます。

    マルチ AD 領域が存在する場合、レルムの 1 の NTLM、 Kerberos、高度な実行中の認証を使用するアイデンティティ ポリシーを定義できます。 デバイスは、プライマリ・レルムと見なされるその AD のレルムにバインドします。 すべてのレルムとの基本使用され、実行中の認証、またはパッシブ認証を形作る、できます。

    ディレクトリ レルムまたはサーバに関連するコマンドを表示するには、ディレクトリ レルムのヘッダーまたはディレクトリ サーバの行にマウスを置きます。 使用可能なコマンドは次のとおりです。

    ディレクトリ レルムには次のコマンドがあります。
    • [Add New Directory]:新しいディレクトリ サーバをレルムに追加します。 サーバは、最初のエントリとしてレルムの先頭に追加されます。 ディレクトリを追加したら、変更をコミットする前にそのポリシーを目的の位置に移動します。

    • [Delete Realm]:レルムを削除します。 ポリシーやポリシー オブジェクト、またはシステム ユーザのグローバル レルムとしてレルムが使用されている場合、レルムを削除できます。

    • [Edit Real]:レルムのプロパティを編集します。

    ディレクトリ サーバには次のコマンドがあります。
    • [Delete Directory]:ディレクトリ サーバを削除します。

    • [Edit Directory]:ディレクトリ サーバのプロパティを編集します。

    • [Move Up]、[Move Down]:ディレクトリ サーバを目的の位置まで移動します。 この上下移動コマンドでは、ディレクトリが 1 行ずつ移動されます。 ディレクトリをクリックし、目的の位置までドラッグすることもできます。

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


    ヒント


    AD または OpenLDAP の管理者からこれらの設定の値を取得します。


    ディレクトリ レルムは、ディレクトリ サーバの名前付きリストです。 Active Directory (AD) に、レルムに AD ドメインと同じです。 LDAP に、レルムは LDAP サーバと冗長サーバの同じトップ レベルの Distinguished Name (DN) により、つまり、すべてのサーバです。

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


    ヒント


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


    手順
      ステップ 1   [Components] > [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] のいずれか。

          他の管理製品と統合するためのシングル サインオン(SSO)ディレクトリを作成する場合は [SSO] を選択します。 SSO レルムの作成の詳細については、SSO ディレクトリおよびユーザの設定を参照してください。

        • [Primary Domain]:(AD のみ)デバイスが参加する必要のある、完全修飾 Active Directory ドメイン名。 たとえば、example.com のように指定します。 ドメイン間に信頼関係が存在する場合でも、各ドメインに対して他のレルムを作成します。

        • [Join Username]、[Join Password]:(AD のみ)デバイスが AD ドメインに参加する際、またはドメインを脱退する際に使用する Active Directory の sAMAccountName または User Principal Name。 これらのクレデンシャルには、デバイスをドメインに参加または脱退させるための AD 内の権限が必要です。

      3. (AD のみ)AD レルムにデバイスに参加できることを確認するために、[Test Domain Join] リンクをクリックします。

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

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

        • 既存のディレクトリ サーバを編集するには、サーバ名の上にマウスを置き、[Edit Directory] をクリックします。

      2. ディレクトリ サーバのプロパティを入力します。 詳細については、ディレクトリのプロパティを参照してください。
        ヒント   

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

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

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

      ステップ 4   必要に応じて、リストの上部をプライマリ サーバとして、ディレクトリ レルム内の優先順位の順になるようにサーバ エントリを移動します。

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


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


      ヒント


      AD または OpenLDAP の管理者からこれらの設定の値を取得します。


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

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

      プロパティ

      説明

      Directory Hostname

      ディレクトリ サーバの 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 となります。 この文字列では大文字と小文字が区別され、英数字を使用します。 特殊文字も使用できます。

      AD Login Name

      (AD のみ)。

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

      Active Directory の場合、ユーザ特権の要件は、アイデンティティ ポリシーで許可する認証のタイプに基づいて異なります。 必ず、必要な特権を持つユーザを指定してください。
      • NTLM、Basic:すべての有効なユーザ アカウントが可能です。

      • Kerberos:ユーザ アカウントには、「Service Principle Name への検証済み書き込み」権限が必要です。 SPN を修正する権限の委任に関する詳細については、Active Directory のマニュアルを参照してください。

      AD/LDAP Password

      AD/LDAP ログイン名で指定されたユーザのパスワード。

      User Search Base

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

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

      詳細については、ディレクトリ検索ベースの決定を参照してください。

      Group Search Base

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

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

      詳細については、ディレクトリ検索ベースの決定を参照してください。

      (注)     

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

      Group Attribute

      グループに属するすべてのユーザをリストする LDAP 属性。 次のいずれかを選択します。
      • [member]:Active Directory の通常のグループ属性。

      • [uniqueMember]:OpenLDAP の通常のグループ属性。

      • [Custom]:ディレクトリに UserInGroup などのカスタム グループ属性を作成した場合はこのオプションを選択し、表示されたフィールドに属性値を入力します。

      [Test Connection] リンク

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

      ディレクトリ検索ベースの決定

      ディレクトリのプロパティを設定する場合は、ユーザーとグループの検索ベースを指定する必要があります。 これらのベースは、ディレクトリ サーバで定義され、ネットワークとネットワークによって異なります。 動作 ID ポリシーの正しいベースを入力します。 ベースが誤っている場合、システムはユーザまたはグループ名を指示することができないので、 ID ベースのポリシーが操作不可能です。


      ヒント


      正しいベースを取得するには、ディレクトリ・サーバを担当する管理者に問い合わせてください。


      Active Directory には、ドメイン管理者として Active Directory サーバにログインし、コマンド プロンプトで dsquery のコマンドを使用して、正しいベースを指示できます。次のようにベースを指示するには:

      User Search Base

      Base Distinguished Name を指示できます。既知のユーザ名(部分的または完全な) dsquery user コマンドを入力します。 たとえば、次のコマンドは、「John」から始まるすべてのユーザの情報を返すために名前の一部 John* 「」を使用する。

      C:\Users\Administrator>dsquery user -name “Jphn*” 
      “CN=John Doe,CN=Users,DC=csc-lab,DC=example,DC=com”
      
      

      ユーザ検索ベースが「DC=csc-lab、 DC=example、 DC=com。」

      グループ検索ベース(Group Search Base)

      ベース識別名を指定したり、既知のグループ名と dsquery group コマンドを入力します。 たとえば、次のコマンドは、識別名を返すには、グループ名の従業員を使用:

      C:\>dsquery group -name “Employees” 
      “CN=Employees,CN=Users,DC=csc-lab,DC=example,DC=com”
      
      

      グループ検索ベースが「DC=csc-lab、 DC=example、 DC=com。」

      編集する Active Directory 構造を参照するプログラムを ADSI Edit を使用できます(開始 > は adsiedit.msc を > 実行します)。 ADSI Edit で編集、オブジェクトを、組織ユニット (OU) など、グループ、またはユーザ右クリックし、識別名を表示するには、[プロパティ]を選択します。 ベースとして DC 値の文字列をコピーできます。

      正しいベースがあることを確認するには:

      1. 接続を確認するには、ディレクトリのプロパティの[Test Connection]ボタンをクリックします。 問題を解決し、ディレクトリのプロパティを保存します。

      2. デバイスに対する変更をコミットします。

      3. [[Components] > [Objects]私は CX の特定のオブジェクト > を追加したい。 ディレクトリから既知のユーザとグループ名を追加してください。 ディレクトリを含むレルムに一致するユーザおよびグループに対して入力時に自動完全な推奨事項が表示されます。 これらの推奨事項がドロップダウン リストに表示された場合、システムはディレクトリを正常に呼ばれていました。 ユーザが入力した文字列がユーザまたはグループ名で表示されることを推奨事項が反映されない場合、確かめたら対応する検索ベースを修正する必要があります。

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

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

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

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

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

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

        したがって、サーバ A へのユーザ A のトラフィックを許可し、サーバ A へのその他のアクセスをすべて拒否するアイデンティティ ベースのアクセス ルールが可能です。 ユーザ A が認証に成功した場合、アクセス ルールが適用され、ユーザ A はサーバ A にアクセスできます。 ユーザ A が認証に失敗すると、パッシブなマッピングがない場合、アクセス ルールは適用されず、ユーザ A はサーバ A へのアクセスが許可されません。

        ヒント
        • アクティブまたはパッシブ認証によって、トラフィック フローに関連付けられたユーザを認識し、アイデンティティ ベースのアクセス ルールを正しく機能させ、ダッシュボードおよびイベントでユーザ情報が提供されるようにできます。

        • アクティブ認証は HTTP または復号化されない HTTPS トラフィックのみに適用されます。 他のタイプのトラフィックが、アクティブ認証を要求または許可するアイデンティティ ポリシーに適合した場合、アクティブ認証は試行されません。したがって、非 HTTP/HTTPS トラフィック用に Do Not Require Authentication ポリシーを作成する必要はありません。 同様に、たとえば、ICMP を唯一のサービス タイプとして指定するサービス グループを選択することによって、HTTP トラフィックを除外するトラフィック一致基準に [Get Identity via Active Authentication] アクションを適用するポリシーを作成することには意味がありません。

        • トラフィック一致基準の最初の一致に基づいて、アイデンティティ ポリシーが適用されます。 使用するディレクトリ レルムを含む目的のアクションが各トラフィック クラスに適用されるようにするため、一致基準が正確に定義されていることを確認します。

        はじめる前に

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

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

        手順
          ステップ 1   Configurations > Policies/Settings を選択し、[Identity Policies][Identity Policies]タブを開きます。

          (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

          ステップ 2   次のいずれかを実行します。
          • 新しいポリシーを追加するには、[Add Policy] ボタンの 1 つを使用します。 ポリシー セットを選択した場合、セットの上部または下部にポリシーを追加できます。 ポリシーを選択した場合、その上または下に新しいポリシーを追加できます。
          • 既存のポリシーを編集するには、ポリシーを選択し、[Edit Policy] ボタンをクリックします。
          • 類似した既存のポリシーを基に新規ポリシーを作成するには、ポリシーを選択し、[Duplicate Policy] ボタンをクリックします。

          ポリシーのプロパティとともに、フォームが開きます。

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

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

          ステップ 4   [Realm] フィールドで、ディレクトリ レルムを選択します。
          ステップ 5   必要に応じて、認証タイプとユーザ エージェントを含めて、一致するトラフィックに適用するアクションを定義します。
          アクションに関連する設定の詳細については、アイデンティティ ポリシーのプロパティを参照してください。 次のヒントを考慮してください。
          • 使用可能なオプションは、ディレクトリのタイプと、ユーザが CDA または AD エージェントを設定したかどうかに基づいて異なります。

          • アクティブ認証を許可するオプションである [Get Identity via Active Authentication] または [Get Identity Using AD Agent] のいずれかを選択し、アクティブ認証の質問に対して [Yes] を選択した場合は、アクティブ認証からユーザ エージェントを除外することができます。 ソフトウェア アップデート アプリケーションなど、アクティブ認証プロンプトに応答できないエージェントを除外します。

          • 実行中の認証によって、認証方式を選択: 基本や形式(すべてのタイプ)、プラス NTLM、 Kerberos、進められる(AD だけ)。 サーバおよびクライアントがサポートする方式を選択してください"; Kerberos、 NTLM および基礎をサポートする場合は[Advanced]を選択します。 マルチ AD 領域が存在する場合、または単一 AD のレルムのみを進められて NTLM、 Kerberos を使用して; 他の AD レルムはすべて Basic または形式を使用する必要があります。

            (注)     

            Select 形式(エンド ユーザ通知ページのユーザに対して実行する認証ログイン形式をカスタマイズできる選択[Administration] > [End User Notification]します)。

          ステップ 6   親デバイスの特定のインターフェイス上のトラフィックにのみポリシーを制限する場合は、そのインターフェイスを特定する [Source Interface Role] または [Destination Interface Role]、あるいはその両方を選択します。

          デフォルトでは、デバイス上のあらゆるインターフェイス間のトラフィックにポリシーが適用されます。 デバイスに存在しないインターフェイスを選択すると、トラフィックにはポリシーが適用されません。

          ステップ 7   [Save Policy] をクリックします。
          ステップ 8   優先順位に収まるように、必要に応じてポリシーを移動します。

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

          ポリシー セットまたはルールを移動するには、[Move] アイコン(左端の垂直な両方向矢印)をクリックしたまま、挿入位置のすぐ前のポリシーまでドラッグします。 単にシーケンス番号を編集し、目的の値に変更することもできます。


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

          CX デバイス上でアイデンティティ ポリシーを使用して、トラフィックのマッチングに関するユーザ認証要件を定義します。 アイデンティティ ポリシーによってトラフィックがブロックされることはありません。 代わりに、トラフィック フローの送信元 IP アドレスについて、ユーザ ID を取得するかどうかを決定します。

          認証を必須にすることで、ユーザ ID に基づくアクセス ポリシーを設定したり、ダッシュボードでユーザ ベースの使用情報を提供したりできるようになります。

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

          Policy Name

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

          Enable Policy:On/Off

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

          Traffic Matching Criteria

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

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

          • [Destination]:ネットワーク グループのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、送信元条件を満たしていると見なされます。

          • [Service]:プロトコルとポートの組み合わせを定義するサービス グループのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、サービス条件を満たしていると見なされます。


          (注)  


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


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

          Realm

          トラフィックの認証に使用されるディレクトリ レルム。 ユーザが認証を求めるプロンプトが表示され、ユーザから提供された資格情報を確認するために、このレルムのサーバが使用されます。

          Action

          トラフィック フローの照合のために必要な認証のタイプ。 オプションは、ディレクトリのタイプと、ユーザが CDA または AD エージェントを設定したかどうかに基づいて異なります。 可用性に基づいてこれらのオプションの 1 つを選択します。

          Get Identity Using AD Agent

          (CDA または AD エージェントが設定されている AD のみ)。CDA または AD エージェントからユーザと IP アドレスのパッシブなマッピングを取得した場合には、それを使用します。

          [Do you want to use active authentication if AD agent cannot identify the user?] に対して [Yes] または [No] を選択します。 [Yes](デフォルト)を選択し、CDA または AD エージェントからユーザの IP アドレスのパッシブ マッピングが取得されなかった場合、システムは透過的に(NTLM、Kerberos のみ)またはユーザに認証を要求することによって、クライアントを通して ID の取得を試みます。

          [No] を選択したが、パッシブ マッピングを入手できなかった場合は、ユーザの IP アドレスがユーザ名に関連付けられず、ID ベースのアクセス ルールがユーザのトラフィックに適用されません。

          Get Identity via Active Authentication

          (すべてのディレクトリ タイプ)。ユーザに対するパッシブ マッピングが存在する場合であっても、ID 情報を取得します。 NTLM または Kerberos を使用し、クライアントが正しく設定されている場合は、ID が透過的に取得されます。その他の場合には、ユーザが認証を要求されます。

          認証が終わると、ユーザの IP アドレスはユーザを代理するものと考えられ、ユーザはそれ以降のすべての接続で再認証を求められません。 認証済みセッションの設定期間を超過した場合は、再認証が必要になります。

          Do Not Require Authentication

          (設定された CDA または AD エージェントと AD を除くすべてのディレクトリ タイプ) ユーザの ID を取得しないでください。 ユーザ トラフィックに、ID ベースのアクセス ルールは適用されません。


          (注)  


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


          実行中の認証がユーザを特定できなかった場合は、ゲスト アクセスを使用しますか。 はい/いいえ

          実行中の認証を必要とするか、または許可するオプションを選択した場合、実行中の認証ゲスト ユーザとして分類された失敗したユーザかどうかを選択します。 これらのユーザは、ゲスト ユーザの特定のオブジェクトに一致します。 ユーザのカテゴリに書き込みアクセス ポリシーの特別な処理を提供できます。 これらのユーザは、ゲスト ユーザ名の下にダッシュボードおよびイベントに表示されます。

          [No]を選択すると、実行中の証明書マップ未知ユーザの特定のオブジェクトに失敗したユーザ。 未知ユーザに対する書き込みアクセス ポリシーもできます。

          Authentication Type

          (AD のみ)。アクティブ認証を要求または許可するオプションを選択した場合、アクティブ認証中に使用する認証方法を選択します。 次の認証方式を使用できます。AD サーバで設定されている方式を選択します。

          • NTLM (NT LAN Manager、 AD 領域だけが )。 すべての Windows プラットフォームでサポートされます。

          • Kerberos (AD のレルムのみ)。 Windows XP に対してのみサポートされます。

          • [Basic]。 これはデフォルトです。 すべてのプラットフォームでサポートされます。

          • 高度(AD のレルムのみ)。 デバイスがユーザ エージェント(トラフィック フローを開始するためにユーザが使用するアプリケーション)と Active Directory サーバ間の方式をネゴシエートするこのオプションを選択します。 ネゴシエーションの結果は、Kerberos、NTLM、基本の順に、共通にサポートされ、使用されている最も強力な方式の順になります。

          • フォーム これは、ユーザがログイン ブラウザ ページに表示される基本認証タイプです。 エンド ユーザ通知ページの実行中の認証形式をカスタマイズできます(選択[Administration] > [End User Notification]します)。 すべてのプラットフォームでサポートされます。

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


          (注)  


          マルチ AD 領域が存在する場合、または単一 AD のレルムのみを進められて NTLM、 Kerberos を使用して; 他の AD レルムはすべて Basic または形式を使用する必要があります。


          Exclude User Agent

          アクティブ認証を必要とするか、または許可するオプションを選択した場合は、VPN トンネルを介して認証トラフィックを送信するリモート アクセス VPN クライアント(AnyConnect 2.5 を使用する Android 2.3 など)やソフトウェア アップデート アプリケーションなど認証要求に応答できないユーザ エージェント(アプリケーション)を除外できます。 認証を要求しないユーザ エージェントを識別するユーザ エージェント ポリシー オブジェクトを(オブジェクトの許可リストで)選択します。

          Interface Roles

          ポリシーの適用先とする親デバイスのインターフェイスを特定する条件です。 ポリシーに一致するには、該当の送信元インターフェイスのいずれかでデバイスにトラフィックが着信し、該当の宛先インターフェイスのいずれかでデバイスからトラフィックが発信される必要があります。 デフォルトでは、送信元と宛先のいずれにも任意のインターフェイスを使用できます。つまり、ポリシーが特定のインターフェイスに制限されていません。

          特定のインターフェイスにポリシーを制限するには、[Source Interface Role] フィールドまたは [Destination Interface Role] フィールド、あるいはその両方で適切なインターフェイス ロール オブジェクトを選択します。 インターフェイス ロール オブジェクトは、インターフェイス名またはインターフェイスの命名パターンを定義します。


          ヒント


          インターフェイス ロールを指定しても、そのロールで定義しているインターフェイス名に一致するインターフェイスがデバイス上にない場合は、そのデバイス上のどのトラフィックにもポリシーは適用されません。


          Tags

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

          Ticket ID

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

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

          アクティブ認証を使用する場合、次の要件に対応する必要があります。
          • 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 および基本認証では、デバイスがドメイン内に存在している必要がありますが、同じドメイン内に存在しない場合でも認証が機能します。 NTLM はすべての Windows クライアントでサポートされていますが、Kerberos は Windows XP クライアントだけでサポートされています。

            認証が成功する可能性を向上させるには、認証方式として [Advanced] を選択することを検討してください。 これにより、システムは、クライアントとサーバの両方でサポートされる最も強力な方式をネゴシエートできるようになり、また 1 つが失敗した場合には別の方式を試行できるようになります。

          • Active Directory で Kerberos または NTLM を使用する場合、アクティブ認証要求に透過的に応答するようにブラウザを設定できます。 詳細については、透過的なユーザ認証のイネーブル化を参照してください。

          • アクティブ認証要求に、すべてのユーザ エージェントが応答できるわけではありません。 たとえば、リモート アクセス VPN 接続のユーザ エージェントが VPN トンネル経由で認証トラフィックを送信する場合、アクティブ認証は失敗します。 AnyConnect 2.5 を使用する Android 2.3 はこのタイプのエージェントの例です。 ソフトウェア アップデータも、アクティブ認証に正常に応答しないことがあります。

            これらのタイプのユーザ エージェントに対応するためには、既存のユーザ エージェント オブジェクトを使用するか、許可リストにこれらのエージェントをリストするユーザ エージェント ポリシー オブジェクトを作成します。 次に、アクティブ認証アイデンティティ ポリシーで、[Exclude User Agent] フィールドでオブジェクトを選択します。

          • ユーザは、トラフィックが HTTP または復号化 HTTPS の場合にのみ要求されます。 HTTPS フローを要求するには、適切なトラフィックの送信元に [Decrypt Everything] アクションを適用する復号ポリシーを作成します。

          リモート アクセス VPN 用の特別な設定要件

          ASA がリモート アクセス AnyConnect VPN 接続をホストする場合、アクティブ認証プロンプトは特定のクライアントに対して表示されない場合があります。 たとえば、Windows 7 Enterprise および Professional Edition、および Mac OS X 10.6.8 クライアントにこの問題があります。

          このような場合にアクティブ認証のプロンプトをイネーブルにするには、VPN から ASA のインターネット IP アドレスを除外するように VPN アクセス グループにスプリット トンネル ポリシーを設定する必要があります。 このような設定の例を次に示します。

          ASA-5525-3# show running-config interface 
          !
          interface GigabitEthernet0/4
           nameif internet
           security-level 100
           ip address 10.194.204.37 255.255.255.0 
          !             
           
          ASA-5525-3# show running-config access-list 
          access-list Split_Tunnel_List standard permit host 10.194.204.37 
           
          ASA-5525-3# show running-config group-policy 
          group-policy test internal
          group-policy test attributes
           vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless
           split-tunnel-policy excludespecified
           split-tunnel-network-list value Split_Tunnel_List
          ASA-5525-3# 
          
          

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

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

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

          基本はデフォルトの認証メカニズムです。

          形作って(Active Directory および LDAP)

          これは、ユーザがログイン ブラウザ ページに表示される基本認証タイプです。 エンド ユーザ通知ページの実行中の認証形式をカスタマイズできます(選択[Administration] > [End User Notification]します)。 ユーザはログイン フォームに常に表示されます。

          統合 Windows 認証(Active Directory のみ)

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

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

          透過的な認証をイネーブルにするには、統合 Windows 認証をサポートするようにクライアント ブラウザを設定する必要があります。 設定は次のとおりです。

          認証ポリシーを設定するときに、ネットワークで使用する認証方式の種類を選択します。 次のオプションがあります。
          • NTLM。 すべての Windows プラットフォームでサポートされます。

          • [Kerberos]。 Windows XP でのみサポートされます。

          • [Advanced]。Active Directory サーバとユーザ エージェントの両方で許可されている最も強力な方式を使用します。 (ユーザ エージェントは、一般に、ユーザがトラフィック フローを開始した Web ブラウザです)。強度の順序は、Kerberos、NTLM、basic の順です。

          ここでは、統合 Windows 認証をサポートし、よく使用されるいくつかのブラウザでのその一般的な要件および基本設定について説明します。方式はソフトウェア リリース間で変わることがあるため、詳細についてはブラウザ(または他のユーザ エージェント)のヘルプを参照する必要があります。


          ヒント


          Chrome および Safari など、すべてのブラウザが統合 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 が除外されていることを確認します。

              Active Directory エージェントの識別

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

              ASA および CX デバイスの両方が同じ CDA または AD エージェント設定を使用して、アイデンティティ対応ファイアウォール サービスが可能になります。 CDA は古い AD エージェント ソフトウェアに置き換わりますが、Web インターフェイスはいずれかのアプリケーションを示すために「AD エージェント」を使用します。


              ヒント


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


              はじめる前に

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

              CDA または AD エージェント ソフトウェアを http:/​/​www.cisco.com/​go/​asa から入手します。

              ソフトウェアのセットアップと設定については、次のマニュアルを参照してください。

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

              手順
                ステップ 1   Configurations > Policies/Settings を選択し、[AD Agent] タブを開きます。

                (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

                ステップ 2   次の情報を入力します。
                • [Hostname or IP]:CDA または AD エージェント サーバの DNS 名または IP アドレス。
                • [Password]:このクライアント デバイスで使用するために、CDA または AD エージェント上に設定される RADIUS 共有秘密。
                ステップ 3   [Test] をクリックして、提供された情報を使用してエージェントに接続できるかどうか確認します。

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

                ステップ 4   可能な場合は、セカンダリ エージェントを設定します。

                デバイスに設定されたセカンダリ エージェントが存在する場合はセカンダリ CAD エージェントの追加]をクリックして、アドレスとパスワードを入力して、接続をテストします。 プライマリが利用できなくなったマッピングを取得するために、セカンダリが使用されます。 これは、エージェントにハイ アベイラビリティ セットアップを提供します。

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

                次の作業

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

                エージェントが ID 情報を収集するすべての AD ドメイン用の領域を定義することを確認します。

                認証設定の指定

                アイデンティティ ポリシーの動作に関連する認証設定を行うことができます。

                手順
                  ステップ 1   Configurations > Policies/Settings を選択し、[Authentication Settings][Auth Settings]タブを開きます。

                  (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

                  ステップ 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] をクリックして変更を保存します。