Cisco Collaboration システム 10.x ソリューション リファレンス ネットワーク デザイン(SRND)
ディレクトリ統合とアイデンティティ管理
ディレクトリ統合とアイデンティティ管理
発行日;2014/04/25 | 英語版ドキュメント(2013/11/23 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 27MB) | フィードバック

目次

ディレクトリ統合とアイデンティティ管理

この章の新規情報

ディレクトリ統合とは

Unified Communications エンドポイントのディレクトリ アクセス

UnifiedCM とのディレクトリ統合

Cisco Unified Communications Directory のアーキテクチャ

LDAP 同期

同期のメカニズム

セキュリティの考慮事項

LDAP 同期に関する設計上の考慮事項

Microsoft Active Directory に関する追加の考慮事項

UnifiedCM マルチフォレスト LDAP 同期

LDAP 認証

LDAP 認証に関する設計上の考慮事項

Microsoft Active Directory に関する追加の考慮事項

ディレクトリ同期および認証のユーザ フィルタリング

UnifiedCM データベース同期の最適化

同期を制御するための LDAP 構造の使用

LDAP クエリ

LDAP クエリフィルタ構文およびサーバサイドフィルタリング

高可用性

Unified CM データベース同期のキャパシティ プランニング

VCS 登録エンドポイントのディレクトリ統合

アイデンティティ管理アーキテクチャの概要

シングル サインオン(SSO)

SAML 認証

認証タイマー

認証メカニズム

SSO の設計上の検討事項

ディレクトリ統合とアイデンティティ管理

アイデンティティ管理は、どのアプリケーションにも必要な基本概念です。アイデンティティ管理では、個々のプリンシパルの管理とこれらのプリンシパルの認証および認可を行います。従来、各アプリケーションは、アイデンティティ管理を個々に扱っていました。このため、ユーザは個々のアプリケーションに対して認証を実施しなければいけませんでした。アイデンティティ管理、認証、認可を集中化し、シングル サインオン(SSO)などのサービスを提供することで、ユーザ エクスペリエンスを大幅に向上できます。

アイデンティティ管理の集中化の最初のステップは、企業のプリンシパルに関する情報の保存先を一元化することです。これらの一元化された企業全体のデータストアは、一般的にディレクトリとして知られています。

ディレクトリは、大量の読み込みや検索、および随時の書き込みや更新用に最適化された特殊なデータベースです。一般的にディレクトリは、社員情報やユーザ ポリシー、ユーザ特権、グループ メンバーシップなど、頻繁に変更されないデータを企業ネットワーク上に保存します。

ディレクトリに保存された情報の型は、変更および拡張することが可能です。「 ディレクトリ スキーマ 」という用語は、保存されている情報の型、そのコンテナ(または属性)、およびユーザやリソースとの関係を定義します。

Lightweight Directory Access Protocol(LDAP)は、ディレクトリに保存されている情報にアクセスし、変更するための標準方式をアプリケーションに提供します。この機能により、企業は、すべてのユーザ情報を、複数のアプリケーションで利用できる単一リポジトリに集中化させることができます。追加、移動、および変更が簡単なので、保守コストも大幅に削減されます。

この章では、Cisco Unified Communication Manager(Unified CM)に基づく Cisco Unified Communications システムを社内 LDAP ディレクトリと統合する場合の、設計上の主な原則について説明しています。この章の構成は、次のとおりです。

「ディレクトリ統合とは」

一般的な企業の IT 部門における社内 LDAP ディレクトリとの統合に関して、さまざまな要件を分析します。

「Unified Communications エンドポイントのディレクトリ アクセス」

Cisco Unified Communications エンドポイントのディレクトリ アクセスを有効にする技術的なソリューションについて説明し、その設計上のベスト プラクティスを示します。

「Unified CM とのディレクトリ統合」

LDAP 同期機能や LDAP 認証機能などを含む、Cisco Unified CM とのディレクトリ統合に関して、技術的なソリューションについて説明し、設計上の考慮事項を示します。

「VCS 登録エンドポイントのディレクトリ統合」

Cisco TelePresence Video Communication Server(VCS)に登録されたビデオ エンドポイントのディレクトリ アクセスを有効にする技術的なソリューションを簡単に紹介します。

「アイデンティティ管理アーキテクチャの概要」

アイデンティティ管理アーキテクチャについて説明します。

「シングル サインオン(SSO)」

SAML 2.0 シングル サインオン(SSO)の概要を示します。

この章で説明する考慮事項は、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 』の各ホワイト ペーパーを参照してください。

http://www.cisco.com

この章の新規情報

表 16-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 16-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

アイデンティティ管理

「アイデンティティ管理アーキテクチャの概要」

2013 年 11 月 19 日

シングル サインオン(SSO)

「シングル サインオン(SSO)」

2013 年 11 月 19 日

ディレクトリ統合とは

音声アプリケーションと社内 LDAP ディレクトリとの統合は、多くの企業の IT 部門にとって一般的な作業です。統合の正確な範囲は企業によって異なりますが、図 16-1 に示すように、1 つ以上の具体的かつ独立した要件として表すことができます。

図 16-1 ディレクトリ統合のさまざまな要件

 

一般的な要件の 1 つは、IP フォンまたはその他の音声エンドポイントやビデオ エンドポイントからユーザ検索(「個人別電話帳」サービスと呼ばれることもあります)を有効にすることで、ユーザがディレクトリで番号を検索した後に、連絡先に迅速にダイヤルできるようになります。

もう 1 つの要件は、社内ディレクトリからアプリケーションのユーザ データベースへの、ユーザのプロビジョニングを自動的に行うことです。この方法により、社内ディレクトリに変更が発生するたびにコア ユーザ情報を手動で追加、削除、修正する必要がなくなります。

社内ディレクトリのクレデンシャルを使用して、音声アプリケーションやビデオ アプリケーションのエンド ユーザと管理者を認証することもまた一般的な要件です。ディレクトリ認証を有効にすることで、IT 部門はシングル ログオン機能を提供することが可能になり、異なる社内アプリケーション毎にユーザが設定する必要のあるパスワードの数を減らすことができます。

表 16-2 に示すように、Cisco Unified Communications システムに関係する場合、 ディレクトリ アクセス という用語は、Cisco Unified Communications エンドポイントのユーザ ルックアップの要件を満たすメカニズムおよびソリューションを意味します。また、 ディレクトリ統合 という用語は、ユーザ プロビジョニングおよび(エンド ユーザと管理者の両方の)認証の要件を満たすメカニズムおよびソリューションを意味します。

表 16-2 ディレクトリの要件とシスコのソリューション

要件
シスコのソリューション
Cisco Unified CM の機能

エンドポイントのユーザ ルックアップ

ディレクトリ アクセス

Cisco Unified IP Phone Services SDK

ユーザ プロビジョニング

ディレクトリ統合

LDAP 同期

Unified Communications エンド ユーザの認証

ディレクトリ統合

LDAP 認証

Unified Communications アプリケーション管理者の認証

ディレクトリ統合

LDAP 認証

この章では、これ以降、Cisco Unified CM に基づく Cisco Unified Communications システムで、これらの要件にどのように対処するかについて説明します。


) 「ディレクトリ統合」という用語については、管理ポリシーおよびセキュリティ ポリシーを集中化するために、Microsoft Active Directory ドメインにアプリケーション サーバを追加する機能といった解釈もあります。Cisco Unified CM は、カスタマイズした組み込みオペレーティング システムで動作するアプライアンスであり、Microsoft Active Directory ドメインに追加できません。Cisco Unified CM のサーバ管理は、Cisco Real-Time Monitoring Tool(RTMT)によって行われます。アプリケーションに合わせた強力なセキュリティ ポリシーが組み込みオペレーティング システム内にすでに実装されています。


Unified Communications エンドポイントのディレクトリ アクセス

この項では、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)サーバによって提供されます。次の Web サイトの Cisco Developer Community から最新の Cisco Unified IP Phone Services SDK をダウンロードできます。

http://developer.cisco.com/web/ipps/home

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])を設定します。

ステップ 3 変更を有効にするために電話機をリセットします。


 


) 一部のユーザだけにサービスを提供する場合は、[Enterprise Parameters] ページではなく、[Phone Configuration] ページ内で URL Directories パラメータを直接設定します。


結論としましては、Cisco Unified IP Phone Services SDK を使用したディレクトリ アクセスには、次の設計上の考慮事項が適用されます。

ユーザ検索は、LDAP 準拠の社内ディレクトリに対してサポートされます。

Microsoft Active Directory に照会する場合、スクリプトがグローバル カタログ サーバを指し、スクリプトの設定でポート 3268 を指定することにより、グローバル カタログに対して検索を実施できます。一般的には、この方法によって検索が高速になります。グローバル カタログには全てのユーザ属性が含まれているわけではないことに注意してください。詳細については、Microsoft Active Directory のマニュアルを参照してください。

