Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン ガイド Cisco CallManager Release 3.3

ディレクトリ アクセスとディレクトリ統合

---

この章では、Cisco IP Phone や Cisco IP SoftPhone などの Cisco IP テレフォニー エンドポイントから、社内 LDAP（Lightweight Directory Access Protocol）ディレクトリにアクセスする場合の、設計上の考慮事項を説明します。また、Cisco CallManager と社内 LDAP ディレクトリを統合する場合の、設計上の主な原則についても説明しています。この章の構成は、次のとおりです。

• 「ディレクトリ アクセスとディレクトリ統合との比較」

• 「Cisco IP テレフォニー エンドポイントのディレクトリ アクセス」

• 「Cisco CallManager とのディレクトリ統合」

ディレクトリ アクセスとディレクトリ統合との比較

この項では、次の定義が適用されます。

• ディレクトリ アクセスとは、Cisco IP Phone や Cisco IP SoftPhone などの Cisco IP テレフォニー エンドポイントが、社内 LDAP ディレクトリにアクセスする機能のことです。

• ディレクトリ統合とは、Cisco CallManager などのアプリケーションが、独自の組み込みデータベースの替わりに、中央の社内 LDAP ディレクトリに、ユーザ関連情報を保存する機能のことです。

図 10-1 では、この章で定義されるディレクトリ アクセスを示しています。この例では、Cisco IP Phone からアクセスしています。クライアント アプリケーションは、企業の社内ディレクトリなどの LDAP ディレクトリに対してユーザ検索を実行し、一致するエントリを受け取ります。この例では、ユーザ検索に対して 1 つのエントリが選択され、エントリーは Cisco IP Phone から検索されたユーザにダイヤルするために使用されます。

図 10-1 Cisco IP Phone のディレクトリ アクセス例

一方、複数のアプリケーションと 1 つの社内ディレクトリを統合するディレクトリ統合は、これらのアプリケーションが、独自の組み込みデータベースを使用するのではなく、中央ディレクトリにユーザ関連情報を保存することを意味します。図 10-2 では、この章で定義されるディレクトリ統合の例を示しています。

図 10-2 Cisco CallManager とのディレクトリ統合例

デフォルトでは、Cisco CallManager は、組み込み LDAP ディレクトリに、ユーザ情報（たとえば、ユーザが制御するデバイス、IP フォンで設定される短縮ダイヤルなど）を保存します。しかし、通常、電子メール アドレス、オフィスの住所、および役職などの一般的な社員情報を保存するために使用される社内 LDAP ディレクトリに、Cisco CallManager を統合することもできます。この場合、Cisco CallManager は、独自の組み込みディレクトリを使用しなくなり、社内ディレクトリに特定のユーザ情報を保存します。

（注） Cisco CallManager リリース 3.3(2) では、ディレクトリ統合は、Microsoft Active Directory、および Sun/iPlanet/Netscape Directory Server リリース 4.x と 5.1 でサポートされています。

Cisco CallManager などのアプリケーションと社内ディレクトリを統合することには、単にエンドポイントにディレクトリ アクセスを提供すること以外に、次のような意味もあります。

• 社内ディレクトリにアプリケーション固有のユーザ属性を保存するには、ディレクトリ スキーマを拡張する必要があります。この操作は複雑なので、操作の際には、ディレクトリ構造を十分に理解している必要があります。

• アプリケーションは、いつでもディレクトリと交信できなければなりません。ディレクトリ サービスの可用性は、アプリケーションの機能に影響を与える場合があります。

• データ保存と、読み取りと書き込み照会によって、ディレクトリに不必要な負荷がかかります。サーバのオーバーサブスクリプションを回避するために、慎重な計画とサイジングをお勧めします。

複数のアプリケーションにわたるディレクトリ統合には多くの利点がありますが、ディレクトリ統合が及ぼす影響をすべて理解し、個々の配置ごとにビジネスのニーズを確認することが重要です。

Cisco IP テレフォニー エンドポイントのディレクトリ アクセス

Cisco CallManager やその他の IP テレフォニー アプリケーションが社内ディレクトリに統合されているかどうかに関係なく、この項で説明しているガイドラインが適用されます。どちらの場合も、エンドユーザからは同じように見えます。これは、相違点によって影響を受けるのは、アプリケーションがユーザ情報を保存する方法と、ネットワーク上でこの情報の一貫性が保持される方法だけだからです。

次の Cisco IP テレフォニー エンドポイントに対して、任意の LDAP v3 対応ディレクトリ サーバへの社内ディレクトリ アクセスを設定する方法を次の項で説明します。

