キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

CUCM 8 と ITL ファイルを使用した、クラスタ間での IP 電話機の移行

 

目的

CUCM 8 では、セキュリティ機能が新たに標準装備され、ITL(Initial Trust List)ファイルの使用にも対応しました (詳細なドキュメントはこちら)。この新しい機能では、異なる CUCM クラスタ間で電話機を移動するときに注意が必要です。適切な手順に従わないと、数千台の電話機で ITL ファイルを手動で削除する必要が生じる可能性があります。

 

背景説明

新しい ITL ファイルに対応している電話機は、この特殊なファイルを CUCM TFTP サーバからダウンロードします。ITL ファイルが電話機にインストールされると、その後のコンフィギュレーション ファイルおよび ITL ファイルの更新はすべて次のいずれかに該当する必要があります。

 

  1. 電話機の CTL ファイルに現在インストールされている CCM+TFTP サーバの証明書によって署名されている(CTL でのクラスタ セキュリティが有効にされている場合)。
  2. 電話機の ITL ファイルにインストールされている CCM+TFTP サーバ証明書によって署名されている。
  3. ITL ファイルに記載されている CUCM サーバ TVS 証明書ストアのいずれかに存在する証明書によって署名されている。

この新しいセキュリティ機能を念頭に、ここではあるクラスタから別のクラスタに電話機を移動するときに発生する可能性がある 3 つの問題について見ていきます。

  1. 新しいクラスタの ITL ファイルは電話機の既存の ITL CCM+TFTP 証明書によって署名されていないため、電話機が新しい ITL ファイルまたはコンフィギュレーション ファイルを受け入れません。
  2. 電話機の既存の ITL に記載されている TVS サーバは、電話機が新しいクラスタに移動されると接続できなくなる可能性があります。
  3. 証明書の検証に TVS サーバに接続ができたとしても、元のクラスタの TVS サーバには新しいサーバの証明書がない可能性があります。

これら 3 つの問題が発生した場合の解決法の 1 つは、クラスタ間で移動されたすべての電話機から手動で ITL ファイルを削除することです。しかし、これは電話機の数が増えると多大な労力を要するため、理想的な解決策ではありません。

症状

TFTP または HTTP を介して電話機が受信したコンフィギュレーション ファイルの変更が一切有効になりません。コンフィギュレーション ファイルにより渡される設定オプションには次のようなものがあります。

  • 認証 URL、ディレクトリ URL、サービス URL などの URL。これには内部と外部のディレクトリ構造が含まれます
  • 一部のロケール機能
  • プライマリおよびセカンダリ登録の CallManager グループ

電話機では頻繁に登録が行われ、デフォルトでは、設定された TFTP サーバに登録されます。新しい TFTP サーバが CallManager サービスを実行していない場合、電話機が登録を行わない可能性があります。

 

電話機の ITL ファイルが現在の TFTP サーバに対して正しくない場合、電話機のコンソール ログに次のようなメッセージが表示されます。

 

1715: ERR 16:59:35.170584 SECD: EROR:verifyFile: sgn verify file failed </usr/ram/SEP00260BD749E9.cnf.xml>, errclass 8, errcode 19 (signer not in CTL)
1716: ERR 16:59:35.171327 SECD: EROR:verifyFile: verify FAILED, </usr/ram/SEP00260BD749E9.cnf.xml>

 

移行オプション

前述した 3 つの問題を考慮に入れて、電話機を手動で設定することなく、電話機をクラスタ間でシームレスに移行できる方法があります。

 

 

エンタープライズ パラメータのロールバック

 


この方法は、電話機の移行を試みる前に完了した場合のみ有効です。これは、電話機がすでに「verify file failed」(ファイル検証失敗)の状態になっている場合は使用できません。

 

最も好ましいオプションは、CUCM エンタープライズ パラメータ「Prepare Cluster for Rollback to pre-8.0」を利用する方法です。ロールバック パラメータに関する完全なドキュメントはここから参照できます。このパラメータを True に設定すると、電話機は空の TVS と TFTP 証明書セクションを含む特殊な ITL ファイルをダウンロードします。

 

空の ITL ファイルがインストールされている電話機は、署名のないコンフィギュレーション ファイルでもすべて受け入れ(CUCM 8.X 以前のクラスタに移行する場合)、また新しい ITL ファイルも無条件に受け入れます(異なる CUCM 8.X クラスタに移行する場合)。

 

空の ITL ファイルは、[Settings] > [Security] > [Trust List] > [ITL] を確認することで確認できます。元の TVS および TFTP サーバが指定されていたところが空のエントリになっています。

 

電話機は新しい空の ITL ファイルをダウンロードするために必要な時間だけ、元の CUCM サーバにアクセスできる必要があります。電話機が空の ITL ファイルをダウンロードしたら、古いサーバは(ビジネス要件に応じて)廃止、電源オフ、廃棄、または再構築することができます。

 

証明書の一括エクスポート


証明書を一括エクスポートする方法は、電話機が移行される間、両方のクラスタがオンラインでネットワーク接続されている場合のみ有効です。

 

