2012-08-06 03:22 PM 2017-08-30 06:35 AM 更新
CUCM 8 では、セキュリティ機能が新たに標準装備され、ITL(Initial Trust List)ファイルの使用にも対応しました (詳細なドキュメントはこちら)。この新しい機能では、異なる CUCM クラスタ間で電話機を移動するときに注意が必要です。適切な手順に従わないと、数千台の電話機で ITL ファイルを手動で削除する必要が生じる可能性があります。
新しい ITL ファイルに対応している電話機は、この特殊なファイルを CUCM TFTP サーバからダウンロードします。ITL ファイルが電話機にインストールされると、その後のコンフィギュレーション ファイルおよび ITL ファイルの更新はすべて次のいずれかに該当する必要があります。
この新しいセキュリティ機能を念頭に、ここではあるクラスタから別のクラスタに電話機を移動するときに発生する可能性がある 3 つの問題について見ていきます。
これら 3 つの問題が発生した場合の解決法の 1 つは、クラスタ間で移動されたすべての電話機から手動で ITL ファイルを削除することです。しかし、これは電話機の数が増えると多大な労力を要するため、理想的な解決策ではありません。
TFTP または HTTP を介して電話機が受信したコンフィギュレーション ファイルの変更が一切有効になりません。コンフィギュレーション ファイルにより渡される設定オプションには次のようなものがあります。
電話機では頻繁に登録が行われ、デフォルトでは、設定された 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] ページから、次の手順で行うことができます。
新旧両方のクラスタで CTL(Certificate Trust List; 証明書信頼リスト)の生成にハードウェア セキュリティ トークン(製品番号 KEY-CCM-ADMIN-K9=)が使用されている場合、少なくとも 1 つの同じハードウェア トークンが新旧クラスタの両方で使用されている限り、電話機をクラスタ間で自由に移行することができます。
新しい CTL には既存の CTL と共通するセキュリティ トークン証明書が含まれるため、古いクラスタの CTL が設定された電話機を新しいクラスタに移動しても、電話機は新しいクラスタの CTL を受け入れます。CTL には CCM+TFTP サーバの証明書も含まれるため、新しいクラスタの ITL も電話機で受け入れられ、電話機をクラスタ間で移動させることに問題はなくなります。
このセキュリティ トークンを利用する方法は、追加のハードウェアが必要であり、元のクラスタで設定を行う必要もあります。通常、セキュリティ トークンは、クラスタ内の暗号化された信号やメディア(SRTP)、および暗号化または認証されたコンフィギュレーション ファイルを許可するために使用されます。また、セキュリティ トークンを使ってクラスタのセキュリティを一度有効にすると、そのクラスタのセキュリティを無効にするには、そのクラスタ上のすべての電話機本体から CTL を手動で削除する必要があります。
何らかの深刻な障害が発生して、元のクラスタの TFTP 鍵または証明書を利用できなくなった場合(これは DRF バックアップで維持されているので、バックアップを忘れないでください)、電話機を新しいクラスタに移行するには、電話機から手動で ITL ファイルを削除する方法しかありません。
これを行う手順は、電話機のモデルによって異なります。最も一般的な電話機モデルでの必要な手順をここに示します。ほかのモデルの手順は『Phone Administration Guides』を参照してください。
79XX - [Settings] > [Security] > [Trust List] > [ITL File] > [**#](設定のロック解除) > [Erase]
89XX または 99XX - [Settings] > [Administrator Settings] > [Reset Settings] > [Security Settings]
--------------------------------------------------------------
翻訳元
CUCM8.xでCluster Server Hostのドメイン名を変更する際、IP PhoneのITLファイルのアップデートはどのようにやるのがベストプラクティスなのでしょうか・・・。
以下のドキュメントが参考になるかと思いますので、ご一読いただけますか。
なるほどっ!IP Phoneに複数台のTFTPを登録しておき、1台ずつ変更すれば自動的にIP PhoneのもつITLファイルもアップデートされるということですね。
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
下記より関連するコンテンツにアクセスできます