Cisco Secure Access Control System 5.8 での Active Directory との統合
Table of Contents
ACS 5.8 での Active Directory の統合
ACS 5.8 の Active Directory の主要機能
Active Directory と Cisco の統合の前提条件
ACS の Active Directory ドメインへの参加
Active Directory のマシン アクセス制限の設定
Active Directory でサポートされる認証プロトコルおよび機能
Active Directory ユーザ認証プロセス フロー
証明書ベース認証の Active Directory 証明書の取得
パスワード変更、マシン認証、およびマシン アクセス制限の設定の変更
ACS 5.8 での Active Directory の統合
ACS 5.8 の Active Directory の主要機能
ACS が Active Directory ドメインに参加している場合は、Active Directory の信頼ドメインを自動的に検出します。ただし、すべてのドメインが認証と許可を行うために ACS に関係しているとは限りません。ACS では認証と認可用に信頼ドメインから一部のドメインを選択できます。このドメインのサブセットは、認証ドメインと呼ばれます。認証するユーザまたはマシンが存在するドメインを認証ドメインとして定義することを推奨します。認証ドメインを定義すると、ドメインをブロックすることによって、これらのドメインでのユーザ認証が行われないようにするため、セキュリティが強化されます。また、ポリシーおよび認証に関係しないドメインをスキップできるため、パフォーマンスの最適化や、ACS による ID 検索操作の実行の効率化にも役立ちます。
ACS が受信したユーザ名またはマシン名があいまいな場合（一意ではない場合）、ユーザが認証を行おうとすると問題が発生する可能性があります。ユーザにドメイン マークアップがない場合や、複数のドメインに同じユーザ名の ID が複数ある場合、ID クラッシュが発生します。たとえば、userA が domain1 に存在し、別の userA が domain2 に存在する場合です。ID の解決設定を使用すると、このようなユーザの解決範囲を定義できます。UPN や NetBIOS などの修飾名の使用を強く推奨します。修飾名によって、あいまいになる可能性が削減され、遅延を減らすことでパフォーマンスが向上します。
ACS は、グループ メンバーシップ評価の最適化にセキュリティ ID（SID）を使用します。グループを評価する効率（スピード）、およびダウンしたドメインに属するグループのメンバーであるユーザの遅延に対する復元力という 2 つの理由から、SID は有益です。グループを削除して、元と同じ名前で新規グループを作成する場合は、SID を更新して、新規作成したグループに新しい SID を割り当てる必要があります。
診断ツールを使用すると、一般的な接続問題について Active Directory 環境を自動的にテストおよび診断することができます。このツールは、次の情報を提供します。
ACS 5.8 では、証明書認証プロファイルに新しい機能拡張が導入されています。
■
ID のあいまいさの解決専用のオプション：このオプションを使用すると、EAP-TLS 認証の ID の問題を解決できます。TLS 証明書から複数の ID を設定できます。ユーザ名があいまいな場合（たとえば、「jdoe」が 2 つ取得される場合や、クライアント証明書が Active Directory に存在する場合）、ACS はバイナリ比較を使用してあいまいさを排除することができます。
ACS は、Active Directory 関連のアクティビティのモニタリングおよびトラブルシューティングを実行する新しい AD コネクタ操作レポートおよびアラームをダッシュボードに提供します。
高度な調整機能により、ノード固有の変更および設定が可能となり、システムのさらに深いレベルでパラメータを調整できます。このページでは、優先 DC、GC、DC フェールオーバー パラメータ、およびタイムアウトを設定できます。このページには、暗号化の無効化など、トラブルシューティング オプションもあります。これらの設定は、通常の管理フローを対象としていません。シスコ サポートのガイダンスのみに従って使用する必要があります。
■証明書ベース認証の Active Directory 証明書の取得
■Active Directory のアラームおよびレポート
Active Directory と Cisco の統合の前提条件
次に、Active Directory と ACS とを統合するための前提条件を示します。
■Network Time Protocol（NTP）サーバ設定を使用して、ACS サーバと Active Directory との間で時間を同期します。ACS CLI から NTP を設定できます。
■Active Directory 構造にマルチドメインのフォレストがある場合、または複数のフォレストに分割されている場合は、ACS が接続されるドメインと、アクセスする必要があるユーザおよびマシン情報があるその他のドメインとの間に信頼関係があることを確認します。信頼関係の確立の詳細については、Microsoft Active Directory のドキュメントを参照してください。
■ACS を参加させるドメインでは、少なくとも 1 つのグローバル カタログ サーバが動作し、ACS からアクセス可能である必要があります。
さまざまな操作の実行に必要な Active Directory アカウント権限
メモ：参加操作または脱退操作に使用するクレデンシャルは、ACS に保存されません。新しく作成された ACS のマシン アカウントのクレデンシャルのみが保存されます。
DNS サーバ
■ACS に設定されているすべての DNS サーバで、使用するすべてのドメインの正引きおよび逆引き DNS クエリーを解決できるようにする必要があります。
■すべての DNS サーバで、追加サイト情報の有無に関係なく、DC、GC、および KDC の SRV クエリーに回答できるようにする必要があります。
■パフォーマンスを向上させるために、SRV 応答にサーバ IP アドレスを追加することを推奨します。
■パブリック インターネットでクエリーを実行する DNS サーバを使用しないでください。不明な名前を解決する必要がある場合に、遅延やネットワーク情報の漏洩を引き起こす可能性があります。
ACS の Active Directory ドメインへの参加
同じ展開の ACS ノードを異なる AD ドメインに参加させることができます。ただし、各ノードは、単一の AD ドメインにのみ追加できます。これらの ACS ノードのポリシー定義は変更されず、同じ AD ID ストアを使用します。
AD の設定はデフォルトで表示されず、最初に ACS をインストールしたとき、AD ドメインに追加されません。AD の設定ページを開くと、分散展開内のすべての ACS ノードのリストが表示されます。
AD ID ストアを設定すると、ACS によって次のものも作成されます。
■2 個の属性（ExternalGroup 属性と、[Directory Attributes] ページから取得される属性用の別の属性）を持つそのストア用の新しいディクショナリ。
■新しい属性 IdentityAccessRestricted。この属性のカスタム条件を手動で作成できます。
■ExternalGroup 属性からのグループ マッピングのカスタム条件（カスタム条件名は AD1:ExternalGroups）、および [Directory Attributes] ページで選択された各属性用の別のカスタム条件（AD1:cn など）。
事前定義済みの条件名を編集でき、[Custom condition] ページからカスタム条件を作成できます。『 Creating, Duplicating, and Editing a Custom Session Condition （カスタム セッションの条件の作成、複製、および編集）』を参照してください。
AD ドメインに単一ノードまたは複数ノードを追加するには、次の手順を実行してください。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択します。
[Active Directory] ページが表示されます。
2. 単一ノードまたは複数のノードを選択し、[Join] をクリックします。
3. [Join/Test Connection] ページ の説明に従って、[Join] ページのフィールドに入力します。
|
■ ■ |
|
■[Join]：AD ドメインに選択したノードを追加します。ノードの状態が結合の結果によって変化します。
AD ドメインからノードの接続解除
AD ドメインから単一ノードまたは複数ノードを接続解除するには、次の手順を実行してください。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択します。
[Active Directory] ページが表示されます。
2. 単一ノードまたは複数ノードを選択し、[Leave] をクリックします。
[Leave Connection] ページが表示されます。
3. [Leave Connection] ページ の説明に従って、[Leave Connection] ページのフィールドに入力します。
|
■ ■ |
|
認証ドメインの設定
ACS を Active Directory ドメインに参加させると、ACS では信頼関係のある他のドメインが可視化されます。デフォルトでは、ACS はそうした信頼ドメインすべてに対し、認証を許可します。Active Directory 展開と対話している間は、ACS を認証ドメインのサブセットに限定することもできます。認証ドメインを設定すると、選択したドメインに対してのみ認証が実行されるように、各参加ポイントに固有のドメインを選択できます。認証ドメインでは、参加ポイントで信頼されたすべてのドメインではなく、選択したドメインのユーザのみを認証するよう ACS に指示するので、セキュリティが向上します。また、認証ドメインでは検索範囲が制限される（着信したユーザ名または ID に一致するアカウントが検索される）ため、認証要求処理のパフォーマンスと遅延が改善されます。このことは、着信したユーザ名または ID にドメイン マークアップ（プレフィックスまたはサフィックス）が含まれていない場合、特に重要です。これらの理由から、認証ドメインを設定することをベスト プラクティスとして強く推奨します。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択し、[Authentication Domains] タブをクリックします。
テーブルに、信頼ドメインのリストが表示されます。デフォルトでは、ACS はすべての信頼ドメインに対する認証を許可します。
2. 指定したドメインのみを許可するには、認証を許可するドメインの隣にあるチェックボックスをオンにし、[Enable Selected] をクリックします。
サポートされるグループ タイプ
ACS では、次のセキュリティ グループ タイプがサポートされます。
組み込みグループには、ドメインで一意のセキュリティ ID（SID）がありません。これを解決するために、Cisco はグループが属する SID にドメイン名を使用してプレフィクスを付けます。
ACS は、AD 属性の tokenGroups を使用して、ユーザのグループ メンバーシップを評価します。ACS マシン アカウントには、tokenGroups 属性を読み取るための権限が必要です。この属性には、ユーザがメンバーである可能性がある最初の約 1015 グループを含めることができます（実際の数は Active Directory 設定によって異なり、Active Directory を再設定することで増やすことができます）。ユーザが所属するグループの数がこれを超える場合、Cisco ではポリシー ルールで最初の 1015 まで使用します。
Active Directory ユーザ グループの設定
Active Directory ユーザ グループを許可ポリシーで使用できるように設定する必要があります。内部的には、ACS はグループ名のあいまいさの問題を解決し、グループ マッピングを向上させるためにセキュリティ ID（SID）を使用します。SID により、グループ割り当てが正確に一致します。
Active Directory ドメインに ACS が接続されていることを確認します。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択し、[Directory Groups] タブをクリックします。
[Directory Groups] ページが表示されます。[Selected Directory Groups] フィールドに、選択して保存した AD グループが表示されます。[External User Groups] ページで選択した AD グループが表示され、規則テーブルのグループ マッピング条件でオプションとして使用できます。
表示されていない他の信頼ドメインまたはフォレストにさらにグループがある場合は、検索フィルタを使用して検索結果を絞り込むことができます。[Add] ボタンを使用して新しい AD グループを追加することもできます。
注：ACS は、ドメイン ローカル グループを取得しません。ACS ポリシーでドメイン ローカル グループを使用することは推奨されません。その理由は、ドメイン ローカル グループでのメンバーシップ評価には時間がかかるためです。そのため、デフォルトでは、ドメイン ローカル グループは評価されません。
2. [Select] をクリックして、ドメイン（および同じフォレスト内の他の信頼ドメイン）で使用可能な AD グループを表示します。
[External User Groups] ダイアログボックスが表示され、ドメインおよび同じフォレスト内の他の信頼ドメインの AD グループのリストが表示されます。
表示されていないグループがさらにある場合は、検索フィルタを使用して検索を絞り込み、[Go] をクリックします。
3. AD グループを入力するか、リストから選択し、[OK] をクリックします。
AD グループをリストから削除するには、AD グループをクリックして [Deselect] をクリックします。
■変更をすべて廃棄するには、[Discard Changes]。
■AD がすでに設定されており、それを削除する場合は、AD ディクショナリに基づくカスタム条件を使用しているポリシー規則がないことを確認したあとで、[Clear Configuration] をクリックします。
注：グループを削除し、そのグループと同じ名前で新しいグループを作成する場合は、[Update SID Values] をクリックして、新しく作成したグループに新しい SID を割り当てる必要があります。アップグレードすると、最初の参加の後に SID が自動的に更新されます。正しく認証ルールに従って認証に成功するためには、SID が更新された新規作成グループをポリシーにもう一度マップする必要があります。
注：ACS 5.x で AD ID ストアを設定する場合、Active Directory に定義されているセキュリティ グループが列挙され、使用できますが、分散グループは表示されません。Active Directory の分散グループはセキュリティ対応でないため、ユーザの集合に電子メールを送信するために電子メール アプリケーションで使用することしかできません。分散グループの詳細については、Microsoft のマニュアルを参照してください。
注：ACS が外部 ID ストアの 1015 グループ以上に属するユーザを認証しようとすると、Active Directory でログイン認証が失敗することがあります。これは、Active Directory のローカル セキュリティ認証（LSA）の制限によるものです。
Active Directory 属性の設定
許可ポリシーの条件で使用できるように Active Directory の属性を設定する必要があります。
Active Directory ドメインに ACS が接続されていることを確認します。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択し、[Directory Attributes] タブをクリックします。
2. 表 5 の説明に従って、[Active Directory: Attributes] ページのフィールドに入力します。
■[Save Changes] をクリックして、設定を保存します。
■ すべての変更を破棄するには、[Discard Changes] をクリックします。
■AD がすでに設定されており、それを削除する場合は、AD ディクショナリに基づくカスタム条件を使用しているポリシー規則がないことを確認したあとで、[Clear Configuration] をクリックします。
Active Directory のマシン アクセス制限の設定
マシン アクセス制限を設定するには、次の手順を実行してください。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択し、[Machine Access Restrictions] タブをクリックします。
2. 表 6 の説明に従って、[Active Directory: Machine Access Restrictions] ページのフィールドに入力します。
ACS がキャッシュ エントリのクエリーを実行しなければならない回数を入力します。デフォルト値は 1 です。有効な範囲は 0 ～ 5 です。 |
|
選択したノードのキャッシュ分散グループを入力します。ここには、最大 64 文字のテキスト文字列を入力できます。キャッシュ配布グループには特殊文字の「(」と「)」は使用できません。 |
|
■ [Save Changes] をクリック して、設定を保存します。
■ すべての変更を破棄するには、 [Discard Changes] をクリック します。
■AD がすでに設定されており、それを削除する場合は、AD ディクショナリに基づくカスタム条件を使用しているポリシー規則がないことを確認したあとで、[Clear Configuration] をクリックします。
Active Directory でサポートされる認証プロトコルおよび機能
Active Directory は、一部のプロトコルを使用したユーザとマシンの認証、Active Directory ユーザ パスワードの変更などの機能をサポートしています。次の表に、Active Directory でサポートされる認証プロトコルおよびそれぞれの機能を示します。
Active Directory ユーザ認証プロセス フロー
ユーザの認証または問い合わせ時に、ACS は次のことをチェックします。
■MS-CHAP および PAP 認証では、ユーザが無効か、ロックされているか、期限切れか、またはログイン時間外かどうかが確認され、これらの条件のいくつかに一致する場合、認証は失敗します。
■EAP-TLS 認証では、ユーザが無効かどうかまたはロックされているかどうかが確認され、これらの条件のいくつかに一致する場合、認証は失敗します。
また、上記の条件（ユーザが無効など）に一致する場合は、IdentityAccessRestricted 属性を設定できます。従来のポリシーをサポートするために IdentityAccessRestricted 属性を設定します。前述の条件に一致する場合（ユーザが無効など）は認証が失敗するため、ACS 5.8 では必要ありません。
サポートされるユーザ名の形式
■NetBIOS プレフィクス付きの SAM（例：ACME\jdoe）
■Alt UPN（例：john.doe@acme.co.uk）
■サブツリー（例：johndoe@finance.acme.com）
■NetBIOS プレフィクス付きのマシン（例：ACME\laptop$）
Active Directory のパスワードベース認証
パスワード認証プロトコル（PAP）と Microsoft チャレンジ ハンドシェイク認証プロトコル（MS-CHAP）は、パスワードベース プロトコルです。MS-CHAP クレデンシャルは、MS-RPC によってのみ認証できます。ACS では PAP 認証に 2 つのオプション（MS-RPC および Kerberos）があります。MS-RPC も Kerberos も同様にセキュアなオプションです。PAP 認証の MS-RPC はデフォルトであり、次の理由から推奨されるオプションです。
■Active Directory とのより効率的な通信。MS-RPC の場合、ACS は参加しているドメインのみからドメイン コントローラに認証要求を送信し、そのドメイン コントローラが要求を処理します。
Kerberos の場合、ACS は、参加しているドメインからユーザのアカウント ドメインまで Kerberos のリフェラルに従う必要があります（つまり、ACS は参加しているドメインからユーザのアカウント ドメインへの信頼パスにあるすべてのドメインと通信する必要があります）。
ACS は、ユーザ名の形式を確認し、ドメイン マネージャを呼び出して適切な接続を検索します。アカウント ドメインのドメイン コントローラが検出されると、ACS はそれに対してユーザを認証しようとします。パスワードが一致すると、ユーザにネットワークへのアクセス権が付与されます。
パスワードベースのマシン認証は、マシン名がホスト/プレフィクス形式であることを除き、ユーザベース認証によく似ています。この形式（DNS ネームスペース）では、ACS はそのまま認証することはできません。認証する前に、NetBIOS のプレフィクスが付いた SAM 形式に変換します。
証明書ベース認証の Active Directory 証明書の取得
ACS では、EAP-TLS プロトコルを使用するユーザおよびマシンの認証のための証明書取得がサポートされています。Active Directory 上のユーザまたはマシン レコードには、バイナリ データ型の証明書属性が含まれています。この証明書属性に 1 つ以上の証明書を含めることができます。ACS ではこの属性は userCertificate として識別され、この属性に対して他の名前を設定することはできません。ACS はこの証明書を取得し、バイナリ比較の実行に使用します。
証明書認証プロファイルは、証明書の取得に使用する Active Directory のユーザを検索するためにユーザ名を取得するフィールド（たとえば、サブジェクト代替名（SAN）または一般名）を決定します。ACS は、証明書を取得したあと、この証明書とクライアント証明書とのバイナリ比較を実行します。複数の証明書が受信された場合、ACS は、いずれかが一致するかどうかをチェックするために証明書を比較します。一致が見つかった場合、ユーザまたはマシン認証に合格します。
証明書認証プロファイルの追加
Extensible Authentication Protocol-Transport Layer Security（EAP-TLS）証明書ベースの認証方式を使用する場合は、証明書認証プロファイルを作成する必要があります。従来のユーザ名とパスワードの方法で認証する代わりに、ACS はクライアントから受信した証明書とサーバの証明書を比較し、ユーザの信頼性を検証します。
証明書認証プロファイルによって、証明書ベースのアクセス要求に使用される X509 証明書情報が定義されます。ユーザ名として使用される属性を証明書から選択できます。証明書属性のサブセットを選択して、要求のコンテキストにユーザ名フィールドを読み込むことができます。このユーザ名は、要求の残りのユーザを識別する場合に使用されます。ログで使用される識別情報にも使用されます。
証明書認証プロファイルを使用して証明書データを取得し、LDAP または AD クライアントから提示される証明書をさらに確認できます。証明書認証プロファイルのユーザ名を使用して、LDAP または AD ID ストアの問い合わせが行われます。ACS は、クライアント証明書を LDAP または AD ID ストアから取得されたすべての証明書と 1 つずつ比較し、いずれかが一致するかどうかを確認します。ACS は、要求を受け入れるか、または拒否します。
ACS が要求を受け入れるには、LDAP または AD ID ストアの証明書が 1 つだけ、クライアント証明書と一致する必要があります。
ACS が証明書ベースの認証要求を処理するときに、次の 2 つのうちのいずれかが行われます。証明書のユーザ名と、要求を処理している ACS のユーザ名とが比較されます。あるいは、選択した LDAP または AD ID ストアに定義されている情報を使用して、ACS によって証明書情報が確認されます。
証明書認証プロファイルを複製して、既存の証明書認証プロファイルと同じか、または類似した新しいプロファイルを作成できます。複製の完了後、各プロファイル（元のプロファイルおよび複製されたプロファイル）に個別にアクセスして、編集または削除します。
ACS 5.8 では、現在、証明書の名前制約拡張をサポートします。これにより、発行元に名前制約拡張が含まれるクライアント証明書を受け入れます。また、CA およびサブ CA 証明書についてクライアント認証を確認します。この拡張は、証明書パスの後続の証明書におけるすべてのサブジェクト名の名前空間を定義します。これは、サブジェクト識別名とサブジェクト代替名の両方に適用されます。これらの制約は、指定された名前形式がクライアント証明書に存在する場合にのみ適用されます。ACS 認証は、クライアント証明書が名前空間により除外されている、または許可されていない場合、失敗します。
証明書認証プロファイルを作成、複製、または編集するには、次の手順を実行してください。
1. [Users and Identity Stores] > [Certificate Authentication Profile] を選択します。
[Certificate Authentication Profile] ページが表示されます。
■複製する証明書認証プロファイルの隣にあるチェックボックスをオンにし、[Duplicate] をクリックします。
■変更する証明書認証プロファイルをクリックします。または、名前の隣にあるチェックボックスをオンにして [Edit] をクリックします。
[Certificate Authentication Profile Properties] ページが表示されます。
3. 表 8 の説明に従って、[Certificate Authentication Profile Properties] ページのフィールドに入力します。
パスワード変更、マシン認証、およびマシン アクセス制限の設定の変更
Active Directory ドメインに ACS を参加させる必要があります。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択します。
Active Directory の [General] タブが表示されます。
2. 必要に応じて、[Password Change]、[Machine Authentication]、[dial-in check]、[call back check for dial-in clients] を有効にします。デフォルトでは、[Password Change] と [Machine Authentication] は有効になっています。
3. プレーン テキスト認証に Kerberos を使用する場合は、[Use Kerberos for Plain Text Authentications] チェックボックスをオンにします。デフォルトの推奨オプションは MS-RPC です。
許可ポリシーで使用する Active Directory 属性およびグループの取得
ACS は、許可ポリシー ルールで使用するために Active Directory からユーザまたはマシンの属性およびグループを取得します。これらの属性は ACS ポリシーで使用され、ユーザまたはマシンの承認レベルを決定します。ACS は、認証が成功した後にユーザおよびマシンの Active Directory 属性を取得します。また、認証とは別に、認可のために属性を取得することもできます。
ACS は、外部 ID ストア内のグループを使用してユーザまたはコンピュータに権限を割り当てることがあります（たとえば、ユーザをスポンサー グループにマップします）。Active Directory のグループ メンバーシップの次の制限事項に注意してください。
ポリシー ルールの条件は、次のいずれかを参照します。ユーザまたはコンピュータのプライマリ グループ、ユーザまたはコンピュータが直接メンバーであるグループ、または間接的（ネストされた）グループ。
ユーザまたはコンピュータのアカウント ドメイン外のドメイン ローカル グループはサポートされません。
属性およびグループは、Active Directory ドメインごとに取得され、管理されます。これらは許可ポリシーで使用されます（まず参加ポイントを選択し、次に属性を選択します）。許可範囲ごとに属性またはグループを定義することはできませんが、認証ポリシーに範囲を使用できます。認証ポリシーで範囲を使用する場合、ユーザは 1 つの参加ポイントで認証されますが、ユーザのアカウント ドメインへの信頼できるパスがある別の参加ポイント経由で属性またはグループを取得することができます。認証ドメインを使用して、1 つの範囲内にある 2 つの参加ポイントで認証ドメインが重複しないようにすることができます。
使用可能な Active Directory グループの最大数に関する Microsoft の制限については、次の URL を参照してください。 http://technet.microsoft.com/ja-JP/library/active-directory-maximum-limits-scalability(v=WS.10).aspx
ルールに、/!@\#$%^&*()_+~ のような特殊文字を使用した Active Directory グループ名が含まれる場合、許可ポリシーは失敗します。
ID の解決の設定
一部のタイプの ID には、プレフィクスまたはサフィックスのようなドメイン マークアップが含まれます。たとえば、ACME\jdoe などの NetBIOS ID では、「ACME」がドメイン マークアップのプレフィクスで、同様に jdoe@acme.com などの UPN ID では、「acme.com」がドメイン マークアップのサフィックスです。ドメイン プレフィクスは、組織内の Active Directory ドメインの NetBIOS（NTLM）名に一致し、ドメイン サフィックスは、組織内の Active Directory ドメインの DNS 名または代替 UPN サフィックスに一致する必要があります。たとえば、gmail.com は Active Directory ドメインの DNS 名ではないため、jdoe@gmail.com はドメイン マークアップなしとして処理されます。
ID 解決設定では、Active Directory 展開に一致するように、セキュリティおよびパフォーマンスのバランスを調整する重要な設定を指定できます。これらの設定を使用すると、ドメイン マークアップのないユーザ名およびホスト名の認証を調整できます。ACS がユーザのドメインを認識しない場合、すべての認証ドメインでユーザを検索するように設定することができます。ユーザが 1 つのドメインで検出されても、ACS は ID のあいまいさがないことを保証するためにすべての応答を待ちます。このプロセスには、ドメインの数、ネットワークの遅延、負荷などに応じて時間がかかる場合があります。
ID 解決問題の回避
認証時に、ユーザおよびホストに完全修飾名（つまり、ドメイン マークアップが含まれている名前）を使用することを強く推奨します。たとえば、ユーザの UPN と NetBIOS 名、およびホストの FQDN SPN です。これは、複数の Active Directory アカウントが受信ユーザ名と一致する（たとえば、jdoe が jdoe@emea.acme.com および jdoe@amer.acme.com と一致する）など、あいまいエラーが頻繁に生じる場合に特に重要です。場合によっては、完全修飾名を使用することが、問題を解決する唯一の方法になります。また、ユーザに一意のパスワードが設定されていることを保証するだけで十分な場合もあります。したがって、一意の ID を最初から使用すると、効率が向上し、パスワード ロックアウトの問題が減少します。
ID 解決の設定
注：この設定タスクは任意です。あいまいな識別エラーなどのさまざまな理由で発生する認証の失敗を減らすために実行できます。
Active Directory ドメインに ACS を参加させる必要があります。複数参加は ACS 5.8 ではサポートされません。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択します。
ACS は Active Directory の [General] タブに詳細を表示します。
2. [Identity Resolution] セクションで、ユーザ名またはマシン名の ID 解決についての次の設定を定義します。この設定によって、ユーザの検索と認証を詳細に制御できます。
最初に、マークアップなしの ID に対する設定を行います。このような場合、次のオプションのいずれかを選択できます。
■[Reject the request]：このオプションを使用すると、SAM 名などのドメイン マークアップがないユーザの認証は失敗します。このことは、複数参加ドメインの場合に役立ちます。参加しているすべてのグローバル カタログで ID を ACS が検索する必要があるため、安全性が低下する可能性があるためです。このオプションによって、ユーザに対し、ドメイン マークアップを含むユーザ名を使用することが強制されます。
■[Only search in the “Authentication Domains” from the joined forest]：このオプションを使用すると、認証ドメインのセクションで指定した、結合ポイントのフォレスト内のドメインのみで ID が検索されます。これはデフォルト オプションであり、SAM アカウント名に対する ACS 5.7 の動作と同じです。
■[Search in all the “Authentication Domains” sections]：このオプションを使用すると、すべての信頼されたフォレストのすべての認証ドメインで ID が検索されます。これにより、遅延が増加し、パフォーマンスに影響する可能性があります。
ACS で認証ドメインがどのように設定されているかに基づいて選択します。特定の認証ドメインのみを選択した場合は、それらのドメインのみが検索されます（「結合されたフォレスト」と「すべてのフォレスト」のいずれを選択した場合も）。
2 番目の設定は、ACS が、[Authentication Domains] セクションで指定された設定に準拠するために必要となるすべてのグローバル カタログ（GC）と通信できない場合に使用します。このような場合、次のオプションのいずれかを選択できます。
■[Proceed with available domains]：このオプションを使用すると、使用可能ないずれかのドメインで一致が見つかった場合に認証が続行されます。
■[Drop the request]：このオプションを使用すると、ID 解決で到達不能または使用できないドメインが検出された場合に認証要求がドロップされます。
トラブルシューティング ツール
ACS には、Active Directory のエラーを診断およびトラブルシューティングする複数のツールがあります。
Active Directory の問題の診断
診断ツールは、各 ACS ノードで実行するサービスです。診断ツールを使用すると、Active Directory 展開を自動的にテストおよび診断したり、ACS が Active Directory を使用するときに機能やパフォーマンスの障害の原因となる可能性がある問題を検出するための一連のテストを実行したりすることができます。
ACS が Active Directory に参加できない、または Active Directory で認証されない理由は、複数あります。このツールは、ACS を Active Directory に接続するための前提条件が正しく設定されているようにするのに役立ちます。また、ネットワーク、ファイアウォール設定、クロック同期、ユーザ認証などの問題の検出に役立ちます。このツールは、手順をステップごとに説明するガイドとして機能し、各レイヤの問題を（必要に応じて）途中で修正するのに役立ちます。
次の 3 つのテストは、ACS を Active Directory に参加させずに実行でき、AD デーモンが正しく実行しているかどうかを確認できます。
■System health - check AD service
■System health - check DNS configuration
Active Directory の問題を診断するには、次の手順を実行します。
1. [Users and Identity Stores] > [External Identity Stores] > [Active Directory] を選択し、[Diagnostic Tools] タブをクリックします。
Active Directory のドメイン機能を確認するために ACS で実行可能なすべてのテストのリストが [Diagnostic Tools] タブに表示されます。
2. 実行するテストの横にあるチェックボックスをオンにします。複数のボックスを選択できます。
■選択したテストのみを実行するには、[Run Selected Tests]。
■すべてのテストを実行するには、[Run All Tests]。
Active Directory のアラームおよびレポート
ACS は、Active Directory に関連するアクティビティをモニタしてトラブルシューティングを実行するためのさまざまなアラームおよびレポートを提供します。
次のような Active Directory のエラーおよび問題に対して、アラームがトリガーされます。
■Active Directory フォレストが使用できない
次の 2 つのレポートで、Active Directory に関連するアクティビティをモニタできます。
■RADIUS Authentications Report：このレポートは、Active Directory の認証および許可に関する詳細な手順が示されています。このレポートは、[Operations] > [Reports] > [Auth Services Status] > [RADIUS Authentications] にあります。
■AD Connector Operations Report：AD Connector Operations Report には、ACS サーバのパスワード更新、Kerberos チケットの管理、DNS クエリー、DC 検出、LDAP、および RPC 接続管理など、AD コネクタによって実行されるバックグラウンド操作のログが示されています。Active Directory の障害が発生した場合、このレポートの詳細を確認することで、考えられる原因を特定することができます。このレポートは、[Operations] > [Reports] > [Auth Services Status] > [AD Connector Operations] にあります。
AD コネクタの内部操作
ここでは、AD コネクタで行われる内部操作について説明します。
ドメイン検出アルゴリズム
ACS は、次の 3 つのフェーズでドメイン検出を実行します。
1. 参加しているドメインのクエリー：フォレストのドメイン、および参加しているドメインに対して外部的に信頼できるドメインを検出します。
2. フォレスト内のルート ドメインのクエリー：フォレストで信頼を確立します。
3. 信頼できるフォレスト内のルート ドメインのクエリー：信頼できるフォレストからドメインを検出します。
さらに、ACS は DNS ドメイン名（UPN サフィックス）、代替の UPN サフィックスおよび NTLM ドメイン名を検出します。
デフォルト ドメインの検出頻度は、2 時間ごとです。[Advanced Tuning] ページからこの値を変更できますが、シスコのサポート担当者に相談してください。
DC の検出
AD コネクタは、次のように特定ドメインのドメイン コントローラ（DC）を選択します。
1. DNS SRV クエリー（サイトにスコープされていない）を実行し、ドメインで完全なドメイン コントローラ リストを取得します。
2. IP アドレスのない DNS SRV の DNS 解決を実行します。
3. SRV レコードの優先順位に従って CLDAP ping 要求をドメイン コントローラに送信し、応答がある場合は最初の応答のみを処理します。CLDAP 応答には、DC サイトとクライアント サイト（シスコのマシンが割り当てられたサイトなど）が含まれます。
4. DC サイトとクライアント サイトが同じ場合、応答の送信元（DC）が選択されます。
5. DC サイトとクライアント サイトが同じでない場合、AD コネクタは、検出されたクライアント サイトにスコープされた DNS SRV クエリーを実行し、クライアント サイトを使用するドメイン コントローラのリストを取得し、これらのドメイン コントローラに CLDAP ping 要求を送信し、応答がある場合は最初の応答のみを処理します。応答の送信元（DC）が選択されます。サイトを使用するクライアント サイトに DC がない場合や、現在使用できる DC がサイトにない場合は、手順 2 で検出された DC が選択されます。
Active Directory サイトを作成および使用することで、ACS が使用するドメイン コントローラに影響を与える場合があります。サイトの作成および使用方法については、Microsoft Active Directory のマニュアルを参照してください。
ACS は、ドメインごとに優先 DC のリストも定義できます。DC のリストは、DNS SRV クエリーの前に選択の優先順位が付けられます。ただし、この優先 DC のリストは排他的リストではありません。優先 DC が使用できない場合は、その他の DC が選択されます。優先 DC のリストは、次の場合に作成できます。
■SRV レコードが不良か、存在しないか、設定されていない場合。
DC のフェールオーバー
ドメイン コントローラ（DC）のフェールオーバーは、次の条件によってトリガーされます。
■AD コネクタは、現在選択している DC が LDAP、RPC、または Kerberos の通信試行時に使用できなくなった場合に検出します。DC は、ダウンしているかネットワーク接続されていないために使用できない可能性があります。このような場合、AD コネクタは DC の選択を開始し、新しく選択した DC にフェールオーバーします。
■DC が起動していて CLDAP ping に応答しますが、AD コネクタはいくつかの理由で DC と通信できません。たとえば、RPC ポートがブロックされている場合、DC は破損複製状態になっているか、適切に使用停止されていません。このような場合、AD コネクタは、ブラックリストを使用する DC の選択（「不良」DC はブラック リストに置かれます）を開始して、選択した DC との通信を試します。ブラックリストを使用して選択した DC とブラックリストのどちらもキャッシュされません。
DNS のフェールオーバー
最大 3 つの DNS サーバと 1 つのドメイン サフィックスを設定できます。ACS で Active Directory の ID ストア順序を使用している場合、すべての DNS サーバが、使用するすべての Active Directory DNS ドメインの正引きおよび逆引き DNS クエリーに応答できるようにする必要があります。DNS のフェールオーバーは、最初の DNS がダウンしているときにのみ発生します。フェールオーバー DNS には最初の DNS と同じレコーダが必要です。DNS サーバがクエリーの解決に失敗する場合、DNS クライアントは別の DNS サーバを試行しません。デフォルトでは、DNS サーバはクエリーを 2 回再試行し、3 秒でクエリーをタイムアウトします。
ID アルゴリズムの解決
ID に関しては、パスワードが入力されているかどうか、任意のドメイン マークアップが ID に存在するかどうかに関係なく、ID のタイプに基づいて、さまざまなアルゴリズムがユーザまたはマシン オブジェクトの検索に使用されます。次に、ACS がさまざまな ID タイプの解決に使用するさまざまなアルゴリズムを示します。
注：ID が設定済みの ID リライト ルールに従って書き換えられている場合、ID 解決は書き換えられた ID に適用されます。
ID が SAM 名（ドメイン マークアップのないユーザ名またはマシン名）の場合、ACS はフォレストを検索して ID を探します。一意に一致した場合、ACS はドメインまたは一意の名前を特定し、AAA フローに進みます。
SAM 名が一意ではなく、ACS が EAP-TLS などのパスワードのないプロトコルを使用するように設定されている場合は他に適切なユーザを検索する基準がないため、ACS は「あいまいな ID」エラーで認証に失敗します。ただし、ユーザ証明書が Active Directory に存在する場合、ACS はバイナリ比較を使用して ID を解決します。
PAP などのパスワードベースのプロトコル、または MSCHAP を使用するように ACS が設定されている場合、シスコは引き続きパスワードを確認します。一意に一致した場合、ACS は AAA フローに進みます。ただし、パスワードが同じアカウントが複数ある場合、ACS は「あいまいな ID」エラーで認証に失敗します。
ユーザ名の競合を回避する必要があります。これにより、効率およびセキュリティが向上するだけでなく、アカウントがロックされることも防止されます。たとえば、パスワードが異なる 2 つの「Chris」が存在し、ACS は SAM 名の「Chris」のみを受信するとします。このシナリオでは、ACS は正しいアカウントを特定する前に、SAM 名が「Chris」である両方のアカウントを試行し続けます。このような場合、Active Directory は間違ったパスワードの試行によっていずれかのアカウントをロックする可能性があります。このため、一意のユーザ名またはドメイン マークアップ付きのユーザ名を使用するようにしてください。また、各 Active Directory ドメインに特定のネットワーク デバイスを使用する場合、ID 書き換えを使用して SAM 名を認定できます。
ID が UPN の場合、ACS は各フォレストのグローバル カタログを検索して、その UPN ID との一致を確認します。一意に一致した場合、ACS は AAA フローに進みます。同じ UPN の参加ポイントが複数あり、パスワードが入力されていないか、適切なアカウントの特定に役立たない場合、ACS は「あいまいな ID」エラーで認証に失敗します。
また、ACS は、UPN である ID にユーザのメール属性の照合も許可します。つまり、「identity=matching UPN or email」を検索します。一部のユーザは、実際の基盤となる UPN ではなく、電子メール名を使用して（多くの場合、証明書経由で）ログインします。このことは、ID が電子メール アドレスと同じ形式の場合に、暗黙的に行われます。
マシン認証の場合、ACS は、ホスト/プレフィクスを持つ ID を使用して、一致する servicePrincipalName 属性がないかフォレストを検索します。完全修飾ドメイン サフィックス（host/machine.domain.com など）が ID で指定されている場合、ACS はそのドメインが存在するフォレストを検索します。ID がホスト/マシン形式の場合、ACS はサービス プリンシパル名がないかすべてのフォレストを検索します。一致が複数ある場合、ACS は「あいまいな ID」エラーで認証に失敗します。
マシンが別の ID 形式（machine@domain.com、ACME\laptop$、または laptop$ など）の場合、ACS は通常の UPN、NetBIOS、または SAM の解決アルゴリズムを使用します。
ID に NetBIOS ドメイン プレフィクス（ACME\jdoe など）がある場合、ACS は NetBIOS ドメインがないかフォレストを検索します。検出されたら、検出されたドメインで指定の SAM 名（この例では「jdoe」）を検索します。NetBIOS ドメインは、1 つのフォレストにおいても必ずしも一意ではないため、検索によって同じ名前の NetBIOS ドメインが複数検出される場合があります。このような場合にパスワードが入力されていると、適切な ID を検索するために、そのパスワードが使用されます。それでもあいまいな場合やパスワードが入力されていない場合、ACS は「あいまいな ID」エラーで認証に失敗します。
注：デバイスの数が 100,000 を超える導入環境では、4GB 以上の RAM プラットフォームを使用することを推奨します。デバイスの数が 100,000 を超える導入環境で 4GB 以下の RAM が搭載されたマシンを使用すると ACS ランタイムがクラッシュします。
注：ACS の以前のリリースでは、ACS CLI から手動で AD クライアント プロセスを停止すると Active Directory ドメインを切断し、[Active Directory Connection Details] ページに「joined but disconnected」というステータスが表示されます。一方、ACS 5.8 では、ACS CLI から手動で AD クライアント プロセスを停止すると、ACS は Active Directory ドメインを切断し、[Active Directory Connection Details] ページに「None」というステータスが表示されます。ACS CLI から AD クライアント プロセスを再度起動すると、ACS は Active Directory ドメインに接続し、[Active Directory Connection Details] ページに「joined and connected」というステータスが表示されます。
注：RSA ID サーバまたは RSA SecurID サーバに対してユーザおよび管理者を認証するときは、次の場合に ACS によって ACS レポートに「Invalid Password」というエラーメッセージが表示されます。
1）無効なパスワードが入力されている場合
2）外部 ID ストアでユーザが無効になっている場合
3）外部 ID ストアにユーザが存在しない場合
注：Active Directory ドメインから ACS アカウントを無効にした直後に認証が必ずしも失敗するわけではありません。接続または TGT チケットが確立されている限り、認証は実行されます。認証失敗の原因となるエラーは、ACS への接続に使用する接続方法が LDAP か Kerberos か RPC かによって異なることがあります。また、ドメイン コントローラ間のレプリケーションによっても異なります。
注：以前の ACS のリリースでは、ACS の Active Directory ドメインに参加した後にのみ、AD クライアント プロセスが起動しました。しかし ACS 5.8 では、インストールするとすぐに AD クライアント プロセスが起動します。
注： ACS 5.8 の場合、ACS 5.x から ACS 5.8 にアップグレードした後に Active Directory を ACS に手動で参加させる必要があります。アップグレード方法の詳細については、『 Installation and Upgrade Guide for Cisco Secure Access Control System 』を参照してください。
注：AD ドメインに ACS を追加する Windows AD アカウントは、独自の組織ユニット（OU）で作成できます。アカウントを作成するときまたは後で独自 OU で作成できますが、アプライアンスの名前が AD アカウント名に一致する必要があります。
注：ACS では、ユーザ名が OU レベルで設定した代替 UPN サフィックスで指定されている場合は、AD のユーザ認証をサポートしません。UPN サフィックスがドメイン レベルで設定されている場合、認証は正常に動作します。
注：管理者は、セカンダリ サーバから参加または参加解除の操作を実行できます。セカンダリ サーバで次の操作を実行すると、セカンダリ サーバだけに影響します。
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http://www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
このマニュアルで使用している IP アドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。マニュアル内の例、コマンド出力、ネットワーク トポロジ図、およびその他の図は、説明のみを目的として使用されています。説明の中に実際のアドレスおよび電話番号が使用されていたとしても、それは意図的なものではなく、偶然の一致によるものです。
フィードバック