この機能が有効であっても Unified CM に影響はなく、LDAP ディレクトリ サーバにも最小限の影響しか与えません。

SDK に付属のサンプル スクリプトでは、最小限のカスタマイズだけが可能です(たとえば、全ての返り値の番号に対して、その前に番号を付加します)。より高度な操作を行うには、カスタム スクリプトを作成する必要があり、スクリプトの作成に役立つプログラミング ガイドが SDK に付属しています。

この機能には、社内ディレクトリに対する Unified CM ユーザのプロビジョニングまたは認証は必要ありません。

Unified CM とのディレクトリ統合

この項では、社内 LDAP ディレクトリを利用したユーザ プロビジョニングと認証を行うための、Cisco Unified CM でのディレクトリ統合のメカニズムおよびベスト プラクティスについて説明します。扱う項目は次の通りです。

「Cisco Unified Communications Directory のアーキテクチャ」

Unified CM におけるユーザ関連アーキテクチャの概要を示します。

「LDAP 同期」

LDAP 同期の機能および配置に関する設計上のガイドラインを説明し、Microsoft Active Directory に関する追加の考慮事項を示します。

「LDAP 認証」

LDAP 認証の機能および配置に関する設計上のガイドラインを説明し、Microsoft Active Directory に関する追加の考慮事項を示します。

サポートされる LDAP ディレクトリの一覧については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager System Guide 』の最新版を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

Cisco Unified Communications Directory のアーキテクチャ

図 16-3 は、Unified CM クラスタの基本アーキテクチャを示しています。組み込みデータベースには、デバイス関連データ、コール ルーティング、機能のプロビジョニング、ユーザ プロファイルを含む、すべての設定情報が保存されます。データベースは CM クラスタ内のすべてのサーバ上に存在し、パブリッシャ サーバからすべてのサブスクライバ サーバに対して自動的に複製が行われます。

図 16-3 Cisco Unified CM のアーキテクチャ

 

デフォルトでは、すべてのユーザのプロビジョニングは、パブリッシャ データベースに、Unified CM Administration web インターフェースを通じて手動で行います。Cisco Unified CM には、次の 2 つのユーザ タイプがあります。

エンド ユーザ:実在の人間および対話形式のログインに関連付けられているすべてのユーザ。このカテゴリには、すべての Unified Communications ユーザのほか、ユーザ グループと役割設定(以前のバージョンの Unified CM にある Cisco Multilevel Administration 機能に相当)を使用する場合の Unified CM 管理者も含まれます。

アプリケーション ユーザ:Cisco Unified Communications の他の機能またはアプリケーション(Cisco Attendant Console、Cisco Unified Contact Center Express、Cisco Unified Communication Manager Assistant など)に関連付けられているすべてのユーザ。これらのアプリケーションは Unified CM に対して認証を行う必要がありますが、この内部「ユーザ」は対話形式のログインを行わず、単にアプリケーション間の内部通信だけを処理します。

表 16-3 では、Unified CM データベースにデフォルトで作成されるアプリケーション ユーザのリストを、それらのユーザが使用される機能またはアプリケーションと共に示しています。Cisco Unified Communications の他のアプリケーションを統合する場合に、追加のアプリケーション ユーザを手動で作成できます(たとえば、Cisco Attendant Console の ac アプリケーション ユーザ、Cisco Unified Contact Center Express の jtapi アプリケーション ユーザなど)。

表 16-3 Unified CM のデフォルトのアプリケーション ユーザ

アプリケーション ユーザ
使用される機能またはアプリケーション

CCMAdministrator

Unified CM Administration(デフォルトは「スーパー ユーザ」)

CCMQRTSecureSysUser

Cisco Quality Reporting Tool

CCMQRTSysUser

CCMSysUser

Cisco Extension Mobility

IPMASecureSysUser

Cisco Unified Communications Manager Assistant

IPMASysUser

WDSecureSysUser

Cisco WebDialer

WDSysUser

これらの考慮事項に基づいて、図 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 つの独立したプロセスによって実現されます。

LDAP 同期

Unified CM の Cisco Directory Synchronization(DirSync)という内部ツールを使用して、社内 LDAP ディレクトリから多数のユーザ属性を(手動または定期的に)同期します。この機能が有効である場合、Unified CM 管理 GUI を介したローカル ユーザのプロビジョニングに加えて、社内ディレクトリからは自動的にプロビジョニングされます。この機能はエンド ユーザだけに適用され、アプリケーション ユーザは独立したまま、引き続き Unified CM Administration インターフェイスを介してプロビジョニングされます。要約すると、エンド ユーザは社内ディレクトリで定義され Unified CM データベースに同期されますが、アプリケーション ユーザは Cisco Unified CM データベースのみに保存されますので、社内ディレクトリで定義する必要はありません。

LDAP 認証

LDAP の標準的な Simple_Bind 操作を使用して、IMS ライブラリが社内 LDAP ディレクトリに対して LDAP 同期したエンド ユーザのユーザ クレデンシャルを認証できるようにします。この機能が有効になっている場合、LDAP 同期されたエンド ユーザは社内ディレクトリに対して認証される一方、アプリケーションのユーザのパスワードとローカル エンド ユーザのパスワードは引き続き Unified CM データベースに対してローカルで認証されます。Cisco エクステンション モビリティの PIN も引き続きローカルで認証されます。

Unified CM データベース内部でアプリケーション ユーザの保持および認証を行うことで、これらのアカウントを使用して Unified CM と通信するすべてのアプリケーションと機能が回復力を持ちます。この場合は、社内LDAPディレクトリの可用性の影響はありません。

Cisco エクステンション モビリティの PIN も Unified CM データベース内で保持されます。これらの PIN はリアルタイム アプリケーションの必須部分です。リアルタイム アプリケーションは社内ディレクトリの応答性に依存しないようにする必要があります。

次の 2 つの項では、LDAP 同期と LDAP 認証についてさらに詳しく説明し、両方の機能に関して設計上のベスト プラクティスを示します。


「Unified Communications エンドポイントのディレクトリ アクセス」の項で説明したように、外部 Web サーバで Cisco Unified IP Phone Services SDK を設定することにより、エンドポイントからのユーザ検索を社内ディレクトリに対して実行することもできます。


LDAP 同期

Unified CM を社内 LDAP ディレクトリに同期すると、管理者は Unified CM データ フィールドをディレクトリ属性にマッピングすることにより、ユーザを容易にプロビジョニングできるようになります。LDAP ストアに保持されている重要なユーザ データは、スケジュール予約またはオンデマンドによって Unified CM データベース内の対応する適切なフィールドにコピーされます。社内 LDAP ディレクトリの状態は、中央リポジトリのままです。Unified CM は、ユーザ データを保存するための統合データベースを備え、またユーザ アカウントおよびデータを作成して管理するための Web インターフェイスを、Unified CM Administration 内に備えています。LDAP 同期を有効にしても、ローカル データベースは引き続き使用され、追加のローカル エンド ユーザ アカウントを作成できます。エンド ユーザ アカウントの管理は、LDAP ディレクトリおよび Unified CM Administration 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 で見つかった場合、ローカルで設定済みのデータはディレクトリのデータに置き換えられます。

図 16-5 ユーザ データ同期の有効化

 

LDAP 同期を有効にすると、クラスタ全体に対して一度に一種類のみの LDAP ディレクトリを選択できます。また、LDAP ディレクトリ ユーザの 1 つの属性を [Unified CM User ID] フィールドにマッピングするために選択します。Unified CM はデータへのアクセスに標準 LDAPv3 を使用します。

Cisco Unified CM は、標準属性からデータをインポートします。ディレクトリ スキーマの拡張は必要ありません。 表 16-4 に、Unified CM の各フィールドへのマッピングに使用できる属性を示します。[Unified CM User ID] フィールドにマッピングされるディレクトリ属性のデータは、そのクラスタのすべてのエントリ内で一意のものである必要があります。[Cisco UserID] フィールドにマッピングされる属性はディレクトリに格納される必要があり、 sn 属性はデータと一緒に格納される必要があります。そうしないと、このインポート処理時にこれらのレコードはスキップされます。エンドユーザ アカウントのインポート中に使用するプライマリ属性が Unified CM データベースのいずれかのアプリケーション ユーザと一致する場合、そのユーザは LDAP ディレクトリからインポートされません。

表 16-4 では、対応する Unified CM ユーザ フィールドに LDAP ディレクトリからインポートされた属性の一覧と、フィールド間のマッピングについて説明しています。Unified CM ユーザ フィールドの中には、複数の LDAP 属性の中の 1 つからマッピングされるものもあります。

 

