はじめに
このドキュメントでは、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のみです。
注:CMSの今後のリリースでは、Web GUIのLDAP設定が削除される可能性があります。
設定
WebインターフェイスでLDAP設定を設定する唯一のシナリオは、CMSにインポートする単一のLDAPソースがある場合です。
注:CMSの新しいリリースでは、Web GUIからActive Directoryを削除できるようになりました。
Active Directoryサーバの設定
次のコマンドを使用して、LDAPサーバへの接続を設定します。
アドレス |
これは、LDAPサーバのホスト名またはIPアドレスです。 |
ポート |
389 for Unsecure & 636 for secure connection(必ずsecure connectionチェックボックスをオンにする) |
ユーザ名 |
登録ユーザの識別名(DN)。この例では、 この目的に特化したユーザ。例: cn=Tyler Evans,cn=Users,OU=Engineering,dc=YourCompany,dc=com |
Password |
使用しているユーザー名のパスワード |
セキュアな接続 |
ポート636を使用している場合は、このチェックボックスをオンにします |
設定のインポート
インポート設定を使用して、インポートするユーザを制御します。
ベース識別名(Based Distinguished Name) |
ユーザのインポート元となる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インターネット ディレクトリでは、このパラメータを「false」(バージョン2.1以降)に設定する必要があります。 |
Ldapマッピング
1つ以上のLDAPマッピングも必要です。このマッピングは、設定済みのLDAPサーバからユーザをインポートするときにシステムに追加されるユーザアカウント名の形式を定義します。
* =必須
jidマッピング* |
関連付けられたLDAPからユーザJIDを生成するためのテンプレート サーバのエントリ $sAMAccountName$@example.comです。 注:jidMappingによって生成されたユーザJIDは、URIとしても使用されます そのため、他のURIやコールIDとは異なる一意のIDを使用する必要があります。 |
名前マッピング |
関連付けられたテンプレートからユーザー名を生成するためのテンプレート LDAPサーバエントリ。たとえば、「$cn$」と入力すると、 name. |
cdrTagMapping |
ユーザのcdrTag値を生成するためのテンプレート。設定可能 固定値に設定するか、他のLDAPフィールドから作成するか 要求します。ユーザのcdrTagは、callLegStart CDRで使用されます。 詳細については、『Cisco Meeting Server CDR Reference』を参照してください。 |
coSpaceUriMapping |
これらのパラメータを指定すると、各ユーザが このLDAPマッピングによって生成されたアカウントには、 パーソナルスペース: |
coSpaceSecondaryUriMapping |
必要に応じてcoSpaceを設定するには、次のパラメータを使用します 表示されているcoSpacesのURIを設定するためのテンプレートを指定します。 名前と設定済みのコールID。たとえば、次のように設定します coSpaceNameMappingを「$cn$ personal coSpace」に設定すると、 各ユーザのcoSpaceに名前の後に続くラベルが付けられます。 「パーソナルcoSpace」。 |
coSpaceNameMapping |
|
coSpaceCallIdMapping |
|
認証IDマッピング |
WLCから認証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設定の通知
Configurations > Active Directoryに移動して、Web GUIのLDAP設定を表示します。このスクリーンショットを撮るか、これらのコンテンツをコピーしてテキストエディタに貼り付け、後で使用します。
ステップ2:API内のLDAPパラメータに移動します。
Configurations > APIの順に移動し、フィルタバーに「Ldap」と入力します。
LDAP設定のリストが表示されます。
ステップ 3:API内でのldapServerの作成
このリストからldapServersをクリックし、Create Newを選択します。Web GUIのActive Directory内にあるコンテンツについては、スクリーンショットまたはテキストエディタを参照してください。ここでは、「Active Directoryサーバの設定」を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サーバを選択し、baseDNとフィルタをWeb GUIからAPI設定に追加します。
設定のインポート(Web Gui) |
API LdapSource |
ベース識別名(Base Distinguished name) |
ベースDn |
フィルタ |
フィルタ |
手順 6:ldapSyncによる設定変更の確認
これで動作することを確認できます。APIでldapSyncsに移動し、Configuration > API > filter 'ldapSyncs'の順に選択し、これをクリックしてCreate Newを選択します。
何も入力する必要はなく、Createを選択するだけです。同期プロセスが開始されます。30秒~ 1分後、ページを更新して、完全なステータスが表示され、200 OKが返されることを確認します。
確認
すべてのフィールドが正しく設定されていることを確認します。
トラブルシュート
現在、この設定に関する特定のトラブルシューティング情報はありません。