はじめに
このドキュメントでは、Lightweight Directory Access Protocol(LDAP)をCisco Meeting Server(CMS)と統合する手順を追って説明します。
前提条件
要件
次の項目に関する知識があることを推奨しています。
使用するコンポーネント
このドキュメントの情報は、CMS 3.0に基づくものです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
このドキュメントでは、CMSとのLDAP統合を扱う多くのトピックに焦点を当てています。また、CMS GUIのConfiguration > Active DirectoryからAPIにActive Directoryの設定を移行する手順についても説明します。
注:CMSでサポートされているLDAPサーバは、Microsoft Active Directory、OpenLDAP、Directory LDAP3、およびOracle Internet Directoryのみです。
注:Web GUIでのLDAP設定は、CMSの今後のリリースで削除される可能性があります。
設定
WebインターフェイスでLDAP設定を設定する唯一のシナリオは、CMSにインポートする単一のLDAPソースがある場合です。
注:CMSの今後のリリースでは、Web GUIからActive Directoryを削除できます。
Active Directoryサーバの設定
次のコマンドを使用して、LDAPサーバへの接続を設定します。
アドレス |
これは、LDAPサーバのホスト名またはIPアドレスです。 |
ポート |
Unsecureの場合は389、Secure Connectionの場合は636(Secure Connectionチェックボックスをオンにする必要がある) |
ユーザ名 |
登録ユーザの識別名(DN)。次のものを作成できます。 この目的に特化したユーザ。例: cn=Tyler Evans,cn=Users,OU=Engineering,dc=YourCompany,dc=com |
Password |
使用しているユーザ名のパスワード |
セキュアな接続 |
ポート636を使用する場合は、このボックスをオンにします |
設定のインポート
インポート設定を使用して、インポートするユーザを制御します。
ベースの識別名 |
ユーザのインポート元となるLDAPツリー内のノード。 この例は、ベースDNがユーザをインポートするための適切な選択です |
例: cn=Users,dc=sales,dc=YourCompany,dc=com |
フィルタ |
ユーザLDAPの属性値によって満たされる必要があるフィルタ式 録音します。Filterフィールドの構文は、rfc4515で説明されています。 |
例:mail=* |
フィールドマッピング式
フィールドマッピング式は、Meeting Serverユーザレコードのフィールド値を、対応するLDAPレコードのフィールド値からどのように構築するかを制御します。
表示名 |
ユーザ名 |
スペース名(Space Name)) |
スペース URI ユーザ パート(Space URI user part) |
セカンダリスペースURIユーザパーツ |
スペース コール ID(Space Call ID) |
復元力と拡張性の高い導入
API内でLDAPを設定する必要があるシナリオは2つあります。1つ目のシナリオは、3つ以上のノードで構成されるクラスタ展開がある場合で、2つ目のシナリオは、ユーザのインポート元となるLDAPソースが複数ある場合です。
WebインターフェイスAPI
CMS > Configuration > APIのWeb Adminにログインして、API Web Interfaceに移動します。ここでは、すべてのAPI設定を行います。
LDAP APIオブジェクト
APIに移動した後、フィルタバーに「ldap」と入力すると、作成できるすべてのLDAP設定が表示されます。
オブジェクトツリーの「/ldapMappings」、「/ldapServers」、「/ldapSources」の各ノードに存在する階層内のオブジェクトは、Meeting Serverと1つ以上のLDAPサーバ(Active Directoryなど)とのインタラクションに関連します。これらのサーバは、ユーザアカウントをCisco Meeting Serverにインポートするために使用されます。
Ldapサーバ
1つ以上のLDAPサーバを設定し、各サーバに関連付けられたユーザ名とパスワードを設定する必要があります。これらのサーバは、ユーザアカウント情報を取得する目的でMeeting Serverに接続するために使用されます。
* =必須
住所* |
接続先のLDAPサーバのアドレス |
[名前(Name)] |
関連付けられた名前(バージョン2.9以降) |
ポート番号* |
ポート389(非セキュア)またはポート636(セキュア) |
ユーザ名 |
LDAPサーバから情報を取得するときに使用するユーザ名 |
Password |
ユーザ名に関連付けられたアカウントのパスワード |
セキュア* |
LDAPサーバへのセキュアな接続を確立するかどうかを指定します。「true」の場合、TLS が使用されます。「false」の場合はTCPが使用されます。 |
ページ結果の使用 |
LDAPページ化結果制御を使用して、 LDAP同期。設定されていない場合は、ページ化された結果コントロールが使用されます。Oracleインターネット ディレクトリでは、このパラメータを(バージョン2.1から)falseに設定する必要があります。 |
Ldapマッピング
1つ以上のLDAPマッピングも必要です。これは、設定済みのLDAPサーバからユーザをインポートするときにシステムに追加されるユーザアカウント名の形式を定義します。
* =必須
jidMapping* |
関連付けられたLDAPからユーザJIDを生成するためのテンプレート サーバのエントリなど $sAMAccountName$@example.comです。 注:jidMappingによって生成されたユーザJIDは、URIとしても使用されます そのため、URIやコールIDと同じではなく、一意である必要があります。 |
名前マッピング |
関連付けられたテンプレートからユーザ名を生成するためのテンプレート LDAPサーバエントリ。たとえば、「$cn$」を使用して、 name. |
cdrTagMapping |
ユーザのcdrTag値を生成するためのテンプレート。設定可能 固定値にするか、他のLDAPフィールドから構築するか を設定します。ユーザのcdrTagは、callLegStart CDRで使用されます。 詳細については、『Cisco Meeting Server CDR Reference』を参照してください。 |
coSpaceUriMapping |
これらのパラメータを指定すると、各ユーザが このLDAPマッピングによって生成されたアカウントには、 personal coSpaceの略。 |
coSpaceSecondaryUriMapping |
必要に応じてcoSpaceを設定するには、次のパラメータを使用します 表示されたcoSpacesのURIを設定するためのテンプレートを提供します 名前と設定済みのコールID。たとえば、次のように設定します coSpaceNameMappingを「$cn$ personal coSpace」に設定すると、 各ユーザのcoSpaceに名前の後に続くラベルが付けられます。 「personal coSpace」を参照してください。 |
coSpaceNameMapping |
|
coSpaceCallIdMapping |
|
認証IDマッピング |
認証IDを生成するテンプレートは、 たとえば、関連付けられたLDAPサーバエントリ "$userPrincipalName$" |
Ldapソース
次に、一連のLDAPソースを設定する必要があります。このソースは、設定済みのLDAPサーバとLDAPマッピングを、一連のユーザの実際のインポートに対応する独自のパラメータとともに結び付けます。LDAPソースは、LDAPサーバとLDAPマッピングの組み合わせを受け取り、フィルタリングされたユーザのセットをそのLDAPサーバからインポートします。このフィルタは、LDAPソース「baseDn」(ユーザを検索できるLDAPサーバツリーのノード)と、ユーザアカウントが特定のパターンに一致するLDAPオブジェクトに対してのみ作成されることを保証するフィルタによって決定されます。
* =必須
サーバ* |
以前に設定したLDAPサーバのID |
マッピング* |
以前に設定されたLDAPマッピングのID( |
ベースDn* |
ユーザのインポート元となるLDAPサーバツリー内のノードの識別名(例:cn=Users,dc=,dc=com) |
フィルタ |
|
テナント |
|
ユーザプロファイル |
|
非メンバアクセス |
|
Web GUI設定のAPIへの移行
この項では、LDAP Web GUI設定をAPIに移行する方法について説明します。現在Web GUIでLDAPを設定していて、この情報をAPIに移行する場合は、この例を使用してデータが失われないようにします。
注:ADをGUIからAPIに移動するとどうなりますか。GUIのActive Directory設定を削除する前にAPIを設定すると、ユーザ情報は変更されません。コールIDとシークレットも同じままです。ただし、後でAPIを設定する前にGUIを削除すると、新しいコールIDとシークレットがユーザに割り当てられます。
ステップ 1:Web GUIのActive Directory設定の通知
Web GUIのLDAP設定を表示するには、Configurations > Active Directoryに移動します。このスクリーンショットを撮るか、これらの内容をコピーしてテキストエディタに貼り付け、後で使用します。
ステップ2:API内のLDAPパラメータに移動します。
Configurations > APIの順に移動し、フィルタバーに「Ldap」と入力します。
LDAP設定のリストが表示されます。
ステップ 3:API内でのldapServerの作成
このリストからldapServersをクリックし、次にCreate Newを選択します。Web GUIのActive Directory内にあったコンテンツについては、スクリーンショットまたはテキストエディタを参照してください。次に、「Active Directory Server Settings」をWeb GUIから対応するAPI設定にコピーします。
ステップ 4:API内でのldapMappingsの作成
手順4.が完了したら、API内のldapMappingに移動します。Configurations > API > Filter "ldapMapping"の順に選択し、Create Newをクリックします。
Web GUIからConfigurations > Active Directory > Filed Mapping Expressionsの順に選択して、フィールドマッピング式をコピーします。 次に、Configuration > API > filter "ldapmapping"の順に移動し、Createをクリックします。
フィールドマッピング式(Web GUI) |
API |
表示名 |
名前マッピング |
ユーザ名 |
jidマッピング |
スペース名(Space Name)) |
|
スペース URI ユーザ パート(Space URI user part) |
coSpaceURIMapping |
スペースセカンダリURIユーザパーツ |
coSpaceSecondaryUriMapping |
スペース コール ID(Space Call ID) |
|
ステップ 5:API内でのldapSourcesの作成
Web GUIからLDAPソースAPI設定に社内ディレクトリ/インポート設定を移行し、Configuration > API > filter "ldapSources"の順に選択して、LdapSourcesの横にある矢印をクリックし、create newを選択します。
手順3.および4で設定したLDAPマッピングとLDAPサーバを選択します。
設定したLDAPマッピングとLDAPサーバを選択し、Web GUIからbaseDNとフィルタをAPI設定に追加します。
設定のインポート(Web Gui) |
API LdapSource |
ベース識別名(Base Distinguished name) |
ベースDN |
フィルタ |
フィルタ |
手順 6:ldapSyncによる設定変更の確認
これで動作を確認できます。APIでldapSyncsに移動し、Configuration > API > filter 'ldapSyncs'の順に選択して、それをクリックし、Create Newを選択します。
何も入力する必要はありません。Createを選択するだけです。同期プロセスが開始されます。30秒後(1分)にページを更新して、完全なステータスが表示され、200 OKが返されることを確認します。
確認
すべてのフィールドが正しく設定されていることを確認します。
トラブルシュート
現在、この設定に関する特定のトラブルシューティング情報はありません。