この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
アイデンティティ管理は、どのアプリケーションにも必要な基本概念です。アイデンティティ管理では、個々のプリンシパルの管理とこれらのプリンシパルの認証および認可を行います。従来、各アプリケーションは、アイデンティティ管理を個々に処理していました。このため、ユーザは個々のアプリケーションに対して認証を実施しなければいけませんでした。アイデンティティ管理、認証、認可を集中化することにより、シングル サインオン(SSO)などのサービスを提供することで、ユーザ エクスペリエンスを大幅に向上できます。
アイデンティティ管理の集中化の最初のステップは、エンタープライズのプリンシパルに関する情報のストレージを一元化することです。これらの一元化された企業全体のデータストアは、一般的にディレクトリとして知られています。
ディレクトリ(電話帳)は、多数の読み取りや検索、および随時の書き込みや更新用に最適化される特殊なデータベースです。ディレクトリには、一般に、社員の情報、ユーザ特権、グループ メンバーシップなど、頻繁に変更されないデータが企業ネットワーク上に保存されます。
ディレクトリは拡張可能です。つまり、ディレクトリに保存された情報のタイプを変更し、拡大できます。「 ディレクトリ スキーマ 」という語は、保存されている情報のタイプ、そのコンテナ(または属性)、およびユーザやリソースとの関係を定義します。
Lightweight Directory Access Protocol(LDAP)は、ディレクトリに保存されている情報にアクセスし、変更するための標準方式をアプリケーションに提供します。この機能により、企業は、すべてのユーザ情報を、複数のアプリケーションで利用できる単一リポジトリに集中化させることができます。追加、移動、および変更が簡単なので、保守コストも大幅に削減されます。
この章では、Cisco Unified Communication Manager(Unified CM)に基づく Cisco Unified Communications システムを社内 LDAP ディレクトリと統合する場合の、設計上の主な原則について説明しています。この章の構成は、次のとおりです。
ここでは、一般的な企業の IT 部門における社内 LDAP ディレクトリとの統合に関して、さまざまな要件を分析します。
ここでは、Cisco Unified Communications エンドポイントのディレクトリ アクセスを有効にする技術的なソリューションについて説明し、そのソリューションに基づく設計上のベスト プラクティスを示します。
ここでは、LDAP 同期機能や LDAP 認証機能などを含む、Cisco Unified CM でのディレクトリ統合に関して、技術的なソリューションについて説明し、設計上の考慮事項を示します。
ここでは、Cisco TelePresence Video Communication Server(VCS)に登録されたビデオ エンドポイントのディレクトリ アクセスを有効にする技術的なソリューションを簡単に紹介します。
ここでは、アイデンティティ管理アーキテクチャについて説明します。
ここでは、SAML 2.0 シングル サインオン(SSO)の概要を示します。
ここでは、Cisco Unified CM で利用できる Oauth 承認サービスについて説明します。
この章で説明する考慮事項は、Cisco Unified CM とそれにバンドルされているアプリケーション(Cisco エクステンション モビリティ、Cisco Unified Communications Manager Assistant、WebDialer、Bulk Administration Tool、および Real-Time Monitoring Tool)に適用されます。
Cisco Unity については、次の Web サイトで入手可能な『 Cisco Unity Design Guide 』、および『 Cisco Unity Data and the Directory 』、『 Active Directory Capacity Planning 』、『 Cisco Unity Data Architecture and How Cisco Unity Works 』の各ホワイト ペーパーを参照してください。
表 16-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
Cisco ユーザ データ サービス(UDS)を使用した Unified Communications エンドポイントのディレクトリ アクセス |
||
音声アプリケーションと社内 LDAP ディレクトリとの統合は、多くの企業の IT 部門にとって一般的な作業です。ただし、統合の正確な範囲は企業によって異なるため、図 16-1 に示すように、1 つ以上の具体的かつ独立した要件として表すことができます。
たとえば、1 つの一般的な要件は、IP 電話またはその他の音声エンドポイントやビデオ エンドポイントからユーザ ルックアップ(「個人別電話帳」サービスと呼ばれることもあります)を有効にし、ユーザがディレクトリで番号を検索した後に、連絡先に迅速にダイヤルできるようにすることです。
もう 1 つの要件は、社内ディレクトリからアプリケーションのユーザ データベースを、ユーザに自動的に提供することです。この方法により、社内ディレクトリの変更のたびにコア ユーザ情報を手動で追加、削除、または修正する必要がなくなります。
一般に、社内ディレクトリ クレデンシャルを使用して、音声アプリケーションやビデオ アプリケーションのエンド ユーザと管理者を認証することも必要です。ディレクトリ認証を有効にすることで、IT 部門は 1 つのログイン機能を提供し、さまざまな企業アプリケーションに対して各ユーザが保持する必要のあるパスワードの数を減らすことができます。
表 16-2 に示すように、Cisco Unified Communications システムに関係する場合、 ディレクトリ アクセス という用語は、Cisco Unified Communications エンドポイントのユーザ ルックアップの要件を満たすメカニズムおよびソリューションを意味します。また、 ディレクトリ統合 という用語は、ユーザ プロビジョニングおよび(エンド ユーザと管理者の両方の)認証の要件を満たすメカニズムおよびソリューションを意味します。
|
|
|
---|---|---|
この章では、これ以降、Cisco Unified CM に基づく Cisco Unified Communications システムで、これらの要件にどのように対処するかについて説明します。
(注) 「ディレクトリ統合」という用語については、管理ポリシーおよびセキュリティ ポリシーを集中化するために、Microsoft Active Directory ドメインにアプリケーション サーバを追加する機能といった解釈もあります。Cisco Unified CM は、カスタマイズした組み込みオペレーティング システムで実行するアプライアンスであり、Microsoft Active Directory ドメインに追加できません。Cisco Unified CM のサーバ管理は、Cisco Real-Time Monitoring Tool(RTMT)によって行われます。アプリケーションに合わせた強力なセキュリティ ポリシーが組み込みオペレーティング システム内にすでに実装されています。
この項では、Cisco Unified Communications エンドポイント(Cisco Unified IP Phone など)からユーザ ルックアップを実行するように、LDAP 準拠のディレクトリ サーバへの社内ディレクトリ アクセスを設定する方法について説明します。Unified CM やその他の Unified Communications アプリケーションがユーザ プロビジョニングおよび認証のために社内ディレクトリに統合されているかどうかに関係なく、この項で説明しているガイドラインが適用されます。
ディスプレイ画面を持つ Cisco Unified IP Phone では、ユーザが電話機の Directories ボタンを押すと、ユーザ ディレクトリを検索できます。IP Phone は、ハイパーテキスト転送プロトコル(HTTP)を使用して、要求を Web サーバに送信します。Web サーバからの応答には、電話機が解釈して表示する特定の Extensible Markup Language(XML)オブジェクトが含まれています。
デフォルトでは、Cisco Unified IP Phone は、Unified CM の組み込みデータベースに対してユーザ ルックアップを実行するように設定されます。ただし、社内 LDAP ディレクトリでルックアップを実行するように、この設定を変更できます。変更した場合、電話機は HTTP 要求を外部 Web サーバに送信します。このサーバはプロキシとして動作し、要求を LDAP 照会に変換します。その後、その LDAP 照会は社内ディレクトリによって処理されます。LDAP 応答は、Web サーバによって XML オブジェクトにカプセル化され、HTTP を使用して電話機に返信されて、エンド ユーザに伝えられます。
図 16-2 では、Unified CM が社内ディレクトリに統合されていない配置において、このメカニズムを示しています。このシナリオでは、Unified CM がメッセージ交換にかかわっていないことに注意してください。図 16-2 の右側に表示されている Unified CM Web ページの認証メカニズムは、ディレクトリ ルックアップの設定とは関係ありません。
図 16-2 Cisco Unified IP Phone Services SDK を使用する Cisco Unified IP Phone のディレクトリ アクセス
図 16-2 に示す例では、Web サーバのプロキシ機能は、Cisco Unified IP Phone Services ソフトウェア開発キット(SDK)に組み込まれている Cisco LDAP Search コンポーネント オブジェクト モデル(COM)サーバによって提供されます。次の URL の Cisco DevNet(シスコの開発者コミュニティ)から最新の Cisco Unified IP Phone Services SDK をダウンロードできます。
https://developer.cisco.com/site/devnet/home/index.gsp
IP Phone Services SDK は、IIS 4.0 以降を実行する Microsoft Windows Web サーバにはインストールできますが、Unified CM サーバにはインストールできません。SDK には、単純なディレクトリ ルックアップ機能を提供するサンプル スクリプトが入っています。
IP Phone Services SDK を使用する社内ディレクトリ ルックアップ サービスを設定するには、次の手順を実行します。
手順 1 社内 LDAP ディレクトリを指すようにサンプル スクリプトのいずれかを修正するか、SDK に付属の『LDAP Search COM Programming Guide』を使用して独自のスクリプトを作成します。
手順 2 Unified CM で、外部 Web サーバ上のスクリプトの URL を指すように URL Directories パラメータ([System] > [Enterprise Parameters])を設定します。
(注) ユーザのサブセットだけにサービスを提供する場合は、[Enterprise Parameters] ページではなく、[Phone Configuration] ページ内で URL Directories パラメータを直接設定します。
まとめると、Cisco Unified IP Phone Services SDK によるディレクトリ アクセスには、次の設計上の考慮事項が適用されます。
ここでは、前のセクションで説明した Web サービスの代わりに UDS を使用した、ユーザ データにアクセスするためのエンドポイントのディレクトリ アクセスのメカニズムとベスト プラクティスについて説明します。ユーザ データ サービス(UDS)API は、ユーザのデバイス、加入サービス、スピード ダイヤルをはじめ、Unified Communication 設定データベース内の各ユーザ リソースおよびエンティティに対する認証済みアクセスを提供する、REST ベースの操作を集めたものです。
現在のエンドポイント(CE ソフトウェアを実行するすべてのエンドポイントを含む)は、ユーザがエンドポイントで検索機能を呼び出すときはいつでも、UDS REST ベースのディレクトリ検索メソッドに直接アクセスして検索結果を取得します。UDS の検索メソッドから返された結果は、エンドポイントのディスプレイに表示されます。UDS LDAP プロキシ機能が使用されない限り、UDS の検索機能でリストされるのは、Unified CM データベース内にあるディレクトリ エントリだけです。UDS LDAP プロキシ機能を使用する場合、エンドポイントが UDS を介して Cisco Unified CM にディレクトリ情報を要求することに変わりはありませんが、結果は、設定済みの外部 LDAP ディレクトに UDS サービスによって要求されてから、UDS 要求の結果としてエンドポイントに返されます。
この項では、社内 LDAP ディレクトリに対するユーザ プロビジョニングと認証を考慮した、Cisco Unified CM でのディレクトリ統合のメカニズムおよびベスト プラクティスについて説明します。この項では、次の項目について説明します。
ここでは、Unified CM ユーザ関連アーキテクチャの概要を示します。
ここでは、LDAP 同期の機能について説明し、この機能の配置に関する設計上のガイドラインを Microsoft Active Directory に関する追加の考慮事項と共に示します。
ここでは、LDAP 認証の機能について説明し、この機能の配置に関する設計上のガイドラインを Microsoft Active Directory に関する追加の考慮事項と共に示します。
サポートされる LDAP ディレクトリの一覧については、次の Web サイトで入手可能な『 System Configuration Guide for Cisco Unified Communications Manager 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
図 16-3 は、Unified CM クラスタの基本アーキテクチャを示しています。組み込みデータベースには、デバイス関連データ、コール ルーティング、機能のプロビジョニング、およびユーザ プロファイルなど、すべての設定情報が保存されます。データベースは CM クラスタ内のすべてのサーバ上に存在し、パブリッシャ サーバからすべてのサブスクライバ サーバに自動的に複製されます。
図 16-3 Cisco Unified CM のアーキテクチャ
デフォルトでは、Unified CM Administration Web インターフェイスを介してすべてのユーザを手動でパブリッシャ データベースにプロビジョニングします。Cisco Unified CM には、次の 2 つのユーザ タイプがあります。
表 16-3 では、Unified CM データベースにデフォルトで作成されるアプリケーション ユーザのリストを、それらのユーザが使用される機能またはアプリケーションと共に示しています。Cisco Unified Communications の他のアプリケーションを統合する場合に、追加のアプリケーション ユーザを手動で作成できます(たとえば、Cisco Attendant Console の ac アプリケーション ユーザ、Cisco Unified Contact Center Express の jtapi アプリケーション ユーザなど)。
|
|
---|---|
これらの考慮事項に基づいて、図 16-4 に、ルックアップ、プロビジョニング、認証などのユーザ関連操作に対する Unified CM でのデフォルト動作を示します。
図 16-4 Unified CM のユーザ関連操作に対するデフォルト動作
エンド ユーザは、HTTPS 経由で [Unified CM User Options] ページにアクセスし、ユーザ名およびパスワードで認証します。ユーザ グループと役割によって管理者として設定されている場合、エンド ユーザは同じクレデンシャルで Unified CM Administration のページにもアクセスできます。
同様に、シスコの他の機能とアプリケーションは、それぞれのアプリケーション ユーザに関連付けられたユーザ名およびパスワードで、HTTPS 経由で Unified CM に対して認証します。
HTTPS メッセージによって伝送される認証確認は、Unified CM の Web サービスにより、Identity Management System(IMS)という内部ライブラリにリレーされます。デフォルト設定では、IMS ライブラリは、組み込みデータベースに対してエンド ユーザとアプリケーション ユーザの両方を認証します。このように、Unified Communications システムにおける「現実の」ユーザと内部アプリケーション アカウントの両方が、Unified CM に設定されたクレデンシャルを使用して認証されます。
エンド ユーザは、IP Phone からエクステンション モビリティ サービスにログインするときに、ユーザ名と数値パスワード(PIN)で認証することもできます。この場合、認証確認は HTTP 経由で Unified CM に伝送されますが、やはり Web サービスにより IMS ライブラリにリレーされ、IMS ライブラリは組み込みデータベースに対してクレデンシャルを認証します。
さらに、Directories ボタンを介して Unified Communications エンドポイントによって実行されるユーザ ルックアップでは、HTTP 経由で Unified CM の Web サービスと通信し、組み込みデータベースのデータにアクセスします。
エンド ユーザとアプリケーション ユーザの区別の重要性は、社内ディレクトリとの統合が必要な場合に明らかになります。前の項で説明したように、この統合は次の 2 つの独立したプロセスによって実現されます。
このプロセスでは、Unified CM の Cisco Directory Synchronization(DirSync)という内部ツールを使用して、社内 LDAP ディレクトリから多数のユーザ属性を(手動または定期的に)同期します。この機能がイネーブルの場合、ユーザは Unified CM 管理 GUI を介して、ローカル ユーザのプロビジョニングに加えて社内ディレクトリから自動的にプロビジョニングされます。この機能はエンド ユーザだけに適用され、アプリケーション ユーザは独立したままで、引き続き Unified CM Administration インターフェイスを介してプロビジョニングされます。要約すると、エンド ユーザは社内ディレクトリで定義され、Unified CM データベースに同期されますが、アプリケーション ユーザは Cisco Unified CM データベースに保存されるだけで、社内ディレクトリで定義する必要はありません。
このプロセスは、LDAP の標準的な Simple_Bind 操作を使用して、IMS ライブラリが社内 LDAP ディレクトリに対して LDAP 同期エンド ユーザのユーザ クレデンシャルを認証できるようにします。この機能がイネーブルの場合、LDAP 同期されたエンド ユーザは社内ディレクトリに対して認証される一方、アプリケーションのユーザ パスワードとローカル エンド ユーザのパスワードは引き続き Unified CM データベースに対してローカルで認証されます。Cisco エクステンション モビリティの PIN も引き続きローカルで認証されます。
Unified CM データベースに対して内部でアプリケーション ユーザを維持および認証すると、社内 LDAP ディレクトリの可用性とは無関係に、これらのアカウントを使用して Unified CM と通信するすべてのアプリケーションと機能に対して復元性が提供されます。
Cisco エクステンション モビリティの PIN も Unified CM データベース内で維持されます。これは、これらの PIN はリアルタイム アプリケーションの必須部分であり、リアルタイム アプリケーションは社内ディレクトリの応答性に依存しないようにする必要があるためです。
次の 2 つの項では、LDAP 同期と LDAP 認証についてさらに詳しく説明し、両方の機能に関して設計上のベスト プラクティスを示します。
(注) Unified Communications エンドポイントのディレクトリ アクセスの項で説明したように、外部 Web サーバで Cisco Unified IP Phone Services SDK を設定することにより、エンドポイントからのユーザ ルックアップを社内ディレクトリに対して実行することもできます。
Unified CM を社内 LDAP ディレクトリに同期すると、管理者は Unified CM データ フィールドをディレクトリ属性にマッピングすることにより、ユーザを容易にプロビジョニングできるようになります。LDAP ストアに保持されている重要なユーザ データは、スケジュールまたはオンデマンド ベースで Unified CM データベース内の対応する適切なフィールドにコピーされます。社内 LDAP ディレクトリのステータスは、中央リポジトリのままとなります。Unified CM は、ユーザ データを保存するための統合データベースを備え、またユーザ アカウントおよびデータを作成して管理するための Web インターフェイスを、Unified CM Administration 内に備えています。LDAP 同期を有効にすると、ローカル データベースは引き続き使用され、追加のローカル エンド ユーザ アカウントを作成できます。エンドユーザ アカウントは、LDAP ディレクトリのインターフェイスおよび Unified CM 管理 GUI で管理できます。(図 16-5 を参照)。アプリケーション ユーザのアカウントは、Unified CM Administration Web インターフェイスのみで作成と管理を実行できます。
ユーザ アカウント情報は、LDAP ディレクトリから Unified CM パブリッシャ サーバにあるデータベースにインポートされます。LDAP ディレクトリからインポートされた情報は、Unified CM から変更できません。Cisco Unified Communications に固有の追加のユーザ情報は、Unified CM によって管理され、ローカル データベースだけに保存されます。たとえば、デバイスとユーザのアソシエーション、スピード ダイヤル、自動転送設定、およびユーザ PIN はすべて Unified CM が管理するデータの例であり、社内 LDAP ディレクトリには存在しません。次に、ユーザ データは組み込みデータベース同期メカニズムによって、Unified CM パブリッシャ サーバからサブスクライバ サーバに伝達されます。
LDAP ディレクトリから同期されたユーザ情報は、ユーザ情報を Unified CM でローカルで編集できるよう、ローカル ユーザ情報に変換できます。ローカル エンド ユーザは、Unified CM Administration GUI を使用して手動で追加できます。LDAP 同期信号中、ローカル エンド ユーザはアクティブ LDAP ユーザに変わり、同じユーザ ID のユーザが LDAP で見つかった場合、ローカルで設定済みのデータはディレクトリのデータに置き換えられます。
LDAP 同期をアクティブにすると、一度に 1 つのタイプの LDAP ディレクトリだけをクラスタ用にグローバルに選択できます。また、LDAP ディレクトリ ユーザの 1 つの属性が選択されて [Unified CM User ID] フィールドにマッピングされます。Unified CM はデータへのアクセスに標準 LDAPv3 を使用します。
Cisco Unified CM は、標準属性からデータをインポートします。ディレクトリ スキーマの拡大は必要ありません。 表 16-4 に、Unified CM の各フィールドへのマッピングに使用できる属性を示します。[Unified CM User ID] フィールドにマッピングされるディレクトリ属性のデータは、そのクラスタのすべてのエントリ内で一意のものである必要があります。[Unified CM UserID] フィールドにマッピングされる属性はディレクトリに格納される必要があり、 sn 属性はデータと一緒に格納される必要があります。そうしないと、このインポート処理時にこれらのレコードはスキップされます。エンドユーザ アカウントのインポート中に使用するプライマリ属性が Unified CM データベースのいずれかのアプリケーション ユーザと一致する場合、そのユーザは LDAP ディレクトリからインポートされません。
表 16-4 では、LDAP ディレクトリから対応する Unified CM ユーザ フィールドにインポートされた属性を示していて、またこれらのフィールド間のマッピングについて説明しています。Unified CM ユーザ フィールドの中には、複数の LDAP 属性の 1 つからマッピングされるものもあります。
ディレクトリ属性とローカル ユーザ属性の直接マッピングに加えて、同期されたユーザの他の特性は、LDAP ディレクトリ同期アグリーメントの設定によって決まります。LDAP 同期によって作成されたユーザのアクセス制御グループ メンバーシップは、LDAP ディレクトリ構成設定で直接設定されます。これ以上の機能は、選択した機能グループ テンプレートによって決まります。LDAP ディレクトリ同期アグリーメントにおける機能グループ テンプレートの選択はオプションです。機能グループ テンプレートを使用すると、管理者は、ユーザの特性を定義できます(ホーム クラスタ選択、IM and Presence 機能、モビリティ機能、サービス プロファイル、ユーザ プロファイルなど)。ユーザ プロファイルを使用すると、管理者は、Unified CM で LDAP 同期されたユーザのディレクトリ電話番号を自動作成するために対象となるユニバーサル回線テンプレートを定義できます。
同期は、Serviceability Web ページで有効にする Cisco DirSync というプロセスによって実行されます。このプロセスを有効にすることで、システムに 1 ~ 20 件の同期アグリーメントを設定できます。80,000 人以上のユーザが同期される場合、この数は 10 に減少します。アグリーメントでは、LDAP ツリー内で Unified CM がインポートするユーザ アカウントの検索を開始する場所となる検索ベースを指定します。Unified CM は、特定の同期アグリーメントについて検索ベースで指定したドメインの領域に存在するユーザだけをインポートできます。
図 16-6 は、2 つの同期アグリーメントを示しています。一方の同期アグリーメントでは、User Search Base 1 を指定し、ユーザ jsmith、jdoe、jbloggs をインポートします。もう一方の同期アグリーメントでは、User Search Base 2 を指定し、ユーザ jjones、bfoo、tbrown をインポートします。CCMDirMgr アカウントは、ユーザ検索ベースで指定した場所の下位に存在しないので、インポートされません。ユーザを LDAP ディレクトリの構造に編成すると、その構造を使用して、どのユーザ グループをインポートするかを制御できます。この例では、単一の同期アグリーメントを使用してドメインのルートを指定することもできましたが、その検索ベースでは Service Accts もインポートしていたと考えられます。検索ベースではドメイン ルートを指定する必要はなく、ツリーのどの場所でも指定できます。
データを Unified CM データベースにインポートするために、LDAP Manager Distinguished Name として設定で指定されたアカウントを使用して、システムが LDAP ディレクトリへのバインドを実行し、データベースの読み取りがこのアカウントで実行されます。Unified CM のログインのために、LDAP ディレクトリでアカウントが使用可能である必要があります。ユーザ検索ベースで指定したサブツリー内のすべてのユーザ オブジェクトの読み取り可能な権限を持つ、固有のアカウントを作成することをお勧めします。同期アグリーメントでは、そのアカウントがドメイン内の任意の場所に存在できるように、アカウントの完全認定者名を指定します。図 16-6 の例では、CCMDirMgr が同期に使用するアカウントです。
アカウントのインポートは、LDAP Manager Distinguished Name アカウントの権限を使用して制御できます。この例では、ou=Eng への読み取りアクセスはできるが ou=Mktg への読み取りアクセスはできないようにこのアカウントを制限した場合、Eng の下位にあるアカウントだけがインポートされます。
同期アグリーメントには、複数のディレクトリ サーバを指定して冗長性を実現する機能があります。同期の試行時に使用するディレクトリ サーバを 3 つまで、順序付きのリストにして設定に指定できます。これらのサーバでの試行が、リストの最後まで順に行われます。どのディレクトリ サーバも応答しない場合、同期には失敗しますが、設定済みの同期スケジュールに従って再試行されます。
同期アグリーメントでは、同期を開始する時刻を指定し、再同期の期間を時間、日、週、月のいずれかの単位(最小値は 6 時間)で指定します。同期アグリーメントは、特定の時刻に 1 回だけ実行するように設定することもできます。
Unified CM パブリッシャ サーバで同期を初めて有効にすると、社内ディレクトリに存在するユーザ アカウントが Unified CM データベースにインポートされます。そして、その後のプロセスに従って、既存の Unified CM エンド ユーザ アカウントがアクティブになってデータが更新されるか、新しいエンド ユーザ アカウントが作成されます。
1. エンド ユーザ アカウントがすでに Unified CM データベースに存在するときに同期アグリーメントを設定した場合、以前に LDAP から同期されたすべての既存のアカウントは Unified CM で非アクティブとマークされます。同期アグリーメントの設定で、Unified CM UserID への LDAP データベース属性のマッピングを指定します。同期中に LDAP データベースのアカウントが既存の Unified CM アカウントと一致すると、その Unified CM アカウントは再びアクティブとマークされます。
2. 同期の完了後、アクティブに設定されなかった LDAP 同期アカウントは、ガーベッジ コレクション プロセスの実行時に Unified CM から永続的に削除されます。ガーベッジ コレクションは、午前 3 時 15 分の定時に自動的に実行されるプロセスで、設定はできません。
3. 後で社内ディレクトリに変更を加えると、スケジューリングされた次回の同期期間に、完全な再同期として Microsoft Active Directory から同期が行われます。これに対して、Sun ONE のディレクトリ製品は、ディレクトリに変更が加えられると差分同期を実行します。次の項では、2 つのシナリオのそれぞれの例を示します。
(注) ユーザを LDAP から Unified CM データベースに同期した後で同期設定を削除すると、その設定によってインポートされたユーザには、データベース内で非アクティブのマークが付きます。その後、これらのユーザはガーベッジ コレクションによって削除されます。
図 16-7 は、LDAP 同期と LDAP 認証の両方を有効にした Unified CM 配置について、イベントのスケジュールの例を示しています。再同期は、毎日午後 11 時に設定されています。
図 16-7 Active Directory での変更の伝達
最初の同期の後、アカウントの作成、削除、または無効化は、図 16-7 に示すスケジュールに従って、次の手順で説明するように Unified CM に伝達されます。
1. 1 月 1 日の午前 8 時に、AD でアカウントを無効にするか削除します。これ以降、期間 A 中は、Unified CM が認証を AD にリダイレクトするため、このユーザのパスワード認証(たとえば、[Unified CM User Options] ページ)は失敗します。ただし、PIN は Unified CM データベースに保存されているため、PIN 認証(たとえば、エクステンション モビリティ ログイン)は今までどおり成功します。
2. 定期的な再同期が 1 月 1 日午後 11 時にスケジュールされています。このプロセス中に、Unified CM がすべてのアカウントを検証します。AD で無効にするか削除したアカウントは、この時点で Unified CM データベースでは非アクティブとしてタグ付けされます。1 月 1 日の午後 11 時より後に、アカウントが非アクティブとマークされると、Unified CM による PIN 認証とパスワード認証は両方とも失敗します。
3. アカウントのガーベッジ コレクションは毎日午前 3 時 15 分の定時に発生します。このプロセスは、24 時間以上非アクティブとマークされたレコードの Unified CM データベースからユーザ情報を永続的に削除します。この例では、1 月 2 日の午前 3 時 15 分に実行するガーベッジ コレクションでは、アカウントが非アクティブになってまだ 24 時間が経過していないので、アカウントを削除しません。したがって、アカウントは 1 月 3 日の午前 3 時 15 分に削除されます。この時点で、ユーザ データは Unified CM から永続的に削除されます。
期間 A の開始時にアカウントを AD で作成していた場合、そのアカウントは期間 B の開始時に実行される定期的な再同期で Unified CM にインポートされ、Unified CM ですぐにアクティブになります。
Sun ONE 製品は差分同期アグリーメントをサポートし、Microsoft Active Directory とは異なる同期スケジュールを使用します。同期には、多くの LDAP 実装でサポートされている永続検索メカニズムが使用されます。図 16-8 では、LDAP 同期と LDAP 認証の両方を有効にした Unified CM 配置について、この同期スケジュールの例を示しています。
図 16-8 の例は、次の手順から構成されます。
1. 1 月 1 日の午前 8 時にアカウントが社内ディレクトリから削除され、これにより、差分更新データが LDAP サーバから Unified CM に送信されます。Unified CM は、データに対応するコピーを非アクティブに設定します。LDAP 認証が設定されているので、LDAP サーバがレコードを削除するとすぐに、ユーザはパスワードによるログインができなくなります。また、Unified CM レコードが非アクティブとマークされると、PIN をログインに使用できません。
2. 期間 B 中は、ユーザのレコードは非アクティブですが、まだ Unified CM に存在します。
3. 1 月 2 日の午前 3 時 15 分にガーベッジ コレクションが実行されるときは、レコードが非アクティブになってまだ 24 時間が経過していません。データは 1 月 3 日の期間 C の開始時まで Unified CM データベースに残り、ガーベッジ コレクション プロセスがこの日の午前 3 時 15 分に再び実行され、レコードが 24 時間以上にわたって非アクティブであったことを確認します。その結果、レコードはデータベースから永続的に削除されます。
ディレクトリで新規に作成したアカウントは、差分更新データによって同様に Unified CM に同期し、差分更新データが受信されるとすぐに使用できます。
LDAP 同期中に作成されたユーザに対して、Unified CM は自動的にディレクトリ番号を作成できます。これらの自動生成されたディレクトリ番号は、ディレクトリで見つかった情報のうちディレクトリで見つかった電話番号に適用されるマスクに基づいて定義されたものに基づくか、または LDAP 同期アグリーメントで定義されたディレクトリ番号プールから取得されます。マスクが同期アグリーメントで定義されるている場合は、可変長 +E.164 ディレクトリ番号を生成できるようにするため、次のルールが適用されます。
表 16-5 に、いくつかの例を示します。
|
|
|
---|---|---|
LDAP からの情報に基づいてディレクトリ番号を作成する代わりに、新しいユーザのディレクトリ番号は、事前に定義された番号プールから取得することもできます。各プールは開始番号と終了番号によって決まります。ディレクトリ番号プールは、+E.164 番号をサポートします。最大 5 つのプールを定義できます。番号は、最初のプールのすべての番号が割り当てられるまで、最初のプールから割り当てられます。その後、番号の割り当てには次のプールの番号を使用し始めます。
自動回線作成は、次の 両方 の条件を満たしたときにのみ有効になります。
図 16-9 に、自動回線作成の回線レベル設定を定義するために必要な構成要素の階層を示します。
図 16-9 LDAP ディレクトリ設定、機能グループ テンプレート、ユーザ プロファイル、およびユニバーサル回線テンプレートの関係
最終的に、ユニバーサル回線テンプレートは、対応する LDAP 同期定義によって追加されたユーザに対して自動的に作成されるすべてのディレクトリ番号の特性を定義します。
ユニバーサル回線テンプレートで定義されたコーリング サーチ スペースによって、自動生成されたディレクトリ番号のいずれかを使用するデバイスのサービス クラスが決まります。これは、同じ LDAP 同期アグリーメントによって作成されたすべてのディレクトリ番号が同じサービス クラスを共有すること、およびそのために、複数のサイトや複数のサービス クラスのディレクトリ番号が自動生成される必要がある場合は、複数の LDAP 同期アグリーメント(サイトやサービス クラスごとに 1 つ)が必要なことを意味します。これらの同期アグリーメントごとに、個別の LDAP フィルタを定義する必要があります。それぞれのフィルタは、サイト固有およびサービス クラス固有のユーザ グループのいずれかに属するユーザで完全一致します。サイトおよびサービス クラスに基づくグループ メンバーシップが少数の LDAP 属性で明示的にエンコードされない限り(それがカスタム属性内の場合でも)、LDAP 属性からサイトやサービス クラス グループへのこのようなマッピングは困難なものになることがあります。また、サポートされる LDAP アグリーメントの最大数は限られています。これは、自動的にディレクトリ番号を作成できるユーザ グループの数を制限します。
ディレクトリ番号の自動作成は、LDAP ディレクトリ同期中に作成されたユーザにのみ適用されます。特定の LDAP 同期アグリーメントのユニバーサル回線テンプレートを追加、変更、または更新しても、既存のユーザのディレクトリ番号は作成されず、既存のディレクトリ番号の設定は変更されません。
ユニバーサル回線テンプレートを使用すると、管理者は未登録の接続先へのコール転送を定義できます。その際、ボイスメールを転送先として選択するか、または明示的な接続先を定義できます。WAN の障害時に登録済みのエンドポイントからリモート サイト内のエンドポイントに到達するには、リモート サイトの電話機に対する未登録の接続先へのコール転送を、リモート電話機の PSTN エイリアス(+E.164 番号)に設定する必要があります。これは、ユニバーサル回線テンプレート設定では実現できません。割り当てられたディレクトリ番号(および該当する場合は適用されたマスク)に基づいて未登録の接続先へのコール転送を設定する必要が生じるためです。
Jabber クライアントが Microsoft Active Directory 内のグループを検索できるようにするため、Active Directory からエンド ユーザを同期するように Unified CM を設定するだけでなく、Active Directory に定義された配布グループを含めるように設定できます。社内グループの同期は、データ ソースとして Microsoft Active Directory を使用する場合のみサポートされます。Active Directory ライトウェイト ディレクトリ サービス(AD LDS)またはその他の社内ディレクトリではサポートされません。社内グループの同期は、Unified CM の LDAP ディレクトリ設定で有効になります。社内グループの最大数は 15,000 で、グループあたりのメンバーの最大数は 100 です。グループおよびメンバーを Cisco Unified CM Administration で追加または変更することはできませんが、Active Directory から同期されたグループは [ユーザ管理(User Management)]/[ユーザ設定(User Settings)]/[ユーザ グループ(User Group)] メニューで確認できます。
アカウントのインポート中は、LDAP ディレクトリから Unified CM データベースに、パスワードも PIN もコピーされません。Unified CM で LDAP 認証が有効でなく、シングル サインオンが使用されていない場合、エンド ユーザのパスワードは Unified CM Administration を使用して管理されます。パスワードと PIN は、暗号化形式で Unified CM データベースに保存されます。PIN は常に Unified CM で管理されます。LDAP ディレクトリ パスワードを使用してエンド ユーザを認証する場合は、LDAP 認証の項を参照してください。
Unified CM および LDAP サーバで Secure LDAP(SLDAP)を有効にすることにより、Unified CM パブリッシャ サーバとディレクトリ サーバ間の接続を保護できます。Secure LDAP を使用すると、Secure Socket Layer(SSL)接続で LDAP 送信ができます。Unified CM Platform Administration 内で LDAP サーバを Tomcat 信頼ストアに追加することにより、Secure LDAP を有効にできます。詳細な手順については、 https://www.cisco.com から入手できる Unified CM の製品マニュアルを参照してください。SLDAP を有効にする方法については、LDAP ディレクトリ ベンダーのドキュメンテーションを参照してください。
Cisco Unified CM で LDAP 同期を配置する場合は、設計と実装に関する次のベスト プラクティスに従ってください。
その他すべての LDAP プラットフォームでは、User ID にマッピングされる属性が Unified CM におけるそのアカウントの主要属性となります。LDAP 内の属性を変更すると、Unified CM に新しいユーザが作成され、元のユーザには非アクティブのマークが付きます。
ドメインの同期アグリーメントでは、ドメイン外のユーザや子ドメイン内のユーザは同期されません。同期プロセス中は Unified CM が AD 照会に従わないためです。図 16-10 の例では、すべてのユーザをインポートするために 3 つの同期アグリーメントが必要です。Search Base 1 ではツリーのルートを指定しますが、子ドメインのいずれかに存在するユーザはインポートしません。範囲は VSE.LAB に限定されており、残りの 2 つのドメインに対し、そのユーザをインポートするように別々のアグリーメントが設定されています。
図 16-10 複数の Active Directory ドメインでの同期
図 16-10 では、ドメインとサブドメインのそれぞれに少なくとも 1 つのドメイン コントローラ(DC)が関連付けられ、3 つの同期アグリーメントはそれぞれ適切なドメイン コントローラを指定します。DC にある情報は、その DC が存在するドメイン内のユーザの情報だけなので、すべてのユーザをインポートするために 3 つの同期アグリーメントが必要です。
図 16-11 に示すように、複数のツリーを含む AD フォレストで同期を有効にした場合も、上記と同じ理由で複数の同期アグリーメントが必要です。さらに、UserPrincipalName(UPN)属性がフォレスト全体で一意であることが Active Directory によって保証され、この属性は Unified CM UserID にマッピングする属性として選択する必要があります。マルチツリーの AD シナリオで UPN 属性を使用する場合の追加の考慮事項については、Microsoft Active Directory に関する追加の考慮事項の項を参照してください。
図 16-11 複数の AD ツリー(不連続なネームスペース)での同期
アカウントの同期を実行すると、Unified CM から AD にデフォルトの LDAP 検索フィルタ ストリングが送信されます。その中に、AD で無効のマークが付いているアカウントを戻さないという条件があります。ログインの失敗回数を超えた場合など、AD によって無効のマークが付けられたアカウントには、そのアカウントが無効である間に同期が実行された場合に非アクティブのマークが付けられます。
マルチフォレスト LDAP インフラストラクチャを使用した Unified CM 展開は、複数の異種フォレストを統合する単一のフォレスト ビューとして AD LDS を使用することによって、サポートできます。この統合では、LDAP フィルタリングを使用する必要があります(ディレクトリ同期および認証のユーザ フィルタリングを参照)詳細については、次の URL で入手可能な『 How to Configure Unified Communication Manager Directory Integration in a Multi-Forest Environment 』を参照してください。
https://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a0080b2b103.shtml
LDAP 認証機能により、Unified CM が LDAP で同期されたユーザを社内 LDAP ディレクトリに対して認証できます。アプリケーション ユーザとローカルに設定されたユーザは、ローカル データベースに対して常に認証されます。また、すべてのエンド ユーザの PIN も、常にローカル データベースで確認されます。図 16-12 に示すように、Unified CM 内の Identity Management System(IMS)モジュールと社内ディレクトリ サーバ間で確立した LDAPv3 接続によって、この認証が実現されます。
認証を有効にするために、クラスタ全体に単一の認証アグリーメントを定義できます。認証アグリーメントは、冗長性を得るために LDAP サーバを 3 つまで設定でき、必要に応じて保護接続 Secure LDAP(SLDAP)もサポートします。認証は、LDAP 同期が正しく設定され、使用されている場合にのみ有効にできます。LDAP 認証設定は、SSO を有効にすることによって上書きされます。SSO が有効になると、エンド ユーザは常に SSO を使用して認証され、LDAP 認証設定は無視されます。
認証を有効にした場合の Unified CM の動作説明を、次に示します。
この動作は、リアルタイム Unified Communications システムの操作を社内ディレクトリの可用性に依存しないようにしながら、シングル ログイン機能をエンド ユーザに提供するという原則に従ったものです。図 16-13 に図示します。
図 16-13 エンド ユーザ パスワード、アプリケーション ユーザ パスワード、エンド ユーザ PIN の認証
図 16-14 は、LDAP から同期化されたエンド ユーザを社内 LDAP ディレクトリに対して認証するために Unified CM で採用された、次のプロセスを示しています。
1. ユーザは、HTTPS 経由で [Unified CM User Options] ページに接続し、ユーザ名とパスワードで認証を試行します。この例では、ユーザ名は jsmith です。
2. ユーザがローカル ユーザの場合、パスワードはローカル データベースに対して検査されます。
1. ユーザが LDAP 同期ユーザの場合、Unified CM はユーザ名 jsmith に関する LDAP 照会を発行し、[LDAP 認証(LDAP Authentication)] 設定ページの [LDAP 検索ベース(LDAP Search Base)] で指定された値を、この照会の範囲として使用します。SLDAP を有効にした場合、この照会は SSL 接続を通じて行われます。
2. 社内ディレクトリ サーバは、LDAP 経由で、ユーザ jsmith の完全認定者名(DN)で応答します(たとえば、「cn=jsmith, ou=Users, dc=vse, dc=lab」)。
3. 次に Unified CM は、LDAP バインド操作を使用して、ユーザに提供された完全な DN とパスワードを渡すことにより、ユーザのクレデンシャルの検証を試みます。
4. LDAP バインドが成功した場合、Unified CM は、要求された設定ページにユーザが進むことを許可します。
Cisco Unified CM で LDAP 認証を配置する場合は、設計と実装に関する次のベスト プラクティスに従ってください。
複数のドメイン コントローラを地理的に分散させた分散型 AD トポロジを採用している環境では、認証速度が許容されない可能性があります。認証アグリーメント用のドメイン コントローラにユーザ アカウントが保持されていない場合、他のドメイン コントローラでそのユーザの検索が実行される必要があります。この設定を適用するときに、ログイン速度が許容範囲外である場合、グローバル カタログ サーバを使用するように認証設定を設定できます。
ただし、重要な制限があります。デフォルトでは、グローバル カタログに employeeNumber 属性が組み込まれません。その場合、ドメイン コントローラを認証に使用するか(上記にリストされた制限に注意)、グローバル カタログを更新して、employeeNumber 属性を組み込みます。詳細については、Microsoft Active Directory のマニュアルを参照してください。
グローバル カタログに対する照会を有効にするには、グローバル カタログ ロールが有効になっているドメイン コントローラの IP アドレスまたはホスト名を指すように [LDAP 認証(LDAP Authentication)] ページの [LDAP サーバ情報(LDAP Server Information)] を設定し、LDAP ポートを 3268 として設定するだけです。
Microsoft AD から同期するユーザが複数のドメインに属していると、認証へのグローバル カタログの使用がさらに効率的になります。Unified CM は、照会に従う必要がなく、すぐにユーザを認証できるためです。このような場合は、Unified CM がグローバル カタログ サーバを指すようにし、LDAP User Search Base をルート ドメインの最上位に設定します。
複数のツリーを含む Microsoft AD フォレストの場合には、追加の考慮事項が適用されます。単一の LDAP 検索ベースでは複数のネームスペースを扱えないので、Unified CM は別のメカニズムを使用して、これらの不連続なネームスペース間でユーザを認証する必要があります。
LDAP 同期の項で説明したように、複数のツリーがある AD フォレストで同期をサポートするために、UserPrincipalName(UPN)属性を Unified CM 内でユーザ ID として使用してください。ユーザ ID が UPN の場合、Unified CM Administration の [LDAP Authentication] 設定ページで [LDAP Search Base] フィールドへの入力はできませんが、その代わりに「LDAP user search base is formed using userid information.」という注意が表示されます。
実際には、図 16-15 に示すように、ユーザごとに UPN サフィックスからユーザ検索ベースが導き出されます。この例では、Microsoft Active Directory フォレストは avvid.info と vse.lab という 2 つのツリーで構成されます。同じユーザ名が両方のツリーに表示される場合があるため、同期プロセス中および認証プロセス中は UPN を使用してデータベースのユーザを一意に識別するように、Unified CM が設定されています。
図 16-15 複数のツリーがある Microsoft AD フォレストでの認証
図 16-15 に示すように、John Doe という名前のユーザが avvid.info ツリーと vse.lab ツリーの両方に存在します。次の手順は、UPN が jdoe@avvid.info となる第 1 のユーザに対する認証プロセスを示しています。
1. ユーザは、ユーザ名(UPN に対応するもの)とパスワードを使用し、HTTPS 経由で Unified CM に対して認証します。
2. Unified CM は、Microsoft Active Directory グローバル カタログ サーバに対して LDAP 照会を実行し、UPN で指定したユーザ名(@ 記号よりも前の部分)を使用して、UPN サフィックス(@ 記号より後の部分)から LDAP 検索ベースを得ます。この場合、ユーザ名は jdoe で、LDAP 検索ベースは「dc=avvid, dc=info」です。
3. Microsoft Active Directory は、LDAP 照会で指定したツリーのユーザ名に対応する正しい認定者名を識別します。この場合は、「cn=jdoe, ou=Users, dc=avvid, dc=info」です。
4. Microsoft Active Directory は LDAP 経由で、このユーザの完全認定者名を使用して Unified CM に応答します。
5. Unified CM は、提供された認定者名とユーザが最初に入力したパスワードで LDAP バインドを試行し、その後は図 16-14 に示す標準的な場合と同様に、認証プロセスが続行されます。
(注) 複数のツリーを含む Microsoft AD フォレストでの LDAP 認証のサポートは、上記の方法だけで行われます。したがってサポートは、ユーザの UPN サフィックスが、そのユーザが存在するツリーのルート ドメインに対応する配置だけに限定されます。AD では、異なる UPN サフィックスが許可されたエイリアスを使用できます。UPN サフィックスがツリーの実際のネームスペースから分離されている場合は、Microsoft Active Directory フォレスト全体で Unified CM ユーザを認証できなくなります(ただし、その場合でも、別の属性をユーザ ID として使用し、統合をフォレスト内の単一のツリーに限定することはできます)。
Unified CM は、ディレクトリ同期のパフォーマンスを最適化するために、LDAP 照会フィルタを提供します。Unified Communications リソースに割り当てられるディレクトリ ユーザ アカウントをインポートすることを推奨します。企業全体で UDS ベースのサービス検出を有効にするには、企業内のすべてのクラスタの Unified Communications リソースに割り当てられているすべてのユーザが企業内のすべてのクラスタにインポートされる必要があります。ローカル ユーザとリモート ユーザの差別化は、使用される LDAP 同期アグリーメントに関連付けられた機能グループ テンプレートの [ホーム クラスタ(Home Cluster)] 設定によって行われます。ディレクトリ ユーザ アカウントの数が、各クラスタに対してサポートされている数を超える場合は、フィルタリングを使用して、そのクラスタに関連付けられるユーザのサブセットを選択する必要があります。Unified CM 同期機能は、大規模な社内ディレクトリに置き換わるものではありません。
多くの場合、同期対象のアカウントを制御するために必要となるのは、固有の検索ベースだけです。固有の検索ベースを使用できない場合は、カスタム LDAP フィルタが必要となることがあります。以降の項では、ディレクトリ同期の最適化に使用できる両方の方法について説明します。いずれかのメカニズムを使用して Unified CM へのアカウントのインポートを制限する場合、デフォルトのディレクトリ ルックアップの設定では、UDS LDAP プロキシ機能が使用されない限り、Unified CM データベースに存在するディレクトリ エントリだけが表示されます。ディレクトリ全体にアクセスするディレクトリ ルックアップの場合は、外部 Web サーバを使用するように Unified CM を設定することもできます。この設定の詳細については、ここでは説明しませんが、次の Web サイトで入手可能な Unified CM 製品マニュアルで説明しています。
https://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/tsd_products_support_series_home.html
Unified CM データベース同期機能には、LDAP ディレクトリ ストアから Unified CM パブリッシャ データベースへユーザ設定データ(属性)のサブセットをインポートするメカニズムがあります。ユーザ アカウントの同期が発生すると、各ユーザの LDAP アカウント情報が、そのユーザの特定の Unified Communications 機能を有効にするために必要な追加データと関連付けられることがあります。認証も有効な場合、パスワード確認のための LDAP ストアへのバインドに、ユーザのクレデンシャルを使用します。同期や認証が有効な場合に、エンド ユーザのパスワードは Unified CM データベースには格納されません。
ユーザ アカウント情報はクラスタ固有です。各 Unified CM パブリッシャ サーバは、このクラスタから Unified Communications サービスを受けているユーザの一意のリストを保持しています。同期アグリーメントはクラスタ固有で、各パブリッシャにはユーザ アカウント情報の独自コピーがあります。Unified Communications リソースが割り当てられるユーザだけが Unified CM と同期します。LDAP ディレクトリに定義されているユーザのセット全体が Unified CM クラスタにインポートされない共通の理由の一部を、次に示します。
Unified CM には、システムに追加できるアカウント数の制限がありません。シスコは、ユーザの数をサポートされているエンドポイントの 2 倍に制限することを推奨します。アプリケーション用のアカウントが必要な場合や、設計によっては追加のアカウントが必要な場合があります。
シスコは、ここで説明している制御メカニズムを使用して、LDAP データベース サイズに関係なく、インポートされるユーザ アカウントを最小限にすることを推奨します。これによって、最初とそれ以降の定期同期化の速度が改善され、ユーザ アカウントの管理可能性も向上します。
多数の LDAP ディレクトリの配置には、組織ユニット名(OU)を使用して、ユーザを論理的順序や、場合によっては階層的順序でグループ化します。ユーザを複数の OU に編成する構造が LDAP ディレクトリにある場合、インポートされるユーザのグループを制御するためにこの構造を使用することもできます。各個別 Unified CM 同期アグリーメントは、単一の OU を指定します。サブ OU 内であっても、指定 OU の下にある全アクティブ アカウントがサポートされます。OU 内のユーザだけが同期されます。ユーザを含む複数の OU がクラスタで必要な場合、複数の同期アグリーメントが必要です。Unified Communications リソースを割り当てられていないユーザが OU に含まれている場合は、これらの OU をディレクトリ同期から省くことを推奨します。
AD に同じ手法を使用して、コンテナを定義できます。同期アグリーメントでは、ディレクトリ ツリーの特定のコンテナを指定でき、それによってインポートの範囲を制限できます。
使用できる同期アグリーメントの数は限られているため、多数の OU やコンテナを持つ LDAP の配置では、この手法はすぐに使い果たされてしまいます。複数の OU がある環境でユーザを同期するには、同期サービス アカウントに割り当てる権限を制御するという方法があります。複数のユーザが存在するツリー ノードに同期アグリーメントを設定してから、システム アカウントの読み取りアクセスをサブツリーの選択部分に制限します。このアクセスを制限する方法については、LDAP ベンダーのドキュメンテーションを参照してください。
次のいずれかの理由により、フィルタリングに対して追加の制御が必要となる場合があります。
Unified CM は、標準の LDAP メカニズムを使用して、LDAP ディレクトリ ストアのデータを同期します。Unified CM は、RFC 4510 などで規定されているように、検索メカニズムを使用して要求を送信し、LDAP サーバからデータを取得します。このメカニズムでは、検索メッセージ内のフィルタ ストリング指定する機能も定義されています。LDAP サーバはフィルタ ストリングを使用して、データを返すデータベースのエントリを選択します。フィルタ ストリングの構文は、RFC 4515 の The String Representation of Search Filters で規定されています。この RFC を参照用として使用して、より複雑なフィルタ ストリングを作成できます。
フィルタ ストリングは、Unified CM から LDAP サーバに送信される検索メッセージに組み込まれ、LDAP サーバはそれを実行して、応答で提供するユーザ アカウントを選択します。
標準の属性名と、それらの属性に必要な値を指定して、フィルタを設定できます。属性は、名前の代わりに DN 要素で指定することもできます。Unified CM によって LDAP 照会で使用されるフィルタ ストリングは、ldapfilter テーブルの内部に格納され、検索メッセージに挿入されます。
フィルタは、次の構文を持つ UTF-8 形式のストリングです。
( operator ( filter1 )( filter2 ))
ここで、 filter1 および filter2 には、最初の行で示した構文が含まれ、 operator は、 表 16-6 に示す演算子のいずれかとなります。 attribute は、ディレクトリ内に存在する LDAP 属性に対応し、 operator は、 表 16-6 に示す演算子のいずれかとなり、 value は、その属性に必要な実際のデータ値に対応します。
|
|
---|---|
フィルタでは、LDAP ディレクトリ ストアに存在する任意の属性を指定できます。この属性は、Unified CM によって認識およびインポートされる属性である必要はありません。属性は、LDAP サーバでデータを選択するためにだけ使用され、対応するエントリには、Unified CM にインポートされるデータのサブセットが含められます。
例 16-1 のフィルタでは、指定された名前 Jack を持つすべてのユーザが選択されます。
(&(objectclass=user)(department=Engineering))
例 16-2 のフィルタでは、エンジニアリング部門のすべてのユーザが選択されます。
カスタム フィルタ ストリングが定義されていない場合、Unified CM は次のようにデフォルト LDAP フィルタ ストリングを使用します。
(&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
このデフォルト フィルタでは、オブジェクト クラスがコンピュータではなくユーザであり、かつアカウントに無効のフラグが付いていないエントリが選択されます。
(&(objectclass=user)((objectclass=Computer))(!(msDS-UserAccountDisabled=TRUE)))
デフォルトのフィルタ ストリングを使用して、そこに追加の条件を付加することを推奨します。次に例を示します。
(&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(telephonenumber=+1919*))
このフィルタでは、電話番号フィールドのプレフィックスが +1919 であるユーザだけが選択されます。同期アグリーメントによって、米国でエリア コード 919 を持つユーザだけがインポートされます。この例では、すべてのエントリが +E.164 形式であることを前提としています。
検索フィルタに対して、既存の任意の属性を使用できます。または、LDAP ディレクトリ ストアで定義したカスタム属性を使用することもできます。フィルタ ストリングでは、LDAP サーバによって選択され、Unified CM に返されるレコードが制御されますが、インポートされる属性は、フィルタ ストリングの影響を受けません。
カスタム LDAP フィルタ ストリングの長さは 2048 文字です。最初にカスタム LDAP フィルタを作成する必要があり、その後既存のカスタム LDAP フィルタを LDAP 同期アグリーメントに割り当てることができます。それぞれの LDAP 同期アグリーメントに、別のカスタム LDAP フィルタを使用できます。
Unified CM LDAP 同期を使用すると、ディレクトリ同期アグリーメントごとに最大 3 つの冗長 LDAP サーバを設定できます。Unified CM LDAP 認証を使用すると、認証アグリーメントごとに最大 3 つの冗長 LDAP サーバを設定できます。冗長性を確保するには、最低限 2 つの LDAP サーバを設定する必要があります。これらの LDAP サーバでは、ホスト名の代わりに IP アドレスを設定することで、ドメイン ネーム システム(DNS)の可用性への依存を排除できます。
Unified CM データベース同期機能には、LDAP ストアから Unified CM パブリッシャ データベースへユーザ設定データ(属性)のサブセットをインポートするメカニズムがあります。ユーザ アカウントの同期が発生すると、各ユーザの LDAP アカウント情報が、そのユーザの特定の Unified Communications 機能を有効にするために必要な追加データと関連付けられることがあります。認証も有効な場合、パスワード確認のための LDAP ストアへのバインドに、ユーザのクレデンシャルを使用します。同期や認証が有効な場合に、エンド ユーザのパスワードは Unified CM データベースには格納されません。
ユーザ アカウント情報はクラスタ固有です。各 Unified CM パブリッシャ サーバは、このクラスタから Unified Communications サービスを受けているユーザの一意のリストを保持しています。同期アグリーメントはクラスタ固有で、各パブリッシャにはユーザ アカウント情報の独自コピーがあります。
Unified CM クラスタが処理できる最大ユーザ数は、クラスタのメンバー間で複製される内部コンフィギュレーション データベースの最大サイズによって制限されます。設定または同期化可能なユーザの最大数は 160,000 です。80,000 人以上のユーザの場合、LDAP 同期アグリーメントの最大数は 10 に制限されますが、80,000 人未満のユーザの場合、LDAP 同期アグリーメントの合計数は 20 に制限されます。ディレクトリ同期のパフォーマンスを最適化するには、次の点を考慮してください。
(注) シスコは、上記で説明している制限までユーザ アカウントの同期をサポートしていますが、この制限を強制しているわけではありません。多くのユーザ アカウントを同期化すると、ディスク容量のスターベーション、データベース パフォーマンスの低速化、およびアップグレードの長時間化を招くことがあります。
連絡先ソース アクセスのためにユーザ データ サービス(UDS)を使用するクライアントは、Unified CM エンドユーザ データベースに存在するユーザにのみアクセスが制限されます。このデータベースは LDAP 同期によって社内ディレクトリからデータを格納できますが、検索されるユーザの数は、Unified CM でサポートされるユーザの最大数によって制限されます(詳細については、Unified CM データベース同期のキャパシティ プランニングの項を参照してください)。この制限に対処するため、Cisco Unified CM 11.5 以降のリリースでは、UDS ベースのユーザ検索で UDS から LDAP へのプロキシとして動作するように設定できます。このモードでは、UDS で要求されるユーザ検索ごとに、Unified CM は社内ディレクトリに接続して検索を実行し、その結果を UDS 経由でクライアントにリレーします。UDS 検索要求を直接実行する代わりに、このモードの Unified CM は社内 LDAP ディレクトリから返される情報に依存します。
(注) オンプレミスの Jabber 導入環境に推奨される連絡先ソースは、Cisco Directory Integration(CDI)です。LDAP の UDS プロキシは、エンドポイントが連絡先検索で UDS に依存したり、社内ディレクトリのユーザ数が Cisco Unified CM でサポートされるエンド ユーザの最大数を超えたりする導入でのみ使用してください。
UDS プロキシ機能は、Unified CM でグローバルにイネーブルになります。プロキシ機能用に LDAP データ ソースを定義するために、最大 3 つのディレクトリ Unified Communications サービスを選択できます。Unified CM は LDAP バインドを使用して検索操作を実行します。このバインド操作に使用するユーザとパスワードは、この機能専用として設定されます。UDS プロキシは、最大 3 つの LDAP ユーザ検索ベースをサポートします。
Cisco TelePresence Video Communication Server(VCS)のエンドポイントは VCS によって管理され、Cisco TelePresence Management Suite(TMS)からディレクトリ情報を受信できるようになります。Cisco TelePresence Management Suite は、Unified CM および VCS 登録エンドポイントのスケジューリングのような多くのサービスと、VCS 登録エンドポイントの管理を提供します。
Cisco TelePresence Management Suite は、複数のソースから取得する複数の電話帳を管理できます。
Cisco TMS 14.1 は、Cisco Unified Communications Manager との統合も可能で、Unified CM からディレクトリ情報を受信できます。これは Unified CM および VCS エンドポイント用の統合されたディレクトリを用意する場合に推奨される構成です。
複数の Unified CM クラスタは、Cisco TMS に複数のディレクトリ ソースとして追加され、1 つのディレクトリに編成できます。TMS は、TMS に接続され、単一または複数の VCS に登録されたエンドポイントにディレクトリ情報をプッシュできます。
詳細については、次の URL にある『 Cisco TelePresence Management Suite Administrator Guide 』と『 Cisco TelePresence Management Suite Provisioning Extension Deployment Guide 』の最新バージョンを参照してください。
https://www.cisco.com/en/US/products/ps11338/tsd_products_support_series_home.html
図 16-16 は、アイデンティティ管理アーキテクチャの概要を示します。すべてのシスコ コラボレーション アプリケーション(Cisco Unified CM with IM and Presence、Cisco Unity Connection など)は、個々の ID ストアを維持します。これらの ID ストアのユーザは個々の LDAP 同期アグリーメントによって社内ディレクトリから同期できますが、ローカルに設定することもできます。すべての関連プリンシパル(ユーザ)が社内ディレクトリと個々の ID ストアの両方に存在するようにするため、LDAP から同期することを強く推奨します。
LDAP 同期は、管理インターフェイスにアクセスするコラボレーション クライアントおよびワークステーションや、コラボレーション アプリケーションで提供されるさまざまなユニファイドコミュニケーション サービスが、シングル サインオン(SSO)を使用できるための条件です。SSO は、Security Assertion Markup Language(SAML)バージョン 2.0(SAML 2.0)に基づいて実装されています。SAML 2.0 認証では、サービスにアクセスするクライアント、これらのサービスを提供するコラボレーション アプリケーション、およびアイデンティティ プロバイダー(IdP)の間で、SAML 認証フローを使用します。IdP は実際のユーザ認証を行うコンポーネントです。IdP は、LDAP に対するユーザ/パスワード ベース認証、Kerberos 認証、スマートカード ベース認証など、さまざまな認証メカニズムをサポートできます。IdP は、SAML 2.0 仕様に準拠するマーケットで利用可能な IdP になることができます。シスコは、OpenAM、Ping Federate、Microsoft Active Directory Federated Services(ADFS)など、一部の IdP で SSO を検証しています。
シングル サインオン(SSO)に対して、Unified Communications サービスへの認証は、SAML 2.0 による IdP で処理されます。この機能を使用すると、任意のユーザは Unified Communications サービスを提供するどのエンティティについても必要な認証は一度のみになり、再び認証しないで他のすべての Unified Communications サービス プロバイダーの GUI にアクセスできます。
SAML 2.0 はユーザ認証のみを提供し、ブラウザ ベースです。SAML 2.0 は、UC インターフェイス(Unified CM UDS、Unified CM SIP、Unified CM CTI、Unified CM IM and Presence SOAP、Unified CM IM and Presence XMPP、Unity Connection VMRest など)を使用するための分散型承認の要件に対処しません。
Unified CM 上で実行される集中型承認サービスが、Unified CM、Unified CM IM and Presence、Unity Connection によって提供される UC サービスの認証を提供します。この集中型承認機能は、OAuth 2.0 の仕様に基づいています。OAuth 2.0 は、リソース所有者に代わってサービスへの委任アクセスを提供する、承認用のオープン フレームワークです。このプロトコルは、クライアントが認証に使用するクレデンシャルを共有せずに、クライアントがリソースにアクセスすることを承認できるようにします。基本的に OAuth では中央承認インスタンスがクライアントにアクセス トークンを発行できるようにします。クライアントはこのトークンを、承認された証拠としてサービスを提供するサーバに提示します。アクセス トークンは、特定のリソースに対するアクセス権の付与レベルと有効期間を表す文字列値です。アクセス トークンは、承認サービスから承認の詳細を取得するために使用できる識別子を表しているか、実際の承認内容を格納しているかのいずれかです。後者の場合、アクセス トークンは 自己完結型 と呼ばれます。自己完結型アクセス トークンのコンテンツには署名を付けて、承認内容の信ぴょう性を検証できるようにする必要があります。必要に応じて、自己完結型アクセス トークンのコンテンツを暗号化することもできます。アクセス トークンが自己完結型でない場合、サービス プロバイダーは承認の有効性を確認するために、提示されたトークンの検証を承認サービスに要請する必要があります。このプロセスにおいて、承認トークンの内容、およびクライアント認証とトークン発行に使用するメカニズムは、サービス プロバイダーに対して完全に透過的です。
シスコ コラボレーション ソリューションの承認フレームワークでは、自己完結型アクセス トークンを使用しています。アクセス トークンの署名と暗号化に使用されたキーは、Unified CM から Unified CM IM and Presence にプッシュされ、Cisco Unity Connection および Cisco Expressway からプルされます。
SAML 2.0 による SSO は、既存の LDAP バインドとローカル認証に追加された認証オプションです。SAML 2.0 SSO では、OAuth 承認サービスを含むすべての Unified Communications サービスは、SAML 2.0 を使用して社内アイデンティティ管理システムと直接統合します。
SSO に使用されるプライマリ プロトコルは、SAML です。プロトコル仕様、使用例、認証フローなどの SAML の詳細情報は、インターネットで公開されています。ここでは、SAML の重要な点だけを紹介します。
SAML を使用したアイデンティティ プロバイダー(IdP)とのすべての対話は、クライアント側の Web ブラウザを経由する必要があります。SAML の認証がユーザに Web GUI を公開しないクライアントに使用する場合、これらのクライアントは、内部の WebView クライアントを使用します。この例では、SSO をサポートする Jabber ソフトクライアントおよびコラボレーション エンドポイントが含まれます。
Security Assertion Markup Language(SAML)は、サービス プロバイダー(SP)と IdP との間のデータ交換用に特別に設計された XML データ形式です。SAML は IdP と SP 間で認証関連情報を渡すためにアサーションを含むセキュリティ トークンを使用します。この交換では、IdP が SAML 認証局のロールを担い、SP は SAML ユーザとなります。SAML の仕様は次の URL から入手できます。
https://saml.xml.org/saml-specifications
SAML 認証を行う前に、サービス プロバイダー(SP)と ID プロバイダー(Idp)間に信頼関係が確立されていなければなりません。これは、SP と IdP 間でメタデータを交換することによって行われます。
一般的に、単一の SAML メタデータ インスタンスに単一の SAML エンティティまたは複数のエンティティが記述されています。複数の SAML インスタンスを記述する SAML メタデータ インスタンスには、単一エンティティの記述のリストが含まれます。Cisco Unified CM リリース 11.5 以前では、シスコ コラボレーション ソリューションによって作成された SAML メタデータ インスタンスは、常に単一の SAML インスタンスのみを記述します。
SAML メタデータ インスタンスに記述されているどの SAML インスタンスについても、メタデータには以下が含まれます。
これらのうち固有識別子以外は SAML 仕様でオプションであり、シスコ コラボレーション SP によって作成されたメタデータに含まれません。
SAML メタデータ インスタンスに含まれる各ロールの記述はサポートされるプロトコルを定義します。また、オプションで SSO キー情報も含まれます。これらのキーは、後で SAML エンティティ間で交換される SAML メッセージに署名するために使用されます。
SAML サービス プロバイダーの SAML メタデータは、SAML ID プロバイダーがこれらの 2 つのエンティティ間における SAML 交換に関連するサービス プロバイダーについて理解するために必要です。サービス プロバイダーに固有の SAML メタデータには、サービス プロバイダーが SAML 認証要求に署名するかどうかや、サービス プロバイダーが署名するためにサービス プロバイダーに返される SAML アサーションを要求するかどうかを示します。また、サービス プロバイダー SAML メタデータは、認証応答のポスト先を定義します。この認証コンシューマ サービス(ACS)の定義は基本的に URL です。また、サービス プロバイダー SAML のメタデータは、SAML 認証プロセスの一部として SAML サービス プロバイダーと SAML ID プロバイダーの間で交換される属性を定義する場合があります。
同様に、ID プロバイダーのメタデータは IdP と SP 間の SAML 交換に関連する IdP 特性を定義します。IdP のメタデータも、認証要求の署名要件と、SAML 認証プロセスの一部として IdP と SP 間で交換する必要がある属性を定義できます。
SAML のメタデータ形式に関する詳細情報は次の URL から入手できます。
https://saml.xml.org/saml-specifications
シスコ コラボレーション SP によって作成された SAML メタデータには、以下のみが含まれます。
SAML は、一般的な使用例を解決するための SAML の用途を記述するプロファイル数を定義します。シスコ コラボレーション サービスで SSO に使用される関連プロファイルは、SAML V2.0 の Web ブラウザ SSO プロファイルです。
このプロファイルによって解決する使用例は、図 16-17 に示すマルチドメイン Web のシングル サインオンです。この使用例では、ユーザはすでに何らかの Web サービスでログイン セッションを行っており(たとえば、travel.example.org)、このサービスを使用しています。ログイン プロセスの一環として、セキュリティ コンテキストが travel.example.org に確立されました。同じユーザが別の Web サービス(たとえば、sales.example.de)に移動し、travel.example.org と sales.example.de の間にこれらのサービス間でユーザにフェデレーション ID を確立するビジネス契約が存在する場合、そのユーザは認証クレデンシャルを再び提供せずに Web サービス sales.example.de にアクセスできます。この場合、ID プロバイダーのサイト(travel.example.org)は、このユーザは既知であり、適切に認証されており、特定の ID 属性を持っていることを、サービス プロバイダーのサイト(sales.example.de)にアサートします。サービス プロバイダーのサイト(sales.example.de)は、これらのサイト間の既存のビジネス契約に基づきこのアサーションを信頼し、このサービスへのアクセスを許可します。
図 16-17 マルチドメイン Web のシングル サインオン
この説明は、ユーザが最初に Web サービスによって認証され、その最初の Web サービスはユーザが 2 つ目の Web サービスにアクセスできるように ID アサーションを提供することを示しています。最初にアクセスした Web サービス(travel.example.org)は、SP sales.example.de の IdP として機能します。これは IdP 起動の Web SSO と呼ばれます。
図 16-18 に示す、シスコ コラボレーション サービスで使用されるより一般的な Web SSO のフローは、SP 起動の Web SSO です。この場合、ユーザは直接(最初に IdP にアクセスせずに)SP の保護されているリソースにアクセスしようとします。SP は IdP にユーザを送信して認証させ、次にユーザは IdP から受け取った認証アサーションを SP に提示してアクセスします。
図 16-18 サービス プロバイダーによって起動される Web SSO
SAML の Web ブラウザ SSO プロファイルは、認証が IdP と SP のどちらによって起動されるのかや、IdP と SP 間のメッセージの交換方法によって、さまざまなオプションを提供します。前述のとおり、シスコ コラボレーション サービスは、サービス プロバイダーとのアクティブなセッションを行っていないユーザが保護されているリソースにアクセスしようとした場合に、SP がユーザを IdP に送信して最初に認証させる場合に限り、SP 起動の SSO を使用します。IdP は、認証アサーションを作成して、ユーザをそのアサーションとともに SP に戻します。
シスコ コラボレーション サービスの IdP と SP 間のメッセージ交換に使用されるバインディングは、図 16-19 に示す Redirect/POST バインディングです。ここでは HTTP 302 リダイレクトを使用し SP から IdP に SAML 認証要求メッセージが送信され、認証応答は HTTP POST メッセージを使用して IdP から SP に送信されます。
図 16-19 SP 起動の SSO(Redirect/POST バインディング)
1. ユーザが、アプリケーション サーバでホストされている URL をブラウザに入力して、サービスまたはリソースにアクセスしようとします。この時点でブラウザにそのサービスとのアクティブなセッションはありません。
2. SP は、要求元のクライアントにアクティブなセッションがないことがわかると、HTTP はステートレスなので、クライアントが事前に SP によって発行されたセッション Cookie を送信する場合にのみ、アクティブ セッションは SP によって検出できます。SSO の設定に基づいて、SP は、SSO 設定の一部として定義されている適切な IdP に送信される SAML 認証要求を生成します。この SAML 要求には、要求を生成した SP に関する情報が含まれています。この情報は、IdP が SAML 要求の送信元 SP を識別できるようにするために必要です。
SP は、直接 IdP と通信してユーザを認証するのではなく、代わりに SP は、ブラウザを IdP にリダイレクトします。リダイレクトに使用する URL は、事前に交換した IdP のメタデータから取得します。IdP に送信される SAML 要求は Base64 エンコードを使用して URL のクエリー パラメータとしてリダイレクトに含まれます。
この HTTP 302 のリダイレクトは次のようになります。
上記のエンコードされた SAML 認証要求は以下にデコードできます。
認証パラメータを指定し、要求 SP を識別する他の詳細の中でも、上記の SAML 認証要求は、アサーション コンシューマ サービス(ACS)URL も指定します。ACS の URL は、認証プロセス終了時に SAML 認証応答を POST する必要がある URL です。
3. ブラウザはリダイレクトを受信し、URL に続き、IdP に対応する GET を発行します。SAML 要求は維持されます。この時点ではブラウザは IdP のアクティブなセッションがありません。
4. アクティブなセッションがないブラウザから新しい要求を受信したら(ブラウザは事前に IdP で発行された Cookie を送信しない)、IdP は事前に設定された認証メカニズムに基づいてユーザを認証します。利用可能な認証メカニズムには、ユーザ/パスワード、PKI/CAC、または Kerberos が含まれます。ユーザ/パスワード認証のため、IdP はユーザにクレデンシャルを入力するようにフォームをプッシュすることがあります(たとえば、IdP ログイン フォーム付きの「200 OK」メッセージなど)。実際の認証の場合、IdP はユーザ/パスワード認証のために LDAP サーバなど、バックエンド システムに依存する可能性があります。
ここで重要な点は、認証のためのクレデンシャルの交換が IdP とブラウザの間で行われることです。SP は関与せず、クレデンシャルを目にすることもありません。
5. 認証プロセスに必要な詳細情報がブラウザから提供されます。ユーザ/パスワード認証の場合、この情報は POST で提供されます。その他の認証メカニズムの場合は、ブラウザが IdP にその他の詳細を送信する必要があります。
6. 提供されたクレデンシャルを IdP が確認および検証します。この確認には、それぞれのバックエンド システム(LDAP に対するユーザ/パスワード認証の LDAP バインド、チケットを検証する Kerberos サーバとの通信などです。
最終的に IdP は SP に対して SAML 応答を生成します。この応答には、認証プロセスの結果を記録した SAML アサーションが含まれます。SAML アサーションには、基本的な Yes/No 情報に加えて、有効性の情報と認証されたエンティティを記述する属性に関する情報が含まれます。認証されたエンティティのユーザ ID は、よく知られている属性 uid に最低限含まれている必要があります。これは、SP がこの情報をアサーションから抽出し、認証されたエンティティをローカルのデータベースに存在するユーザに関連付けるためです。
SAML アサーションは、IdP のメタデータで公開されている SSO キーの情報に従って、IdP によって署名され、場合によっては暗号化されます。これにより、SAML アサーションが本物であることを SP が確認できます。
IdP は 200 OK メッセージで非表示フォームの SAML アサーションをブラウザに返します。非表示のフォームは、SP のアサーション コンシューマ サービス(ACS)URL に SAML アサーションを POST するようブラウザに指示します。
IdP は、今後、クレデンシャルの交換を実行せずに同じブラウザからの認証要求に応答できるようにセキュリティ コンテキストを確立する必要があります。IdP は、ブラウザで有効なセッションがすでにあることを認識し、再度クレデンシャルを要求することなく、前に認証されたユーザの認証をアサートします。このコンテキストは、IdP によってブラウザで設定されたセッション Cookie によって確立されます。これにより、複数の SP に対する SSO がおおむね実現されます。
7. ブラウザは 200 OK メッセージで受信した非表示の POST に続き、SP のアサーション コンシューマ サービスに SAML アサーションを POST します。
8. SP は、SAML アサーションを POST から抽出して、アサーションの署名を検証します。これにより、SAML アサーションと IdP が本物であることが保証されます。その後、属性ステートメントの一部として SAML アサーションの属性 uid で受け取ったユーザ ID を使用して、そのユーザが要求したサービスへのアクセスを許可されているかどうかを判断します。この判断は、SP のローカル アクセス制御の設定に基づいて行われます。SAML アサーションで受け取った uid 値は、要求されたサービスで承認されたエンド ユーザの Unified CM ユーザ ID と一致する必要があります。SAML アサーションで IdP から送信されたユーザ識別子を Unified CM のユーザ ID に関連付けるため、SSO 認証は LDAP からで同期されたエンド ユーザでのみサポートされます。ここでは、IdP が同じディレクトリに統合されているため、IdP によって返される uid 値は Unified CM のエンド ユーザ情報と同じデータ ソースに基づいているという前提があります。
SP は要求されたリソースへのアクセス権を付与し、ブラウザに 200 OK メッセージの内容を返信します。SP はまた、同じブラウザから同じ SP へのそれ以降のアクセス要求に対して SP が IdP との交換をそれ以上開始する必要がないように、ブラウザにセッション Cookie を設定します。IdP は、SP セッションの期限が切れた後にのみ、同じブラウザからの追加要求に関与します。
SSO がコラボレーション サービスで有効になっている場合、各サービスへのすべてのアクセスは、SSO を使用して認証されます。フォールバック手段として、バニティ URL またはリカバリ URL もランディング ページに存在します。バニティ URL は SSO メカニズムをバイパスし、すべての管理者 GUI へのアクセスを提供します。バニティ URL による管理者 GUI へのアクセスは、ローカル ユーザ データベースに対して認証されます。バニティ URL による GUI へのアクセスは utils sso recovery-url disable コマンドを使用して CLI で無効にできます。
IdP に到達できないか IdP がダウンしている、メタデータに問題がある(たとえば、期限切れの署名付き証明書)、IdP の設定が変更されるなど、SAML のインフラストラクチャに問題がある場合はバニティ URL をリカバリのバック ドアとして使用できます。
コラボレーション サービスは現在、次の種類のユーザをサポートしています。
このユーザはインストール中に指定され、CLI、Disaster Recovery System(DRS)GUI、および OS Admin GUI にもアクセスできます。OS ユーザのクレデンシャルは、他のユーザのクレデンシャルとは別に維持されます。SSO を有効にすると、ローカル データベースに格納されているパスワードを使用して、CLI に対するアクセスが常にローカルで認証されます。一方、DRS および OS 管理 GUI に対するアクセスは SSO によって認証され、プラットフォーム データベースに照らし合わせて承認されます。CLI で set account name コマンドを使用することで、SSO UID 値からプラットフォーム ユーザへのマッピングを作成できます。
これらはローカルで作成および管理される機能ユーザです。パスワードは、ローカル データベースに保存されます。アプリケーション ユーザは SSO に対してイネーブルになっていません。SSO がイネーブルになっている場合、アプリケーション ユーザはランディング ページのバニティ URL から Admin GUI のみにアクセスできます。
これらのユーザはローカルで作成および管理されます。パスワードはローカルに保存されます。これらのユーザはエンタープライズ ID 管理システムに存在しません。SSO がイネーブルの場合、ローカル エンド ユーザを正常に認証できません。SSO がイネーブルでないと、ローカル エンド ユーザと LDAP 同期ユーザは引き続きサポートされます。
これらのユーザは、社内 LDAP ディレクトリで管理され、LDAP 同期アグリーメントにより Unified Communications サービスに同期されます。ローカル データベースのどの LDAP 同期エンド ユーザにも、社内 LDAP ディレクトリに一致するユーザがあります。SSO がディセーブルの場合、LDAP 同期エンド ユーザのパスワードは、LDAP バインド操作を使用して検証されます。SSO がイネーブルになっている場合、LDAP 同期ユーザの認証は IdP で定義された認証メカニズムに基づき、認証はローカル設定に基づきます。LDAP 同期エンド ユーザは、要求されたリソースにアクセスするためにローカルに割り当てられた適切な権限が必要です。
PIN ベースの認証は常に(SSO が有効になっている場合でも)ローカル設定に基づきます。複数のコラボレーション サービスは個別の PIN を維持します。Cisco Unified CM リリース 11.5 以降、PIN は Unified CM と Cisco Unity Connection との間で同期させることができます。
次の Web サービスは、SAML IdP リダイレクトに基づいて SSO で有効になります。
すべての Jabber プラットフォームは、SSO に組み込みのブラウザ制御を使用します。この制御は、基盤となるオペレーティング システム ブラウザ技術に依存します( 表 16-7 を参照)。Jabber で使用する組み込みブラウザのコントロールがシステム ブラウザと同じテクノロジーに基づいているとしても、この 2 つの間で Cookie が共有されることは決してありません。これは、ユーザがシステム ブラウザを使用してすでに同じ IdP に対して認証されているとしても、Jabber には常に SSO を使用した専用の認証が必要であることを意味します。この問題を回避する唯一の方法は、セッション Cookie の代わりに永続的な Cookie を使用するように IdP を設定しないことです。ただし、この方法はベスト プラクティスであるとは見なせません。永続的な Cookie を使用すると IdP 認証状態が一般に公開されることから、同じ Cookie 保管場所にアクセスできる他のアプリケーションによってハイジャックされる可能性があるためです。
|
|
|
|
|
|
||||
|
Apple iOS 上の Jabber の場合、ブラウザの選択(WebKit または Safari)は、[iOS での SSO ログイン動作(SSO Login Behavior for iOS)] エンタープライズ パラメータによって決まります。Apple iOS 上で SSO のブラウザとして Safari を選択すると、Apple 製アプリケーションだけがアクセスできる iOS 証明書ストアやその他の保護されたリソースにもアクセスできるようになります。SSO で証明書ベースの認証スキームを使用しなければならない場合は、このように選択する必要があります。
SAML SSO は、クラスタ内のすべてのノードに対して常にイネーブルまたはディセーブルにする必要があります。クラスタ内のすべてのノードが SSO に対してイネーブルになるか、どのノードも SSO に対してイネーブルになりません。Admin GUI 経由で SSO をイネーブルにすると、自動的にすべての既存のノードが同時に SSO をイネーブルにします。このプロセスの一部として SP メタデータがダウンロードされて、IdP とクラスタ ノードの間の信頼の範囲を確立するために使用されます。
Cisco Unified CM リリース 11.5 より前、IdP では各クラスタ ノードを個々の SP として表現する必要がありました。すでに SSO モードに入っているクラスタに後でノードが追加されると、その追加されたノードのメタデータは IdP で定義された SP のリストを完成するために IdP にインポートされる必要がありました。
Cisco Unified CM リリース 11.5 以降では、SSO をクラスタ全体モードで有効にできます。この場合、IdP と交換する必要があるメタデータ ファイルは 1 つのみです。クラスタの SAML メタデータには暗号化および署名キーを 1 つだけ含めることができるため、クラスタ全体の SSO は単一のマルチサーバ Tomcat 証明書がクラスタで使用される場合だけ使用できます。マルチサーバ証明書は、CA 署名付き証明書である必要があります。新しいノードがクラスタ全体の SSO に対応したクラスタに追加されると、追加されたノードの新しい Assertion Consumer Service URL を IdP が認識できるように、更新されたメタデータは IdP と交換される必要があります。
シスコ コラボレーション SP の SP メタデータには、HTTP-POST および HTTP-Redirect バインドの Assertion Consumer Service 定義が含まれます。これらのバインドは、IdP によってサポートされ、IdP で有効である必要があります。クラスタ全体モードの SSO の場合、IdP が単一 SP に対する複数の Assertion Consumer Service 定義をサポートできる必要があります。
IdP のメタデータはすべての SAML SP にインポートされる必要があります。SSO が Admin GUI でイネーブルの場合、プロセスで提供される IdP のメタデータは、クラスタ内のすべてのノードに自動的にインポートされます。アサーションの署名または暗号化が IdP によって使用される場合、シスコ コラボレーション SP と交換した IdP のメタデータに署名および暗号化キーを含める必要があります。
SP メタデータはオプションの ContactPerson 情報を含まないため、IdP はシスコ コラボレーション SP の連絡先情報を表示できません。
SAML SP は、SAML AuthnRequest に WantAssertionsSigned を含めることで、IdP から署名されるアサーションを要求できます。現在、シスコ コラボレーション SP はこの情報を送信せず、SP メタデータで同じパラメータが False に設定されます。これによって、IdP はアサーションの署名を完全に制御できます。シスコは IdP で署名する SAML アサーションを実行することを推奨します。
そうでない場合は、IdP によって要求されないと、シスコ コラボレーション SP は SAML 認証要求を暗号化したり署名したりしません。これは IdP によってサポートされている必要があります。
シスコ コラボレーション SP は、メタデータと SAML 認証要求の両方で、namedid-format:transient を要求します。IdP はこの形式をサポートし、適切に設定される必要があります。
SAML アサーションの一部として、IdP は AttributeStatement で属性 uid を返す必要があり、この属性の値は Unified CM の各エンド ユーザのユーザ ID と一致している必要があります。
IdP の可用性は SSO を使用するうえでの重要な要件です。IdP は完全な冗長性と耐障害性とともに導入する必要があります。このタイプの導入に重要なのは、IdP が単一の論理 URL を使用して導入され、単一の IdP URL の可用性が高くなるように適切なロード バランサと Web サーバ ファームが導入されることです。単一の IdP URL は IdP のメタデータに含まれ、すべてのシスコ コラボレーション SP にインポートされます。1 つの要素の障害(たとえば、1 つの Web サーバ)は、コラボレーション サービスでは非表示にする必要があります。
SAML 要求およびアサーションは、SP および IdP の証明書を使用して署名されます。SAML SSO のメカニズムが引き続き機能することを確認するために、これらの証明書の有効期間を厳密に監視する必要があります。
SAML アサーションには、有効性の情報(NotBefore、NotOnOrAfter)が含まれます。有効なアサーションがタイミングの問題で拒否されないようにするには、Network Time Protocol(NTP)などの適切なメカニズムを使用してすべてのサービスを同期することが必須です。
Web インターフェイスにアクセスするユーザの場合、認証はローカル設定または LDAP に基づいて行われるか、あるいは(SSO の場合)ユーザのブラウザ、Web サーバ、IdP 間の SAML 交換に基づいて行われるかのいずれかです。認証に成功すると、Web サーバ(Unified CM Administration GUI にアクセスする場合は、Unified CM で実行している管理アプリケーション)は、ローカル設定を確認して、認証済みユーザに特定のリソースへのアクセスが承認されているかどうかを判断します。たとえば、ユーザ Bob が IdP に有効なクレデンシャルを提供して SSO 認証が成功したとしても、Bob が「Standard CCM Super Users」グループのメンバでなければ、Unified CM は引き続き Unified CM Administration インターフェイスへのアクセスを拒否できます。この場合 Bob は、Unified CM Administration へのアクセスを取得する代わりに、システムにアクセスするために必要な権限を持っていないことを示すメッセージだけを受け取ります。Unified CM 管理 GUI やエンドユーザのページなどの Web サービスに対するアクセスの承認は、常にアプリケーションで定義されたアクセス レベルに基づいて行われます。
Jabber クライアントおよびその他のエンドポイントは、多数のコラボレーション インターフェイス(Unified CM SIP、Unified CM CTI、Unified CM IM and Presence SOAP、Unity Connection VMRest など)へのアクセスが必要です。(各インターフェイスで)多重認証メカニズムにならないよう、Cisco Collaboration システムでは単一の認証に基づく一元化された承認フレームワークとして OAuth を使用しています。
Oauth 2.0 認証フレームワークは、IETF OAuth 作業グループによって定義されたオープン スタンダードです。現在のバージョンは RFC 6749 としてリリースされています。
アプリケーションがユーザに代わって複数のサービスにアクセスしなければならない場合、OAuth を使用しなければ常に、サービスごとに個別の認証および承認が必要になります。これはエンドユーザにとって、準最適なユーザ エクスペリエンスになります。なぜなら、エンド ユーザが複数のクレデンシャルのセットを管理せざるを得ないためです(ただし、SSO を使用することで部分的に対処できます)。しかも、アクセス クレデンシャルを複数のアプリケーションで共有しなければならないという信頼に関する問題があります。
OAuth はこのような課題に対処するために、アプリケーションがエンド ユーザの代理としてサービスに対するアクセス権を取得できるよう、エンド ユーザとサービスの間で行われる承認インタラクションを調整します。この承認インタラクションの一環として、エンド ユーザは認証後に、承認を求めるアプリケーションにアクセス トークンを付与するよう OAuth 承認サービスに指示します。アクセス トークンを受け取ったアプリケーションは、サービスにアクセスする際に、承認された証拠としてそのトークンを提示します。
アクセス トークンには有効期限があるため、アプリケーションでアクセス トークンを使用できる期間は限られます。OAuth 仕様では、OAuth 承認サービスがアクセス トークンと併せてリフレッシュ トークンも付与できるようになっています。通常、リフレッシュ トークンの有効期間はアクセス トークンよりも長くなっていて、リフレッシュ トークンが有効な限り、アプリケーションはこれを使用して OAuth 承認サービスから新しいアクセス トークンを取得することができます。完全な承認手順に従ってアクセス トークンを取得する場合とは対照的に、リフレッシュ トークンと引き換えに新しいアクセス トークンを取得する場合、エンド ユーザのインタラクションも、さらにはエンド ユーザの認証も必要ありません。リフレッシュ トークンの概念により、エンド ユーザに代わってサービスへのアクセスがアプリケーションに承認される期間は(リフレッシュ トークンが有効な期間だけ)長くなりますが、リフレッシュ トークンを失効できるようにすることによってアクセス トークンの露出をその有効期間に制限しています。アプリケーションが現在使用しているアクセス トークンの有効期間の終了時に新しいアクセス トークンを取得しようとする場合、OAuth 承認サービスとのインタラクションが必要になります。リフレッシュ トークンが失効していると、OAuth 承認サービスは、アプリケーションが引き続き承認されていることを表す新しいアクセス トークンの発行を拒否します。
インターネットでは、さまざまなサービスで OAuth が一般的に使用されています。一部のサービスでは、Web アプリケーションに独自の承認ロジックを組み込む代わりに、Facebook、Google、Twitter などのサイトの OAuth 承認サービスにこのプロセスを委任しています。その場合、メインの Web サイトで、ユーザがたとえば Facebook による OAuth 承認リンクを表すアイコンをクリックするだけで、メインの Web サイト(クライアント)が OAuth 承認フローを開始します。これにより、エンド ユーザのユーザ エージェント(Web ブラウザ)は承認サーバ(たとえば Facebook)にリダイレクトされます。承認サーバに対し、エンド ユーザが自分のクレデンシャルを使用して認証を行った後、承認サーバはエンド ユーザに対し、このフローでクライアントが要求したアクセス レベル(スコープ)(たとえば、ユーザのメール アドレスに対するアクセス)を承認するよう求めます。エンド ユーザがアクセスを承認すると、それと同時に承認サーバはアクセスを要求しているクライアントにアクセス権を付与し、アクセス トークンを発行します。クライアントがアクセス トークンを取得する実際のプロセスは、そのクライアントで使用する OAuth 承認フローのタイプによって異なります。
OAuth の動作を理解するには、以下のロール定義が参考になります。
保護されたリソースの所有者。OAuth フレームワークでのリソース所有者とは、保護されたリソースに対するアクセス権を付与するエンティティのことです。リソース所有者が個人の場合は、エンド ユーザとも呼ばれます。
保護されたリソースは、リソース サーバでホストされます。リソースに対するアクセスの要求では、承認された証拠としてアクセス トークンを使用します。要求に含めて提示されたアクセス トークンに基づいて、リソース サーバはアクセス権を付与するか要求を拒否します。シスコ コラボレーション ソリューションのコンテキストでは、保護されたリソースとは、Cisco Jabber クライアントおよびエンドポイントで使用する UDS、Unity Connection VMRest などのインターフェイスを指します。
リソース所有者に代わり、保護されたリソースに対して要求を行うアプリケーション。クライアントとしては、デスクトップ マシンやモバイル デバイス上で稼働するアプリケーション、サーバ アプリケーション、クラウド サービスなどが考えられます。「クライアント」という用語は、OAuth フレームワークのコンテキストにおけるロールを単に意味します。
一部の使用例では、OAuth クライアントはシスコ コラボレーション サービス(たとえばコラボレーション エッジ)またはエンド ユーザ クライアント(たとえば Jabber)になります。コラボレーション エッジがユーザに代わって OAuth トークンを要求する場合、コラボレーション エッジは OAuth クライアントとして機能します。企業内の Jabber クライアント ログイン フローの場合、Jabber クライアントが OAuth クライアントとして動作します。
各 OAuth クライアントには、OAuth client_id と呼ばれる固有識別子があります。この OAuth client_id は、クライアント タイプを一意に識別します。たとえば、Jabber for Windows と Jabber for Android は、異なる client_id を使用します。しかし、明確な理由から変更された client_id によって異なるクライアント リリースを認証サービスが区別できることが要求される(たとえば、クライアント リリース別に OAuth 交換のバリエーションをサポートする)場合を除き、Jabber for Windows ではすべてのリリースで同じ client_id を使用します。シスコ製品およびサードパーティ クライアント用に、一連の client_id が事前定義されています。
保護されたリソースに対する承認を要求すると、OAuth クライアントは特定の範囲のトークンを要求できます。この範囲は、アクセスするために OAuth トークンを使用できるサービスの範囲を表します。
OAuth アクセス トークンは、承認サービスによって提供され、べアラー(クライアント)によって保護されたリソースへのアクセスに使用されます。通常、アクセス トークンは、特定のユーザに対して発行され、特定の有効期限があります。アクセス トークンが期限切れになると、クライアントは新しいアクセス トークンを取得する必要があります。
リソース所有者の認証が完了し、そのリソース所有者から承認を得ると、承認サーバはクライアントが使用するアクセス トークンを発行します。
リソース サーバと承認サーバは必ずしも別々のエンティティである必要はありません。これらの機能は、同じサーバ上に存在することができます。さらに、単一の承認サーバが複数のリソース サーバのアクセス トークンを発行することもできます。
Cisco Unified Communications アーキテクチャでは、承認サーバは Unified CM 上で実行される機能です。承認サーバによって発行されたアクセス トークンは、Cisco Jabber クライアントやその他のエンドポイントがさまざまなコラボレーション インターフェイス(Unified CM SIP、Unified CM CTI、Unified CM IM and Presence SOAP、Unity Connection VMRest など)のアクセス権を取得するために使用します。
OAuth では、多種多様な承認フローを定義していますが、このすべてのフローの間で共有する共通点がいくつかあります(図 16-20 を参照)。
図 16-20 に示されている OAuth フローは、4 つのロールと、それらのロール間での以下のインタラクションを説明しています。
1. クライアントがリソース所有者(エンド ユーザ)に、保護されたリソースへのアクセスを承認するよう求めます。図 16-20 では、これはクライアントとリソース所有者間で直接行われるインタラクションとして示されていますが、実際には、この要求は承認サーバの仲介によって行われるのが通常です。その場合、承認サーバはリソース所有者の認証が成功した後、承認フローを開始したクライアントを承認するよう、リソース所有者に求めます。図 16-20 に示されているように、クライアントを承認するかどうかの決定は、リソース所有者(エンド ユーザ)の手に委ねられています。
2. クライアントが、リソース所有者の承認を表す承認付与を受け取ります。この付与は、OAuth 仕様で定義されている付与の 4 つのタイプのうちの 1 つによって表現されます。付与のタイプは、そのクライアントが承認を要求するために使用した手段と、承認サーバでサポートされているタイプによって決まります。
3. クライアントは承認付与を使用して、承認サーバにアクセス トークンを要求できます。それには、クライアントが認証を行って、取得済みの承認付与を提示する必要があります。クライアントの認証が必要となるのは、信頼されていない仲介者によって承認付与が悪用されないようにするためです。
4. 承認サーバはクライアントを認証する際に、承認付与を検証します。承認付与が有効であれば、アクセス トークンと(オプションで)リフレッシュ トークンを発行します。承認サーバによるクライアント認証では、クライアントの認証クレデンシャルが事前に承認サーバに登録されていることが必要になります。
5. この段階で、クライアントは保護されたリソースへのアクセスを要求し、取得済みの承認トークンを承認の証拠として使用できます。
6. リソース サーバはアクセス トークンを検証し、有効であれば、要求を処理します。この検証では、自己完結型アクセス トークンが使用されていない場合は特に、リソース サーバと承認サーバの間でのトランザクションが必要になることがあります。
ステップ 1 の説明で述べたように、承認サーバから承認付与を取得する方法として優先されるのは、承認サーバを仲介として使用することです。OAuth 承認コード付与フローは、この手順の一例です(詳細については、承認コード付与フローを参照)。
図 16-20 の一般的な OAuth 承認フローの説明に示されているように、承認付与は、保護されたリソースへのアクセスの承認がリソース所有者によって付与されていることを表すクレデンシャルです。クライアントは承認付与を使用してアクセス トークンを取得します。OAuth 仕様では、承認付与のタイプとして、承認コード、暗黙、リソース所有者パスワード クレデンシャル、クライアント クレデンシャルの 4 つを定義しています。このドキュメントでは、以下に説明する 2 つのフローのみが関連します。
暗黙の付与フローは、承認コード付与フローを単純化したものです。このフローでは、承認コード付与を発行する代わりに、承認サーバが直接、アクセス トークンをクライアントに発行します。中間クレデンシャルが発行されないことから。これは「暗黙」と呼ばれます。
このフローは、スクリプト言語を使用してブラウザに実装されたクライアントに対して最適化されています。このフローではアクセス トークンが直接発行されるため、クライアントの認証は行われません。したがって、アクセス トークンがリソース所有者だけでなく、リソース所有者のブラウザにアクセス可能な他のアプリケーションに漏れる可能性があります。
暗黙の付与フローは応答性に優れていますが(アクセス トークンの承認コード付与を交換するための追加トランザクションが不要であるため)、それほどセキュアではないフローとして見なすべきです。
また、シスコ ユニファイド コミュニケーション ソリューションのコンテキストでは、Jabber クライアントやその他のエンドポイントが OAuth 承認フローによって取得したアクセス トークンを使用して各種のシステム インターフェイスにアクセスします。そのため、暗黙の付与フローを使用する場合、それまで使用していたアクセス トークンの有効期限に達した時点で新しいアクセス トークンを取得するには、常に新しい承認手順が必要になることに注意してください。承認コード付与フローであれば、クライアントはリフレッシュ トークンも取得するため、エンド ユーザの認証を繰り返すことなく、リフレッシュ トークンを使用して新しいアクセス トークンを取得できます。
エンティティ(通常はサービス)は、エンド ユーザに代わり、発行されたアサーションを使用して、そのエンド ユーザに関連付けられた OAuth トークンを入手します。コラボレーション エッジでは、このフローのバリエーションを使用して、承認コードを取得するためにエッジ外部から接続するクライアントに代わってトークンを取得します。
このフローでは、クライアントとリソース所有者との間の仲介として承認サーバを使用します(図 16-21 を参照)。
図 16-21 に、承認コード付与フローの詳細を示します。クライアントはエンド ユーザに直接承認付与(承認コード)を要求することはしません。代わりに、クライアントはエンド ユーザを承認サーバにリダイレクトします。フローではその後、承認コードが付与されエンド ユーザはクライアントに戻されます。このリダイレクションでは、エンド ユーザの Web ブラウザが使用されます。つまり、承認コード付与フローはブラウザ ベースです。このフローでのエンド ユーザのブラウザのリダイレクションでは、HTTP 302 リダイレクトを使用できるだけでなく、ブラウザに返される Web コンテンツでは JavaScript コードベースのリダイレクションも使用できます。
1. クライアント(たとえば Cisco Jabber)が承認フローを開始するために、エンド ユーザのブラウザを承認エンドポイントにリダイレクトします。シスコ ユニファイド コミュニケーション ソリューションでは、これは Unified CM 上の /ssosp/oauth/authorize です。
2. ブラウザが承認サーバ上のエンドポイントにアクセス(GET)します。この要求で、いくつものパラメータが渡されます。具体的には、クライアント ID、要求するアクセス レベル(スコープ)、一意の要求 ID、フローの最後に結果の承認コードを送信するリダイレクト URI などです。
3. 承認サーバがエンド ユーザを認証します。Unified CM 上のローカル エンド ユーザ テーブルに照らし合わせた認証、または LDAP バインドを使用した認証の場合は、エンド ユーザにユーザ名とパスワードの入力が求められます。ユーザ名とパスワードに基づく認証の場合は、承認エンドポイントに対する GET リクエストの結果として承認サーバが Web フォームを返します。エンド ユーザがこのフォームにクレデンシャルを入力すると、承認サーバがそのクレデンシャルを、ローカル エンド ユーザ テーブルに照らし合わせて検証するか、LDAP バインドをして設定済み LDAP サーバに照らし合わせて検証します。
SSO が設定されていれば、承認サーバは SAML 2.0 Redirect/Post フローを開始します。この場合、Redirect/Post フローの終了時に SAML アサーションが承認サービスに送信されると、承認手順が完了します。
認証が成功した後、Cisco 承認サービスは、直ちに承認コード付与の発行を進めます。これは、エンド ユーザが、要求されたリソースを使用することをクライアント(たとえば Cisco Jabber)に承認したことを示します。
4. 承認コードをクライアントに付与するために、承認サーバはエンド ユーザのブラウザを、ステップ 1 と 2 で指定されたリダイレクト URI にリダイレクトします。リダイレクト URI には、承認コードと、ステップ 2 で識別された要求が組み込まれます。
5. ブラウザはこの URL にアクセスすることで、承認コードと指定された要求をクライアントに示します。クライアントは指定された要求を使用して、このイベントと、フローをトリガーした未処理のイベントを関連付けることができます。
6. クライアントは、前のステップで取得した承認コードを使用して、承認サービスにアクセス トークンを要求します。承認サービスに対するトークン要求は、クライアントのクレデンシャル(クライアント ID とシークレット)を使用して認証されます。また、ここでもクライアントはリダイレクション URI を渡します。
7. 承認サーバがクライアント認証を行って、リダイレクション URL をチェックします。有効であれば、応答としてアクセス トークンとリフレッシュ トークンを返します。
重要な点として、承認サーバはローカル認証、LDAP バインド、SSO を使用してエンド ユーザ認証を取得するため、リソース所有者の認証詳細(認証のタイプ、リソース所有者のクレデンシャルなど)がクライアントと共有されることは決してありません。クライアントが取得するのは承認コード付与のみです。
承認コード付与フローは、Cisco Unified CM リリース 11.5(1) SU3 で導入されました。承認コード付与フローでリフレッシュ トークンを使用するには、[リフレッシュを使用した Oauth ログイン フロー(OAuth with Refresh Login Flow)] エンタープライズ パラメータを使用する必要があります。このパラメータはデフォルトで [無効(disabled)] に設定されていますが、このフローを有効にすることをお勧めします。リフレッシュ トークンを使用した承認コード付与フローを有効にした場合でも、後方互換性のために暗黙の付与フローは常にサポートされます。
シスコ コラボレーション ソリューションで使用されるアクセス トークンのデフォルトの有効期間は、1 時間(3,600 秒)です。期限切れのアクセス トークンを使用すると、リソース サーバがサービスを拒否して、トークンが失効していることを示すエラーを返します。この場合、クライアントは新しいアクセス トークンを取得する必要があります。このような強制的なアクセス トークン更新を回避するため、シスコ コラボレーション クライアントは、トークン有効期間の 75% が経過するとトークン更新を開始するようになっています。アクセス トークンの有効期限が切れても、XMPP や SIP などのプロトコルを使用した既存のセッションに影響はありません。このようなセッションでは、セッションを確立する際(たとえば、SIP 登録の際)にだけ、アクセス トークンに基づく認証が行われるためです。
モバイルおよびリモート アクセス(MRA)を使用してコラボレーション エッジ経由で接続された企業外部のクライアントに OAuth でアクセスを承認するには、図 16-22 に示すように Cisco Expressway-E および Expressway-C 導入します。
図 16-22 コラボレーション エッジを使用した OAuth
コラボレーション エッジを介したエンドポイントとコラボレーション クライアントの登録では、(Expressway-E によってプロキシされる)Expressway-C の承認 API を使用することにより、OAuth を使用してアクセス トークンを取得できます。クライアントがこの承認エンドポイントを呼び出す際は、client_id、要求固有の状態 ID、ユーザ ID と併せて承認コード付与フローを使用するように指定する必要があります。ユーザを識別するには、ユーザ名、電子メール アドレス、またはユーザ ID を使用できます。Expressway-C 上の承認 API は、ユーザの認証方式に応じて、ブラウザを IdP にリダイレクトして SAML Redirect/Post 認証フローを開始するか、ローカル認証ページを表示します。ユーザの認証方式は、Expressway-C 上の MRA アクセス制御設定およびユーザのホーム クラスタ設定によって決まります。
図 16-23 に、ユーザ名とパスワードに基づく認証で Cisco Expressway を使用してアクセス トークンを取得する場合に使用されるフローを示します。
図 16-23 ローカル認証での Expressway を使用した OAuth 承認
図 16-23 に示されているフローのステップは、以下のとおりです。
1. Jabber クライアントが Expressway 上の承認 API にアクセスするために Web ブラウザをリダイレクトします。要求には、その要求を一意に識別する状態情報、client_id、ユーザ ID が格納されます。
2. ユーザ ID に基づいて、Expressway はユーザ名とパスワードによる認証が必要であることを判別し、ユーザ クレデンシャルを入力するための Web フォームを表示する Web ページを返します。この Web フォームの非表示の入力フィールドを介して、ステップ 1 で取得したすべてのパラメータが渡されます。
3. ユーザ クレデンシャルが入力された後、Web フォームが Expressway に送り返されます。
4. Expressway が Unified CM 上の承認サービスに設定されている /authorize_proxy エンドポイントを使用して、承認コードを取得します。これは、SAML べアラー アサーション付与フローのバリエーションです。この要求は、アプリケーション ユーザのユーザ名とパスワードを使用して認証されます。参照元アプリケーション ユーザは、Unified CM 上の承認サービスの AXL API にアクセスする権限が必要です。/authorize_proxy 要求には、先ほどキャッシュされたすべての承認パラメータが含まれています。
5. 承認サービスがクレデンシャルを検証します。それには、クレデンシャルをローカル エンド ユーザ テーブルに照合するという方法、または LDAP バインドという方法が使用されます。検証後、承認サービスは承認コードを(コラボレーション)エッジに返します。
6. エッジはそのコードをキャッシュできますが、そのコードをクライアントに返す必要もあります。そのために、クライアントに 302 メッセージを返して、クライアント上のブラウザ インスタンスをエッジ上の OAuth コールバックにリダイレクトします。リダイレクトのターゲット URL には、承認コードに関する必要な情報が含まれています。
7. クライアント上のブラウザは、リダイレクションに従い、エッジ上の OAuth コールバック リソースにアクセスします。
8. 200 OK メッセージによって、エッジを使用した SSO フローが完了します。これで、クライアントは最終的な URL から承認コードを抽出できます。
その結果、承認パラメータが Expressway 上でキャッシュされ、Jabber クライアントが承認コードを所有することになります。
Jabber は、再び Expressway の承認 API にアクセスすることで、この承認コードをアクセス トークンと交換できます。この場合の Expressway は、上記のフローのステップ 4 と 5 と同じように、承認サービスの access_token エンドポイントへの要求をプロキシします。
このフローは、ユーザ名とパスワードに基づく認証フローと非常によく似ています。このフローの場合、Cisco Expressway は SAML 2.0 Redirect/Post フローを使用して認証を取得し、クライアント上のブラウザが一般にアクセス可能な ID プロバイダーにリダイレクトされます。これは一般に顧客の DMZ 内にある IdP プロキシであり、企業内に導入された IdP のプロキシとして機能します。基本的に、DMZ 内の IdP プロキシは、企業 IdP 用の汎用 HTTPS リバース プロキシです。一部の IdP のベンダーは、IdP プロキシとして DMZ 内に IdP インスタンスをインストールするオプションを提供します。Expressway-E および Expressway-C プロキシはコラボレーション アプリケーションのサービスへのコラボレーション クライアント要求のみをプロキシします。パブリック DNS が企業 IdP の DNS 名を DMZ 内の IdP プロキシのパブリック IP アドレスに解決したことを確認することで、SAML 認証フローは DMZ 内の IdP プロキシにリダイレクトされますが、OAuth トークンを実現する OAuth 交換は Expressway-C および Expressway-E をパススルーし、Expressway-E は実際のクライアントのプロキシとして OAuth トークンを要求します。これは、図 16-24 に示すように、OAuth SAML べアラー付与フローの一種です。
図 16-24 SSO 認証での Expressway を使用した OAuth 認証
1. OAuth トークンを取得するため、ブラウザは Edge 上の /authorize エンドポイントに HTTP GET リクエストを送信します。Edge 上の /authorize エンドポイントは、顧客ドメインを参照するプレフィックス エンコーディングを使用してアクセスされます。この説明でのエッジはコラボレーション エッジを実装する Expressway-C と Expressway-E のペアを指します。
2. Expressway が、ブラウザから IdP にリダイレクトする 302 応答を返すことによって、SP 起点の SAML 2.0 Redirect/POST 認証フローを開始します。さらに Edge は、後で実際の OAuth プロキシ要求で必要になるため、クライアント要求の承認パラメータをキャッシュします。
3. ブラウザと IdP は、ユーザを認証するために必要なメッセージを交換します。メッセージ交換は、IdP に設定されている認証方式によって異なります。
4. SAML 認証が成功すると、SAML 交換の最後の手順として、ブラウザはエッジ上のアサーションを使用するサービスに SAML アサーションを POST します。エッジは、この SAML アサーションを承認コードと交換する必要があります。
5. そのために、エッジは承認サービス上の /authorize_proxy エンドポイントを使用します。この要求は、アプリケーション ユーザのユーザ名とパスワードを使用して認証されます。参照元アプリケーション ユーザは、Unified CM 上の承認サービスの AXL API にアクセスする権限が必要です。/authorize_proxy 要求には、先ほどキャッシュされたすべての承認パラメータが含まれています。
6. このため、承認サービスは、認証されたエンド ユーザに必要な権限があるかどうかを確認できます。要求したサービスへのアクセスが認証されたユーザに承認されると、承認サービスは承認コードを発行し、その承認コードを 200 OK メッセージで返します。
7. エッジそのコードをキャッシュできますが、そのコードをクライアントに返す必要があります。そのために、クライアントに 302 メッセージを返して、クライアント上のブラウザ インスタンスをエッジ上の OAuth コールバックにリダイレクトします。リダイレクトのターゲット URL には、承認コードに関する必要な情報が含まれています。
8. クライアント上のブラウザは、リダイレクションに従い、エッジ上の OAuth コールバック リソースにアクセスします。
9. 200 OK メッセージによって、エッジを使用した SSO フローが完了します。これで、クライアントは最終的な URL から承認コードを抽出できます。
その結果、承認パラメータが Expressway 上でキャッシュされ、Jabber クライアントが承認コードを所有することになります。
Jabber は、再び Expressway の承認 API にアクセスすることで、この承認コードをアクセス トークンと交換できます。この場合の Expressway は、上記のフロー同じように、承認サービスの access_token エンドポイントへの要求をプロキシします。
アクセス トークンは、認証サービスによってクライアントに発行されます。アクセス トークンの内容は、クライアントには判読できないものとなっていますが、クライアントがアクセス トークンの意味を理解する必要はありません。クライアントはアクセス トークンを、任意の文字列値として扱うためです。アクセス トークンは、クライアントからサービスに送信される要求を承認するためだけに使用されます。
Cisco Unified CM 上の承認サービスによって発行されるアクセス トークンは、自己完結型トークンです。これらの自己完結型トークンは、承認サービスにアクセスすることなく Unified Communications サービスにより検証できます。これらのアクセス トークンは RFC 7519 で規定されている JSON Web トークンであり、承認されたユーザ、有効期限、承認されるスコープに関する情報が含まれています。アクセス トークンは承認サービスによって暗号化され、デジタル署名が付けられます。
Unified Communications サービスは許可サーバにアクセスせずに、自己完結型トークンに基づいて承認をチェックするため、アクセス トークンの有効期間中に事前に承認されたアクセスを一元的に失効させる手段はありません。露出を制限するために、通常は、自己完結型アクセス トークンの有効期間は短くなっています。Cisco Unified CM 上の承認サービスによって発行されるアクセス トークンの有効期間は、デフォルトで 60 分に設定されます。この値は、1 分から 1440 分(1 日)までの範囲で設定できます。
Jabber では通常、現在のアクセス トークンの有効期間が残り 25 % になると新しいアクセス トークンの取得を試みます。つまり、有効期間が 60 分のトークンは 45 分後に更新されるということです。
リフレッシュ トークンは、Cisco Unified CM 上の承認サービスによってクライアントに発行されます。リフレッシュ トークンの有効期間内であれば、クライアントは Cisco Unified CM 上の承認サービスにリフレッシュ トークンを提示することで、アクセス トークンを取得できます。その際、エンド ユーザの認証は必要にならないため、新しいアクセス トークンを取得するためのトランザクションは、ユーザ エクスペリエンスに影響を与えることなく非常に短時間で実行できます。リフレッシュ トークンの場合も、クライアントはその内容を判読することはできません。新しいアクセス トークンを取得するための要求は、クライアント クレデンシャル(クライアント ID、クライアント シークレット、およびリダイレクト URI)を使用して認証されます。
Unified CM 上の承認サービスによって発行されるリフレッシュ トークンの有効期間は、デフォルトで 60 日に設定されます。この値は、1 日から 1825 日(5 年)までの範囲で設定できます。
(注) リフレッシュ トークンの有効期間を変更すると、承認サービスによって現在発行されているすべてのリフレッシュ トークンが無効になります。したがって、すべてのユーザが再認証を行って新しいリフレッシュ トークンを取得しなければならなくなります。
新しいリフレッシュ トークンを取得するには、改めて初めから最後まで承認フローに従わなければなりません。これには、エンド ユーザの認証が必要になります。Jabber クライアントはリフレッシュ トークンの有効期限が近づくとエンド ユーザに通知するため、エンド ユーザは新たに承認フローを開始することができます。
管理者は、特定のユーザのすべてのリフレッシュ トークンを失効させることができます。それには、Unified CM 上の https:// <unifed_cm> :8443/ssosp/token/revoke?user_id= <uid> エンドポイントを使用します。ここで、 unified_cm は Unified CM パブリッシャの IP アドレスまたはホスト名で置き換え、 uid はリフレッシュ トークンを失効させる対象のユーザのユーザ ID で置き換えます。この要求の認証には、管理者ユーザのクレデンシャルを使用する必要があります。
自己完結型アクセス トークンは、Cisco Unified CM 上の承認サービスによって暗号化され、デジタル署名されます。必要なキーは、Unified CM パブリッシャ ノードで作成されて、クラスタのすべてのノードに配布されます。Unified CM IM and Presence はクラスタ内のレプリケーションによってキーを取得しますが、Cisco Expressway と Unity Connection は Unified CM からキーをプルして、アクセス トークンの検証を有効にする必要があります。これらのキーにアクセスするには、Unified CM 上のトークン キー API を使用します。この API にアクセスするには、AXL アクセス権限を持つアプリケーション ユーザのクレデンシャルを使用した認証が必要です。Cisco Unity Connection では、Cisco Unity Connection 管理の [システム設定(System Setting)] タブにある [承認サーバ(Authz Server)] セクションで、承認サーバが定義されます。
管理者は、署名キーや暗号キーのセキュリティが侵害されていると判断した場合、キーを再生成することができます。これらのキーのいずれかを再生成すると、承認サービスによって発行されたすべてのアクセス トークンが無効になります。したがって、すべてのクライアントが新しいトークンを取得しなければならなくなり、それによってすべてのエンド ユーザの再認証が必要になります。
署名キーを再生成するには、 set key regen authz signing CLI コマンドを使用します。暗号キーを再生成するには、 set key regen authz encryption CLI コマンドを使用します。現在の署名キーと暗号キーに関する情報は、 show key authz signing と show key authz encryption CLI コマンドを使用して表示することができます。
アクセス トークンには、スコープ要素が含まれています。スコープは、アクセス トークンの所有者に使用を許可する Unified Communications サービスを定義するものです。どのユーザに対しても、発行するアクセス トークンのスコープを定義するには、Cisco Unified CM 上のユーザ プロファイル設定の [モバイルおよびリモート アクセス ポリシー(Mobile and Remote Access Policy)] にある [Jabber デスクトップ クライアント ポリシー(Jabber Desktop Client Policy)] と [Jabber モバイル クライアント ポリシー(Jabber Mobile Client Policy)] を設定します。この 2 つの設定を使用して、管理者は Jabber デスクトップ クライアントと Jabber モバイル クライアントにそれぞれ異なるスコープを定義することができます。使用可能な値は、[サービスなし(No Service)]、[IM&Presence のみ(IM&Presence only)]、[IM&Presence コール、音声コール、ビデオ コール(IM&Presence, Voice and Video calls)] です。
クライアントが接続を確立する際は常に Expressway によってスコープがチェックされます。Expressway はアクセスが承認されているサービスへの接続だけを確立します。