Cisco Unified Communications Manager, Release 9.1(1) IM and Presence サービス導入ガイド
Cisco Unified Personal Communicator の Active directory の設定
Cisco Unified Personal Communicator の Active directory の設定
発行日;2013/08/12   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

目次

Cisco Unified Personal Communicator の Active directory の設定

Cisco Unified Personal Communicator の電話番号およびその他のユーザ情報は、Active Directory によって提供されます。 Cisco Unified Client Services Framework は、Cisco Unified Personal Communicator に Active Directory サービスを提供します。

Cisco Unified Client Services Framework は、次のいずれかのメカニズムを使用して、Active Directory サーバから連絡先情報を取得します。

  • 拡張ディレクトリ統合(EDI):EDI はネイティブ Windows API を使用します。 EDI の使用を選択した場合は、クライアントがディレクトリにアクセスする方法に応じて、追加設定が必要がないことがあります。
  • 基本ディレクトリ統合(BDI):統合は Windows 環境にネイティブではなく、設定が必要です。

拡張および基本ディレクトリ統合の機能の比較で説明されているように、EDI には BDI よりも重要な利点があるため、EDI を使用することを推奨します。

BDI または EDI を使用し、追加設定を実行する場合は、Cisco Unified Communications システムでコンピュータに設定を展開する必要があります。 これを行うには、Active Directory グループ ポリシーを使用できます。

拡張および基本ディレクトリ統合の機能の比較

次の表に、拡張および基本ディレクトリ統合で使用可能な機能を示します。 この表は、Cisco Unified Communications システムに最も適しているメカニズムを判断するのに役立ちます。

表 1 拡張および基本ディレクトリ統合の機能の比較

機能

拡張

基本

Active Directory 統合のためのデフォルト メカニズムとして設定

なし

あり

最小限の設定が必要

あり

なし

ディレクトリ サービスの自動検出

あり

なし(設定が必要)

Active Directory ドメイン コントローラ(DC)への接続のサポート

あり

あり(設定が必要)

Active Directory グローバル カタログ(GC)への接続のサポート

あり(デフォルトでサポート)

あり(設定が必要)

Active Directory Lightweight Directory Services(AD LDS)および Active Directory Application Mode(ADAM)サーバへの接続のサポート

あり

部分的(プロキシ認証は未サポート)

ディレクトリ サービスのサービスおよびポートを定義可能

あり(オプション)

あり(必須)

バックアップ ディレクトリ サーバを設定可能

あり

なし

検索ベースを定義可能

あり(最大 5)

あり(最大 5)

SSL のサポート

あり

あり

SSL の WIndows 証明書ストアを使用可能

あり

なし(Java ストアを使用する必要がある)

Active Directory クレデンシャルの暗号化のサポート

あり

なし(SSL を使用する場合を除く)

Windows クレデンシャルと統合された認証のサポート

あり

なし

管理者は代替クレデンシャルを定義可能

あり

なし

ユーザは代替クレデンシャルを定義可能

あり

あり

カスタム属性マップ

あり

あり(マップが定義されている必要がある)

電話属性の検索範囲制御

あり

なし

LDAP クエリーをカスタマイズ可能

あり

あり

電話番号マスクのサポート

あり

あり

連絡先写真の URL を取得可能

あり

あり

バイナリ写真オブジェクトを取得可能

あり

なし

Active Directory と Cisco Unified Client Services Framework の統合

次の表に、拡張ディレクトリ統合を使用するか基本ディレクトリ統合を使用するかを指定するための作成または変更できるレジストリ サブキーを示します。 サブキーは、次のレジストリの場所にあります。

[HKEY_CURRENT_USER\Software\Cisco Systems, Inc.\Client Services Framework\AdminData].

次のサブキーがまだ存在しない場合は、作成する必要があります。

表 2 拡張または基本ディレクトリ統合の設定のレジストリ サブキー

サブキー名

説明

EnableNativeDirectoryProvider

Active Directory から連絡先情報を取得するために拡張ディレクトリ統合を使用するか基本ディレクトリ統合を使用するかを指定します。 次のいずれかの値を入力します。

  • 0:基本ディレクトリ統合を使用します。 これがデフォルト値です。
  • 1:拡張ディレクトリ統合を使用します。

データ型:REG_SZ

パーティション化されたドメイン内フェデレーションにプレゼンスまたはチャットを設定する場合は、ユーザを Active Directory から直接追加できるように、次の表に示すサブキーを作成または変更する必要があります。 サブキーは、次のレジストリの場所にあります。

[HKEY_CURRENT_USER\Software\Cisco Systems, Inc.\Client Services Framework\AdminData].

表 3 パーティション化されたドメイン内フェデレーションのプレゼンスおよびチャットの設定用レジストリ サブキー

サブキー名

LDAP_AttributeName_uri

msRTCPSIP

LDAP_UriSchemeName SIP

基本および拡張ディレクトリ統合に必要なマッピング キー

この章では、基本ディレクトリ統合と拡張ディレクトリ統合の両方の設定に関する情報を示します。 次のガイドラインは、1 つのタイプのディレクトリ統合にのみ、または両方に適用されるレジストリ キーの説明を管理者が明確かつ容易に理解できるように記述されています。

  • レジストリ キー LDAP_AttributeName_uriLDAP_SearchByUsername、および LDAP_DisableNumberLookups は、基本ディレクトリ統合と拡張ディレクトリ統合の両方で使用できるサービスを提供します。
  • レジストリ キー EnableNativeDirectoryProvider は、拡張ディレクトリ統合にのみ適用できます。
  • この章で示す先頭に LDAP_(最初の中黒を除く)が付いているすべてのレジストリ キーは、基本ディレクトリ統合だけに適用できます。

拡張ディレクトリ統合

