バージョン 4.13 以降、Cisco Security Manager は、VPN 接続の複数証明書認証に関する ASA 9.7.1 の機能をサポートします。ASA のリリース 9.7.1 では、VPN クライアントのお客様に対する複数証明書認証のサポートが導入されました。その結果、クライアントは 2 つのクライアント証明書を使用してリモート VPN ユーザーを認証できるようになりました。2 つのクライアント証明書は、1 つのユーザー証明書と 1 つのマシン証明書の組み合わせ、または 2 つのユーザー証明書の組み合わせにすることができます。セキュリティを考慮して、2 つのマシン証明書による認証はサポートされていません。複数証明書認証は、SSL VPN と IPsec VPN の両方で機能します。

Cisco Security Manager 4.13 で複数証明書認証のサポートを有効にするには、AAA 認証方式を適切に指定し（[AAA] タブ（[Connection Profiles]）を参照）、DAP ポリシーを設定する必要があります（[DAP エントリの追加（Add DAP Entry）]/[DAP エントリの編集（Edit DAP Entry）] ダイアログボックスの [マルチ証明書認証（Multiple Certificate Authentication）]を参照）。

デバイスを検出しようとするとエラーが発生し、デバイスから取得したセキュリティ証明書が拒否されたことがエラー メッセージに示される場合、証明書を更新する必要があります。これには、次のいずれかの方法を使用できます。

• IPS デバイスの場合にのみ、[管理（Manage）] > [IPS] > [IPS証明書（IPS Certificates）] を選択して、証明書を同期します。また、証明書の再生成が必要になる場合があります。詳細については、IPS 証明書の管理を参照してください。

• 次のいずれかの操作を実行して、証明書に必要なサムプリントを手動で入力します。

  • [ツール（Tools）] > [Security Managerの管理（Security Manager Administration）] > [デバイス通信（Device Communication）] を選択します。[証明書の追加（Add Certificate）] をクリックし、デバイスの IP アドレスを入力してから、エラーメッセージに表示されたサムプリントをコピーして [証明書サムプリント（Certificate Thumbprint）] フィールドに貼り付けます。

  • デバイスを右クリックし、[デバイスのプロパティ（Device Properties）] > [資格情報（Credentials）] を選択します。エラー メッセージに表示されたサムプリントをコピーして、[Authentication Certificate Thumbprint] フィールドに貼り付けます。

[Add New Device] または [Add From Configuration File] オプションを使用して新しいデバイスを追加するとき、および再検出を実行するときは、サムプリントを手動で入力する必要があります。[Add New Device From Network] または [Add Device From File] オプションを使用して新しいデバイスを追加するときには、この操作は不要です。

• デバイスの追加時に証明書を自動的に取得するように SSL 証明書を設定します。IPS、ルータ、および ASA/PIX/FWSM デバイスには、それぞれ異なる設定を選択できます。これらの設定を行うには、[ツール（Tools）] > [Security Managerの管理（Security Manager Administration）] > [デバイス通信（Device Communication）] を選択し、[SSL証明書パラメータ（SSL Certificate Parameters）] グループを参照します。

デバイスと Security Manager の時刻設定が同期していない場合、（インベントリにデバイスを追加したり、インベントリ内にすでに存在するデバイス上のポリシーを再検出して）デバイス上のポリシーを検出しようとすると、証明書がまだ有効になっていないというエラー メッセージが表示されることがあります。

Security Manager サーバの設定時刻がデバイスの設定時刻よりも遅れている場合、有効期間の開始時刻が Security Manager の時刻設定よりも進んでいると、Security Manager はデバイス証明書を検証できません。設定されているタイム ゾーンがデバイスと Security Manager で同じであっても、夏時間（サマータイム）の設定が異なっていると、無効な証明書のエラーが発生します。この問題を解決するには、タイム ゾーンが同じであるかどうかにかかわらず、夏時間の時刻設定がデバイスと Security Manager で同じになっていることを確認します。夏時間の設定後に、デバイスのクロックを Security Manager と同期して、どちらにも同じ時刻が表示されるようにします。

最善の結果を得るために、デバイスと Security Manager で同じタイム ゾーンを設定し、証明書の検出後に、必要に応じてあとからタイム ゾーンを変更することを推奨します。

トランスポート プロトコルとして SSH を使用するデバイスの場合、Security Manager は、各デバイスで使用する適切な SSH バージョン（1.5 または 2）を自動的に検出します。SSH バージョン 2 の接続中、Security Manager は暗号化アルゴリズムまたは暗号をデバイスと自動的にネゴシエートします。また、キーが変更された場合、Security Manager はデバイスの SSH 公開キーを自動的に上書きします。このため、通常は SSH 接続の問題が発生することはありません。

