シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。 ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。 シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
この資料は複数のフォレスト環境の Cisco Unified 通信マネージャ(CUCM)ディレクトリ統合を設定する方法を説明します。
Cisco では次の前提を満たす推奨しています。
このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。
以前アダムとして知られている Microsoft AD LDS が、ディレクトリ対応アプリケーションにディレクトリ サービスを提供するのに使用することができます。 ディレクトリ対応 適用業務 データを保存するために組織のアクティブ ディレクトリ ドメイン サービス(AD DS)データベースを使用するかわりに AD LDS がデータを保存するのに使用することができます。 アプリケーション 設定およびディレクトリ データ(AD LDS)をサポートするためにセキュリティ アカウント(AD DS)および別の位置のためのセントラルロケーションがあることができるように AD LDS は AD DS と共に使用することができます。 AD LDS を使うと、AD 複製を使うと関連付けられるオーバーヘッドを減らすことができますアプリケーションをサポートするために AD スキーマを伸ばす必要がないし AD LDS サービスがディレクトリ対応 アプリケーションをサポートする必要があるサーバにだけ展開されるように配分しましたディレクトリ構造をできます。
アダム間に多くの違いがあり、AD は、アダム AD によって提供される機能の一部しか渡さないことができます。
この資料の目標は、ですユーザ情報を得、異なるフォレストにあることができる異なる AD ドメインから認証を行うためにメカニズムを CUCM を可能にする、またはディレクトリ統合サービス(DirSync)を利用するその他のCisco製品を説明すること。 この目標を達成するために、アダムは異なる AD ドメインコントローラか他の LDAP ソースとユーザデータベースを同期するために使用されます。
アダムはユーザのデータベースを作成し、詳細を保存できます。 (SSO)機能性の単一 サインは異なるシステムの資格情報の異なるセットを維持しなければなっていないエンドユーザを避けるために望まれます; 従って、アダム バインド リダイレクションは使用されます。 アダム バインド リダイレクションは認証機構として LDAP バインドをサポートするアプリケーションのための特殊関数です。 場合によっては、特別なスキーマ、かコンテキストを指名することは、アダムに必要な選択をする AD を避けさせますかもしれません。 これは自身のユーザ ID およびパスワードで追加ディレクトリの雇用による複数のパスワードを覚えなければなっていないユーザを避けます。
規則的な AD ユーザアカウントへのアダム マップの特別 な ユーザ プロキシ オブジェクト。 ユーザ プロキシにアダム オブジェクトで保存される実際のパスワード自体がありません。 アプリケーションが正常なバインド操作を行うとき、ID をローカルでチェックしますが、AD に対して送付の下でこの図に示すようにパスワードを確認します。 アプリケーションはこの AD 相互対話に気づく必要はありません。
アダム バインド リダイレクションはアプリケーションがアダムに簡単な LDAP バインドを行うことができるところに特別な場合にだけ使用する必要があります。 ただし、アプリケーションは依然として AD のセキュリティ プリンシパルとユーザを関連付ける必要があります。
アダム バインド リダイレクションはアダムへのバインドがプロキシ オブジェクトと呼ばれる特別なオブジェクトの使用と試みられるとき発生します。 プロキシ オブジェクトは AD のセキュリティ プリンシパルを表すアダムのオブジェクトです。 アダムの各プロキシ オブジェクトは AD でユーザの SID が含まれています。 ユーザがプロキシ オブジェクトに結合 するように試みるときアダムはバインド時に供給される保存され、認証のための AD に SID およびパスワードを示すパスワードとともにプロキシ オブジェクトで、SID を奪取 します。 アダムのプロキシ オブジェクトはパスワードを保存しないし、ユーザはアダム プロキシ オブジェクトを通して AD パスワードを変更できません。
パスワードはアダムに平文で最初のバインド要求が簡単な LDAP バインド要求であるので示されます。 従って、ディレクトリ クライアントとアダムの間で SSL 接続がデフォルトで必要となります。 アダムは AD にパスワードを示すために Windows セキュリティ API を使用します。
アダム バインド リダイレクションの理解のバインド リダイレクションに関する詳細を得ることができます。
方式を説明するために、シスコシステムズ シナリオを想像して下さい(フォレストは 2) 2 人の他の会社を得ました: Tandberg (フォレスト 3)および WebEx (1)フォレスト。 移行フェーズでは、単一 Cisco Unified Communications クラスタの配備を可能にするために各会社の AD 構造を統合。
例では、会社 Cisco (フォレストに 2) 2 つのドメイン、フォレスト ルート ドメイン呼出された CISCO (dns cisco.com)および緊急事態(dns emerg.cisco.com と呼ばれるサブドメインがあります)。 両方のドメインにまたグローバル な カタログである、各自は Windows 2008 サーバ SP2 でホストされますドメインコントローラがあり。
会社 Tandberg (森林に 3)またグローバル な カタログである、Windows 2008 サーバ SP2 でホストされますドメインコントローラが付いている単一 ドメインがあり。
会社 WebEx (森林に 1)またグローバル な カタログである、Windows 2003 R2 サーバ SP2 でホストされますドメインコントローラが付いている単一 ドメインがあり。
AD LDS はドメイン CISCO のためのドメインコントローラにインストールされているか、または個別のマシンである場合もあります; 実際それは 3 つのフォレストの 1 つにどこでもある可能性があります。 DNS インフラストラクチャは 1 つのフォレストのドメインが他のフォレストのドメインと通信し、フォレスト間の適切なトラスト 関係および有効性確認を確立できることきちんと整う必要がありますそのような物。
はたらくユーザの認証に関してはアダム例がホストされる、とユーザアカウントをホストする他のドメイン必要がありますドメイン間の信頼がある。 この信頼は必要であれば一方向信頼である場合もあります(ユーザアカウントをホストする)ドメインにアダム例をホストするドメインからの発信信頼。 こうすればは、アダム例それらのアカウント ドメインの DC に認証要求を転送できます。
なお、アカウント ドメイン ドメインですべてのユーザアカウントのすべての属性にアクセスできる両方からのユーザアカウントがある必要があります。 このアカウントは ADAMSync によってアダムにアカウント ドメイン ユーザを同期するために使用されます。
大事なことを言い忘れたが、アダムを実行するマシンはすべてのドメイン(DNS)を見つけ、両方のドメインでドメインコントローラを(DNS と)見つけ、これらのドメインコントローラに接続できる必要があります。
intertrust 関係を設定するためにこれらのステップを完了して下さい:
これは Tandberg および WebEx ドメイン両方のためのこのプロセスを実行した後受け取る結果です。 ドメイン緊急事態はそれが子ドメインであるのでデフォルトでそこにあります。 [OK] をクリックします。
アクティブ ディレクトリ軽量ディレクトリ サービス チェックボックスをチェックして下さい。 [Next] をクリックします。
2012 年に AD LDS を設定するためにこれらのステップを完了して下さい:
AD LDS は同じマシンで動作するべき異なるユーザー ディレクトリ「アプリケーション」を可能に異なるポートとサービスの異なるインスタンスを実行できます。 デフォルトで AD LDS は 389/LDAP および 636/LDAPS を『Ports』 を選択 します、システムが既に持っていればそれらをそれ実行するどの種類の LDAP サービスでもポート 50000/LDAP および 50001/LDAPS を使用します。 各例に使用される前の数に基づいて増分するポートのペアがあります。
場合によっては、Microsoft 不具合が原因で、ポートは Microsoft DNSサーバによって既に使用され、例 ウィザードは(自ら明らかではない)エラー与えます。 このエラーは TCP/IPスタックのポートを予約するとき固定である場合もあります。 この問題を見つける場合、AD LDS がエラー「セットアップとサービス開始するサービスを開始できなかった…」失敗することを参照して下さい + エラー コード 8007041d。
注: CUCM は一つのアプリケーション ディレクトリの配分だけ、マルチ パーティション現在サポートされませんサポートします。
ステップ 5 を参照して下さい: アプリケーション ディレクトリの配分を作成する方法の情報のためのアプリケーション ディレクトリの配分によってフィールド ワーク。 作業に対して同期したいと思う各ドメインのためのディレクトリの配分を作成するプロセスは LDAP 紹介(RFC 2251)に基づき、LDAP クライアント(CUCM、コップ、等)が紹介をサポートすることを必要とします。
Yes をクリックして下さい、アプリケーション ディレクトリの配分 オプション ボタンを作成して下さい。 例のための Partition Name フィールドでパーティション名を入力して下さい。 ほとんどの場合それがスキーマのエラーを作成するので、ウィザードの例ののような cn を提供しないで下さい。 このシナリオでは、ホスト AD LDS (dc=Cisco、dc=com)が入った AD ドメインコントローラと同じパーティション。 [Next] をクリックします。
現在ログオンされた Userオプション・ボタンをクリックして下さい。 管理許可のユーザの名前を入力して下さい。 [Next] をクリックします。
注: アダムがで Windows 2003 インストールされていたら断絶して下さい、前の画面に 4 つのオプションだけあります: MSAZMan.LDF、MSInetOrgPerson.LDF、MSUser.LDF および MSUserProxy.LDF。 この 4 から、MSUser.LDF および MSInetOrgPerson.LDF があるようにチェックボックスだけ確認して下さい。
注: CUCM は一つのアプリケーション ディレクトリの配分だけ、マルチ パーティション現在サポートされませんサポートします。
ステップ 5 を参照して下さい: アプリケーション ディレクトリの配分を作成する方法の情報のためのアプリケーション ディレクトリの配分によってフィールド ワーク。 作業に対して同期したいと思う各ドメインのためのディレクトリの配分を作成するプロセスは LDAP 紹介(RFC 2251)に基づき、LDAP クライアント(CUCM、コップ、等)が紹介をサポートすることを必要とします。 詳細についてはマイクロソフトのサポートを参照して下さい。
Yes をクリックして下さい、アプリケーション ディレクトリの配分 オプション ボタンを作成して下さい。 パーティション名を入力して下さい。 cisco.com として LDS のためのパーティションを作成して下さい。 どの適した値でも提供することができます。 [Next] をクリックします。
ユーザー ID (sAMAccountNames)が異なるドメインを渡ってユニークで、そこに異なるフォレストの異なるドメインの同じ ID の複数のユーザではない場合、ユーザは AD からマルチ フォレスト セットアップの AD LDS の一つのパーティションにあることができる AD LDS のそれぞれフォレストへの同期することができます。 たとえば 3 つのドメインの 1 だけで存在 して いたら ユーザ ID 「アリス」がこのシナリオのセットアップ次の通りだった場合、CUCM セクションのアクティブ ディレクトリ多重フォレスト サポート シナリオの図を、考慮すれば:
パーティション フォレスト DN
P1 cisco.com DC=cisco、DC=com
webex.com DC=webex、DC=cisco、DC=com
tandberg.com DC=Tandberg、DC=cisco、DC=com
CUCM を AD LDS で設定するために、ユーザ ID (sAMAccountName)はすべてのフォレストを渡ってユニークである必要があります。 CUCM は現在 AD LDS の一つのパーティションだけサポートします。
sAMAccountNames がユニークではない場合、ユーザアカウントを-電子メール、telephoneNumber、employeeNumber、uid、または userPrincipalName 識別する場合のこれらの属性利用することを考えて下さい。
利用可能 な オプションは生成される必要があるファイルの編成を助けるためにこれらのファイルが c:\windows\adam 主要なディレクトリから分かれることができるように可能にするために別 の ディレクトリを作成することです。 コマンド プロンプトを開き、c:\windows\adam のログ ディレクトリを作成して下さい。
cd \windows\adam
mkdir logs
ldifde -i -s localhost:50000 -c CN=Configuration,DC=X
#ConfigurationNamingContext -f diff-schema.ldf -j c:\windows\adam\logs
参照しま追加 ldifde オプションおよびコマンド形式のためのアクティブ ディレクトリへのディレクトリ オブジェクトをインポートし、エクスポートするのに LDIFDE を使用します。
プロキシ認証のためのオブジェクトは作成される必要があり、オブジェクト クラスのユーザは」使用されません。 作成されるオブジェクト クラスは、userProxy、バインド リダイレクションを可能にするものがです。 オブジェクト クラス詳細は ldif ファイルで作成される必要があります。 ファイルはこの例の MSUserProxy Cisco.ldf の新しいファイルの作成です。 この新しいファイルはオリジナル MSUserProxy.ldf から生成され、編集される、テキストをこのコンテンツを持つために編集しますプログラムを、使用して下さい:
#==================================================================
# @@UI-Description: AD LDS simple userProxy class.
#
# This file contains user extensions for default ADAM schema.
# It should be imported with the following command:
# ldifde -i -f MS-UserProxy.ldf -s server:port -b username domain password -k -j . -c
"CN=Schema,CN=Configuration,DC=X" #schemaNamingContext
#
#==================================================================
dn: CN=User-Proxy,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaAdd
objectClass: top
objectClass: classSchema
cn: User-Proxy
subClassOf: top
governsID: 1.2.840.113556.1.5.246
schemaIDGUID:: bxjWYLbzmEiwrWU1r8B2IA==
rDNAttID: cn
showInAdvancedViewOnly: TRUE
adminDisplayName: User-Proxy
adminDescription: Sample class for bind proxy implementation.
objectClassCategory: 1
lDAPDisplayName: userProxy
systemOnly: FALSE
possSuperiors: domainDNS
possSuperiors: organizationalUnit
possSuperiors: container
possSuperiors: organization
defaultSecurityDescriptor:
D:(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)S:
defaultHidingValue: TRUE
defaultObjectCategory: CN=User-Proxy,CN=Schema,CN=Configuration,DC=X
systemAuxiliaryClass: msDS-BindProxy
systemMayContain: userPrincipalName
systemMayContain: givenName
systemMayContain: middleName
systemMayContain: sn
systemMayContain: manager
systemMayContain: department
systemMayContain: telephoneNumber
systemMayContain: mail
systemMayContain: title
systemMayContain: homephone
systemMayContain: mobile
systemMayContain: pager
systemMayContain: msDS-UserAccountDisabled
systemMayContain: samAccountName
systemMayContain: employeeNumber
systemMayContain: initials
systemMayContain: ipPhone
systemMayContain: displayName
systemMayContain: msRTCSIP-primaryuseraddress
systemMayContain: uid
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
C:\windows\adam の MSUserProxy Cisco.ldf ファイルを保存して下さい。
AD LDS に新しいオブジェクト クラスをインポートして下さい。
ldifde -i -s localhost:50000 -c CN=Configuration,DC=X #ConfigurationNamingContext -f
MS-UserProxy-Cisco.ldf -j c:\windows\adam\logs
各ドメインからユーザは今 AD LDS にインポートされる必要があります。 このステップは同期する必要がある各ドメインのために繰り返される必要があります。 この例はドメインの 1 つに対してだけプロセスを表示したものです。 オリジナル MSAdamSyncConf.xml から開始し、同期される必要がある作成し、このコンテンツを持つために各ドメインに特定の詳細とのファイルを修正して下さい各ドメインのための XML ファイルを:
<?xml version="1.0"?>
<doc>
<configuration>
<description>Adam-Sync1</description>
<security-mode>object</security-mode>
<source-ad-name>ad2k8-1</source-ad-name>
<source-ad-partition>dc=cisco,dc=com</source-ad-partition>
<source-ad-account></source-ad-account>
<account-domain></account-domain>
<target-dn>dc=cisco,dc=com</target-dn>
<query>
<base-dn>dc=cisco,dc=com</base-dn>
<object-filter>
(|(&(!cn=Administrator)(!cn=Guest) (!cn=ASPNET)
(!cn=krbtgt)(sAMAccountType=805306368))(&(objectClass=user)(isDeleted=TRUE)))
</object-filter>
<attributes>
<include>objectSID</include>
<include>mail</include>
<include>userPrincipalName</include>
<include>middleName</include>
<include>manager</include>
<include>givenName</include>
<include>sn</include>
<include>department</include>
<include>telephoneNumber</include>
<include>title</include>
<include>homephone</include>
<include>mobile</include>
<include>pager</include>
<include>msDS-UserAccountDisabled</include>
<include>samAccountName</include>
<include>employeeNumber</include>
<include>initials</include>
<include>ipPhone</include>
<include> displayName</include>
<include> msRTCSIP-primaryuseraddress</include>
<include>uid</include>
<exclude></exclude>
</attributes>
</query>
<user-proxy>
<source-object-class>user</source-object-class>
<target-object-class>userProxy</target-object-class>
</user-proxy>
<schedule>
<aging>
<frequency>0</frequency>
<num-objects>0</num-objects>
</aging>
<schtasks-cmd></schtasks-cmd>
</schedule>
</configuration>
<synchronizer-state>
<dirsync-cookie></dirsync-cookie>
<status></status>
<authoritative-adam-instance></authoritative-adam-instance>
<configuration-file-guid></configuration-file-guid>
<last-sync-attempt-time></last-sync-attempt-time>
<last-sync-success-time></last-sync-success-time>
<last-sync-error-time></last-sync-error-time>
<last-sync-error-string></last-sync-error-string>
<consecutive-sync-failures></consecutive-sync-failures>
<user-credentials></user-credentials>
<runs-since-last-object-update></runs-since-last-object-update>
<runs-since-last-full-sync></runs-since-last-full-sync>
</synchronizer-state>
</doc>
このファイルではドメインを一致するために、これらのタグは取り替える必要があります:
<object-filter> を作成する方法に関する詳細については検索フィルタ構文を参照して下さい。
C:\windows\adam の新しく作成された XML ファイルを保存して下さい。
コマンド ウィンドウを、cd \ウィンドウ\アダム開いて下さい。
コマンドを、ADAMSync /install localhost:50000 c:\windows\ADAM\AdamSyncConf1.xml /log c:\windows\adam\logs\install.log 入力して下さい。
ファイル AdamSyncConf1.xml が新しく作成された XML ファイルであることを確認して下さい。
コマンド ADAMSync /sync localhost:50000 「dc=cisco でユーザを、dc=com」/log c:\windows\adam\logs\sync.log 同期して下さい。
結果は類似したにであるはずです:
AD からアダムに自動同期化を完了するために、Windows でタスク スケジューラを使用して下さい。
それのこのコンテンツで .bat ファイルを作成して下さい:
「C:\Windows\ADAM\ADAMSync」/install localhost:50000 c:\windows\ADAM\AdamSyncConf1.xml /log c:\windows\adam\logs\install.log
「C:\Windows\ADAM\ADAMSync」/sync localhost:50000 「dc=cisco、dc=com」/log c:\windows\adam\logs\syn.log
必要とされる場合 .bat ファイルを実行するためにタスクをスケジュールして下さい。 これ付加、アダムに同様に反映されるべき AD で起こる修正および削除は処理します。
別の .bat ファイルを作成し、他のフォレストからの自動同期化を完了するためにそれをスケジュールできます。
デフォルトでは、バインド リダイレクトを使用した ADAM へのバインドには SSL 接続を必要とします。 SSL はアダムを実行するとクライアントとしてアダムに接続するコンピュータの認証のインストールおよび使用を必要としますコンピュータ。 ADAM テスト環境に証明書がインストールされていない場合は、代替手段として、SSL の要件をディセーブルにすることができます。
デフォルトで、SSL は有効に なります。 認証を生成する必要がある ADAM/LDS の LDAPS プロトコル作業を作るため。
この例では認証を発行するために、Microsoft 認証局 サーバは使用されます。 認証を要求するために、Microsoft CA の Webページに- http:// <MSFT CA ホスト名 >/certsrv 行き、これらのステップを完了して下さい:
認証局 (CA) インターフェイスに戻り、保留中の認証 フォルダをクリックして下さい。 ADAM/AD-LDS マシンによってなされる証明書要求を右クリックし、認証を発行して下さい。
認証は今作成され、「発された認証」フォルダに常駐します。 次に、認証をダウンロードし、インストールする必要があります:
アダムを使用を保守することを許可するために認証、アダム サービスの個人的なストアに認証を置く必要があります:
サーバ認証証明の読み取り権限をネットワーク サービス アカウントに与えるために、これらのステップを完了して下さい:
詳細は付録 A で見つけることができます: AD LDS のための SSL 必要条件上の LDAP の設定。
次に、ADAM/AD LDS マシンに認証をように CUCM ディレクトリ信頼発行した CA の認証をアップロードして下さい。
追加詳細については Cisco Unified Communications オペレーション システム管理ガイドを参照して下さい。
LDAP で SSL を使用するためにチェックボックスを Directory ページおよび LDAP認証 ページ選択して下さい。
ADAM/AD LDS 例をインストールしたときに与えられる SSL ポート番号である LDAP ポートのための 50001 を(この例で)入力して下さい。
バインド リダイレクションのための SSL 要件をディセーブルにするために、これらのステップを完了して下さい:
ADAM/AD LDS 同期および認証は CUCM バージョン 9.1(2) および それ 以降でサポートされます。
uid はスタンドアロン ADAM/AD LDS とない AD 複数のフォレスト サポートとだけ使用されます。
現在、LDAPサーバ型「Microsoft アダムまたは軽量ディレクトリ サービス」モードのために、samAccountName はドロップダウン USERID のための LDAP アトリビュートに含まれていません。 原因はそれがスタンドアロン ADAM/AD LDS でサポートされるアトリビュートではないことです。 協定が AD で設定する必要がある sAMAccountName にマッピング される CUCM USERID が使用される必要があれば。
オブジェクト クラス ユーザはもはや使用されません。 従ってユーザの代りに userProxy を使用するために、LDAP フィルタは変更される必要があります。
既定フィルターは次のとおりです:
(及び(objectclass=user) (! (objectclass=Computer))(! (msDS-UserAccountDisabled=TRUE)))
このフィルタ、ログインを Webブラウザの CCMAdmin に修正し、LDAP カスタム フィルタオプションを LDAP設定 メニューから選択するため。
このフィルタは Directory ページ LDAP で LDAP を同期一致前の図に示すように設定している間使用されます。