表 16-4 同期された LDAP 属性と対応する Unified CM フィールド名

Unified CM のユーザ フィールド
Microsoft Active Directory
Active Directory アプリケーション モード(ADAM)
または Active Directory ライトウェイト ディレクトリ サービス(AD LDS)
Sun ONE
OpenLDAP

ユーザ ID(User ID)

次のいずれかになります。

sAMAccountName
mail
employeeNumber
telephoneNumber
userPrincipalName

次のいずれかになります。

uid
mail
employeeNumber
telephoneNumber
userPrincipalName

次のいずれかになります。

uid
mail
employeeNumber
telephonePhone

次のいずれかになります。

uid
mail
employeeNumber
telephonePhone

名(First Name)

givenName

givenName

givenname

givenname

ミドル ネーム(Middle Name)

次のいずれかになります。

middleName
initials

次のいずれかになります。

middleName
initials

initials

initials

姓(Last Name)

sn

sn

sn

sn

マネージャ ID(Manager ID)

manager

manager

manager

manager

部署名(Department)

department

department

departmentnumber

departmentnumber

電話番号(Phone Number)

次のいずれかになります。

telephoneNumber
ipPhone

次のいずれかになります。

telephoneNumber
ipPhone

telephonenumber

telephonenumber

メール ID(Mail ID)

次のいずれかになります。

mail
sAMAccountName

次のいずれかになります。

mail
uid

次のいずれかになります。

mail
uid

次のいずれかになります。

mail
uid

表 16-5 に、DirSync プロセスによってインポートされ、Unified CM データベースにコピーされるものの、管理者ユーザの設定 Web ページには表示されない追加属性のリストを示します。 Microsoft OCS を使用する場合、属性 msRTCSIP-PrimaryUserAddress は AD に格納されます。この表は、完全な情報を提供する目的で記載されています。

 

表 16-5 表示されない同期 LDAP 属性

Unified CM のユーザ フィールド
Microsoft Active Directory
Sun ONE
OpenLDAP

objectGUID

objectGUID

N/A

N/A

OCSPrimaryUserAddress

msRTCSIP-PrimaryUserAddress

N/A

N/A

Title

title

Title

title

Home Phone Number

homePhone

Homephone

hometelephonenumber

Mobile Phone Number

mobile

Mobile

Mobiletelephonenumber

Pager Number

pager

Pager

pagertelephonenumber

Serviceability 管理画面で有効にする Cisco DirSync というプロセスによって同期が実行されます。このプロセスを有効にすることで、システムに 1 ~ 30 件の同期合意を設定できます。合意では、検索ベースを指定します。これは LDAP ツリー内で Unified CM がインポートするユーザ アカウントの検索を開始する場所となります。Unified CM は特定の同期同意において、検索ベースで指定したドメインの領域に存在するユーザだけをインポートできます。

図 16-6 は、2 つの同期合意を示しています。一方の同期合意では、ユーザ検索ベース 1 を指定し、ユーザ jsmith、jdoe、jbloggs をインポートします。もう一方の同期合意では、ユーザ検索ベース 2 を指定し、ユーザ jjones、bfoo、tbrown をインポートします。CCMDirMgr アカウントは、ユーザ検索ベースで指定した場所の下に存在しないので、インポートされません。ユーザを LDAP ディレクトリの構造に整理することで、どのユーザ グループをインポートするかを制御できます。この例では、単一の同期合意を使用してドメインのルートを指定することもできましたが、その検索ベースでは Service Accts もインポートしていたことになります。検索ベースではドメイン ルートを指定する必要はなく、ツリーのどの場所でも指定できます。

図 16-6 ユーザ検索ベース

 

データを 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 アカウントは再び有効とマークされます。LDAP からのアカウントが LDAP 同期アカウントとしてマークされていない既存の Unified CM アカウントと一致する場合、それらのアカウントは無視されます。

2. 同期の完了後、利用中に設定されなかった LDAP 同期アカウントは、ガーベッジ コレクション プロセスの実行時に Unified CM から恒久的に削除されます。ガーベッジ コレクションは、午前 3 時 15 分の定時に自動的に実行されるプロセスで、変更はできません。

3. 後に社内ディレクトリに変更が発生すると、次回の同期の際に、Microsoft Active Directory から完全な再同期が行われます。これに対して、Sun ONE のディレクトリ製品は、ディレクトリに変更が加えられると差分同期を実行します。次の項では、2 つのシナリオのそれぞれの例を示します。


) ユーザを LDAP から Unified CM データベースに同期した後で同期設定を削除すると、その設定によってインポートされたユーザには、データベース内で休止中のマークが付きます。その後、これらのユーザはガーベッジ コレクションによって削除されます。


Active Directory とのアカウント同期

図 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 とのアカウント同期

Sun ONE 製品は差分同期合意をサポートし、Microsoft Active Directory とは異なる同期スケジュールを使用します。同期には、Internet Engineering Task Force(IETF)ドラフトで定義され、多くの LDAP 実装でサポートされている永続検索メカニズムが使用されます。図 16-8 では、LDAP 同期と LDAP 認証の両方を有効にした Unified CM 配置について、この同期スケジュールの例を示しています。

図 16-8 Sun ONE での変更の伝播

 

図 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 データベースに、パスワードも 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 内で SSL 証明書をアップロードすることにより、Secure LDAP を有効にできます。詳細な手順については、 http://www.cisco.com で入手可能な Unified CM の製品マニュアルを参照してください。SLDAP を有効にする方法については、LDAP ディレクトリ ベンダーのドキュメンテーションを参照してください。

LDAP 同期に関する設計上の考慮事項

Cisco Unified CM で LDAP 同期を利用する場合は、設計と実装に関する次のベスト プラクティスに従ってください。

社内ディレクトリ内における特定のアカウントを使用することで、Unified CM 同期合意がそのディレクトリに対して接続および認証できるようにします。Unified CM に専用アカウントを準備する事を推奨します。このアカウントには、目的の検索ベース内の全ユーザ オブジェクトに対する「読み取り」が可能な最低限の権限を付与してください。またパスワードは無期限に設定してください。このアカウントのディレクトリ内のパスワードは、Unified CM 内のパスワード設定と同期継続する必要があります。サービス アカウントのパスワードがディレクトリ内で変更された場合は、必ず Unified CM でアカウント設定を更新してください。

所定のクラスタにあるすべての同期合意は、同じ LDAP サーバのファミリと統合する必要があります。

複数の合意が同じ LDAP サーバに同時に照会することがないように、同期合意の予約に時間差を設けてください。同期がオフピーク時間に実行されるように時刻を設定してください。

ユーザ データのセキュリティが必要である場合、Unified CM Administration の [LDAP Directory] 設定ページで [Use SSL] フィールドのチェックボックスをオンにして、Secure LDAP(SLDAP)を有効にしてください。

[Unified CM UserID] フィールドへのマッピングのために選択した LDAP ディレクトリ属性が、そのクラスタのすべての同期合意内で一意であることを確認してください。

UserID として選択した属性は、Unified CM で定義したいずれのアプリケーション ユーザとも同一にならないようにしてください。

LDAP 属性 sn(姓)は、ユーザの LDAP 同期に必須です。

同期前に Unified CM データベースに存在したアカウントは、LDAP ディレクトリからインポートされたアカウントに一致する属性があった場合だけ保持されます。Unified CM UserID に一致する属性は、同期合意によって確認されます。

エンド ユーザ アカウントは LDAP ディレクトリの管理ツールによって管理し、これらのアカウントのシスコ固有データは Unified CM Administration ページによって管理してください。

LDAP 同期は、Microsoft NT LAN Manager(NTLM)でのみサポートされます。Kerberos と NTLMv2 はサポートされていません。

AD の配置については、ObjectGUID がユーザのキー属性として Unified CM で内部的に使用されます。Unified CM User ID に対応する AD 内の属性は、AD 内で変更できます。たとえば sAMAccountname を使用している場合、ユーザは AD 上の自分の sAMAccountname を変更することができ、Unified CM 内の対応するユーザ レコードが更新されます。

その他すべての LDAP プラットフォームでは、User ID にマッピングされる属性が Unified CM におけるそのアカウントのキー属性となります。LDAP 内の属性を変更すると、Unified CM に新しいユーザが作成され、元のユーザには休止中とマークされます。

Microsoft Active Directory に関する追加の考慮事項

あるドメインに対する同期合意では、そのドメイン外のユーザや子ドメイン内のユーザは同期されません。同期プロセス中は Unified CM が AD 紹介に従わないためです。図 16-9 の例では、すべてのユーザをインポートするために 3 つの同期合意が必要です。検索ベース 1 ではツリーのルートを指定しますが、いずれかの子ドメインに存在するユーザはインポートしません。範囲は VSE.LAB に限定されており、残りの 2 つのドメインに対し、そのユーザをインポートするように別々のアグリーメントが設定されています。

