Cisco Collaboration 9.xソリューション リファレンス ネットワーク デザイン(SRND)
LDAP ディレクトリ統合
LDAP ディレクトリ統合
発行日;2013/10/03 | 英語版ドキュメント(2013/09/09 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 30MB) | フィードバック

目次

LDAP ディレクトリ統合

この章の新規情報

ディレクトリ統合とは

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 登録エンドポイントのディレクトリ統合

LDAP ディレクトリ統合

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

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

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 でのディレクトリ統合に関して、技術的なソリューションについて説明し、設計上の考慮事項を示します。

この章で説明する考慮事項は、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 年 5 月 24 日

Cisco TelePresence Management Suite(TMS)

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

2013 年 4 月 2 日

ローカルおよび LDAP 同期ユーザの同時サポート

「LDAP 同期」

2012 年 6 月 28 日

カスタム LDAP フィルタ ストリング

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

2012 年 6 月 28 日

Cisco Unified Communications システム Release 9.0 向けのマイナー アップデート

この章の各項で説明

2012 年 6 月 28 日

ディレクトリ統合とは

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

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

 

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

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

一般に、社内ディレクトリ クレデンシャルを使用して、音声アプリケーションやビデオ アプリケーションのエンド ユーザと管理者を認証することも必要です。ディレクトリ認証を有効にすることで、IT 部門は 1 つのログイン機能を提供し、さまざまな企業アプリケーションに対して各ユーザが保持する必要のあるパスワードの数を減らすことができます。

表 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 ユーザのほか、User Groups and Roles 設定(以前のバージョンの 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 データベースに対して内部でアプリケーション ユーザを維持および認証すると、社内 LDAP ディレクトリの可用性とは無関係に、これらのアカウントを使用して Unified CM と通信するすべてのアプリケーションと機能に対して復元性が提供されます。

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 でローカルで編集できるよう、ローカル ユーザ情報に変換できます。LDAP 同期されたユーザをローカル ユーザに変換した後、そのユーザの情報が LDAP からそれ以上同期されることはありません。ローカル エンド ユーザは、Unified CM Administration GUI を使用して手動で追加できます。

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

 

LDAP 同期をアクティブにすると、一度に 1 つのタイプの 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 では、LDAP ディレクトリから対応する Unified CM ユーザ フィールドにインポートされた属性を示していて、またこれらのフィールド間のマッピングについて説明しています。Unified CM ユーザ フィールドの中には、複数の LDAP 属性の 1 つからマッピングされるものもあります。

 

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

Unified CM のユーザ フィールド
Microsoft Active Directory
Active Directory アプリケーション モード(ADAM)
または Active Directory ライトウェイト ディレクトリ サービス(AD LDS)
Netscape、iPlanet、または 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 に、Dirsynch プロセスによってインポートされ、Unified CM データベースにコピーされるが、管理者ユーザの設定 Web ページには表示されない追加属性のリストを示します。 Microsoft OCS を使用する場合、属性 msRTCSIP-PrimaryUserAddress は AD に格納されます。この表は、完全な情報を提供する目的で記載されています。

 

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

Unified CM のユーザ フィールド
Microsoft Active Directory
Netscape、iPlanet、または 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 Web ページで有効にする Cisco DirSync というプロセスによって実行されます。このプロセスを有効にすることで、システムに 1 ~ 5 つの同期アグリーメントを設定できます。アグリーメントでは、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 もインポートしていたと考えられます。検索ベースではドメイン ルートを指定する必要はなく、ツリーのどの場所でも指定できます。

図 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 から同期が行われます。これに対して、iPlanet および 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 ですぐにアクティブになります。

iPlanet または Sun ONE でのアカウント同期

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

図 16-8 iPlanet および 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 Web ページによって管理する。

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

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

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

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

ドメインの同期アグリーメントでは、ドメイン外のユーザや子ドメイン内のユーザは同期されません。同期プロセス中は Unified CM が AD 照会に従わないためです。図 16-9 の例では、すべてのユーザをインポートするために 3 つの同期アグリーメントが必要です。Search Base 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 展開は、複数の異種フォレストを統合する単一のフォレスト ビューとして 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 データベースに対して認証される。

この動作は、リアルタイム Unified Communications システムの操作を社内ディレクトリの可用性に依存しないようにしながら、シングル ログイン機能をエンド ユーザに提供するという原則に従ったものです。図 16-12 に図示します。

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

 

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

1. ユーザは、HTTPS 経由で [Unified CM User Options] ページに接続し、ユーザ名とパスワードで認証を試行します。この例では、ユーザ名は jsmith です。

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

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

3. ユーザが LDAP 同期ユーザの場合、Unified CM はユーザ名 jsmith に関する LDAP 照会を発行し、[LDAP Authentication] 設定ページの [LDAP Search Base] で指定された値を、この照会の範囲として使用します。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 User Search Base ですべてのユーザが存在するディレクトリ サブツリーを指定することにより、Unified CM で LDAP 認証を有効にする。

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

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

Unified CM Administration の Web ページまたは [Unified CM User Options] ページでエンド ユーザ PIN を管理する。

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

対応するエンド ユーザを Unified CM Administration の Web ページから 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 のユーザに対する認証プロセスを示しています。

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 に同じ手法を使用して、コンテナを定義できます。同期アグリーメントでは、ディレクトリ ツリーの特定のコンテナを指定でき、それによってインポートの範囲を制限できます。

使用できる同期アグリーメントは 5 つだけなので、多数の 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 または Netscape のデフォルトのフィルタ ストリング

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

詳細については、次の 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