Configure Cisco Meeting Server LDAP Integration
Available Languages
Contents
Introduction
This document describes the step-by-step process of integrating Lightweight Directory Access Protocol (LDAP) with the Cisco Meeting Server (CMS).
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on CMS 3.0.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Background Information
This will focus on a number of topics that deal with LDAP integration with the CMS. It also includes steps on how to migrate TZVREPLACETHIS configurations to API.
Configure
Single Combined Deployment
The only scenario that you would configure the LDAP configuration within the Web Interface is if you have a Single Combined Deployment for CMS.
Active Directory Server Settings
Configure the connection to the LDAP Server with:
| Address | This is the hostname or IP address of your LDAP server. |
| Port | 389 for Unsecure & 636 for secure connection (must check the secure connection checkbox) |
| Username | The Distinguished Name (DN) of a registered user. You may want to create a user specifically for this purpose. Example: cn=Tyler Evans,cn=Users,OU=Engineering,dc=YourCompany,dc=com |
| Password | The password for the user name you are using |
| Secure Connection | Check this box if using port 636 |
Import Settings
Import Settings is used to control which users will be imported:
| Based Distinguished Name | the node in the LDAP tree from which to import users. The following is a sensible choice for base DN to import users |
Example: cn=Users,dc=sales,dc=YourCompany,dc=com |
| Filter | a filter expression that must be satisfied by the attribute values in a user's LDAP record. The syntax for the Filter field is described in rfc4515. |
Example: mail=* |
Field Mapping Expressions
The field mapping expressions control how the field values in the Meeting Server’s user records are constructed from those in the corresponding LDAP records.
| Display Name | |
| User Name | |
| Space Name | |
| Space URI User Part | |
| Secondary Space URI User Part | |
| Space Call ID |
Resilient/Scalable Deployment
There are two scenarios where you would need to configure LDAP within the API. One scenario is when you have a clustered deployment of 3 or more nodes and the second scenario is when you have more than one TZVREPLACETHIS server.
Web Interface API
Navigate to the API Web Interface by logging into your Web Admin of your CMS > Configuration > API. Here is where you will make all of your API configurations.
LDAP API Objects
After navigating to the API in the step mentioned previously, you will now type "Ldap" in the filter bar. This will display all of the Ldap configurations you can make.
Objects in the hierarchy that reside in the “/ldapMappings”, “/ldapServers” and “/ldapSources” nodes in the object tree relate to the Meeting Server’s interaction with one or more LDAP servers (for instance, Active Directory) which are used to import user accounts to the Cisco Meeting Server.
LdapServers
One or more LDAP servers should be configured, with each one having associated username and password information for the Meeting Server to use to connect to it for the purpose of retrieving user account information from it.
* = Required
| Address* | address of the LDAP server to connect to |
| Name | associated name (from version 2.9 onwards) |
| portNumber * | Port 389(unsecure) or Port 636(Secure) |
| Username | username to use when retrieving information from the LDAP server |
| Password | password of the account associated with username |
| Secure * | whether to make a secure connection to the LDAP server. If “true” then TLS will be used; if “false”, TCP will be used. |
| usePagedResults | whether to use the LDAP paged results control in search operations during LDAP sync; if not set the paged results control will be used. Oracle Internet Directory requires this parameter to be set to “false” (from version 2.1). |
LdapMappings:
One or more LDAP mappings are also required, which define the form of the user account names which will be added to the system when users are imported from configured TZVREPLACETHIS servers.
* = Required
| jidMapping* | The template for generating user JIDs from the associated LDAP server’s entries, for instance $sAMAccountName$@example.com. Note: user JIDs generated by jidMapping are also used as URIs so must be unique and not the same as any URI or call ID. |
| nameMapping | The template for generating user names from the associated LDAP server’s entries; for instance “$cn$” to use the common name. |
| cdrTagMapping | The template for generating a users' cdrTag value. Can be set either to a fixed value or be constructed from other LDAP fields for that user. The user’s cdrTag is used in callLegStart CDRs. See the Cisco Meeting Server CDR Reference for details. |
| coSpaceUriMapping | If these parameters are supplied, they ensure that each user account generated by this LDAP mapping has an associated personal coSpace. |
| coSpaceSecondaryUriMapping | For that coSpace to be set up as required, these parameters provide the template for setting the coSpaces’ URI, displayed name and configured Call ID. For example, setting coSpaceNameMapping to “$cn$ personal coSpace” ensures that each user’s coSpace is labelled with their name followed by “personal coSpace”. |
| coSpaceNameMapping | |
| coSpaceCallIdMapping | |
| authenticationIdMapping | The template for generating authentication IDs from the associated LDAP server"s entries, for instance "$userPrincipalName$" |
LdapSources:
A set of LDAP sources then need to be configured, which tie together configured TZVREPLACETHIS servers and TZVREPLACETHIS mappings, along with parameters of its own, which correspond to the actual import of a set of users. An TZVREPLACETHIS source takes an TZVREPLACETHIS server / TZVREPLACETHIS mapping combination and imports a filtered set of users from that TZVREPLACETHIS server. This filter is determined by the TZVREPLACETHIS source's "baseDn" (the node of the TZVREPLACETHIS server's tree under which the users can be found) and a filter to ensure that user accounts are only created for TZVREPLACETHIS objects that match a specific pattern.
* = Required
| server* | The ID of a previously-configured LDAP server |
| mapping* | The ID of a previously-configured LDAP mapping ( |
| baseDn* | The distinguished name of the node in the LDAP server’s tree from which users should be imported, for instance “cn=Useers,dc=,dc=com” |
| filter | |
| tenant | |
| userProfile | |
| nonMemberAccess |
Migrating Web GUI Configurations to API
This section will discuss how we migrate LDAP web GUI configurations to API. If you currently have Ldap configuration in the web GUI and you want to migrate this information to API then follow this example.
Please note: What happens when you move AD from GUI to API? If you configure the API first before removing the GUI Active directory settings, the user information will remain unchanged; call ID and secret also remain the same. However, If you remove the GUI before configuring the API afterwards, all users will get a new call ID and secret.
Step 1. Notating Web GUI Active Directory Settings
Navigate to Configurations > Active Directory. Here, you will see the LDAP configurations for your Web GUI. Take a screenshot of this or copy and paste these contents into notepad++ because you will need this later.
Step 2: Navigate to LDAP parameters within API
Navigate to Configurations > API > Type “Ldap” in the filter bar.
Here you will see a list of LDAP configurations. We will be focusing on ldapMappings, ldapServers, and ldapSources. So, let’s begin with ldapServers.
Step 3. Create ldapServer within API
From this list, click on ldapServers and then select “Create New”. Now bring up that screenshot or notepad++ of the contents that was within your Web GUI Active Directory. You are now going to copy the “Active Directory Server Settings” from the Web Gui into the corresponding API configurations. See here:
Step 4. Create ldapMappings within API
After you complete Step 4., navigate to ldapMapping within the API. Configurations > API > Filter “ldapMapping” and click Create New.
Here, copy the Field Mapping Expressions from the Web GUI. Navigate to Configurations > Active Directory > Filed Mapping Expressions into the API configuration for ldapMapping. Then, navigate to Configuration > API > filter “ldapmapping” and then click Create.
|
Field Mapping Expressions (Web GUI) |
API |
|
Display name |
nameMapping |
|
Username |
jidMapping |
|
Space name |
|
|
Space URI user part |
coSpaceURIMapping |
|
Space secondary URI User Part |
coSpaceSecondaryUriMapping |
|
Space call ID |
Step 5. Create ldapSources within API
Now migrate the Corporate Directory/Import settings from the Web GUI into the LDAP Sources API configurations, Configuration > API > filter “ldapSources” and click the arrow next to LdapSources and then select create new.
Select the LDAP Mapping and TZVREPLACETHIS server that you configured in Steps 3. and 4.
Here you will select the LDAP Mapping and TZVREPLACETHIS server we just configured and then you will add the baseDN and filter from the Web Gui to the API configuration.
|
Import Settings (Web Gui) |
API LdapSource |
|
Base Distinguished Name |
baseDn |
|
Filter |
filter |
Step 6. Verify Settings Change Through ldapSync
You can now confirm that it works. Navigate to ldapSyncs in API, Configuration > API > filter ‘ldapSyncs’ and click it and select Create New.
You will not have to fill anything out, and you will just select Create. This will begin the Sync Process. After 30 secs – 1 min, refresh the page in order to verify that you get a complete status and a 200 OK returned.
Verify
Ensure that all fields are properly configured.
Troubleshoot
There is currently no specific troubleshooting information available for this configuration.
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
08-Sep-2021 |
Initial Release |
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)