図 16-9 複数の Active Directory ドメインでの同期

 

図 16-9 では、ドメインとサブドメインのそれぞれに少なくとも 1 つのドメイン コントローラ(DC)が関連付けられ、3 つの同期合意はそれぞれ適切なドメイン コントローラを指定します。DC にある情報は、その DC が存在するドメイン内のユーザの情報だけなので、すべてのユーザをインポートするために 3 つの同期合意が必要です。

図 16-10 に示すように、複数のツリーを含む AD フォレストで同期を有効にした場合も、上記と同じ理由で複数の同期合意が必要です。さらに、UserPrincipalName(UPN)属性がフォレスト全体で一意であることが Active Directory によって保証され、Unified CM UserID にマッピングする属性として選択される必要があります。マルチツリーの AD シナリオで UPN 属性を使用する場合の追加の考慮事項については、「Microsoft Active Directory に関する追加の考慮事項」の項を参照してください。

図 16-10 複数の AD ツリー(不連続なネームスペース)での同期

 

アカウントの同期を実行すると、Unified CM から AD にデフォルト LDAP 検索フィルタ文字列が送信されます。その中に、AD で無効のマークが付いているアカウントは返さないという条項があります。ログインの失敗回数を超えた場合など、AD によって無効のマークが付けられたアカウントには、そのアカウントが無効である間に同期が実行された場合に休止中のマークが付けられます。

Unified CM マルチフォレスト LDAP 同期

マルチフォレスト LDAP インフラストラクチャを使用した Unified CM 配置は、複数のばらばらなフォレストを統合して単一のフォレストとして見ることのできる Active Directory Lightweight Directory Services(AD LDS)を使用することでサポートされます。この統合では、LDAP フィルタリングを使用する必要があります(「ディレクトリ同期および認証のユーザ フィルタリング」を参照) 詳細については、次の URL で入手可能な『 How to Configure Unified Communication Manager Directory Integration in a Multi-Forest Environment 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a0080b2b103.shtml

LDAP 認証

LDAP 認証機能により、Unified CM が社内 LDAP ディレクトリに対して LDAP 同期ユーザを認証できるようになります。アプリケーション ユーザとローカルで設定されたユーザは、常にローカル データベースに対して認証されます。またすべてのエンド ユーザの PIN は、常にローカル データベースに対してのみ照合されます。図 16-11 に示すように、Unified CM 内の Identity Management System(IMS)モジュールと社内ディレクトリ サーバ間で確立した LDAPv3 接続によって、この認証が実現されます。

図 16-11 LDAP 認証の有効化

 

認証を有効にするために、クラスタ全体に単一の認証合意を定義できます。認証合意は、冗長化のために LDAP サーバを 3 つまで設定でき、必要に応じて Secure LDAP(SLDAP)もサポートします。LDAP 同期が正しく設定かつ使用されている場合にのみ、認証を有効にできます。

認証を有効にした場合の Unified CM の動作説明を、次に示します。

LDAP からインポートされたユーザのエンド ユーザ パスワードは、シンプル バインド操作によって社内ディレクトリに対して認証が行われます。

ローカルのエンド ユーザ パスワードは、Unified CM データベースに対して認証されます。

アプリケーション ユーザ パスワードは、Unified CM データベースに対して認証されます。

エンド ユーザ PIN は、Unified CM データベースに対して認証されます。

この動作は、エンドユーザにシングル ログイン機能を提供するための指針に沿ったものです。リアルタイム UC システムの稼動が、社内ディレクトリの可用性の影響を受けないようにしています。図 16-12 に図示します。

図 16-12 エンド ユーザ パスワード、アプリケーション ユーザ パスワード、エンド ユーザ PIN の認証

 

図 16-13 は、LDAP 同期されたエンド ユーザを社内 LDAP ディレクトリを使って認証するために Unified CM で採用された一連のプロセスを示しています。

1. ユーザは、HTTPS 経由で Unified CM ユーザ オプション ページに接続し、ユーザ名とパスワードで認証を行います。この例では、ユーザ名は jsmith です。

2. ユーザがローカル ユーザの場合、パスワードはローカル データベースに対して照会されます。

以降の手順は、LDAP 同期ユーザにのみ適用されます。

3. ユーザが LDAP 同期ユーザの場合、Unified CM はユーザ名 jsmith に関する LDAP クエリを発行し、LDAP 認証設定ページの LDAP 検索ベースで指定された値を、このクエリの範囲として使用します。SLDAP を有効にした場合、このクエリは SSL 接続を通じて行われます。

4. 社内ディレクトリ サーバは LDAP にて、ユーザ jsmith の完全識別名(DN)で応答します(たとえば、"cn=jsmith, ou=Users, dc=vse, dc=lab")。

5. 次に Unified CM は、LDAP バインド操作を使用して、ユーザに提供された完全な DN とパスワードを渡すことにより、ユーザのクレデンシャルの検証を試みます。

6. LDAP バインドが成功した場合、Unified CM は、要求された設定ページへのユーザ接続を許可します。

図 16-13 認証プロセス

 

LDAP 認証に関する設計上の考慮事項

Cisco Unified CM で LDAP 認証を配置する場合は、設計と実装に関する次のベスト プラクティスに従ってください。

社内ディレクトリ内に特定のアカウントを作成し、Unified CM がそのディレクトリに対して接続および認証できるようにします。Unified CM に専用アカウントを準備する事を推奨します。このアカウントには、目的の検索ベース内の全ユーザ オブジェクトに対する「読み取り」が可能な最低限の権限を付与してください。またパスワードは無期限に設定してください。このアカウントのディレクトリ内のパスワードは、Unified CM 内のアカウントのパスワード設定と同期を継続する必要があります。アカウントのパスワードがディレクトリ内で変更された場合は、必ず Unified CM でアカウント設定を更新してください。LDAP 同期も有効にする場合、両方の機能に同じアカウントを使用できます。

LDAP Manager Distinguished Name および LDAP Password で前述のアカウントのクレデンシャルを指定し、LDAP ユーザ検索ベースですべてのユーザが存在するディレクトリ サブツリーを指定することにより、Unified CM で LDAP 認証を有効にします。

この方法は、LDAP 同期したすべてのエンド ユーザにシングル ログイン機能を提供します。Unified CM ユーザ オプション ページにログインするために、社内ディレクトリ クレデンシャルを使用できます。

社内ディレクトリ インターフェイスで LDAP 同期ユーザのエンドユーザ パスワードを管理してください。認証を有効にすると、Unified CM Administration のページの LDAP 同期ユーザにパスワード フィールドが表示されなくなります。

Unified CM 管理のページまたは Unified CM ユーザ オプション ページでエンド ユーザ PIN を管理してください。

Unified CM 管理のページでアプリケーション ユーザのパスワードを管理してください。アプリケーション ユーザは他の Cisco Unified Communications アプリケーションとの通信やリモート呼制御を司り、実際のユーザには関連付けられないことに留意してください。

対応するエンド ユーザを Unified CM 管理のページから Unified CM Super Users ユーザ グループに追加することにより、Unified CM 管理者のシングル ログインを有効にしてください。カスタマイズしたユーザ グループおよびロールを作成することにより、マルチレベルの管理者権限を定義できます。

Microsoft Active Directory に関する追加の考慮事項

地理的に離れた複数のドメイン コントローラによる分散型 AD トポロジを採用している環境では、認証が遅くなり過ぎる恐れがあります。認証合意用のドメイン コントローラにユーザ アカウントが保持されていない場合、他のドメイン コントローラでそのユーザの検索が必ず実行されます。この構成を適用するときに、ログインが遅過ぎる場合、グローバル カタログ サーバを使用するように認証方法を設定できます。

ここで大きな制限があります。グローバル カタログは employeeNumber 属性をデフォルトで伝達しません。この場合は、認証用のドメイン コントローラを使用するか(上記制限に注意)、employeeNumber 属性を含めるようにグローバル カタログを更新してください。詳細については、Microsoft Active Directory のマニュアルを参照してください。