実際に SSH 接続の問題が発生した場合は、次の修正策を考慮してください。

• デバイスの公開キーが変更され、キーの問題が原因で SSH 接続が失敗する場合は、Security Manager サーバ上の Program Files/CSCOpx/MDC/be/tmp/.shh/known_hosts ファイルからデバイスのキーを削除してから、操作を再試行します。

• Security Manager は、デフォルトの暗号化アルゴリズムとして Triple Data Encryption Standard（3DES; トリプル データ暗号規格）を使用します。このアルゴリズムが使用中のデバイスに適していない場合は、デバイスの設定を変更するか、DCS.ssh.encipher プロパティで適切なアルゴリズムを指定するように Program Files/MDC/athena/config/DCS.properties ファイルを更新します（不明な点があれば、Cisco TAC にお問い合わせください）。このファイルを変更した場合は、Security Manager デーモン マネージャを再起動する必要があります。

Security Manager がデバイスと通信できない場合（デバイスのログイン、検出、展開、その他の処理で失敗するなど）、次の領域を確認し、問題を特定して解決してください。

• デバイスが動作していることを確認します。

• どのトランスポート プロトコルが選択されているかを確認します。デバイスで受け入れるように設定されているプロトコルを選択する必要があります。ほとんどのデバイスの場合、プロトコルは [デバイスプロパティ（Device Properties）] の [全般（General）] ページ（[ツール（Tools）] > [デバイスプロパティ（Device Properties）] > [全般（General）] を選択）で選択します。IPS デバイスの場合は、デバイス プロパティの [Credentials] ページで [IPS RDEP] モードが選択されています。

K8 または K9 暗号イメージを持たない IOS デバイスの場合は、プロトコルとして Telnet を選択する必要があります。

デバイスを追加する方法によっては、デフォルト以外のトランスポート プロトコルを選択することもできます。デバイスクラスに対してデフォルトのトランスポートプロトコルを設定するには、[ツール（Tools）] > [Security Manager管理（Security Manager Administration）] > [デバイス通信（Device Communications）] を選択します。

• [Device Properties General] ページで、ホスト名、ドメイン名、および IP アドレスが正しいことを確認します。デバイスのホスト名、アカウント、およびクレデンシャルのポリシーによって、デバイスで設定される実際の名前およびクレデンシャルが定義されます。ただし、ポリシーはデバイス通信には使用されません。デバイス通信に使用しているクレデンシャルに影響を与えるポリシーを変更した場合は、デバイス プロパティも手動で更新する必要があります。

• Security Manager サーバから DNS 名を解決できることを確認します。サーバ上の DNS 設定を修正する必要があることもあります。

• Security Manager でデバイスのクレデンシャルを調べて、クレデンシャルが正しいこと、およびサーバとデバイスの間にルートが存在することを確認します。デバイスを右クリックし、[デバイスプロパティ（Device Properties）] を選択します。次に [クレデンシャル（Credentials）] タブを選択して、[テスト接続（Test Connectivity）] ボタンをクリックします。接続が失敗した場合は、エラー メッセージを確認して、接続の問題かクレデンシャルの問題かを判断します。必要に応じて、デバイス プロパティ内のクレデンシャルを更新します。

デバイスを追加する方法でクレデンシャルが必要とされる場合は、新しいデバイスを追加するときに、New Device ウィザードでクレデンシャルが定義されます。次の点を考慮してください。

• SSH 接続および Telnet 接続にはプライマリ クレデンシャルが使用される。

• HTTP 接続および SSL 接続には、HTTP/HTTPS クレデンシャルが使用されます。ただし、[プライマリクレデンシャルを使用（Use Primary Credentials）] を選択した場合は例外で、これらの接続にもプライマリクレデンシャルが使用されます。

• バージョン 4.11 以降、Security Manager は、MD5 アルゴリズムを使用するデバイス SSL 証明書をサポートしていません。デバイスの SSL が MD5 アルゴリズムを使用している場合、デバイスを Security Manager に追加しようとすると、Security Manager にエラーが表示されます。このエラーは、セキュリティの脆弱性を理由として、JRE がデフォルトで MD5 アルゴリズムを無効にするために発生します。これを解決するには、デバイスの SSL 証明書により高度な暗号化アルゴリズムを使用する必要があります。