• Cisco IP Phone（7940 および 7960）

• Cisco IP SoftPhone

Cisco IP Phone のディレクトリ アクセス

Cisco IP Phone 7940 および 7960 は、ユーザが電話機上の Directories ボタンをアクティブにすると、社内 LDAP ディレクトリを検索できます。IP Phone は、ハイパーテキスト転送プロトコル（HTTP）を使用して、要求を Web サーバに送信します。Web サーバからの応答には、電話機が解釈し表示できる、特定の XML（eXtensible Markup Language）オブジェクトが入っていなければなりません。社内ディレクトリを検索する場合、Web サーバは、プロキシとして動作します。電話機から要求を受け取り、その要求を LDAP 要求に変換します。LDAP 要求は、社内ディレクトリ サーバに送信されます。次に、応答が解釈され、適切な XML オブジェクトにカプセル化された後、電話機に戻されます。

図 10-3 では、Cisco CallManager が社内ディレクトリに統合されていない配置における、このメカニズムを示しています。このシナリオでは、Cisco CallManager はメッセージ交換に関わっていないことに注意してください。

図 10-3 Cisco IP Phone のディレクトリ アクセス メカニズム

Web サーバのプロキシ機能は、Cisco LDAP Search COM Server が組み込まれている Cisco IP Phone Services Software Development Kit（SDK）バージョン 2.0 を使用して設定できます。SDK をインストールすると、Cisco LDAP Search COM Server が自動的にインストールされます（インストレーション手順の詳細は、SDK 製品資料を参照）。

SDK をインストールした後、Web サーバが処理する ASP（Active Server Page）をカスタマイズする必要があります。SDK の一部として、サンプル スクリプトが用意されています。これらのスクリプトを編集すると、実際の配置に固有のニーズに合わせて、さまざまなディレクトリ検索を提供できます。

ASP をカスタマイズした後、Cisco CallManager の Enterprise Parameters 内の URL Directories フィールドを、上記の Web サーバを指定するように設定し、その後、Cisco IP Phone をリセットしてください。

Cisco IP SoftPhone のディレクトリ アクセス

Cisco IP SoftPhone リリース 1.2 には、LDAP ディレクトリにアクセスし、検索する内蔵メカニズムがあります。この機能の設定方法の詳細は、製品資料を参照してください。

Cisco CallManager とのディレクトリ統合

Cisco CallManager は、組み込み Microsoft SQL データベースを使用して、システムとデバイスの設定データ（たとえば、ダイヤル プラン情報、IP フォンとゲートウェイ設定、メディア リソースの使用率）を保存します。また、組み込み LDAP ディレクトリを使用して、ユーザとアプリケーション プロファイル（たとえば、ユーザが制御するデバイス、短縮ダイヤル設定、個人用アドレス帳）を保存します。

SQL データベースと LDAP ディレクトリはどちらも、クラスタ内の各 Cisco CallManager サーバで実行され、サーバ間でレプリケーション アグリーメントが自動的にセットアップされます。パブリッシャ サーバには、SQL データベースと LDAP ディレクトリの両方のマスター コピーが入っています。パブリッシャ サーバは、すべてのサブスクライバ サーバへの複写を処理します。サブスクライバ サーバには、両方のリポジトリの読み取り専用コピーが入っています。

アプリケーション固有の情報を LDAP ディレクトリに保存するために、Cisco CallManager は、組み込みディレクトリの使用時と、社内ディレクトリとの統合時の両方で有効な方法を採用します。

ディレクトリ ベンダが異なると、通常、複数の標準外の追加属性を持つ User オブジェクト モデルも異なります。Cisco CallManager は、User オブジェクトには、標準の LDAPv3 コア属性だけが含まれていることを想定しています。User オブジェクトは、ciscoatUserProfileString と呼ばれる単一の属性が入っている、補助クラス ciscoocUser で拡張されます（以前のバージョンの Cisco CallManager は、ciscoatUserProfile と呼ばれる別の属性を使用していました。下位互換性、および他の Cisco アプリケーションとの互換性を確保するために、このスキーマでは、両方の属性が保持されます）。この属性は、アプリケーション固有のプロファイルが入っている、ディレクトリ内の別のオブジェクトを指す Distinguished Name ポインタです。この方法では、コア User オブジェクトに対する影響が最小限に抑えられ、アプリケーション固有の情報はすべて、ディレクトリ内の別個の Organizational Unit（OU）（通常、Cisco サブツリーまたは Cisco DIT と呼ばれます）に保存できます。図 10-4 では、このプロセスをグラフィカルに表示します。