グローバル カタログに対するクエリを有効にするには、グローバル カタログ ロールが有効になっているドメイン コントローラの IP アドレスまたはホスト名を指すように [LDAP Authentication] ページの [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-14 に示すように、各ユーザの UPN サフィックスをユーザ検索ベースとします。この例では、Microsoft Active Directory フォレストは avvid.info と vse.lab という 2 つのツリーで構成されます。同じユーザ名が両方のツリーに存在する場合があるため、同期プロセス中および認証プロセス中は UPN を使用してデータベースのユーザを一意に識別するように、Unified CM が設定されています。

図 16-14 複数のツリーがある Microsoft AD フォレストでの認証

 

図 16-14 に示すように、John Doe という名前のユーザが avvid.info ツリーと vse.lab ツリーの両方に存在します。次の手順は、UPN が jdoe@avvid.info のユーザに対する認証プロセスを示しています。

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-13 に示す標準的な場合と同様に、認証プロセスが続行されます。


) 複数のツリーを含む Microsoft AD フォレストでの LDAP 認証のサポートは、上記の方法で行われます。そのため、ユーザの UPN サフィックスが、そのユーザが存在するツリーのルート ドメインに対応する配置のみがサポートされます。AD では、異なる UPN サフィックスが許可されたエイリアスを使用できます。UPN サフィックスがツリーの実際のネームスペースから分離されている場合は、Microsoft Active Directory フォレスト全体で Unified CM ユーザを認証できなくなります(ただし、その場合でも、別の属性をユーザ ID として使用し、統合をフォレスト内の単一のツリーに限定することはできます)。


ディレクトリ同期および認証のユーザ フィルタリング

Unified CM は、ディレクトリ同期のパフォーマンスを最適化するために、LDAP クエリフィルタを提供します。各クラスタの Unified Communications リソースに割り当てられるディレクトリ ユーザ アカウントだけをインポートすることを推奨します。ディレクトリ ユーザ アカウントの数が、各クラスタに対してサポートされている数を超える場合は、フィルタリングを使用して、そのクラスタに関連付けられるユーザの一部分を選択する必要があります。Unified CM 同期機能は、大規模な社内ディレクトリに置き換わるものではありません。

多くの場合、同期対象のアカウントを制御するために必要となるのは、固有の検索ベースだけです。固有の検索ベースを使用できない場合は、カスタム LDAP フィルタが必要となることがあります。以降の項では、ディレクトリ同期の最適化に使用できる両方の方法について説明します。いずれかのメカニズムを使用して Unified CM へのアカウントのインポートを制限する場合、デフォルトのディレクトリ検索の設定では、Unified CM データベースに存在するディレクトリ エントリだけが表示されます。ディレクトリ全体にアクセスするディレクトリ検索の場合は、外部 Web サーバを使用するように Unified CM を設定する必要があります。 この設定の詳細については、ここでは説明しませんが、次の Web サイトで入手可能な Unified CM 製品マニュアルで説明しています。

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/tsd_products_support_series_home.html

Unified CM データベース同期の最適化

Unified CM データベース同期機能には、LDAP ディレクトリ ストアから Unified CM パブリッシャ データベースへユーザ設定データ(属性)の一部分をインポートするメカニズムがあります。ユーザ アカウントの同期が発生すると、各ユーザの LDAP アカウント情報が、そのユーザの特定の Unified Communications 機能を有効にするために必要な追加データと関連付けられることがあります。認証も有効にしている場合、パスワード検証のための LDAP ストアへのバインドに、ユーザのクレデンシャルを使用します。同期や認証が有効な場合にも、エンド ユーザのパスワードは Unified CM データベースには格納されません。

ユーザ アカウント情報はクラスタ固有です。各 Unified CM パブリッシャ サーバは、このクラスタから Unified Communications サービスを受けているユーザの一意のリストを保持しています。同期合意はクラスタ固有で、各パブリッシャにはユーザ アカウント情報の独自コピーがあります。Unified Communications リソースが割り当てられるユーザだけが Unified CM と同期します。LDAP ディレクトリに定義されているユーザのセット全体が Unified CM クラスタにインポートされない一般的な理由の一部を、次に示します。

Unified Communications リソースが割り当てられないユーザのインポートにより、ディレクトリ同期時間が長くなります。

Unified Communications リソースが割り当てられていないユーザのインポートにより、Unified CM 検索とデータベース全体のパフォーマンスが遅くなる可能性があります。

多くの場合、LDAP ディレクトリ ストアのユーザ アカウント数が、Unified CM データベースの合計ユーザ容量を大幅に超過します。

Unified CM には、システムに追加できるアカウント数の制限がありません。シスコは、ユーザの数をサポートされているエンドポイントの 2 倍に制限することを推奨します。アプリケーション用のアカウントが必要な場合や、設計によっては追加のアカウントが必要な場合があります。

シスコは、ここで説明している制御メカニズムを使用して、LDAP データベース サイズに関係なく、インポートされるユーザ アカウントを最小限に抑えることを推奨します。これによって、最初とそれ以降の定期的な同期の速度が改善され、ユーザ アカウントの管理可能性も向上します。

同期を制御するための LDAP 構造の使用

多くの LDAP ディレクトリの配置では、組織ユニット名(OU)を使用して、ユーザを論理的順序や、場合によっては階層的順序でグループ化しています。ユーザを複数の OU に編成する構造が LDAP ディレクトリにある場合、インポートされるユーザのグループを制御するためにこの構造を使用することもできます。各個別 Unified CM 同期合意は、単一の OU を指定します。サブ OU 内であっても、指定 OU の下にある全アクティブ アカウントがサポートされます。OU 内のユーザだけが同期されます。ユーザを含む複数の OU がクラスタで必要な場合、複数の同期合意が必要です。Unified Communications リソースを割り当てられていないユーザが OU に含まれている場合は、これらの OU をディレクトリ同期から省くことを推奨します。

AD に同じ手法を使用して、コンテナを定義できます。同期合意では、ディレクトリ ツリーの特定のコンテナを指定でき、それによってインポートの範囲を制限できます。

使用できる同期合意の数は限られているため、多数の OU やコンテナを持つ LDAP の配置では、この手法はすぐに使い果たされてしまいます。複数の OU がある環境でユーザを同期するには、同期サービス アカウントに割り当てる権限を制御するという方法があります。複数のユーザが存在するツリー ノードに同期合意を設定してから、システム アカウントの読み取りアクセスをサブツリーの選択部分に制限します。このアクセスを制限する方法については、LDAP ベンダーのドキュメンテーションを参照してください。

LDAP クエリ

次のいずれかの理由により、フィルタリングに対して追加の制御が必要となる場合があります。

LDAP ディレクトリがフラット構造となっており、同期合意の設定によって適切に制御できない。すべての同期合意によってインポートされるユーザの総数が、Unified CM クラスタでサポートされる最大ユーザ数を超える場合は、フィルタを介してインポートされるユーザの数を制御する必要があります。

管理目的でユーザをセグメント化するために、ユーザ アカウントの一部分を Unified CM クラスタにインポートし、クラスタへのアクセス権および認証を持つユーザのサブセットを制御する必要があります。クラスタにインポートされるいずれかのアカウントが、Web ページへのあるレベルのアクセス権および認証メカニズムを持ち、このことが適切でない場合があります。

LDAP ディレクトリ構造は、Unified CM クラスタに対してどのようにユーザがマッピングされるのかを正確に反映していません。たとえば、OU は組織階層に応じて設定されているものの、Unified CMではユーザが地理的にマッピングされている場合、これら 2 つの間で重複する部分はほとんどありません。

このような場合、LDAP クエリフィルタを使用して、同期合意に対して追加の制御を提供できます。

LDAP クエリフィルタ構文およびサーバサイドフィルタリング

Unified CM は、標準の LDAP メカニズムを使用して、LDAP ディレクトリ ストアのデータを同期します。Unified CM は、RFC 2251 の Lightweight Directory Access Protocol (v3) で規定されているように、検索メカニズムを使用して要求を送信し、LDAP サーバからデータを取得します。このメカニズムでは、検索メッセージ内のフィルタ文字列を指定する機能も定義されています。LDAP サーバはフィルタ文字列を使用して、データを返すデータベースのエントリを選択します。フィルタ文字列の構文は、RFC 2254 の The String Representation of LDAP Search Filters で規定されています。この RFC を参照用として使用することで、より複雑なフィルタ ストリングを作成できます。

フィルタ文字列は、Unified CM から LDAP サーバに送信される検索メッセージに組み込まれ、LDAP サーバはそれを実行して、応答で返すユーザ アカウントを選択します。

単純なフィルタ構文

標準の属性名と、それらの属性に必要な値を指定して、フィルタを設定できます。属性は、名前の代わりに DN 要素で指定することもできます。Unified CM によって LDAP クエリで使用されるフィルタ文字列は、ldapfilter テーブルの内部に格納され、検索メッセージに挿入されます。

フィルタは、次の構文を持つ UTF-8 形式の文字列です。

( attribute operator value )

または

( operator ( filter1 )( filter2 ))

ここで、 filter1 および filter2 には最初の行で示した構文が含まれ、 operator 表 16-6 に示す演算子のいずれかとなります。 attribute はディレクトリ内に存在する LDAP 属性に対応し、 operator 表 16-6 に示す演算子のいずれかとなり、 value は、その属性に必要な実際のデータ値に対応します。

 