• バージョン 4.19 以降、Cisco Security Manager は、DES アルゴリズムを使用したデバイス SSL 証明書をサポートしていません。デバイスの SSL が DES アルゴリズムを使用している場合、デバイスを Security Manager に追加しようとすると、Security Manager にエラーが表示されます。このエラーは、セキュリティの脆弱性を理由として、JRE がデフォルトで DES アルゴリズムを無効にするために発生します。これを解決するには、デバイスの SSL 証明書により高度な暗号化アルゴリズムを使用するか、以下の手順に従う必要があります。

  • Security Manager サーバーサービスを停止します。

  • 必ず MDC\vms\jre\lib\security\java.security プロパティのバックアップを取ってください。

  • プロパティで、「jdk.tls.disabledAlgorithms=SSLv3, DES, MD5withRSA, DH keySize <1024, \ EC keySize < 224, RC4_40, 3DES_EDE_CBC」を見つけ、リストから「DES」を削除します。

  • Security Manager サーバーサービスを再度開始します。

ASA ソフトウェア リリース 8.3+ では、旧バージョンの ASA ソフトウェアに比べ、必要なデバイス メモリが大幅に増加しています。最小メモリ要件を満たしていない ASA デバイスをアップグレードすると、アップグレード プロセスで問題が通知され、デバイスは、最小メモリ要件が満たされるまで syslog メッセージを定期的に送信します。

最小メモリ要件を満たしていない ASA デバイスは正常に動作できないため、インベントリへのデバイスの追加、およびインベントリからのポリシーの検出がユーザに許可されていても、Security Manager は設定をこれらのデバイスに展開しません。ただし、メモリを追加する前にポリシーをデバイスに展開しようとすると、デバイスが最小メモリ要件を満たしていないことを示す展開エラーが発生し、展開は失敗します。

エラーを解決する最善の方法は、メモリをデバイスに追加することです。ASA デバイスおよびメモリアップグレードの可能性の詳細については、https://www.cisco.com/c/ja_jp/products/security/asa-firepower-services/index.html を参照してください。

また、ASA ソフトウェア バージョンをダウングレードすることもできます。この場合は、インベントリからデバイスを削除してから再びインベントリに追加したあと、ポリシーを検出する必要があります。

[ツール（Tools）] > [Security Manager管理（Security Manager Administration）] > [展開（Deployment）] ページで [未参照のオブジェクトグループをデバイスから削除（Remove Unreferenced Object Groups from Device）] オプションを有効にすると、Security Manager は、Security Manager によって管理または検出されたポリシーで使用されていないオブジェクトを展開中に削除します。Security Manager によって検出または管理されていないポリシーがそのようなオブジェクトを使用している場合、Security Manager は展開中にそのオブジェクトを削除しようとします。このような場合、オブジェクトが使用されているためオブジェクトを削除できなかったことを示すトランスクリプトエラーが表示されて、展開が失敗します。正常に展開するには、[未参照のオブジェクトグループのデバイスからの削除を無効化（disable the Remove Unreferenced Object Groups from Device）] オプションを無効にします。

Security Manager で設定可能な、デバイスへのアクセスを妨げるようなポリシーが数多くあります。これがセキュリティのポイントであり、望ましくないホストがネットワークやネットワーク デバイスに侵入できないようにします。

ただし、間違って Security Manager サーバがデバイスからロックアウトされてしまうと、Security Manager が設定をデバイスに展開できなくなったり、デバイスを管理できなくなることがあります。展開後に Security Manager がデバイスにアクセスできなくなっていることが判明した場合は、デバイスが動作中であること、またはデバイスが正常に機能していることを確認してから、次のポリシーをよく調べて、ポリシーがロックアウトの原因となっていないかどうかを確認します。

• [ファイアウォール（Firewall）] > [アクセスルール（Access Rules）] または [ファイアウォール（Firewall）] > [ゾーンベースのファイアウォールルール（Zone Based Firewall Rules）]：これらのポリシーを使用する場合は、ルールが Security Manager サーバーからの管理トラフィックを許可する必要があります。少なくとも、HTTP、HTTPS、SSH、および Telnet を許可することを検討してください。Security Manager に対する必要なアクセスを定義する共有ポリシーを作成して、すべてのデバイスにそれを適用することを検討してください。これらのポリシー内にルールを作成した場合、明示的に許可されていないトラフィックはすべて拒否されるという暗黙のルールがポリシーの最後に追加されます。

• [NATポリシー（NAT policies）]：デバイス上で変換対象の元のアドレスとしてローカルアドレスを使用していないことを確認します。このアドレスを変換すると、Security Manager とデバイス間で送信される管理トラフィックが変換されて、中断されることがあります。