図 10-4 Cisco CallManager ディレクトリ アプローチ

ciscoatUserProfileString 属性が指すオブジェクトは、ciscoocUserProfile と呼ばれる別の補助クラスに属しています。その標準名（CN）は、コア User オブジェクトの CN にサフィックス「-profile」を付けたものです。このオブジェクトの主な目的は、ディレクトリと統合するすべての Cisco アプリケーションに固有のプロファイル オブジェクトを指す、その他のポインタを保存することです（これは、ciscoatAppProfile という名前の多値属性により行われます）。Cisco CallManager が使用するアプリケーション プロファイルは、ciscoCCNocAppProfile と呼ばれる補助クラスに属し、その CN は、コア ユーザの CN にサフィックス「-CCNprofile」を付けたものです。Cisco CallManager は、ここに、ユーザのエクステンション モビリティ PIN 番号、このユーザが制御するデバイスのリスト、このユーザの CTI アプリケーションを使用する権限などを保存します。図 10-5 では、これらの 2 つのプロファイル オブジェクト間の関係を示しています。

図 10-5 コア ユーザ オブジェクト、ユーザ プロファイル、アプリケーション プロファイル間の関係

Cisco CallManager と外部の LDAP ディレクトリを統合するには、Cisco CallManager ソフトウェアに付属している Cisco Customer Directory Integration Plugin を実行します。このプラグインを利用する主な目的は、次の 3 点です。

• 社内ディレクトリ スキーマを拡張して、アプリケーション固有のオブジェクトと属性に対応すること。

• 「Cisco」サブツリーに、Cisco CallManager が必要とする設定オブジェクトを取り込むこと。

• 社内ディレクトリを使用するように Cisco CallManager を設定し、その組み込みディレクトリを使用不可にすること。

Cisco Customer Directory Integration Plugin のインストール方法の詳細は、製品資料を参照してください。

ベスト プラクティス

Cisco CallManager と、AD（Microsoft Active Directory）などの社内ディレクトリを統合する際には、次のベスト プラクティスが適用されます。

• 社内のディレクトリ チームによって統合が計画され、実行されることを確認する。

• 統合前に、実際の AD の正確なレプリカを実験室でセットアップしてテストする。

• 統合前に、AD フォレストのバックアップを作成する。

• Cisco Customer Directory Integration Plugin 設定で、特定の AD サーバ名ではなく、ドメイン ネーム システム（DNS）によって解決可能なドメイン名を使用する。

• AD 統合 DNS ロード バランシングが使用できない場合、Catalyst 6000 で Cisco IOS Server Load Balancing（SLB）を使用する。

• 「User Search base」を、必要なすべてのユーザを含むツリー内の最低ポイントに設定する。

• Cisco CallManager リリース 3.3 を配置する場合、設定されている「User Search base」内に、「User Creation base」が含まれていることを確認する。

• Microsoft Windows 2000 ドメイン コントローラ（DC）が、配置されている各 Cisco CallManager サーバのローカル側にあること、およびディレクトリ インフラストラクチャの可用性が高いことを確認する。

• MMC（Microsoft Management Console）に含まれている ADU&C（Active Directory Users & Computers）を使用して、AD ユーザ アカウントを管理する。

• Cisco CallManager Administration を使用して、Cisco CallManager 属性を管理する。

• ADU&C または Windows PC からパスワードを設定する。

• ディレクトリにアクセスするために Cisco CallManager の専用「サービス アカウント」を使用し、このアカウントに必要最小限の権限を付与する。

• 新しい配置では、AD 統合を最初から計画する。

Cisco CallManager と、AD（Microsoft Active Directory）などの社内ディレクトリを統合する際には、次の制約事項も適用されます。

• 現在、Cisco Customer Directory Integration Plugin はデータ マイグレーションを実行しません。サンプル マイグレーション スクリプトは、Cisco アカウント チームからガイドラインとして入手できます。

• Cisco CallManager リリース 3.3 より前のリリースでは、複数のクラスタ配置では、AD ツリー内で検索ベースが重複できませんでした。複数の Cisco CallManager クラスタと同じ社内ディレクトリを統合するには、Cisco アカウント チームによるリビューが必要です。

• 1 つの Cisco CallManager クラスタと、AD フォレスト内の単一ツリーを統合できます。

• AD パスワードは、Cisco CallManager User ページ、または Cisco CallManager Administration ページから設定またはリセットできません。