表 16-6 フィルタ文字列の基本的な演算子

演算子
機能の意味

!

論理否定

&

論理積

|

論理和

*

ワイルドカード

=

右辺と等しい

>=

辞書順における以上

<=

辞書順における以下

フィルタでは、LDAP ディレクトリ ストアに存在する任意の属性を指定できます。この属性は、Unified CM によって認識およびインポートされる属性である必要はありません。属性は、LDAP サーバでデータを選択するためにだけ使用され、対応するエントリには、Unified CM にインポートされるデータの一部分が含まれます。

例 16-1 単一の条件

(givenName=Jack)

例 16-1 のフィルタでは、指定された名前 Jack を持つすべてのユーザが選択されます。

例 16-2 複数の条件(論理文字を使用して結合)

(&(objectclass=user)(department=Engineering))

例 16-2 のフィルタでは、エンジニアリング部門のすべてのユーザが選択されます。

デフォルトのフィルタ文字列

カスタム フィルタ文字列が定義されていない場合、Unified CM は次のようにデフォルト LDAP フィルタ文字列を使用します。

Active Directory(AD)のデフォルトのフィルタ文字列

(&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

このデフォルト フィルタでは、オブジェクト クラスがコンピュータではなくユーザであり、かつアカウントに無効のフラグが付いていないエントリが選択されます。

SunONE および Oracle Directory Server のデフォルトのフィルタ文字列

(objectclass=inetOrgPerson)

このデフォルト フィルタでは、オブジェクト クラスが inetOrgPerson であるすべてのユーザが選択されます。

OpenLDAP のデフォルトのフィルタ文字列

(objectclass=inetOrgPerson)

Active Directory アプリケーション モード(ADAM)または Active Directory ライトウェイト ディレクトリ サービス(AD LDS)のデフォルトのフィルタ文字列

(&(objectclass=user)((objectclass=Computer))(!(msDS-UserAccountDisabled=TRUE)))

デフォルト フィルタの拡張

デフォルトのフィルタ文字列を使用して、そこに追加の条件を付加することを推奨します。次に、例を示します。

(&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(telephonenumber=919*))

このフィルタでは、電話番号フィールドのプレフィックスが 919 であるユーザだけが選択されます。同期アグリーメントによって、エリア コード 919 を持つユーザだけがインポートされます。この例では、すべてのエントリがエリア コードで開始されることを想定しています。

検索フィルタに対して、既存の任意の属性を使用できます。または、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 データベース同期のキャパシティ プランニング

Unified CM データベース同期機能には、LDAP ストアから Unified CM パブリッシャ データベースへユーザ設定データ(属性)のサブセットをインポートするメカニズムがあります。ユーザ アカウントの同期が発生すると、各ユーザの LDAP アカウント情報が、そのユーザの特定の Unified Communications 機能を有効にするために必要な追加データと関連付けられることがあります。認証も有効な場合、パスワード確認のための LDAP ストアへのバインドに、ユーザのクレデンシャルを使用します。同期や認証が有効な場合に、エンド ユーザのパスワードは Unified CM データベースには格納されません。

ユーザ アカウント情報はクラスタ固有です。各 Unified CM パブリッシャ サーバは、このクラスタから Unified Communications サービスを受けているユーザの一意のリストを保持しています。同期アグリーメントはクラスタ固有で、各パブリッシャにはユーザ アカウント情報の独自コピーがあります。

Unified CM クラスタが処理できる最大ユーザ数は、クラスタのメンバー間で複製される内部コンフィギュレーション データベースの最大サイズによって制限されます。設定または同期化可能なユーザの最大数は 80,000 です。ディレクトリ同期のパフォーマンスを最適化するには、次の点を考慮してください。

電話機や Web ページからのディレクトリ ルックアップには、Unified CM データベースまたは IP Phone Service SDK を使用できます。ディレクトリ ルックアップ機能に Unified CM データベースを使用する場合、LDAP ストアから設定された、または同期されたユーザだけがディレクトリに表示されます。ユーザのサブセットを同期すると、ユーザのそのサブセットだけがディレクトリ ルックアップに表示されます。

ディレクトリ ルックアップに IP Phone Services SDK を使用する場合に、LDAP に対する Unified CM ユーザの認証が不要であれば、Unified CM クラスタにログインするユーザのサブセットだけに同期を制限できます。

クラスタが 1 つしか存在せず、LDAP ストア内のユーザ数が Unified CM クラスタでサポートされている最大ユーザ数よりも少なく、ディレクトリ ルックアップが Unified CM データベースに実装されている場合、LDAP ディレクトリ全体をインポートできます。

複数のクラスタが存在し、LDAP 内のユーザ数が Unified CM クラスタでサポートされている最大ユーザ数よりも少ない場合、すべてのユーザを各クラスタにインポートし、ディレクトリ ルックアップにすべてのエントリを確実に含めることができます。

LDAP のユーザ アカウントの数が Unified CM クラスタでサポートされている最大ユーザ数を超え、ユーザ セット全体をすべてのユーザに表示する必要がある場合は、Unified IP Phone Services SDK を使用して Unified CM からディレクトリ ルックアップをオフロードする必要があります。

同期と認証の両方を有効にすると、Unified CM データベースに設定または同期されたユーザ アカウントはそのクラスタにログインできるようになります。同期するユーザの決定は、ディレクトリ ルックアップ サポートの決定に影響します。


) シスコは、上記で説明している制限までユーザ アカウントの同期をサポートしていますが、この制限を強制しているわけではありません。多くのユーザ アカウントを同期化すると、ディスク容量の枯渇、データベース パフォーマンスの低速化、およびアップグレードの長時間化を招くことがあります。


VCS 登録エンドポイントのディレクトリ統合

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 に接続し、単一または複数の VCS に登録されたエンドポイントに対して、TMS はディレクトリ情報をプッシュできます。

詳細については、次の URL にある『 Cisco TelePresence Management Suite Administrator Guide 』と『 Cisco TelePresence Management Suite Provisioning Extension Deployment Guide 』の最新バージョンを参照してください。

http://www.cisco.com/en/US/products/ps11338/tsd_products_support_series_home.html

アイデンティティ管理アーキテクチャの概要

図 16-15 は、アイデンティティ管理アーキテクチャの概要を示しています。管理者 GUI へのアクセス企業 ID 管理ソリューションの一部として配置される、アイデンティティ プロバイダー(IdP)を使用して認証できます。サポートされる IdP には、OpenAM、Ping Federate、Microsoft Active Directory Federated Services(ADFS)、および Oracle Identity Manager が含まれます。サポートされる唯一のプロトコルは、Security Assertion Markup Language(SAML)バージョン 2.0 です。すべての Cisco Unified Communications サービス(Cisco Unified CM with IM and Presence、Cisco Unity、および WebEx オンプレミス)は、個々の ID ストアを保持します。これらの ID ストアのユーザは個々の LDAP 同期アグリーメントによって社内ディレクトリから同期できますが、ローカルに設定することもできます。すべての関連プリンシパル(ユーザ)が社内ディレクトリと個々の ID ストアの両方に存在するようにするため、LDAP から同期することを強く推奨します。

シングル サインオン(SSO)については、Unified Communications サービスの Web GUI への認証は、SAML 2.0 を通じて IdP に委任されます。この機能を使用すると、管理者は Unified Communications サービスを提供するどのエンティティについても必要な認証は一度のみになり、再認証しないで他のすべての Unified Communications サービス プロバイダーの管理者 GUI にアクセスできます。

図 16-15 アイデンティティ管理アーキテクチャ

 

シングル サインオン(SSO)

SSO をサポートするすべての Cisco Unified Communications サービスは SAML 2.0 を使用します。また、直接 LDAP バインドを使用した認証も引き続きサポートされます。SSO では、すべての Unified Communications サービスは、SAML 2.0 を使用して社内 ID 管理システムと直接統合します。

SSO に使用される主要プロトコルは、SAML です。プロトコル仕様、使用例、認証フローなどの SAML の詳細情報は、インターネットで公開されています。ここでは、SAML の重要な点だけを紹介します。

SAML を使用したアイデンティティ プロバイダー(IdP)とのすべての対話は、クライアント側の Web ブラウザを経由する必要があります。SAML の認証がユーザに Web GUI を公開しないクライアントに使用する場合、これらのクライアントは通常、内部の WebView クライアントを使用します。現在 SSO は、標準 Web ブラウザからの GUI へのアクセスについてのみサポートされているため、これはこのマニュアルの範囲外となります。

Security Assertion Markup Language(SAML)は、サービス プロバイダー(SP)と IdP との間のデータ交換用に特別に設計された XML データ形式です。SAML は IdP と SP 間で認証関連情報を渡すためにアサーションを含むセキュリティ トークンを使用します。この交換では、IdP が SAML 認証局の役割を担い、SP は SAML ユーザとなります。SAML の仕様は次の URL から入手できます。