• [ルータ上のデバイスアクセスポリシー（Device Access policies on routers）]：デバイスへのデバイスアクセスポリシーの割り当てを解除して再展開したあと、Security Manager がデバイスとの接続を解除することがあります。デバイス アクセス ポリシーを使用して、デバイスにアクセスするためのイネーブル パスワードを定義できます。このポリシーの割り当てを解除して再展開すると、パスワードがデバイスから削除されます。この場合は通常、デバイスによってパスワードがデフォルトに戻されます。ただし、Security Manager に認識されない追加パスワード（ライン コンソール パスワードなど）がデバイスに含まれる場合もあります。この追加パスワードが存在する場合は、デフォルト パスワードではなくこのパスワードに戻されます。この場合、Security Manager はこのデバイスを設定できません。このため、デバイス アクセス ポリシーを使用してデバイス上にイネーブル パスワードやイネーブル シークレット パスワードを設定する場合は、ポリシーの割り当てを解除してから、次の展開までに新しいポリシーを割り当ててください。

• [サイト間VPN（Site-to-Site VPNs）]：VPN 内のスポークとの通信を失った場合、Security Manager サーバーがハブの保護対象ネットワーク内からスポーク上の外部インターフェイスと通信するときに、問題が発生する可能性があります。ハブデバイスを Security Manager に追加するときは、ハブの保護対象ネットワークの外側にある管理 IP アドレスを定義することを推奨します。

• [プラットフォーム（Platform）] > [デバイス管理（Device Admin）] > [デバイスアクセス（Device Access）] > [許可ホスト（Allowed Hosts）]：IPS デバイスの場合、[許可ホスト（Allowed Hosts）] ポリシーでは、センサーに接続できるホストを指定します。このポリシーには、Security Manager サーバを含める必要があります。

問題：（Site-to-Site VPN Manager またはルーティングポリシーを使用して）VPN トポロジによって使用されているルーティングプロセスへの変更を定義および展開した場合、行った変更は、デバイスで設定されている CLI コマンドには反映されません。

解決策：ルーティングプロセスを組み込む VPN トポロジ（GRE 完全メッシュなど）を検出した場合、Security Manager は、Site-to-Site VPN Manager に GRE Modes ポリシーおよび関連するルーティングポリシーを移入します。ただし、Security Manager でこれらのポリシーの 1 つに対して行われた変更が他のポリシーに自動的に反映されることはないため、展開後に予期しない結果が起こることがあります。したがって、Site-to-Site VPN Manager で保護対象の IGP に変更を行った場合は、[プラットフォーム（Platform）] > [デバイスでのルーティング（Routing in Device）] ビューを選択してデバイスのルーティングポリシーに必要な変更を行ってください。同様に、ルーティング ポリシーを直接変更した場合も、Site-to-Site VPN Manager で必要な変更を行ってください。

ルータ プラットフォーム ポリシーおよび VPN ポリシーを、設定ファイルにすでに展開したあとで動作中のデバイスに展開すると、予期しない結果が発生することがあります。

この問題は、ルータ プラットフォーム ポリシーと VPN ポリシーを使用した展開方式（デバイスへの展開およびファイルへの展開）を混合して使用すると、発生することがあります。Security Manager では、これらのポリシー タイプに対する使用可能なすべての CLI コマンドが管理されるわけではないため、設定されたコマンドのスナップショットが維持され、他のすべてのコマンド（Security Manager でサポートされていないコマンドや、Security Manager で設定されていないポリシー内のサポート対象コマンドを含む）はデバイスでその状態のまま残ります。

展開が終わるたびに、Security Manager では、各デバイスに展開されたポリシーのスナップショットが作成されます。このスナップショットは、次の展開時に、デバイスに展開される設定変更リストを生成するために使用されます。デバイス 1 つにつき、一度に 1 つだけスナップショットが維持されます。

この例に示すように、ルータ プラットフォーム ポリシーと VPN ポリシーを使用した展開方式を混合すると、予期しない結果が発生することがあります。

1. 動作中のデバイスに対してルータ プラットフォーム ポリシー A を設定します。展開が完了すると、Security Manager によって、ポリシー A を持つそのデバイスのスナップショットが作成されます。

2. 次に、ポリシー A に置き換わるポリシー B を設定します。ただし、ポリシー B は、デバイスではなくファイルに展開します。この展開が完了すると、Security Manager によって、ポリシー A を持つ以前のスナップショットに置き換わるポリシー B を持つスナップショットが作成されます。ただし、ポリシー B をデバイスに展開していないため、ポリシー A を無効にするために必要な CLI コマンドは展開されていません。ポリシー A はデバイス上に展開されたままです。