元のクラスタと新しいクラスタの両方を同時にオンラインにできる場合に実行可能な別のオプションとして、証明書をまとめて移行する方法があります。

 

IP 電話機は、ダウンロードしたファイルを、ITL ファイルまたは ITL ファイルに存在する TVS サーバのいずれかに対して検証します。電話機を新しいクラスタに移動する必要がある場合、新しいクラスタが提示する ITL ファイルが元のクラスタの TVS 証明書ストアによって信頼されている必要があります。

 

証明書の一括エクスポートは、[OS Administration] > [Security] > [Bulk Certificate] ページから、次の手順で行うことができます。

  1. 新しい宛先のクラスタ(TFTP のみ)から中央 SFTP サーバに証明書をエクスポートします。
  2. 証明書の一括処理用のインターフェイスを使用して SFTP サーバで証明書(TFTP のみ)を統合します。
  3. 元の古いクラスタで証明書の一括処理機能を使用して、中央 SFTP サーバから TFTP 証明書をインポートします。
  4. DHCP オプション 150、またはその他の方法を使用して、電話機に新しい宛先クラスタを指定します。
  5. 電話機が新しい宛先クラスタの ITL ファイルをダウンロードし、既存の ITL ファイルに対してそれを検証しようとします。
  6. 既存の ITL ファイルには証明書が存在しないため、電話機は古い TVS サーバに新しい ITL ファイルの署名を検証するよう要求します。電話機は TCP ポート 2445 の古いクラスタに TVS クエリを送信してこの要求を行います。
  7. 証明書のエクスポート/統合/インポートのプロセスが正常に完了すると、TVS が成功のステータスを返し、電話機のメモリ内の ITL ファイルが新たにダウンロードされた ITL ファイルで置き換えられます。
  8. これで電話機は新しいクラスタから署名付きのコンフィギュレーション ファイルをダウンロードし、検証できるようになります。

 

ハードウェア セキュリティ トークン(KEY-CCM-ADMIN-K9=)の使用

新旧両方のクラスタで CTL(Certificate Trust List; 証明書信頼リスト)の生成にハードウェア セキュリティ トークン(製品番号 KEY-CCM-ADMIN-K9=)が使用されている場合、少なくとも 1 つの同じハードウェア トークンが新旧クラスタの両方で使用されている限り、電話機をクラスタ間で自由に移行することができます。

 

新しい CTL には既存の CTL と共通するセキュリティ トークン証明書が含まれるため、古いクラスタの CTL が設定された電話機を新しいクラスタに移動しても、電話機は新しいクラスタの CTL を受け入れます。CTL には CCM+TFTP サーバの証明書も含まれるため、新しいクラスタの ITL も電話機で受け入れられ、電話機をクラスタ間で移動させることに問題はなくなります。

 

このセキュリティ トークンを利用する方法は、追加のハードウェアが必要であり、元のクラスタで設定を行う必要もあります。通常、セキュリティ トークンは、クラスタ内の暗号化された信号やメディア(SRTP)、および暗号化または認証されたコンフィギュレーション ファイルを許可するために使用されます。また、セキュリティ トークンを使ってクラスタのセキュリティを一度有効にすると、そのクラスタのセキュリティを無効にするには、そのクラスタ上のすべての電話機本体から CTL を手動で削除する必要があります。

 

手動による ITL の削除

何らかの深刻な障害が発生して、元のクラスタの TFTP 鍵または証明書を利用できなくなった場合(これは DRF バックアップで維持されているので、バックアップを忘れないでください)、電話機を新しいクラスタに移行するには、電話機から手動で ITL ファイルを削除する方法しかありません。

 

これを行う手順は、電話機のモデルによって異なります。最も一般的な電話機モデルでの必要な手順をここに示します。ほかのモデルの手順は『Phone Administration Guides』を参照してください。

 

79XX - [Settings] > [Security] > [Trust List] > [ITL File] > [**#](設定のロック解除) > [Erase]

 

89XX または 99XX - [Settings] > [Administrator Settings] > [Reset Settings] > [Security Settings]

--------------------------------------------------------------

翻訳元

https://supportforums.cisco.com/docs/DOC-15799

バージョン履歴
改訂番号
2/2
最終更新:
‎08-30-2017 06:35 AM
更新者:
 
ラベル(1)
寄稿者:
タグ(5)
コメント
New Member

CUCM8.xでCluster Server Hostのドメイン名を変更する際、IP PhoneのITLファイルのアップデートはどのようにやるのがベストプラクティスなのでしょうか・・・。

Cisco Employee

以下のドキュメントが参考になるかと思いますので、ご一読いただけますか。

Changing Host Names or Domain Names

Changing the IP Address and Hostname for Cisco Unified Communications Manager Release 8.6(1)

New Member

なるほどっ!IP Phoneに複数台のTFTPを登録しておき、1台ずつ変更すれば自動的にIP PhoneのもつITLファイルもアップデートされるということですね。