拡張ディレクトリ統合(EDI)を使用する場合は、次のような利点が得られます。

  • クライアントがディレクトリにアクセスする方法に応じて、追加設定が必要がないことがあります。 クライアントは、ユーザがログインするドメイン内のグローバル カタログ(GC)サーバに安全に接続します。 GC サーバは Windows 認証を使用して DNS で検出できる必要があります。 使用するクレデンシャルは、現在ログインしている Windows ユーザのクレデンシャルです。
  • ディレクトリ サーバは DNS によって自動的に検出されます。
  • ユーザは Windows ドメインにログインし、Active Directory ユーザ名とパスワードを入力せずに Active Directory にアクセスします。
  • ローカルおよびプロキシ認証を実装する Active Directory Lightweight Directory Services(AD LDS)および Active Directory Application Mode(ADAM)サーバへの接続がサポートされます。
  • SSL がサポートされます。 Windows 証明書ストアが使用されるため、別の証明書ストアを設定する必要はありません。
  • DNS は、Windows ドメインのフェールオーバー サポートを提供します。
  • DNS は、Windows ドメインのロード バランシング サポートを提供します。
  • 匿名バインドと簡易バインドがサポートされます。

ディレクトリ サービスの自動検出

自動検出を使用するように拡張ディレクトリ統合を設定すると、Cisco Unified Client Services Framework は、Windows がドメイン コントローラ(DC)またはグローバル カタログ(GC)の検出に使用するディレクトリ サービスを検出するために同様の方法を使用します。 つまり、Cisco Unified Client Services Framework は、DNS サービス レコード(SRV)要求を使用します。

Cisco Unified Client Services Framework は、クライアント コンピュータがメンバーであるドメインの GC のサーバを検索します。 ドメインを識別するために、クライアント コンピュータのクエリーは、コンピュータの USERDNSDOMAIN 環境変数の値を確認します。

自動的に検出できないディレクトリ サーバ

プライマリ サーバとセカンダリ サーバを設定すると、Cisco Unified Personal Communicator はプライマリ サーバに接続しようとします。 プライマリ サーバが使用できない場合は、Cisco Unified Personal Communicator はセカンダリ サーバへの接続を試行します。 セカンダリ サーバへの接続が成功すると、プライマリ サーバは、一定期間ブラックリストに記載されます。

グローバル カタログ サーバまたはドメイン コントローラへの接続

ドメイン コントローラ(DC)ではなくグローバル カタログ(GC)サーバへの Cisco Unified Communications システムの LDAP および LDAPS 接続を設定することを推奨します。 GC サーバは、Windows ドメイン フォレスト内の全ユーザのプライマリ ディレクトリ属性を保持しています。 Cisco Unified Client Services Framework が使用するデフォルトの検索属性は、通常 GC サーバからすべて使用できます。

DC への LDAP および LDAPS 接続が設定されている場合、Cisco Unified Client Services Framework からのディレクトリ検索はそのドメイン内のデータに制限されます。 検索は、組織内のピア サブドメインから連絡先を解決できない場合があります。

ディレクトリ サーバの管理者は、いくつかの検索属性が GC サーバ上にない場合に DC 接続するよう選択することがあります。 DC は、DC が管理するドメインで使用する連絡先情報だけを保持します。

Cisco Unified Communications システムで電話番号のカスタム属性を使用する場合、これらの属性は GC から使用できないことがあります。 一部の属性を GC から使用できない場合、ディレクトリ サーバの管理者は、DC に接続するか、または GC サーバの欠落属性を有効にすることをディレクトリ マネージャに要求するように Cisco Unified Personal Communicator を設定することがあります。

システムで連絡先のディレクトリ ベースの写真を使用する場合は、写真属性が GC から使用できることをディレクトリ管理者に確認してください。 ディレクトリ管理者は GC サーバでこれらの属性を有効にすることができます。

LDAP を使用するように拡張ディレクトリ統合を設定した場合は、GC サーバまたは DC サーバの選択が上書きされます。

GC サーバと DC サーバの接続に使用されるデフォルト ポートは次のとおりです。

  • GC:3268
  • DC:389

SSL の使用

拡張ディレクトリ統合(EDI)は、すべての認証データをデフォルトで暗号化します。

システムがユーザ クレデンシャルとクエリー データの両方の暗号化を必要とする場合は、SSL を有効にできます。 グローバル カタログ(GC)とドメイン コントローラ(DC)の両方の接続に SSL を使用できます。 EDI を使用する場合は、SSL 接続の証明書が Windows 証明書ストアに必要です。 Windows ドメインでは、証明書は、通常はクライアント コンピュータの証明書ストアにあります。

SSL を使用する場合に GC サーバと DC サーバの接続に使用されるデフォルトのプロトコルとポートは次のとおりです。

  • GC:TCP、3269
  • DC:TCP、636

ドメインに含まれないユーザでの SSL の使用

ドメインの一部ではないユーザで拡張ディレクトリ統合(EDI)を使用するには、SSL を使用する必要があり、ドメイン外の各ユーザに証明書が必要です。

証明書は、ユーザのコンピュータ上の信頼できるルート認証局(CA)証明書のリストに含まれている必要があります。 証明書がサードパーティ レジストラから取得される場合、証明書は信頼されたルート CA. に連結されることがあります。 証明書チェーンが Cisco Unified Personal Communicator ユーザのコンピュータ上の信頼されたルート証明書のデフォルト セットにないルート CA に連結された場合、コンピュータはサーバとネゴシエートできません。

Windows クレデンシャルの使用

クライアント コンピュータが Active Directory サーバに接続する場合、暗号化された認証が使用されます。 Windows 以外のサーバに接続する場合、Windows 暗号化の無効化が必要になることがあります。 Windows 暗号化を無効にすると、ディレクトリへの接続に基本的なバインドが使用されます。 基本的なバインドを使用すると、ユーザ クレデンシャルがクリア テキストで送信されます。

このシナリオでは SSL を使用することを推奨します。

関連トピック

SSL の使用

非 Windows クレデンシャルの使用

ディレクトリ クエリーの認証のために Cisco Unified Personal Communicator のクレデンシャルの共通セットを使用するように選択する場合があります。 このシナリオでは、すべてのクライアント コンピュータにクレデンシャルをプッシュできます。

Cisco Unified Communications システムがサードパーティ製ディレクトリ サービスにアクセスする場合に、この機能を使用することがあります。