3. 設定ファイル内の変更をデバイスにコピーせずに、再びデバイスに展開します。ポリシー A を持つスナップショットはもう存在しないため、Security Manager は、デバイスからポリシー A を無効にするために必要なコマンドを生成できません。

ポリシー A はルータ プラットフォーム ポリシーであるため、次のいずれの結果になる可能性があります。

• 最後の展開のポリシーによってポリシー A が上書きされる。

• デバイスで両方のポリシーが定義されることになる。

• 2 つのポリシーが共存できないため、展開が失敗する。

このため、動作中のデバイスでの作業中にファイルに展開する場合は、設定変更をファイルからデバイスにコピーしてから、デバイスへの追加の展開を実行することを強く推奨します。

次に、設定を Cisco IOS ルータに展開するときに発生する可能性のある問題を示します。

インターフェイス設定の展開に失敗

問題：ルータへのインターフェイス設定の展開が失敗します。

解決策：Security Manager は、インターフェイスポリシーをサポートするための適切なタイプのインターフェイスカードまたは共有ポートアダプタ（SPA）がルータにインストールされているか、または適切なライセンスが設定されているかどうかを検証できません。インターフェイス ポリシーを変更せずにインターフェイス カードを追加または削除すると、展開エラーが発生することがあります。ベスト プラクティスとして、Security Manager が適切なインターフェイス機能を検出できるように、インターフェイス モジュールまたは SPA を変更するたびに必ずルータからインベントリを検出することを推奨します。

レイヤ 2 インターフェイス定義の展開

問題：インターフェイスポリシーにレイヤ 2 インターフェイスの定義が含まれていると、展開に失敗します。

解決策：レイヤ 2 インターフェイスは、IP アドレスなどのレイヤ 3 インターフェイス定義をサポートしていません。レイヤ 2 インターフェイスにレイヤ 3 を定義していないことを確認してください。

VPN トラフィックが暗号化されずに送信される

問題：VPN を介して暗号化して送信する必要のあるトラフィックが、暗号化されずに送信されます。

解決策：VPN トラフィックに対して NAT を実行していないことを確認してください。VPN トラフィックに対してアドレス変換を実行すると、トラフィックが暗号化されなくなり、VPN トンネル経由で送信されなくなります。ダイナミック NAT ルールを定義する際は、IPSec に対して NAT を実行する場合でも、[Do Not Translate VPN Traffic] チェックボックスが選択されていることを確認してください（このオプションを設定しても、重複するネットワークから到着したアドレスの変換は行われます）。

このオプションは、サイト間 VPN に対してだけ使用できます。リモート アクセス VPN の場合は、VPN トラフィックを含むフローを明示的に拒否する ACL オブジェクトを作成し、この ACL を NAT ポリシー内にダイナミック ルールの一部として定義する必要があります。詳細については、[NAT] ページ - [Dynamic Rules]を参照してください。

ADSL または PVC ポリシーを展開できない

問題：ADSL または PVC ポリシーの展開が失敗します。

解決策：ポリシー定義で適切な ATM インターフェイス カード タイプを選択していることを確認してください。Security Manager は、適切なカード タイプが不明な場合、ポリシー定義を正しく検証できません。これにより、展開が失敗することがあります。

DHCP トラフィックが送信されない

問題：DHCP ポリシーをデバイスに展開した後も、DHCP トラフィックが送信されません。

解決策：デバイス上のアクセスルールによりブートストラッププロトコル（BootP）トラフィックがブロックされていないかどうかを確認してください。このようなルールが設定されていると、DHCP トラフィックは送信されません。

NAC がルータ上に実装されない

問題：NAC ポリシーがルータに展開されているにもかかわらず、ネットワーク アドミッション コントロールがルータ上に実装されません。

解決策：ルータ上のデフォルト ACL で、EAP over UDP トラフィックの NAC ポリシーで定義されているポートを経由する UDP トラフィックが許可されていることを確認してください。これは、NAC が Cisco Trust Agent（CTA）とネットワーク アクセス デバイス（NAD）の間の通信に使用するプロトコルです。CTA は、インストールされているエンドポイント デバイスのポスチャ クレデンシャルを提供する NAC クライアントであり、NAD は、検証のためにポスチャ クレデンシャルを AAA サーバに中継するデバイス（この場合はルータ）です。EAP over UDP トラフィックに使用されるデフォルト ポートは 21862 ですが、このポートは NAC ポリシーの一部として変更できます。デフォルト ACL により UDP トラフィックがブロックされている場合、EAP over UDP トラフィックも同様にブロックされるため、NAC は実装されません。