http://saml.xml.org/saml-specifications

SAML 認証を行う前に、サービス プロバイダー(SP)と ID プロバイダー(IdP)間に信頼関係が確立されていなければなりません。これは、SP と IdP 間でメタデータを交換することによって行われます。

一般的に、単一の SAML メタデータ インスタンスに単一の SAML エンティティまたは複数のエンティティが記述されています。複数の SAML インスタンスを記述する SAML メタデータ インスタンスには、単一エンティティの記述のリストが含まれます。Cisco Collaboration ソリューションによって作成される SAML メタデータ インスタンスは、常に単一の SAML インスタンスのみを記述します。

SAML メタデータ インスタンスに記述されているどの SAML インスタンスについても、メタデータには以下が含まれます。

固有 ID

組織

この情報の有効期限

キャッシュ期間

この情報の XML シグニチャ

連絡窓口

エンティティの固有ID(エンティティ ID)

この SAML インスタンスのロールの記述(ID プロバイダー、サービス プロバイダーなど)

固有 ID を除くすべての記述は任意です。

SAML メタデータ インスタンスに含まれる各ロールの記述では、サポートされるプロトコルを定義します。また、オプションで SSO キー情報も含まれます。これらのキーは、後で SAML エンティティ間で交換される SAML メッセージに署名するために使用されます。

SAML サービス プロバイダーの SAML メタデータは、SAML ID プロバイダーがこれらの 2 つの SAML エンティティ間における SAML 交換に関連するサービス プロバイダーの特徴について理解するために必要です。SAML メタデータのサービス プロバイダー固有部分は、サービス プロバイダーが SAML 認証要求に署名するかどうかや、署名するためにサービス プロバイダーに返される SAML アサーションを要求するかどうかを示します。また、サービス プロバイダー SAML メタデータは、認証応答の送信先を定義します。この認証コンシューマ サービス(ACS)の定義は基本的に URL です。また、サービス プロバイダー SAML のメタデータは、SAML 認証プロセスの一部として SAML サービス プロバイダーと SAML ID プロバイダーの間で交換される属性を定義する場合があります。

同様に、ID プロバイダーのメタデータは IdP と SP 間の SAML 交換に関連する IdP 特性を定義します。IdP のメタデータも、認証要求の署名要件と、SAML 認証プロセスの一部として IdP と SP 間で交換する必要がある属性を定義できます。

SAML のメタデータ形式に関する詳細情報は次の URL から入手できます。

http://saml.xml.org/saml-specifications

SAML 認証

一般的な SAML 認証フローにおける登場人物は次のとおりです。

クライアント:サービスへのアクセスに使用するブラウザ ベースのユーザ クライアント

SP:ユーザがアクセスするアプリケーションまたはサービス

IdP:ユーザ クレデンシャルに基づいてユーザ認証を実行するエンティティ。IdP によって、実際のクレデンシャルとクレデンシャル認証メカニズムは見えないようになっています。IdP は、認証プロセスの結果に基づいて SAML アサーションを発行します。

SAML は、一般的な SAML の用途を記述するプロファイル数を定義します。Cisco Collaboration サービスで SSO に使用される関連プロファイルは、SAML V2.0 の Web ブラウザ SSO プロファイルです。

このプロファイルの 1 つの使用例は、図 16-16 に示すマルチドメイン 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-16 マルチドメイン Web のシングル サイン オン

 

この説明は、ユーザが最初に Web サービスによって認証され、その最初の Web サービスはユーザが 2 つ目の Web サービスにアクセスできるように ID アサーションを提供することを示しています。最初にアクセスした Web サービス(travel.example.org)は、SP sales.example.de の IdP として機能します。これは IdP initiated Web SSO と呼ばれます。

図 16-17 に示す、Cisco Collaboration サービスで使用されるより一般的な Web SSO のフローは、SP linitiated Web SSO です。この場合、ユーザは直接(最初に IdP にアクセスせずに)SP の保護リソースにアクセスしようとします。SP は IdP にユーザを送信して認証させ、次にユーザは IdP から受け取った認証アサーションを SP に提示してアクセスします。

図 16-17 SP initiated Web SSO

 

SAML の Web ブラウザ SSO プロファイルは、認証が IdP initiated と SP-initiated のどちらなのか、IdP と SP 間のメッセージの交換をどうするのかによって、さまざまなオプションを提供します。前述のとおり、Cisco Collaboration サービスは、SP とのアクティブなセッションを持っていないユーザが保護されているリソースにアクセスしようとした場合に、SP がユーザを IdP に送信して最初に認証させる場合に限り、SP-initiated の SSO を使用します。IdP は、認証アサーションを作成し、そのアサーションを持つ SP にユーザを送り返します。

Cisco Collaboration サービスの IdP と SP 間のメッセージ交換に使用されるバインディングは、図 16-18 に示す Redirect/POST バインディングです。ここでは HTTP 302 リダイレクトを使用し SP から IdP に SAML 認証要求メッセージが送信され、認証応答は HTTP POST メッセージを使用して IdP から SP に送信されます。

図 16-18 SP-initiated の SSO(Redirect/POST バインディング)

 

SAML 認証フローの一般的な手順は次のとおりです。

1. ユーザは、アプリケーション サーバの URL をブラウザに入力して、サービスまたはリソースにアクセスを試みます。この時点ではブラウザはサービスのアクティブなセッションがありません。

2. SP は、この要求がアクティブ セッションなしでクライアントから送信されたことを認識します。HTTP はステートレスなので、クライアントが事前に SP によって発行されたセッション Cookie を送信する場合にのみ、アクティブ セッションは SP によって検出できます。SSO の設定に基づいて、SP は適切な IdP に対して送信するための SAML 認証要求を生成します。SAML 要求には、要求を生成する SP についての情報が含まれます。これは IdP が SAML 要求を送信する SP を識別するために必要です。

SP はユーザを認証するために IdP と直接通信しません。代わりに SP は、ブラウザを IdP にリダイレクトします。このリダイレクトに使用する URL は、事前に交換された IdP のメタデータから取得されます。IdP に送信される SAML 要求は Base64 エンコードを使用して URL のクエリー パラメータとしてリダイレクトに含まれます。

この HTTP 302 のリダイレクトは次のようになります。

HTTP/1.1 302 Found
Location:
https://pingsso.home.org:9031/idp/SSO.saml2?SAMLRequest=nZLNbtswEITveQqCd1m0pKoWYR
lwYxQ1kDZK5OaQG02tYwISqXLJtH37kkra%2FBjwodflcPab3V2iGPqRr7076lv44QEdIb%2BGXiOfXmrq
reZGoEKuxQDIneTt%2BusVz2aMj9Y4I01PL7abmmJWVCxnku07sYCqFAu2KGWVdaycV1AWRbnPPjJZlDkl
d2BRGV3TYEPJFtHDVqMT2oUSm%2BcJq5Ks2LGK5x84K%2B8p2QQ0pYWbfh2dG5Gn6aj0A6KZHc0AM2MfeA
CYp6ob07a9nsUEGSWfjZUwJazpQfQIsWEjENUj%2FKs0z1E%2BKd0F0%2FO5908i5F92uyZprtsdJWtEsJ
Hu0mj0A9gW7KOS8P326oVXejkk4F94F0WRpyEBjmmkjdip6JXAEyldXSyjhE%2FDsq%2BWdJ5V%2FOWiq%
2FeWy%2FSV4bP9yL8Fi%2B2mMb2Sv%2F%2FnFuK8B%2BHOq2NFdclhknJnhUYF2lHSNrH%2FjQ9DOCiwNT
2ZA1n3vfl5aUG4sD5nPdDVU5K37CFQenrdqz8%3D&RelayState=s249030c0bda8e96a8086c92d0619e
6446b270c463

上記の符号化された SAML 認証要求は以下の通り復号できます。

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="s249030c0bda8e96a8086c92d0619e6446b270c463"
Version="2.0"
IssueInstant="2013-09-19T09:35:06Z"
Destination="https://pingsso.home.org:9031/idp/SSO.saml2"
ForceAuthn="false"
IsPassive="false"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://cucm-eu.home.org:
8443/ssosp/saml/SSO/alias/cucm-eu.home.org"
>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
cucm-eu.home.org</saml:Issuer>
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
SPNameQualifier="cucm-eu.home.org"
AllowCreate="true"
/>
</samlp:AuthnRequest>

上記の 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 によって署名されます。これにより SP は、SAML アサーションの信頼性を検証できるようになります。

IdP は 200 OK メッセージで非表示フォームの SAML アサーションをブラウザに返します。非表示のフォームは、SP のアサーション コンシューマ サービス(ACS)URL に SAML アサーションを POST するようブラウザに指示します。