クライアント コンピュータがクレデンシャルを提供しない場合、拡張ディレクトリ統合(EDI)は、ディレクトリ サービスへの匿名バインドを試みます。

拡張ディレクトリ統合を使用する前に考慮するトピック

拡張ディレクトリ統合(EDI)を使用する前に、次のトピックを考慮する必要があります。

  • 接続する必要があるディレクトリのタイプタイプ:
    • グローバル カタログ(GC)
    • Active Directory または LDAP
    • Active Directory Lightweight Directory Service(AD LDS)または Active Directory Application Mode(ADAM)
  • Windows 認証が使用できるかどうか。
  • ディレクトリのルートが検索されるかどうか、またはユーザが複数の検索ベースに存在するかどうか。

関連トピック

設定の質問例

Active Directory との拡張ディレクトリ統合の設定

拡張ディレクトリ統合を使用した Active Directory のデフォルト設定

次の表に、拡張ディレクトリ統合(EDI)で Active Directory がどのようにデフォルトで設定されるかを詳しく示します。 これらの設定詳細が要件を満たしていない場合、一部の設定を適切に変更する必要がある場合があります。

表 4 EDI を使用した Active Directory のデフォルト設定

設定領域

説明

グローバル カタログ サーバの検索

DNS を使用して、Windows マシンのドメインのグローバル カタログ(GC)サーバまたはドメイン コントローラ(DC)を検索します。 GC または DC は DNS サービス(SRV)の _gc レコードで検索します。

ポート

3268

デフォルトの検索ベース

ドメイン ルート、つまり RootDSE。

資格情報

現在ログインしている Windows ユーザのクレデンシャルで接続します。

セキュリティ

セキュア接続を使用します。

検索のプリファレンス

subtree、chaseReferrals、timeout 5s、pageSize 100、PagedTimeLimit 5s

ディレクトリ属性名

デフォルトの Active Directory 属性名。

拡張ディレクトリ統合の接続設定

拡張ディレクトリ統合(EDI)のデフォルト設定が要件を満たしていない場合、一部の設定を適切に変更する必要がある場合があります。 次の表に、作成または変更できる Active Directory 設定のレジストリ サブキーを示します。 サブキーは、次のレジストリの場所にあります。

[HKEY_CURRENT_USER\Software\Cisco Systems, Inc.\Client Services Framework\Active Directory]

特に指定しない限り、レジストリ設定のデータ型は REG_SZ です。

まだ存在しないキーは作成する必要があります。

表 5 Active Directory 接続設定のレジストリ サブキー

サブキー名

説明

ConnectionType

Client Services Framework で Active Directory を検出する方法を指定します。 次のいずれかの値を入力します。

  • 0:グローバル カタログ(GC)またはドメイン コントローラ(DC)を使用して Active Directory サーバを自動的に検出します。 これがデフォルト値です。
  • 1:LDAP を使用します。

データ型:REG_DWORD

UseSecureConnection

Client Services Framework で接続のユーザ名とパスワードを暗号化するかどうかを指定します。 次のいずれかの値を入力します。

  • 0:暗号化を使用します。 これがデフォルト値です。
  • 1:暗号化を使用しません。

データ型:REG_DWORD

UseSSL

Client Services Framework がディレクトリに安全に接続するために SSL を使用するかどうかを指定します。 次のいずれかの値を入力します。

  • 0:SSL を使用しません。 これがデフォルト値です。
  • 1:SSL を使用します。

データ型:REG_DWORD

UseWindowsCredentials

Client Services Framework がクレデンシャル、つまり、ユーザ名とパスワードを Windows と別のソースのどちらから使用するかを指定します。 次のいずれかの値を入力します。

  • 0:Windows 以外のソースのクレデンシャルを使用します。
  • 1:Windows クレデンシャルを使用します。 これがデフォルト値です。

データ型:REG_DWORD

ConnectionUsername

Windows 以外のソースのクレデンシャルを使用することを選択した場合、Client Services Framework が Active Directory に接続するときに使用するユーザ名を指定します。

デフォルトでは、このサブキー名は使用されません。

ConnectionPassword

Windows 以外のソースのクレデンシャルを使用することを選択した場合、Client Services Framework が Active Directory に接続するときに使用するパスワードを指定します。

デフォルトでは、このサブキー名は使用されません。

BaseFilter

Active Directory に対して実行するクエリーで取得するオブジェクト タイプがユーザ オブジェクトでない場合に限り、このサブキー名を使用します。 デフォルト値は(objectCategory=person)。

次の例の基本フィルタでは、無効なユーザを除外します。