「Error Writing to Server」または「HTTP Response Code 500」メッセージとともに展開が失敗する

問題：Cisco IOS ルータへの展開が失敗し、「Error Writing to Server」または「Http Response Code 500」というエラーメッセージが表示されます。

解決策：SSL をトランスポートプロトコルとして使用して設定を Cisco IOS ルータに展開する場合、設定は複数の設定バルクに分割されます。この設定バルクのサイズは、プラットフォームによって異なります。Security Manager が、そのデバイスで設定されている SSL チャンクサイズを超える設定バルクを展開しようとすると、展開は失敗し、「Error Writing to Server」または「Http Response Code 500」というエラーメッセージが表示されます。

これを解決するには、次の手順を実行します。

1. Security Manager サーバで、インストール先ディレクトリ（通常は C:\Program Files）\CSCOpx\MDC\athena\config フォルダから DCS.properties ファイルを開きます。

2. DCS.IOS.ssl.maxChunkSize=<value of the configuration bulk> を見つけます。

3. 設定バルクの値を小さくします。

4. CiscoWorks Daemon Manager を再起動します。

（注）	バージョン 4.17 以降、Cisco Security Manager は引き続き Cisco Catalyst スイッチの機能をサポートしますが、拡張機能はサポートしていません。

次に、Catalyst スイッチおよび Catalyst 6500/7600 サービス モジュールに設定を展開するときに発生する可能性のある問題を示します。

インターフェイス設定の展開に失敗

問題：Catalyst 6500/7600 デバイスへのインターフェイス設定の展開が失敗します。

解決策：一部のインターフェイス設定（速度、デュプレックス、MTU 設定など）は特定のカードタイプに固有のものであり、展開の前に検証されません。展開が正常に行われるように、特定のカード タイプには適切な値を入力してください。

インターフェイス ポリシーの変更後に FWSM セキュリティ コンテキストの展開が失敗する

問題：セキュリティコンテキストとともに FWSM を追加し、そのポリシーを検出します。設定にはインターフェイス エイリアス（allocate interface コマンド）が含まれます。コンテキストのインターフェイス ポリシーを変更したあと、展開が失敗します。

解決策：FWSM に直接接続し、システム実行領域設定から、マッピングされているすべてのインターフェイス名を削除します。また、他のすべてのコンテキストで、マッピングされている名前へのインターフェイス参照を、インターフェイスの VLAN ID で置き換えます。これにより、Security Manager インベントリから FWSM を削除し、再検出できるようになります。

複数のコンテキストを持つ FWSM への展開が失敗する

問題：複数のセキュリティコンテキストを持つ FWSM に展開しようとすると、展開が失敗したり、FWSM のパフォーマンスが一時的に低下したりすることがあります。

解決策：問題は、Security Manager が設定を 1 つのデバイス上にある複数のセキュリティコンテキストに同時に展開しようとしている点です。設定変更によっては、これによりデバイスでエラーが発生して、展開が失敗することがあります。マルチ コンテキスト モードで FWSM を使用する場合は、Security Manager でマルチ コンテキストの FWSM に設定を展開する方法の変更の説明に従って、一度に 1 つずつコンテキストが設定され、設定がシリアルにデバイスに展開されるように、Security Manager を設定します。

内部 VLAN への展開の失敗

問題：Security Manager がデバイスの内部 VLAN リストの範囲に含まれる ID で VLAN を作成しようとすると、展開が失敗します。

解決策：Security Manager は内部 VLAN を検出できません。このため、デバイスの内部 VLAN リストの範囲外にある VLAN ID をユーザーが定義する必要があります。デバイスで show vlan internal usage コマンドを使用して、内部 VLAN のリストを表示します。

IDSM データ ポート VLAN の動作モードの変更時に展開が失敗する

問題：データポート VLAN の動作モードを [Trunk（トランク）]（IPS）から [Capture（キャプチャ）]（IDS）に変更しようとすると、展開が失敗し、次のエラーメッセージが表示されます。

Command Rejected: Remove trunk allowed vlan configuration from data port 2 before configuring capture allowed-vlans

解決策：一部のソフトウェアリリース（12.2(18)SFX4 など）には、正常な変更を妨げるバグがあります。この問題を解決するには、デバイスをリロードしてください。

