この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco Context Directory Agent(CDA)は、ISO イメージとしてパッケージ化されているソフトウェア アプリケーションです。 Cisco.com からダウンロードできます。これは、VMware ESX サーバ上の専用 X86 マシンまたは仮想マシンにインストールし、コンシューマ デバイスと Active Directory ドメイン コントローラで設定する必要があります。
CDA は、バンドルされる Cisco Linux OS にインストールされています。CDA ISO イメージをスタンドアロン マシンまたは VMWare サーバにインストールすると、Linux が OS としてインストールされ、CDA はその上でアプリケーションとして実行されます。
CDA マシンは別個の専用アプライアンスまたは VMWare である必要があります。UCSC-C220-M3S アプライアンスに CDA をインストールすることができます。NIC 要件については、 表 2-1 を参照してください。
すべての場合において、CDA マシンは 表 2-1 に記載されている標準ハードウェア仕様と VMWare 仕様を満たす必要があります。
|
|
---|---|
1 つの NIC または仮想 NIC。UCS-C220-M3S アプライアンスでは、Broadcom 5709、1 Gbps、2 ポート NIC を使用する必要があります。 |
表 2-2 には、CDA を VMWare にインストールするための最小限のハードウェア要件がリストされています。
|
|
---|---|
1 つの仮想 NIC。CDA は、NIC のフレキシブル タイプおよび E1000 タイプをサポートしています。VMXNET 2 と VMXNET 3 はサポートされていません。 |
CDA が適切に機能するためには、この CDA で設定されているすべてのコンシューマ デバイス、ログを受信する Active Directory ドメイン コントローラ マシン、およびターゲット Syslog サーバと自由に通信できる必要があります。ログ転送が採用されている場合、CDA と統合されるドメイン コントローラ マシンの間の接続のみが必要です。一元化されたログ転送の展開では、すべてのドメイン コントローラ マシンと CDA の間で接続を提供する必要はありません。CDA は、ドメイン コントローラの RPC ポート 135 との接続を開始します。接続を確立すると、ドメイン コントローラは高いポートを動的に選択します。
Windows Firewall(またはその他の同等のサードパーティ ファイアウォール ソフトウェア)がいずれかの Active Directory ドメイン コントローラ マシンで実行されている場合、これらの各エンドポイントのファイアウォール ソフトウェアで、自由に通信を行うために必要な例外を設定する必要があります。
この項では Windows Firewall を例にして、Windows Firewall を実行する可能性のあるすべてのエンドポイントに定義する必要のある例外について詳しく説明します。
その他の互換サードパーティ ファイアウォール ソフトウェアについては、ベンダーのマニュアルで該当する例外の設定方法を参照してください。
個別の Active Directory ドメイン コントローラ マシンで設定する必要がある Windows Firewall 例外
CDA マシンで GUI を使用して設定されている個々の Active Directory ドメイン コントローラ マシンで、Windows Firewall がその個々のドメイン コントローラ マシンで有効な場合は、その特定のドメイン コントローラ マシンで必要な Windows Management Instrumentation(WMI)関連の通信を許可する Windows Firewall 例外を定義する必要があります。
このドメイン コントローラ マシンで Windows Server 2008、Windows Server 2008 R2、Windows Server 2012 または Windows Server 2012 R2 が実行されている場合は、以下の Windows コマンド ラインを使用してこの WMI 関連の例外を設定できます(コマンドは 1 行に入力します)。
netsh advfirewall firewall set rule group=”Windows Management Instrumentation (WMI)" new enable=yes
このドメイン コントローラ マシンで Windows Server 2003 または Windows Server 2003 R2(SP1 以降がインストールされている状態)が実行されている場合は、以下の Windows コマンド ラインを使用してこの WMI 関連の例外を設定できます(コマンドは 1 行に入力します)。
表 2-3 に、CDA がコンシューマ デバイスとの通信に使用する Transmission Control Protocol(TCP)ポートと User Datagram Protocol(UDP)ポートの一部を示します。CDA では、これらのポートはデフォルトで空いています。CDA は動的にポートを選択してドメイン コントローラと通信します。
|
|
|
|
---|---|---|---|
表 2-3 に記載されたポートは CDA と ASA または WSA 間の正常な通信を確立するために開いている必要があります。
次のポートは、CDA プロセス間の内部コミュニケーションに対して空いていますが、アプライアンス外部からのアクセスに対してブロックされます。
CDA は、Active Directory ドメイン コントローラによって生成される Active Directory ログイン監査イベントを利用してユーザ ログイン情報を収集します。CDA が適切に動作するには、CDA が Active Directory に接続し、ユーザ ログイン情報を取得できる必要があります。
次の手順は、Active Directory ドメイン コントローラで実行する必要があります。
1. Active Directory のバージョンがサポートされ(「サポートされる Active Directory バージョン」を参照)、Active Directory ドメイン コントローラと CDA の間にネットワーク接続があることを確認します(「接続要件」を参照)。
2. 該当する Microsoft のパッチが Active Directory ドメイン コントローラにインストールされていることを確認します。
a. http://support.microsoft.com/kb/958124
このパッチは、CDA がドメイン コントローラと正常な接続を確立するのを妨げる Microsoft WMI でのメモリ リークを解消します(CDA 管理者は、CDA Active Directory ドメイン コントローラの GUI ページでこの問題を体験する場合があります。この GUI ページでは、接続が正常に確立されたときにステータスが「up」になる必要があります)。
b. http://support.microsoft.com/kb/973995
このパッチは、Microsoft WMI の別のメモリ リークを解消します。このメモリ リークは、Active Directory ドメイン コントローラが必要なユーザ ログイン イベントをドメイン コントローラのセキュリティ ログに書き込むのを散発的に妨げます。結果として、CDA はこのドメイン コントローラからすべてのユーザ ログイン イベントを取得できない場合があります。
a. http://support.microsoft.com/kb/981314
このパッチは、Microsoft WMI のメモリ リークを解消します。このメモリ リークは、Active Directory ドメイン コントローラが必要なユーザ ログイン イベントをドメイン コントローラのセキュリティ ログに書き込むのを散発的に妨げます。結果として、CDA はこのドメイン コントローラからすべてのユーザ ログイン イベントを取得できない場合があります。
b. http://support.microsoft.com/kb/2617858
このパッチは、Windows Server 2008 R2 での予期しない起動やログイン プロセスの遅れを解消します。
a. http://support.microsoft.com/kb/2591403
これらのホットフィックスは、WMI サービスおよび関連コンポーネントの動作と機能に関連付けられます。
3. Active Directory がユーザ ログイン イベントを Windows セキュリティ ログに記録するのを確認します。
「監査ポリシー」(「グループ ポリシーの管理」設定の一部)が、正常なログインによって、Windows セキュリティ ログに必要なイベントが生成されるように設定されていることを確認します(これはデフォルトの Windows 設定ですが、この設定が適切であることを明示的に確認する必要があります)。監査ポリシーの設定を参照してください。
4. Active Directory に接続するために CDA が使用する十分な権限を持つ Active Directory ユーザが設定されている必要があります。CDA パッチ 2 では、このユーザが Active Directory ドメインの管理グループのメンバーであるかどうかを選択できます。次の手順に従って、管理ドメイン グループのユーザ、または管理ドメイン グループではないユーザに対して権限を定義します。
– Active Directory ユーザが Domain Admin グループのメンバーである場合に必要な権限
– Active Directory ユーザが Domain Admin グループのメンバーでない場合に必要な権限
5. CAD によって使用される Active Directory ユーザは、NTLMv1 または NTLMv2 のいずれかによって認証を受けることができます。CDA と Active Directory ドメイン コントローラ間の正常な認証済み接続を確実に行うために、Active Directory NTLM の設定が CDA NTLM の設定と合っていることを確認する必要があります。図 2-1 に、すべての Microsoft NTLM オプションを示します。CDA が NTLMv2 に設定される場合、図 2-1 に記載された 6 つのオプションがすべてサポートされます。NTLMv1 をサポートするように CDA が設定されている場合、最初の 5 つのオプションだけがサポートされます。これも 表 2-4 に要約されています。
|
|
|
---|---|---|
6. Active Directory ドメイン コントローラで dllhost.exe へのトラフィックを許可するファイアウォール ルールを作成していることを確認します。
「監査ポリシー」(「Group Policy Management」の設定の一部)が、正常なログオンによってその AD ドメイン コントローラ マシンの Windows セキュリティ ログに必要なイベントが生成されるように設定されていることを確認します(これは Windows のデフォルト設定ですが、この設定が適切であることを明示的に確認する必要があります)。
手順 1 [Start] > [Programs] > [Administrative Tools] > [Group Policy Management] を選択します。
手順 2 [Domains] で関連するドメインに移動し、ナビゲーション ツリーを展開します。
手順 3 [Default Domain Controller Policy] を選択し、右クリックして、[編集] を選択します。
手順 4 [Default Domain Controllers Policy] > [Computer Configuration] > [Policies] > [Windows Settings] > [Security Settings] を選択します。
手順 5 [監査ポリシー] の項目設定が変更されている場合は、「 gpupdate /force 」を実行して新しい設定を強制的に有効にする必要があります。
次の Active Directory のバージョンには、特別な権限は必要ありません。
Windows 2008 R2、Windows 2012 および Windows 2012 R2 の場合、ドメイン管理グループは、デフォルトで Windows オペレーティング システムの特定のレジストリ キーを完全に制御することができません。CDA を動作させるには、Active Directory の管理者は、Active Directory ユーザに次のレジストリ キーに対する完全制御権限を提供する必要があります。
完全な制御を許可するには、まず Active Directory 管理者がキーの所有権を取得する必要があります。次の手順を実行します。
手順 1 キーを右クリックして [オーナー(Owner)] タブに移動します。
Windows 2012 R2 で動作する CDA の場合、Active Directory 管理者は、まず Active Directory ユーザに次のレジストリ キーに対する完全制御権限を提供する必要があります。
Active Directory ユーザがドメイン管理グループの一部ではなく、ドメイン ユーザ グループの一部である場合は、次の権限も必要です。
CDA がドメイン ユーザを操作する場合、特定のレジストリ キーを手動で追加する必要があります。これらのレジストリの変更は、CDA とドメイン コントローラの間に有効な接続を確立し、ユーザのログイン認証イベントを取得するために必要です。CDA では、ドメイン コントローラ上またはドメイン内のマシン上へのエージェントのインストールは必要ありません。
(注) ドメイン管理者権限を使用しているにもかかわらず、Windows 2012 R2 に接続しているときはこれらのレジストリ エントリがまだ必要であることが判明しています。これらがないと、サーバは CDA 接続試行をリセットします。
変更は、次のレジストリのスクリプトに記述されています。Active Directory 管理者は、これを.reg 拡張子のテキスト ファイルにコピーして貼り付け、ダブル クリックしてレジストリを変更することも可能です。レジストリ キーを次のように追加するには、ルート キーのオーナーである必要があります。
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"AppID"="{76A64158-CB41-11D1-8B02-00600806D9B6}"
[HKEY_CLASSES_ROOT\AppID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
[HKEY_CLASSES_ROOT\Wow6432Node\AppID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"DllSurrogate"=" "
Active Directory ユーザは、ドメイン コントローラで DCOM(リモート COM)を使用する権限がなければなりません。 dcomcnfg ツールを使用してこれを実行できます。
手順 1 コマンドラインから dcomcnfg ツールを起動します。
手順 2 [Component Services] を展開します。
手順 3 [Computers] を展開し、[My Computer] をクリックします。
手順 4 メニュー バーで [Action] を選択し、[properties] をクリックし、[COM Security] をクリックします。
手順 5 アクセスおよび起動の両方に対して CDA アカウントが許可権限を持っていることを確認します。Active Directory ユーザは、4 つのオプション([Access Permissions] および [Launch and Activation Permissions] の両方に対する [Edit Limits] と [Edit Default])のすべてに追加される必要があります。図 2-2 を参照してください。
手順 6 [アクセス権限(Access Permissions)] および [起動およびアクティベーションの権限(Launch and Activation Permissions)] の両方に対してローカルおよびリモート アクセスをすべて許可します。
図 2-2 [My Computer Properties]
図 2-3 [Access Permissions] のローカルおよびリモート アクセス
図 2-4 [Launch and Activation Permissions] のローカルおよびリモート アクセス
Active Directory ユーザには、デフォルトでメソッドの実行およびリモートの有効化の権限がありません。これらは wmimgmt.msc MMC コンソールを使用して付与することができます。
手順 1 [Start] > [Run] をクリックし、wmimgmt.msc と入力します。
手順 2 [WMI Control] を右クリックし、[プロパティ] をクリックします。
手順 3 [Security] タブで [Root] を展開し、[CIMV2] を選択します。
手順 5 図 2-5 で示すように、Active Directory ユーザを追加し、必要な権限を提供します。
図 2-5 WMI Root\CIMv2 名前空間の必要な権限
Windows 2008 以降では、Event Log Readers と呼ばれるグループにユーザを追加することで実行できます。
Windows のすべての旧バージョンでは、レジストリ キーを次のように編集することで実行できます。
手順 1 セキュリティ イベント ログへのアクセスを委任するために、アカウントの SID を見つけます。
手順 2 すべての SID アカウントを表示するには、図 2-6 に示すように、コマンド ラインから次のコマンドを使用します。
特定のユーザ名とドメインに対して、次のコマンドを使用することもでます。
wmic useraccount where name=“cdaUser” get domain,name,sid
手順 3 SID を見つけ、レジストリ エディタを開き、次の場所を参照します。
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Eventlog
手順 4 [セキュリティ] をクリックし、[CustomSD] をダブルクリックします。図 2-7 を参照してください。
たとえば、cda_agent アカウント(SID:S-1-5-21-1742827456-3351963980-3809373604-1107)への読み取りアクセスを許可するには、「(A;;0x1;;;S-1-5-21-1742827456-3351963980-3809373604-1107)」と入力します。
手順 5 DC 上で WMI サービスを再起動します。次の 2 とおりの方法で WMI サービスを再起動できます。
b. Services.msc を実行します(これにより、Windows サービス管理ウィンドウが開きます)。
Windows サービス管理ウィンドウで、「Windows Management Instrumentation」サービスを検索し、右クリックして [再起動] を選択します。
Context Directory Agent は ISO イメージとしてパッケージされています。Cisco.com からパッケージをダウンロードして、それを専用の X86 マシンまたは VMWare ESX サーバにインストールすることができます。
CDA は、VMWare ESX バージョン 4.0、4.1、および 5.0 をサポートします。
Context Directory Agent をインストールするには、次の手順を実行します。
手順 1 CDA ISO イメージ cda-1.0.0.xxx.i386.iso をダウンロードして、それをローカル リポジトリに保存します。
手順 3 DVD を挿入して、光学ドライブからイメージをインストールするオプションを選択します。
CDA パッケージのインストールが開始します。インストールが完了すると、マシンがリブートします。ブート シーケンスが完了すると、次のプロンプトが表示されます。
**********************************************
Please type ‘setup’ to configure the appliance
**********************************************
手順 4 プロンプトに ‘setup’ と入力して、セットアップ プログラムを開始します。ネットワーキング パラメータと最初のクレデンシャルの入力を求めるプロンプトが表示されます。
次は、サンプルのセットアップ プログラムとデフォルト プロンプトを示しています。
localhost.localdomain login: setup
Enter IP Address []: 192.168.10.10
Enter IP netmask []:
255.255.255.0
Enter IP default gateway []: 192.168.10.100
Enter default DNS domain []: cisco.com
Enter primary nameserver []: 200.150.200.150
Enter secondary nameserver? Y/N: n
Enter primary NTP server [time.nist.gov]: clock.cisco.com
Enter secondary NTP server? Y/N: n
Enter system timezone [UTC]: UTC
Bringing up the network interface...
Pinging the primary nameserver...
Do not use ‘Ctrl-C’ from this point on...
Application bundle (cda) installed successfully
=== Initial setup for application: cda ===
手順 5 CDA の利用可能な最新のパッチをインストールします。Context Directory Agent パッチのインストールを参照してください。
手順 6 マシンがリブートした後、CDA CLI にログインしてパッケージのインストールを確認できます。次はサンプルの確認手順を示しています。
cda Cisco Context Directory Agent
/admin# show application status cda
CDA application server is running PID:2840
手順 7 これで、CDA ユーザ インターフェイスにログインして、CDA の設定を開始できるようになりました。
(注) 初期セットアップ プログラム中に指定したユーザ名とパスワードは、CLI と GUI の両方に使用できます。ユーザ インターフェイスを使用して GUI パスワードを変更しても、CLI パスワードは変更されず、その逆の場合も同じです。
Cisco.com から最新の CDA 1.0 パッチをダウンロードし、インストールできます。
手順 1 パッチを CDA にアップロードできるようにリポジトリを作成します。リポジトリの作成方法の手順については、“repository” sectionを参照してください。
手順 2 作成したリポジトリに最新の CDA パッチをダウンロードします。
手順 3 “patch install” sectionに従って CDA パッチをインストールします。
手順 4 次の手順に従って、パッチがインストールされていることを確認します。
CDA は、AD エージェントと互換性があります。AD エージェントがネットワークにすでにデプロイされている場合、同様の対応する設定を使用して、CDA によってそれを置き換えることができます。ID ベースのファイアウォール ソリューションの他のコンポーネント(Active Directory サーバと Identity コンシューマ デバイス(ASA/WSA))で、ソフトウェアの変更やアップグレードを行う必要はありません。
AD エージェントから CDA に遷移する前に、次の AD エージェント設定の詳細を記録しておきます。
AD エージェント コマンド adacfg options list を使用
AD エージェント コマンド adacfg syslog list を使用
AD エージェント コマンド adacfg dc list を使用(パスワードを表示しない)
AD エージェント コマンド adacfg client list を使用(共有秘密を表示しない)
上記のコマンドのすべての構文と出力例については、『 Installation and Setup Guide for the Active Directory Agent, Release 1.0 』を参照してください。
既存の AD エージェント アプリケーションに対応するように CDA をインストールおよび設定します。
CDA の履歴は、AD エージェントの dcHistoryTime に相当します(CDA ではデフォルトで 10 秒ですが、AD エージェントではデフォルトで 24 時間である点が異なります)。
CDA のユーザ ログイン有効期限は、AD エージェントの userLogonTTL に相当します(デフォルトの 24 時間は同じです)。
同じホスト名/IP アドレスを使用して AD エージェント サーバを CDA サーバと置き換える場合、コンシューマ デバイス(ASA/WSA)設定を変更する必要はなく、コンシューマ デバイスは自動的に CDA に接続して、ID マッピング情報を取得します。
これとは異なり、新たに CDA サーバを導入に追加する場合、その新しい CDA サーバを指すように、コンシューマ デバイスの設定を更新する必要があります。詳細については、Cisco.com の ASA および WSA の資料を参照してください。