(&(objectCategory=person)(objectClass=user)( !(userAccountControl:1.2.840.113556.1.4.803:=2))

(注)     

すべてのフィルタから最後のカッコを削除します。 これは、フィルタのロード方法によるものです。

SearchTimeout

クエリーのタイムアウト時間を秒数で指定します。 デフォルト値は 5 です。

PrimaryServerName

サーバが DNS で検出できない場合は、ディレクトリ アクセスのために接続するプライマリ サーバの FQDN または IP アドレスを指定します。

デフォルトでは、このサブキー名は使用されません。

SecondaryServerName

サーバが DNS で検出できない場合は、ディレクトリ アクセスのために接続するバックアップ サーバの FQDN または IP アドレスを指定します。

デフォルトでは、このサブキー名は使用されません。

Port1

DNS で検出できないプライマリ サーバのポートを指定します。

Port2

DNS で検出できないセカンダリ サーバのポートを指定します。

SearchBase1、SearchBase2、SearchBase3、SearchBase4、SearchBase5

パフォーマンス上の理由から、検索を開始する Active Directory 内の位置を指定する必要がある場合があります。 これを行う必要がある場合は、ツリーの最初の検索可能な組織単位(OU)の値になるようにこのサブキー名を設定します。 デフォルト値はツリーのルートです。

また、その他の検索ベースも指定します。

DisableSecondaryNumberLookups

職場の電話番号が使用できない場合は、連絡先の携帯電話番号、別の電話番号、または自宅の電話番号をユーザが検索できるかどうかを指定します。

次のいずれかの値を入力します。

  • 0:ユーザは、連絡先の携帯電話番号、別の電話番号、または自宅の電話番号を検索できます。
  • 1:ユーザは、連絡先の携帯電話番号、別の電話番号、または自宅の電話番号を検索できません。

デフォルトでは、このサブキー名は使用されません。

PhoneNumberMasks

ユーザが電話番号を検索するときに使用するマスクを設定します。

たとえば、ユーザが +14085550100 からコールを受信し、番号が +(1)408 555 0100 として Active Directory に保存されている場合、次のマスクを設定すると連絡先を見つけることができます。

+1408|+(#) ### ### ####

マスクの文字列の長さに制限はありません。ただし、長さは、レジストリ サブキー名で許可されたサイズを超えることはできません。

一般に、ディレクトリ内の電話番号が +E.164 形式の場合は、電話番号マスクを使用する必要はありません。

UseWildcards

LDAP で電話番号を検索するときにワイルドカード検索を有効にする場合は、この値を 1 に設定します。

このキーを 1 に設定すると、特に検索されるディレクトリ属性がインデックス化されていない場合に、LDAP の検索速度が影響を受ける可能性があります。

ワイルドカードの代わりに、電話番号のマスクを使用できます。

一般に、ディレクトリ内の電話番号が +E.164 形式の場合は、ワイルドカード検索を使用する必要はありません。

UserSearchFields

この値は、ユーザが連絡先を検索するときに検索する Active Directory フィールドを指定するために使用されます。 カンマで区切られた次の値を 1 つまたは複数指定します。

  • DisplayName
  • UserAccountName
  • FirstName
  • LastName

たとえば、管理者がユーザ連絡先検索で同等の Active Directory フィールドを照会する場合は、UserSearchFields キーを UserAccountName,FirstName に設定する必要があります。 上記のフィールドはすべて、値が指定されていない場合に検索されます。

(注)     

管理者が検索をインデックス化されたフィールドに制限する場合は、UserAccountName または FirstName 値の検索対象の Active Directory フィールドをカスタマイズできます。

関連トピック

電話番号マスク

ディレクトリ属性のデフォルト値

ディレクトリ属性のデフォルト値は、標準の Active Directory 属性名です。 つまり、接続先となるディレクトリに Active Directory 属性名とは異なる属性がある場合を除き、ディレクトリ属性の値を設定する必要はありません。

次のレジストリ キーでディレクトリ属性の値を指定します。

[HKEY_CURRENT_USER\Software\Cisco Systems, Inc.\Client Services Framework\Active Directory]

次の表に、ディレクトリ属性、対応するサブキー名、およびデフォルト値を示します。

表 6 ディレクトリ属性のサブキー名のデフォルト値

属性の説明

サブキー名

デフォルト値

共通名

CommonName

cn

表示名

DisplayName

displayName

Firstname

givenName

Lastname

sn

電子メール アドレス

EmailAddress

mail

SIP URI

SipUri

msRTCSIP-PrimaryUserAddress

写真 URI

PhotoUri

photoUri

職場の電話番号

BusinessPhone

telephoneNumber1

携帯電話番号

MobilePhone

mobile

自宅の電話番号

HomePhone

homePhone

その他の電話番号

OtherPhone

otherTelephone

優先電話番号

PreferredNumber

telephoneNumber

タイトル

Title

title

会社名

CompanyName

company

アカウント名

UserAccount

sAMAccountName

ユーザ プリンシパル名

Domain

userPrincipalName

場所

Location

co

ニックネーム

Nickname

mailNickname

郵便番号

PostalCode

postalCode

State

st

番地

StreetAddress

StreetAddress

1 これは、連絡先解決のためのプライマリおよびデフォルトのディレクトリ属性です。 DisableSecondaryNumberLookups キーの値に応じて、連絡先を見つけるためにその他のディレクトリ電話番号属性が使用されることがあります。

追加のディレクトリ属性の設定

拡張ディレクトリ統合を設定する場合は、追加のディレクトリ属性を設定できます。 次のレジストリ キーでディレクトリ属性の値を指定します。

[HKEY_CURRENT_USER\Software\Cisco Systems, Inc.\Client Services Framework\Active Directory]

次の表に、追加のディレクトリ属性、対応するサブキー名、およびデフォルト値を示します。

表 7 追加のディレクトリ属性のサブキー名のデフォルト値

属性の説明

サブキー名

デフォルト値

写真 URI の置換の有効化

PhotoUriSubstitutionEnabled

データ型:REG_DWORD

デフォルトでは、このサブキー名は使用されません。

値の例:True

変数値を持つ写真 URI

PhotoUriWithToken

デフォルトでは、このサブキー名は使用されません。

値の例:http://staffphoto.example.com/sAMAccountName.jpg

可変値を持つ写真 URI に挿入される値

PhotoUriSubstitutionToken

デフォルトでは、このサブキー名は使用されません。

値の例:sAMAccountName

ワイルドカードの使用

UseWildcards

データ型:REG_DWORD

0

電話番号マスク

PhoneNumberMasks

デフォルトでは、このサブキー名は使用されません。

値の例:

+1408|+(#) ### ### ####

インデックス化する必要がある Active Directory 属性

次の Active Directory 属性はインデックス化する必要があります。

  • sAMAccountName
  • displayName
  • mail
  • msRTCSIP-PrimaryUserAddress

連絡先の解決に使用する属性もインデックス化する必要があります。 たとえば、次の属性のインデックスを作成しなければならない場合があります。

  • telephoneNumber
  • 連絡先を見つけるために使用されるその他のディレクトリ電話番号属性(DisableSecondaryNumberLookups キーの値に依存)
  • ipPhone(この属性が環境内で使用されている場合)

設定の質問例


次の表に、拡張ディレクトリ統合(EDI)を使用するように Cisco Unified Client Services Framework を設定する場合の一般的な質問を示します。 この表には、質問に対する答えに応じて実行する必要がある処理も示されています。

表 8 EDI を使用する Client Services Framework の設定に関する質問例

設定に関する質問

設定処理

ディレクトリは DNS で検出できますか。

  • 検出できる場合、ディレクトリはグローバル カタログ(GC)または LDAP サーバのどちらですか。
    • ディレクトリが GC の場合、処理は不要です。
    • ディレクトリが LDAP ディレクトリの場合、ConnectionType サブキー名を 1 に設定します。
  • 検出できない場合、次の操作を実行します。
    • ConnectionType サブキー名を 1 に設定します。
    • PrimaryServerName および Port1 に適切な値を指定します。
    • (任意)BackupServerName および Port2 に適切な値を指定します。 たとえば、ディレクトリが ADAM ディレクトリの場合、これらの値を設定できます。

ディレクトリに接続するときに SSL を使用しますか。

  • 使用する場合、UseSSL サブキー名を 1 に設定します。
  • 使用しない場合、処理は不要です。

ユーザは統合 Windows 認証でディレクトリに接続できますか。

  • 接続できる場合、処理は不要です。
  • 接続できない場合、次のサブキー名の値を設定します。
    • ConnectionUsername
    • ConnectionPassword
(注)     

パスワードは暗号化されずにレジストリに保存されます。 この機能は、既知のアプリケーション アカウントに使用するように設計されています。 アプリケーション アカウントは Cisco Unified Personal Communicator である可能性があり、その場合、Cisco Unified Personal Communicator の各ユーザはユーザ名とパスワードを把握しています。

セキュア接続を確立しますか。

  • 確立する場合、処理は不要です。
  • 確立しない場合、ConnectionSecurity サブキー名を 1 に設定します。 ユーザ名とパスワードを指定しない場合、Client Services Framework は、Active Directory サーバへの匿名バインドを試行します。

簡易バインドを使用しますか。

  • 使用する場合、ConnectionSecurity サブキー名を 1 に設定します。 ユーザ名とパスワードを指定します。 ユーザ名は、識別名(DN)形式にする必要があります。
  • 使用しない場合、処理は不要です。

基本ディレクトリ統合

Cisco Unified Client Services Framework は、基本ディレクトリ統合(BDI)を使用して、Active Directory サーバから連絡先を取得できます。 Cisco Unified Personal Communicator は、IM and Presence サーバにより提供される LDAP プロファイルから LDAP 設定の大部分を取得します。 基本ディレクトリ統合の設定項目のごく一部だけをレジストリ設定で設定できます。

提供される LDAP プロファイルの詳細については、LDAP ディレクトリ統合を参照してください。

拡張および基本ディレクトリ統合の機能の比較で説明されているように、拡張ディレクトリ統合(EDI)には BDI よりも重要な利点があるため、EDI を使用することを推奨します。

Active Directory サーバからの連絡先の取得に BDI を使用する場合に実行する必要がある設定については、電話番号マスクで説明します。

グループ ポリシーの管理用テンプレートは、Cisco Unified Personal Communicator に付属しています。 これらのいずれかのテンプレートを使用して、システムまたはユーザのグループの Client Services Framework レジストリ設定を定義できます。 このタスクを実行する方法については、Active Directory グループ ポリシーの管理用テンプレートを使用した Client Services Framework クライアントの設定を参照してください。

Active Directory グループ ポリシーの管理用テンプレートを使用した Client Services Framework クライアントの設定

グループ ポリシーの管理用テンプレートは、Cisco Unified Personal Communicator に付属しています。 これらのいずれかのテンプレートを使用して、システムまたはユーザのグループの Client Services Framework レジストリ設定を定義できます。

このパッケージに含まれる管理用テンプレートは、Active Directory レベルでグループ ポリシーによって管理されるドメイン ユーザ グループへの展開をサポートします。 グループ ポリシーによって展開されるファイルの名前は Group_Policy です。

提供される管理用テンプレート ファイルは、Windows Server 2003 または 2008 環境をサポートするために使用できます。 使用されるファイルは、Windows Server 環境によって異なります。 これらのファイルは次のとおりです。

手順
    ステップ 1   ADM:ADM ファイルは Windows Server 2003 環境でグループ ポリシー管理に使用されます。 これらは Windows Server 2008 環境で必要に応じて使用できます。
    ステップ 2   ADML/ADMX:ADML/ADMX ファイルは Windows Server 2008 環境でグループ ポリシー管理に使用されます。 これらは Windows Server 2003 との下位互換性はありません。

    ここで説明する手順は、グループ ポリシーを展開するための参照用としてのみ使用してください。 グループ ポリシーの管理プロセスについてまだ十分に理解していない場合は、Microsoft 社から提供される Windows Server 2003 または Windows Server 2008 のマニュアルを参照してください。 このマニュアルは、グループ ポリシー管理の詳細な手順を示しており、展開前に参照する必要があります。

    ここでは、次の手順について説明します。

    (注)     

    レジストリ キーは、ローカル システムにテスト目的で展開できます。


    Windows Server 2003 環境でのグループ ポリシー管理用テンプレートの展開

    Windows Server 2003 環境でグループ ポリシー管理用テンプレートを展開するには、次の手順を使用します。

    手順
      ステップ 1   Active Directory ユーザとコンピュータを起動します。
      ステップ 2   新しいポリシーが適用されるユーザを含むコンテナを参照します。
      ステップ 3   コンテナ プロパティを表示し、[グループ ポリシー(Group Policy)] タブを選択します。
      ステップ 4   目的の名前で新しいグループ ポリシー オブジェクトを作成します。
      ステップ 5   新しいオブジェクトを強調表示し、[編集(Edit)] を選択します。
      ステップ 6   [管理用テンプレート(Administrative Templates)] セクションに新しいテンプレートを追加します。
      ステップ 7   [管理用テンプレート(Administrative Templates)] フォルダを右クリックし、[テンプレートの追加と削除(Add/Remove Templates)] を選択します。
      ステップ 8   目的の ADM ファイルの場所を参照します。
      ステップ 9   ファイルを選択し、[OK] をクリックします。
      ステップ 10   Cisco Unified Client Services Framework または Cisco Unified Personal Communicator という名前のフォルダが [管理用テンプレート(Administrative Templates)] フォルダの下に配置されます。
      ステップ 11   ここから、レジストリ キーを管理したり、選択したアクセス コントロール グループに展開したりします。

      Windows Server 2008 環境でのグループ ポリシー管理用テンプレートの展開

      Windows Server 2008 環境でグループ ポリシーの管理用テンプレートを展開するには、次の手順を使用します。

      手順
        ステップ 1   Active Directory サーバでポリシー定義の場所を参照します。 これらは、通常、C:\Windows\PolicyDefinitions にあります。
        ステップ 2   その場所に目的の ADMX ファイルをコピーします。
        ステップ 3   en-US フォルダを開きます。
        ステップ 4   その場所に目的の ADML ファイルをコピーします。
        ステップ 5   [グループ ポリシーの管理(Group Policy Management)] コンソールを起動します。 これは、通常、スタート メニューの [スタート(Start)] > [すべてのプログラム(All Programs)] > [管理ツール(Administrative Tools)] にあります。
        ステップ 6   ポリシーが適用されるユーザを保持するコンテナを右クリックします。
        ステップ 7   [このドメインに GPO を作成し、このコンテナにリンクします。(Create a GPO in this domain and, Link it here)] を選択します。
        ステップ 8   適切な名前を付けます。
        ステップ 9   [OK] をクリックします。
        ステップ 10   選択したユーザ コンテナを展開します。 ここに、指定した名前で新しく作成された GPO を含める必要があります。
        ステップ 11   GPO オブジェクトを右クリックし、[編集(Edit)] を選択します。
        ステップ 12   [ポリシー(Policies)] フォルダを展開します。
        ステップ 13   [管理用テンプレート(Administrative Templates)] フォルダを展開します。
        ステップ 14   インポートしたポリシー ファイルに応じて、Cisco Unified Client Service Framework または Cisco Unified Personal Communicator という名前のフォルダが配置されます。
        ステップ 15   ここから、レジストリ キーを管理したり、選択したアクセス コントロール グループに展開したりします。

        クライアント マシンのレジストリの場所

        管理用テンプレートが設定され、クライアントにプッシュされると、キー値が次のレジストリの場所に配置されます。

        • オフィス経由のダイヤル設定フォルダに含まれるキー:
          • HKEY_CURRENT_USER\Software\Policies\Cisco Systems, Inc.\Unified Communications\CUPC8
        • 基本ディレクトリ統合に使用されるキー:
          • HKEY_CURRENT_USER\Software\Policies\Cisco Systems, Inc.\Client Services Framework\AdminData
        • 拡張ディレクトリ統合に使用されるキー:
          • HKEY_CURRENT_USER\Software\Policies\Cisco Systems, Inc.\Client Services Framework\Active Directory

        LDAP レジストリ設定

        次の表に、BDI または EDI の LDAP 設定に対して使用できるレジストリ サブキーを示します。 基本ディレクトリ統合(BDI)の代わりに拡張ディレクトリ統合(EDI)を使用する場合は、レジストリ設定の値を指定する必要がない場合があります。

        表 9 LDAP レジストリのサブキー

        サブキー名

        説明

        LDAP_enableWildcardMatches

        ForPhoneNumberSearches

        LDAP で電話番号を検索するときにワイルドカード検索を無効にする場合は、この値を False に設定します。

        このキーを True に設定すると、LDAP の検索速度に影響する場合があります。

        ワイルドカードの代わりに、電話番号のマスクを使用できます。

        一般に、ディレクトリ内の電話番号が +E.164 形式の場合は、ワイルドカード検索を使用する必要はありません。

        LDAP_SearchFields

        ユーザが連絡先を検索するときに検索する Active Directory フィールドを指定します。 スペースで区切られた次の値を 1 つまたは複数指定します。

        • LDAP_AttributeName_UserAccountName
        • LDAP_AttributeName_lastName
        • LDAP_AttributeName_firstName
        • LDAP_AttributeName_displayName

        デフォルトの動作では、これらのすべてのフィールドが検索されます。 これらのフィールドの一部を検索する必要がある場合があります。 たとえば、インデックス化されたフィールドだけを検索する場合があります。

        LDAP_UriSchemeName

        LDAP_AttributeName_uri のサブキー名で指定される値である Active Directory 属性。 通常、この Active Directory フィールド値の前に、スキーム名、たとえば、次のいずれかが付けられます。

        • im:
        • sip:

        スキーム名を使用する場合は、LDAP_UriSchemeName サブキー名のスキーム名を検索で完全一致するように指定する必要があります。

        LDAP_UriSchemeName サブキー名で値を指定しない場合は、ワイルドカード検索が指定されます。 ワイルドカード検索は、特にフィールドがインデックス化されていない場合に、Active Directory のパフォーマンスに悪影響を与えることがあります。

        たとえば、Active Directory フィールド msRTCSIP-PrimaryUserAddress には、sip:mweinstein@example.com 形式の URI が入力されます。推奨設定は次のとおりです。

        • LDAP_AttributeName_uri サブキー名:msRTCSIP-PrimaryUserAddress
        • LDAP_UriSchemeName サブキー名:sip:

        LDAP_AttributeName_uri

        Client Services Framework 検索を Active Directory にマッピングするために使用するレジストリのサブキー。

        一般的な値 = msRTCSIP-PrimaryUserAddress

        LDAP_SearchByUsername

        電話番号や電子メール アドレスに対するボイスメール LDAP 検索を有効または無効にします。 無効にした場合、Unity の電子メール アドレスのユーザ ID が使用されます。

        たとえば、Unity で「calane@cisco.com」としてユーザが設定されている場合、ボイスメールで実行される LDAP 検索は、ユーザ アカウント名「calene」に対して実行されます。電話番号と電子メール アドレスのボイスメール LDAP 検索を無効にし、代わりに Unity の電子メール アドレスのユーザ ID を使用できます。

        「pizza-guy」というボイスメールの連絡先については、電話番号の検索が引き続き実行されます。

        このレジストリ キーは、HKEY_CURRENT_USER\Software\Policies\Cisco Systems, Inc.\Client Services Framework\AdminData にある文字列値です。 この機能を有効にするにはキーを True に設定し、無効にするには False に設定します。 デフォルトは False です。

        LDAP_DisableSecondaryNumber

        Lookups

        職場の電話番号が使用できない場合は、連絡先の携帯電話番号、別の電話番号、または自宅の電話番号をユーザが検索できるかどうかを指定します。

        次のいずれかの値を入力します。

        • 0:ユーザは、連絡先の携帯電話番号、別の電話番号、または自宅の電話番号を検索できます。
        • 1:ユーザは、連絡先の携帯電話番号、別の電話番号、または自宅の電話番号を検索できません。 デフォルトでは、このサブキー名は使用されません。

        EnableNativeDirectoryProvider

        Active Directory から連絡先情報を取得するために拡張ディレクトリ統合を使用するか基本ディレクトリ統合を使用するかを指定します。 次のいずれかの値を入力します。

        • 0:基本ディレクトリ統合を使用します。 これがデフォルト値です。
        • 1:拡張ディレクトリ統合を使用します。 データ型:REG_SZ

        LDAP_PhoneNumberMask(BDI)/PhoneNumberMasks(EDI)

        ユーザが電話番号を検索するときに使用するマスクを設定します。

        たとえば、ユーザが +14085550100 からコールを受信し、番号が +(1)408 555 0100 として Active Directory に保存されている場合、次のマスクを設定すると連絡先を見つけることができます。

        +1408|+(#) ### ### ####

        マスクの文字列の長さに制限はありません。ただし、長さは、レジストリ サブキー名で許可されたサイズを超えることはできません。

        一般に、ディレクトリ内の電話番号が +E.164 形式の場合は、電話番号マスクを使用する必要はありません。

        LDAP_DisableNumberLookups

        ユーザ連絡先リストまたは通信履歴にない番号に対して着信コールを受信するか、発信コールが行われると、ディレクトリ内のその番号を検索するための LDAP クエリーが実行されます。 一致が見つかると、クライアントはこの番号に関する連絡先情報を表示できます。 この検索は、このレジストリ キーを false に設定して無効にすることができます。 これにより、すべての電話番号の検索が無効になります。 この値が false に設定されている場合、クライアントは、着信番号または発信番号の連絡先情報を表示できません。

        ディレクトリ属性のデフォルト値は、標準の Active Directory 属性名です。 ディレクトリ属性は、EDI を使用する場合およびデフォルト値で不十分な場合にのみレジストリで設定します。 BDI は、IM and Presence サーバにより提供される LDAP プロファイル値を使用します。

        次の表に、ディレクトリ属性およびデフォルト値を示します。

        表 10 ディレクトリ属性値

        ディレクトリ属性

        BusinessPhone

        会社の電話番号属性(デフォルト値:「telephoneNumber」)

        CommonName

        共通名属性(デフォルト値:「cn」)

        CompanyName

        会社名属性(デフォルト値:「company」)

        DisplayName

        表示名属性(デフォルト値:「displayName」)

        DomainName

        ドメイン名属性(デフォルト値:「userPrincipalName」)

        EmailAddress

        電子メール アドレス属性(デフォルト値:「mail」)

        Firstname

        名属性(デフォルト値:「givenName」)

        HomePhone

        自宅の電話番号属性(デフォルト値:「homePhone」)

        Lastname

        姓属性(デフォルト値:「sn」)

        Location

        場所属性(デフォルト値:「co」)

        MobilePhone

        携帯電話番号属性(デフォルト値:「mobile」)

        Nickname

        ニックネーム属性(デフォルト値:「mailNickname」)

        OtherPhone

        別の電話番号属性(デフォルト値:「otherTelephone」)

        PhotoUri

        写真 URI 属性(デフォルト値:「photoUri」)

        PostalCode

        郵便番号属性(デフォルト値:「postalCode」)

        PreferredNumber

        優先電話番号属性(デフォルト値:「telephoneNumber」)

        SipUri

        IP URI 属性(デフォルト値:「msRTCSIP-PrimaryUserAddress」)

        State

        状態属性(デフォルト値:「st」)

        StreetAddress

        住所属性(デフォルト値:「streetAddress」)

        Title

        タイトル属性(デフォルト値:「title」)

        UserAccount

        ユーザ アカウント名属性(デフォルト値:「sAMAccountName」)

        電話番号マスク

        Cisco Unified Personal Communicator で電話番号を Active Directory から検索するときに使用するマスクを設定できます。

        コールを発信すると、Cisco Unified Personal Communicator は Active Directory を検索して、電話番号に対応する連絡先情報を取得することがあります。 コールを受信すると、Cisco Unified Personal Communicator は Active Directory を検索して、電話番号を連絡先名に解決することがあります。 Active Directory の電話番号が +E.164 形式でない場合は、これらの検索で Active Directory のユーザに解決できない場合があります。 この問題に対処するために、検索にマスクを適用できます。

        たとえば、ユーザが +14085550100 からコールを受信し、番号が +(1)408 555 0100 として Active Directory に保存されている場合、次のマスクを設定すると連絡先を見つけることができます。

        +1408|+(#) ### ### ####

        マスクは、Active Directory で番号が検索される前に番号に適用されます。 マスクを正しく設定すると、ディレクトリ検索は、完全一致検索として成功します。 したがって、これらの検索では、ディレクトリ サーバのパフォーマンスへの影響が最小限に抑えられます。

        一般に、ディレクトリ内の電話番号が +E.164 形式の場合は、電話番号マスクを使用する必要はありません。 拡張ディレクトリ統合(EDI)または基本ディレクトリ統合(BDI)で電話番号マスクを使用できます。

        電話番号マスクの要素

        次の表に、マスクに含めることができる要素を示します。

        要素

        説明

        電話番号パターン

        マスクを適用する番号パターンを指定する必要があります。 たとえば、+1408 で始まる検索のマスクを指定するには、次のマスクを使用できます:

        +1408|+(#) ### ### ####

        マスクを適用する番号パターンを指定する場合は、同じ桁数の複数のマスクを使用できます。 これにより、異なる企業サイトの電話番号が同じ桁数でパターンが異なるシナリオをマスクで処理できます。

        たとえば、企業にサイト A とサイト B があり、各サイトで独自のディレクトリ情報を保持しているとします。 次のような 2 つの番号形式になる可能性があります。

        +(1) 408 555 0100

        +1-510-5550101

        このシナリオで、12 桁の +E.164 番号を正しく解決するには、電話マスクを次のように設定できます。

        +1408|+(#) ### ### ####|+1510|+#-###-#######

        パイプ記号(「|」)

        次の例に示すように、パイプ記号で番号パターンとマスクのペアを区切ります。

        +1408|+(#) ### ### ####|+34|+(##) ### ####

        検索で複数のマスクを追加する場合、各マスクに異なる番号パターンが必要です。

        Cisco Unified Personal Communicator で電話番号を Active Directory から検索する場合、1 つのマスクだけが検索前に電話番号に適用されます。 電話番号が複数の番号パターンに一致する場合、電話番号のより多くの桁に一致する番号パターンが選択され、関連するマスクが適用されます。

        ワイルドカード文字

        マスクでワイルドカード文字を使用することもできます。 1 つ以上の文字を表すにはアスタリスク(*)を使用します。 たとえば、マスクを次のように設定できます。

        +3498|+##*##*###*####

        Cisco Unified Personal Communicator が +E.164 形式の番号 +34985550199 を Active Directory で検索すると、ディレクトリに次のいずれかの形式が見つかります。

        +34(98)555 0199

        +34 98 555-0199

        +34-(98)-555.0199

        逆マスク

        逆マスクを使用することもできます。 逆マスクは右から左に適用されます。 マスクと電話番号のパターンは、右から左に検討され、電話番号から桁をコピーするかどうかを判断するためにマスクの各文字がチェックされます。

        Cisco Unified Personal Communicator が Active Directory を検索するときに次の両方を行う場合は、逆マスクを使用します。

        • 電話番号の先頭の数字の一部を変更する。
        • ディレクトリ形式と一致するように番号をフォーマットする。

        たとえば、逆マスクを次のように設定できます。

        +3498|R+34 (98) 559 ####

        このマスクを +34985550199 に適用した場合、結果は +34(98)559 0199 です。

        順方向および逆方向のマスクを組み合わせて使用できます。

        マスクを指定するためのサブキー名

        EDI および BDI の電話番号検索マスクの場所は、次のように指定します。

        ディレクトリ統合のタイプ

        このマスクを設定するサブキー名

        拡張ディレクトリ統合(EDI)

        [HKEY_CURRENT_USER\Software\Cisco Systems, Inc.\Client Services Framework\Active Directory] の PhoneNumberMasks

        基本ディレクトリ統合(BDI)

        [HKEY_CURRENT_USER\Software\Cisco Systems, Inc.\Client Services Framework\AdminData] の LDAP_PhoneNumberMask

        連絡先写真の取得

        Cisco Unified Client Services Framework は、次のように連絡先の写真情報を取得できます。

        • (拡張ディレクトリ統合のみ)Active Directory からバイナリ写真を取得します。
        • (基本および拡張ディレクトリ統合)Active Directory から静的 URL を取得します。
        • (拡張ディレクトリ統合のみ)Active Directory から動的に作成された URL を取得します。

        Active Directory からのバイナリ写真の取得

        写真は Active Directory にバイナリ オブジェクトとして保存されます。 Cisco Unified Client Services Framework は PhotoUri 設定で定義されるディレクトリ属性の属性内容を取得します。

        拡張ディレクトリ統合(EDI)は、返された属性の内容を解析します。 属性にバイナリ データが含まれている場合、内容は JPEG 写真として表示されます。 属性に URL が含まれている場合、写真は URI から取得されます。

        ディレクトリ ユーザ オブジェクトに thumbnailphoto 属性設定に保存されている写真があり、Cisco Unified Client Services Framework でこのフィールドから写真を取得する場合は、PhotoUri を thumbnailphoto に設定します。 また、Active Directory の jpegPhoto 属性にも写真を保存できます。

        Microsoft Lync と Microsoft Outlook も、thumbnailphoto バイナリ属性を使用して写真を取得します。

        Active Directory からの静的 URL の取得

        拡張ディレクトリ統合と基本ディレクトリ統合の両方で、Active Directory から写真を指し示す静的 URL を取得できます。

        拡張ディレクトリ統合(EDI)は、返された属性の内容を解析します。 属性にバイナリ データが含まれている場合、内容は JPEG 写真として表示されます。 属性に URL が含まれている場合、写真は URI から取得されます。 たとえば、属性には次のような構造の URL が含まれている場合があります。

        http://staffphoto.example.com/mweinstein.jpg

        Active Directory に保存される文字列は、写真の場所を指す静的 URI 文字列です。


        (注)  


        基本的なディレクトリ属性マップでは、属性名に異なる設定を使用します。 写真属性が PhotoUri という名前の Active Directory フィールドに格納されていない場合、EDI の PhotoUri を入力する必要があります。


        Active Directory からの動的 URL の取得

        別のディレクトリ属性に基づいて写真 URL を動的に構築するように EDI を設定できます。 写真 URL は基本 URL および代替トークンから構成されます。

        たとえば、組織でスタッフの写真の Web サーバを維持し、写真のファイル名がユーザ アカウント名と一致する場合、次の設定を作成できます。

        設定

        UserAccount

        sAMAccountName

        PhotoUri

        http://staffphoto.example.com/PHOTONAME.jpg

        PhotoUriSubstitutionEnabled

        true

        PhotoUriSubstitutionToken

        PHOTONAME

        文字列 PHOTONAME の値は、AccountName 設定で指定されるディレクトリ属性に置き換えられます。 上記の設定を使用すると、sAMAccountName が mweinstein のユーザの場合、次の URL になります:

        http://staffphoto.example.com/mweinstein.jpg