多数の ACL が含まれる FWSM 設定で展開が失敗する

問題：設定に多数の ACL が含まれている場合、FWSM デバイスへの展開が失敗します。

解決策：これは、ACL コンパイル中に CPU 使用率が高くなったために発生する可能性があります。これを解決するには、次の手順を実行して、CPU 使用率のしきい値制限を再設定します。

1. Security Manager サーバで、インストール先ディレクトリ（通常は C:\Program Files）\CSCOpx\MDC\athena\config フォルダから DCS.properties ファイルを開きます。

2. DCS.FWSM.checkThreshold=False プロパティを見つけます。

3. 値を true に変更します（DCS.FWSM.checkThreshold=True）。

4. CiscoWorks Daemon Manager を再起動します。

5. 設定を再びデバイスに展開します。

値を true に設定したあと、検出および展開によって CPU 使用率が確認されます。CPU 使用率が DCS.FWSM.minThresholdLimit プロパティ内に設定されている値の範囲を超えていると、エラー メッセージが生成されます。デフォルト値は 85 です。

Auto Update Server（AUS）を起動してから、完全に動作可能になる前に展開を実行すると、AUS により管理される複数のデバイスに展開するとき、展開が失敗することがあります。次の操作の実行後は、AUS が起動するまでに時間がかかります。

• 新規インストールまたはアップグレード

• 手動による再起動（停電後など）

• 手動による Cisco Security Manager Daemon Manager サービスの再起動

AUS が完全に動作可能になったかどうかを確認するには、Windows サービスのステータスを確認します。このためには、[スタート（Start）] > [コントロールパネル（Control Panel）] > [管理サービス（Administrative Services）] > [サービス（Services）] を選択してから、CiscoWorks AUS Database Engine サービスのステータスを確認します。このサービスがすでに開始されていれば、展開を再試行してください。

問題：VPN トポロジの説明に認識できない文字が含まれていると、設定の展開とプレビューが失敗することがあります。

解決策：VPN トポロジの説明に認識されない文字を使用しないようにします。他のアプリケーションまたは Web ページからテキストをコピーする場合は、テキストをワードパッドに貼り付け、ワードパッドから CSM テキストボックスにテキストをコピーします。

次の質問と回答で、Cisco Configuration Engine（CNS）により管理されるデバイスのセットアップ時に発生する可能性のある問題と、その解決方法について説明します。

質問：Configuration Engine の展開が失敗するのはなぜですか。

回答：Configuration Engine のすべてのバージョンが互換性をもって機能するわけではありません。Configuration Engine をデバイス インベントリに追加するとき、Security Manager では Configuration Engine 上で動作しているソフトウェア バージョンを確認できないため、サポートされていないバージョンをユーザがインベントリに追加してしまう可能性があります。この場合、展開しようとすると、予期しないエラーが発生することがあります。サポートされている Configuration Engine バージョンを実行していることを確認してください（バージョン情報については、http://www.cisco.com/en/US/products/ps6498/prod_release_notes_list.html にあるこのバージョンの Security Manager のリリースノートを参照してください）。

質問：Configuration Engine の Web ページで IOS デバイスをクリックすると、InvalidParameterException が発生するのはなぜですか。

回答：これは想定された動作です。IOS デバイスの場合、Security Manager は展開ジョブを使用して、設定を Configuration Engine の IOS デバイスに関連付けるのではなく、設定を Configuration Engine に展開します。このため、Configuration Engine の Web ページでデバイス名をクリックしても、関連付けられた設定は表示されません。ASA/PIX デバイスの場合、Security Manager は設定を Configuration Engine のデバイスに関連付けます。このため、デバイス名をクリックすると、関連付けられた設定が表示されます。

質問：「com.cisco.netmgmt.ce.websvc.exec.ExecServiceException: [002-01003]]deviceName does not exists?」というエラーが発生するのはなぜですか。

回答：このエラーは、デバイスがまだ Configuration Engine に追加されていないことを示します。Security Manager でロールバックも展開も（いずれもデバイスが自動的に追加されます）実行しておらず、手動でも Configuration Engine にデバイスを追加していない場合、このエラーが表示されます。

質問：「com.cisco.netmgmt.ce.websvc.config.ConfigServiceException: [002-01003]]Device device id is not connected」というエラーが発生するのはなぜですか。

回答：回答は、実行しているセットアップのタイプによって異なります。

• イベントモードセットアップ：Security Manager の [デバイスのプロパティ（Device Properties）] ウィンドウで定義されている Configuration Engine デバイス ID が、ルータで設定されているデバイス ID と一致していることを確認してください（cns id string コマンドを使用）。