IdP は将来発生する同じブラウザからの認証要求に対して、クレデンシャルの交換を実行せずに応答できるようにセキュリティ コンテキストを確立する必要があります。IdP は、ブラウザで有効なセッションがすでにあることを認識し、再度クレデンシャルを要求することなく、前に認証されたユーザの認証をアサートします。これにより、基本的に複数の SP に対する SSO が有効になります。

7. ブラウザは 200 OK メッセージで受信した非表示の POST に続き、SP のアサーション コンシューマ サービスに SAML アサーションを POST します。

8. SP は POST から SAML アサーションを抽出し、アサーションの署名を検証します。これは、SAML アサーションと IdP の信頼性を保証します。SAML アサーションの属性 uid で受信したユーザ ID は、ユーザに要求されたサービスへのアクセスを許可するかどうかを決定する際に使用されます。これは SP のローカル アクセス コントロールの設定に基づいています。

SP は要求されたリソースへのアクセス権を付与し、ブラウザに 200 OK メッセージの内容を返信します。SP はまた、同じブラウザから同じ SP へのそれ以降のアクセス要求に対して SP が IdP との交換をそれ以上開始する必要がないように、ブラウザにセッション Cookie を設定します。IdP は、SP セッションの期限が切れた後にのみ、同じブラウザからの追加要求に関与します。

認証タイマー

前述のとおり、クライアントから要求を受信すると、SP と IdP の両方とも、要求元のクライアントがすでにアクティブなセッションを行っているかどうかを確認します。セッション コンテキストは SP および IdP によって、セッション Cookie を発行することによって確立されます。Cisco Collaboration サービスのセッション コンテキストの有効期間は、UC サービス アイドル タイマーおよび UC サービス セッション タイマーが決定します。クライアントが UC サービス アイドル タイマーよりも長い時間、それ以上の要求を送信しない場合、Collaboration サービスのセッションは終了します。UC サービス セッション タイマーが期限切れになると、UC サービス セッションが無条件に終了します。同じロジックが IdP セッション タイマーと IdP セッション タイムアウトを使用する IdP とのセッションに存在します。上記のとおり、UC サービス セッションが終了した後の、クライアントから UC サービスに送信されたそれ以降の要求については、UC サービスは IdP による新しい SAML 認証を開始します。IdP セッションが有効である限り(クライアントは有効な IdP セッション Cookie と有効期限が切れていない IdP セッション タイマーを示します)、IdP はクライアントからの証明書を要求することなく新しい SAML の認証トークンを付与します。これは、クライアントに IdP セッション Cookie があり、IdP セッションが期限切れになっていない限り、クライアントは任意の SP でホストされるどのサービスへも再認証せずにアクセスできることを意味します。これらのタイマーの一般的な値は次のとおりです。

UC サービス アイドル タイムアウト:30 分

UC サービス セッション タイムアウト:30 分

IdP アイドル タイムアウト:8 時間

IdP セッション タイムアウト:48 時間

IdP タイマーは IdP のすべてのサービスに対してグローバルに設定されますが、UC サービス タイマーは個々の UC サービスに設定されます。

認証メカニズム

SSO がコラボレーション サービスで有効になっている場合、各サービスへのすべてのアクセスは、SSO を使用して認証されます。フォールバック手段として、バニティ URL またはリカバリ URL もランディング ページに存在します。バニティ URL は SSO メカニズムをバイパスし、すべての管理者 GUI へのアクセスを提供します。バニティ URL による管理者 GUI へのアクセスは、ローカル ユーザ データベースに対して認証されます。バニティ URL による GUI へのアクセスは utils sso recovery-url disable コマンドを使用して CLI で無効にできます。

IdP に到達できないか IdP がダウンしている、メタデータに問題がある(たとえば、期限切れの署名付き証明書)、IdP の設定が変更されるなど、SAML のインフラストラクチャに問題がある場合はバニティ URL をリカバリのバック ドアとして使用できます。

コラボレーション サービスは現在、次の種類のユーザをサポートしています。

OS ユーザ

このユーザはインストール中に指定され、CLI、Disaster Recovery System(DRS)GUI、および OS Admin GUI にもアクセスできます。CLI、DRS、OS Admin GUI へのアクセスは常にローカルで認証されます。パスワードは、ローカル データベースに保存されます。

アプリケーション ユーザ

これらはローカルで作成および管理される機能ユーザです。パスワードは、ローカル データベースに保存されます。アプリケーション ユーザは SSO に対して有効になっていません。SSO が有効になっている場合、アプリケーション ユーザはランディング ページのバニティ URL から Admin GUI のみにアクセスできます。

ローカル エンド ユーザ

これらのユーザはローカルで作成および管理されます。パスワードはローカルに保存されます。これらのユーザは企業 ID 管理システムに存在しません。SSO が有効の場合、ローカル エンド ユーザは GUI にアクセスできません。ローカル エンドユーザと SSO による LDAP 同期ユーザのサポートは後で再び導入されます。SSO を使用しないローカル エンド ユーザと LDAP 同期ユーザは引き続きサポートされます。

LDAP 同期エンド ユーザ

これらのユーザは、社内 LDAP ディレクトリで管理され、LDAP 同期アグリーメントにより Unified Communications サービスに同期されます。ローカル データベースの LDAP 同期エンド ユーザにはそれぞれ、社内 LDAP ディレクトリに対応するユーザがあります。SSO が無効の場合、LDAP 同期エンド ユーザのパスワードは、LDAP バインド操作を使用して検証されます。SSO が有効になっている場合、LDAP 同期ユーザの認証は IdP で定義された認証メカニズムに基づき、承認はローカル設定に基づきます。LDAP 同期エンド ユーザは、要求されたリソースにアクセスするためにローカルに割り当てられた適切な権限が必要です。

PIN ベースの認証は常に(SSO が有効になっている場合でも)ローカル設定に基づきます。複数のコラボレーション サービスは個別の PIN を保持します。

次の Web サービスは、SAML IdP リダイレクトに基づいた SSO が可能になっています。

Cisco Unified Communications Manager Admin GUI

Cisco Unified Communications Manager Serviceability GUI

Cisco Unified Communications Manager Reporting Tool GUI

Cisco Unified Communications Manager IM&P Admin GUI

Cisco Unity Connection Admin GUI

Cisco Unified Personal Communicator Assistant

Cisco Unity Connection WebInBox

SSO の設計上の検討事項

SAML SSO は常に、クラスタ内のすべてのノードに対して有効もしくは無効にしておく必要があります。クラスタ内のすべてのノードにおいて、SSO を有効にするか、もしくは無効にしてください。Admin GUI 経由で SSO を有効にすると、自動的にすべての既存のノードで同時に SSO が有効化されます。このプロセスの一環として、すべてのクラスタ ノードの SP メタデータがダウンロードされます。各クラスタ ノードは個別の SP として IdP 上で表す必要があります。すでに SSO モードに入っているクラスタに後でノードが追加されると、追加されたノードのメタデータは IdP で定義された SP のリストを完成するために IdP にインポートされる必要があります。

IdP のメタデータはすべての SAML SP にインポートされる必要があります。SSO が Admin GUI で有効化された場合、この過程で提供された IdP のメタデータは、クラスタ内のすべてのノードに自動的にインポートされます。

SP メタデータはオプションの ContactPerson 情報を含まないため、IdP は Cisco Collaboration SP の連絡先情報を表示できません。

SAML SP は、SAML AuthnRequest に WantAssertionsSigned を含めることで、IdP から署名付きアサーションを要求できます。現在 Cisco Collaboration SP はこの情報を送信しません。IdP はアサーションの署名を完全に制御できます。IdP 上で SAML アサーションの署名を有効化することを推奨します。

IdP の可用性は SSO を使用するうえでの重要な要件です。IdP は完全な冗長性と耐障害性とともに導入する必要があります。この種の配置において重要なのは、IdP が単一の論理 URL を使用して導入され、単一の IdP URL の可用性が高くなるように適切なロード バランサと Web サーバ ファームを導入するることです。単一の IdP URL は IdP のメタデータに含まれ、すべての Cisco Collaboration SP にインポートされます。単一要素の障害(たとえば、1 台の Web サーバ)は、Collaboration サービスからは見えないようにする必要があります。

SAML 要求およびアサーションは、SP および IdP の証明書を使用して署名されます。SAML SSO のメカニズムが引き続き機能することを確認するために、これらの証明書の有効期間を厳密に監視する必要があります。

SAML アサーションには、有効性の情報(NotBefore、NotOnOrAfter)が含まれます。有効なアサーションがタイミングの問題で拒否されないようにするには、Network Time Protocol(NTP)などの適切なメカニズムを使用してすべての SP と IdP を同期する必要があります。