• Call Home モード セットアップ：このモードでは、デバイスは Configuration Engine に接続されません。このため、Configuration Engine を使用してデバイス設定を取得することが必要となる Security Manager 操作はいずれもサポートされません。これには、検出、プレビュー設定、表示実行設定、および接続テスト（IOS デバイスの場合はロールバックも）が含まれます。

質問：Configuration Engine により管理される ASA/PIX デバイスへの展開が正常に行われないのはなぜですか。

回答：いくつかの原因が考えられます。

• 設定に無効なコマンドが含まれている。このことをテストするには、Configuration Engine で ASA/PIX デバイスに関連付けられている設定をコピーして、デバイスに直接貼り付けます。

• auto-update server コマンドに無効なユーザー名およびパスワードが含まれている。

• 設定を ASA/PIX デバイスにポーリングするための待機時間が足りなかった。次回のポーリングサイクルがいつ開始されるかを確認するには、show auto コマンドを使用します。

• 以前に同じ ASA/PIX デバイスに対して Configuration Engine サーバを使用していて、現在の作業を開始する前に Configuration Engine サーバからそのデバイスを削除しなかった場合、新しい設定をユーザがデバイスに展開する前に、デバイスがサーバから以前の設定を取得した可能性があります。

• 上記のいずれによっても問題が解決しない場合は、ASA/PIX デバイスで Configuration Engine デバッグ モードを有効にし、次のポーリング サイクル終了後にログでエラーを確認します。

質問：Configuration Engine により管理される ASA/PIX デバイスへの展開が最初は成功したのに、2 回め以降は成功しないのはなぜですか。

回答：最初の展開でプッシュされた設定に自動更新機能に対する不適切な CLI コマンドが含まれていた場合、このようなエラーが発生することがあります。次の点をチェックします。

• auto-update コマンドで Configuration Engine サーバーのユーザー名およびパスワードが適切に定義されてることを確認します。

• デバイス CLI を使用して自動更新サーバーを設定する際に name コマンドを使用した場合、必要な name コマンドを含む FlexConfig を定義したことを確認します。このコマンドは Security Manager で直接サポートされていないため、FlexConfig が必要となります。このため、このコマンドが検出されても、完全な設定には表示されません。Security Manager を使用して AUS ポリシーを設定する場合は、name コマンドは必要ありません。

質問：ASA/PIX デバイスで Configuration Engine をデバッグするにはどうすればよいですか。

回答：次の CLI コマンドを入力します。

logging monitor debug
terminal monitor
logging on

Configuration Engine サーバ上の PIX ログで関連情報を確認することもできます。

質問：IOS デバイスで Configuration Engine をデバッグするにはどうすればよいですか。

回答：次の CLI コマンドを入力します。

debug cns all
debug kron exec-cli
terminal monitor

イベント モードの場合は、Configuration Engine サーバ上のイベント ログで関連情報を確認することもできます。Call Home モードの場合は、Configuration Engine サーバ上の config server ログを確認してください。

質問：Configuration Engine を介した IOS デバイスの検出およびその設定の取得に失敗したのはなぜですか。

回答：デバッグモードで、次のエラーが表示されているかどうかを確認します。

*Feb 23 21:42:15.677: CNS exec decode: Unknown hostname cnsServer-lnx.cisco.com ... 474F6860: 72726F72 2D6D6573 73616765 3E584D4C error-message>XML 474F6870: 5F504152 53455F45 52524F52 3C2F6572 _PARSE_ERROR

次のことを確認してください。

• CNS コマンドで完全修飾ホスト名（ホスト名およびドメイン名）が使用されている。

• デバイスに ip domain name コマンドが含まれている。

• デバイスに、ip host コマンドと、Configuration Engine の完全修飾ホスト名およびその IP アドレスが含まれている。

質問：イベントモードルータが Configuration Engine の [デバイスの検出（Discover Device）] ページに表示されない、または Configuration Engine の Web ページに緑色で表示されるのはなぜですか。

回答：次のことを確認してください。

• ルータと Configuration Engine サーバで相互に ping が実行できることを確認します。

• 次のいずれかのコマンドを使用して、Configuration Engine サーバでイベント ゲートウェイが動作していることを確認します。

プレーンテキストモードのステータス：/etc/init.d/EvtGateway

SSL 暗号化モードのステータス：/etc/init.d/EvtGatewayCrypto

• cns event コマンドをクリアしてから、ポート番号を指定せずにコマンドを再入力します。