Novell Home

Integrating eDirectory with Cisco Call Manager

Novell Cool Solutions: AppNote
By Andy Swiffin

Digg This - Slashdot This

Posted: 1 Feb 2006
 

Integrating eDirectory with Cisco Call Manager

Overview

The IP Telephony product from Cisco, Cisco Call Manager (CCM) offers directory integration, but only with Microsoft, Netscape, and Sun offerings. When we said we wanted to integrate directly with eDirectory the response was "No, sorry."

This AppNote show how it is indeed possible to integrate CCM with eDirectory using the procedures intended for Netscape directory with very few modifications. Although not yet deployed on an operational Call Manager, we hope that this "proof of concept" will be a sufficient demonstration of the viability of this integration and that Cisco will consider adding Novell eDirectory to their "supported" list.

About Cisco Call Manager

Cisco Call Manager is the flagship IP Telephony product from Cisco Systems Inc. It is the software-based call-processing component of the Cisco IP telephony solution. In Cisco's own words, "The software extends enterprise telephony features and functions to packet telephony network devices such as IP phones, media processing devices, voice-over-IP (VoIP) gateways, and multimedia applications." To learn more about this see [1].

In simple terms, CCM is an IP telephone switch that establishes calls between IP phones. In order to do this, CCM needs to know about all kinds of devices - this information is stored in an SQL database. It also needs to know about people, names, logon IDs, departments and telephone numbers - this information is stored in an internal X500 directory.

Figure 1: CCM user information

Cisco has chosen DCDirectory from Data Connection for this function [2]. Although the directory and access to it are normally hidden, administration is performed through the tool shown.

Dundee University and the Cisco Project

Dundee University has over 15,000 students and 5,000 staff in an eDirectory of over 20,000 official user objects, plus many more. We have systems in place to import student and staff data from the student registry and personnel databases. Everyone has an official identity in the Directory giving them login rights, an e-mail account, and identities on many other LDAP-driven systems. Naturally, as part of our evaluation and procurement of a telephony system it was important to be able to integrate that system with our campus-wide eDirectory. We needed to be able to transfer identities onto the phone system and phone numbers back to the directory.

The Cisco product was chosen with assurances that all our integration needs could be met, but when we came to look at it more closely, directory integration was far more limited than we had hoped. In fact, CCM administrators are only offered the option of integrating with Microsoft Active Directory, Netscape Directory Server, or Sun One Directory server. When we said we wanted to integrate with eDirectory the response was, "We're sorry, but that isn't one of the options."

This Appnote describes a proof of concept integration directly between CCM and eDirectory. CCM uses LDAP to communicate with its directory, so despite statements that the named directories were the only supported options we took the "why not?" approach. We set out to prove that we could integrate with eDirectory just as easily as with any other directory offering LDAP access.

CCM's "native" directory: DC Directory

DC Directory as used by Cisco looks very similar to some other X500 implementations such as eDirectory and Active Directory. It has a very familiar looking management tool which allows us to view the objects CCM has created:

Figure 2: DC Directory Admin tool

User objects are created in a "Users" OU with several attributes. To find out more about these we wanted to look at the directory with LDAP. CCM supports LDAP access to DCDirectory on a rather unusual port:

Figure 3: Connection port for LDAP access

But once a connection is established the directory looks very normal:

Figure 4: LDAP directory view

You can see that the user object alswiffin refers to other objects created elsewhere in the directory, and we can inspect these as well:

Figure 5: Viewing other directory objects

When we found that we could browse the directory this way and that the objects we found there looked unsurprising, we entertained hopes we could use Identity Manager 2 to integrate with eDirectory directly. To our chagrin we found that there are optional components of DC Directory that are not present in a CCM installation, and the lack of these (schema) components caused the DirXML LDAP driver to fail. Our only option would be to use the documented directory integration approach.

Directory Integration

Chapter 17 of the Cisco Call Manager system guide describes the directory structure and attributes used (see [3]). This manual describes how CCM can be redirected to a corporate LDAP directory (sic) by running the Directory plugin. The directories offered only include Microsoft, Netscape and Sun, so unfortunately Novell eDirectory is not in the supported list. The plugin operation is described in detail in [4].

When the directory integration mechanism is examined in detail, it becomes clear that it contains 4 stages:

  1. Update the Corporate Directory schema with attributes and classes needed by CCM.
  2. Update the corporate directory with the containers needed.
  3. Create the basic set of objects required by CCM.
  4. Redirect CCM to the corporate directory.

It is only at the final stage that anything actually happens to Call Manager. Inspection of certain registry settings and .ini files shows us that this final stage is merely the redirection of the LDAP pointer to the new host:

Figure 6: Directory configuration in the registry

Figure 7: .ini settings for Directory configuration

Compare this with the situation after the snap-in has been run:

Figure 8: .ini settings after running the snap-in

If CCM communicates with its directory through LDAP, then it should not care what is at the other end of the LDAP pipe, provided that the standard is being properly adhered to. If CCM can work with Microsoft Active Directory and Netscape Directory then nothing should stop it from working with eDirectory.

The CCM directory integration plugin offers an optional, staged approach to the integration with manual update of the corporate directory schema and attributes (through LDIF files). We therefore set out to see if the procedure for Netscape integration could be modified and used for eDirectory.

Running the Directory Integration Plug-in

Cisco provides an administration tool, CCMAdmin, which allows an administrator to perform all the functions necessary for the care and feeding of a Call Manager. One of the functions of CCMAdmin is as a launch point for various plug-in applications.

Figure 9: CCAdmin tool

It also includes the Directory integration plug-in:

Figure 10: Directory integration plug-in

The plugin is an external application - you can save it and just run the .exe later, or choose to run it from the web page.

Figure 11: Plug-in application

1. Choose whether to install to AD or to Netscape.

Figure 12: Installing to Netscape

2. Choose the Custom method of installation. (Express is designed as a non-stop process.)

Figure 13: Choosing the Custom method

3. Choose "Generate Configuration LDIF Files. At this stage we only want to generate LDIF files for later import.

Figure 14: Custom installation options

4. Provide information and credentials for the target directory.

Figure 15: Target directory configuration

In our case the target is actually eDirectory, but the plug-in does not care. The containers cisco.dundee and users.dundee must exist before proceeding or an error will be displayed. The value of User Search Attribute defaults to the LDAP attribute mail (Internet e-mail address in eDirectory); this may not be the best choice, so cn or uid may be preferable.

After completion of the configuration, three LDIF files will be generated: SpecialUsers.ldif, SpecialUserProfiles.ldif, and ContainersAndySysProfiles.ldif. These are shown below:

Figure 16: LDIF files for target directory

Importing the LDIF Files

The Integration document [4] tells us that the next step is to import these into the target directory. However, these instructions are in error: the procedure on page 22 misses certain key steps, and the steps it does have are in the wrong order.

Before these LDIF files are imported, two key attribute and class files must be applied. Both can be found in C:\dcdsrvr\run\dcx500\config\Netscape, called Netscape_Objectclasses.ldif and Netscape_Attributes.ldif

The attributes must be added first. I chose to use ldapmodify.exe to import the ldif files, launched from a batch file with the following parameters:

ldapmodify -c -v -h 134.36.1.77 -p389 -D cn=admin,ou=system,o=dundee -w cisco -a -f %1 -e errors.txt

The attributes file will install into eDirectory with no errors and without any modification, and it will create a whole host of CCM specific attributes in the eDirectory schema. The objects are a different matter and will require some attention. There are two fixes required - the first is for a typographical error in the file:

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.2.840.113548.3.1.4.137 NAME 'ciscoatGUID' DES
 C 'User Defined Attribute' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE
 X-ORIGIN 'Cisco AVVID' )

A space character must be added in front of X-ORIGIN or else SINGLE-VALUEX-ORIGIN appears to be concatenated when you import the file.

The second fix addresses something that will not generate an error at this stage but will cause problems later. The definition for Ciscoocuser is currently:

dn: cn=schema
changetype: modify
add: objectclasses
objectClasses: ( 1.2.840.113548.3.2.4.2 NAME 'ciscoocUser' SUP 'top' 
STRUCTURAL MAY ( ciscoatUserProfile $ ciscoatUserProfileString $
ciscoatGUID ) X-ORIGIN 'Cisco AVVID' )

This will install correctly, but as soon as you run the "specialusers" ldif file the error will become apparent. This wants to create a user object as follows:

dn: cn=CCM Administrator, ou=Users, o=dundee
changeType: add
cn: CCM Administrator
givenName: CCM
sn: Administrator
mail: CCMAdministrator
userPassword: ciscocisco
Description: CiscoPrivateUser
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: ciscoocUser

As it stands, this will fail with an error message. However, if the definition of CiscoocUser is changed to an auxiliary class it will work correctly.

dn: cn=schema
changetype: modify
add: objectclasses
objectClasses: ( 1.2.840.113548.3.2.4.2 NAME 'ciscoocUser' SUP 'top' 
AUXILIARY MAY ( ciscoatUserProfile $ ciscoatUserProfileString $
ciscoatGUID ) X-ORIGIN 'Cisco AVVID' X-NDS_NOT_CONTAINER '1' )
These two changes should be made to the objects ldif file before importing it. Errors will still be generated, they indicate that the LDIF file is attempting to delete a pre-existing object class prior to recreating it. This message is cosmetic.

Figure 17: Cosmetic LDIF error message

The end result is that the directory Schema will gain the new classes and attributes.

Figure 18: Schema - new classes and attributes

Now the remaining three LDIF files generated by the integration snap-in may be imported. ContainersAndSysProfiles should be done first. In the instructions on page 22 of [4], steps 2 and 3 are in the wrong order - SpecialUserProfiles must be entered first, as SpecialUsers.ldif creates objects which then refer to these.

The step-by-step instructions for Active Directory do contain the missing steps and are in the right order. However, it is unlikely that anyone will do this manually, as the Express one-step method is probably best for AD.

At this stage, the preliminary directory configuration is complete, and the basic set of objects that CCM will require are in existence:

Figure 19: Directory configuration

Figure 20: Directory configuration (cont'd)

Inspection of the error log reveals one error type that should be addressed. Three crucial user objects have been created with a space in the name (e.g., CCM Administrator). The final LDIF file tries to modify the cn attribute of these objects to remove the space and fails in eDirectory:

# Error: Operation not allowed on RDN
dn: cn=CCM Administrator, ou=Users, o=dundee
changeType: modify
replace: cn
cn: CCMAdministrator

# Error: Operation not allowed on RDN
dn: cn=CCM SysUser, ou=Users, o=dundee
changeType: modify
replace: cn
cn: CCMSysUser

# Error: Operation not allowed on RDN
dn: cn=IPMA SysUser, ou=Users, o=dundee
changeType: modify
replace: cn
cn: IPMASysUser

These users are necessary for a number of Call Manager functions. Part of the migration process is to run an application that changes the passwords on these objects, but this will fail because the application cannot find them. As a workround you can change the object names to remove the space. These objects in DC Directory do not have a space in the name, neither do they have one when Active Directory is used. (It is not clear why the Netscape LDIF adds it.)

Now that the directory has been prepared, CCM can be redirected to it. This is achieved using the Directory Integration snap-in again, only this time selecting the missing options:

Figure 21: Selecting missing options

Don't worry that error messages are generated in the installation process - it tries to update the schema and perform the tasks which have already been done.

At the end of this process, the registry and .ini files will be modified to point to the new directory:

Figure 22: Modified .ini file

This file and the registry need to be edited to re-enable the administrative CCMAdmin functions as described in [4], after the server is rebooted.

Verifying the Integration

When CCMAdmin is used again after the integration, there is no discernible difference with CCM using the embedded DC Directory. Thus, a user can be created normally:

Figure 23: User creation in CCM

The new user will then appear in eDirectory:

Figure 24: eDirectory view of new user

All the eDirectory attributes will be set correctly, including the telephone number.

Figure 25: eDirectory attributes

When the department is set in CCMAdmin, this sets the eDirectory attribute Department Number, and so is not visible above. If required this can be corrected by changing the mapping in the LDAP Group object.

Inspecting the object with an LDAP browser confirms that the object has all of the attributes it had in DC Directory:

Figure 26: LDAP view of object attributes

As you would expect, the profile objects referred to from the user object also correctly exist.

Figure 27: Profile objects

Figure 28: Profile objects (cont'd)

Although you can use CCMAdmin to create some user objects, it is far more likely that users will be created in the Identity Vault (eDirectory) initially, with only the telephone number to be added by the telecom administrator, using CCMAdmin.

For example, we can create a user "FZBloggs" in eDirectory:

Figure 29: New user, eDirectory

Figure 30: New user, eDirectory (cont'd)

and it will be immediately visible in CCMAdmin:

Figure 31: CCAdmin view of new user

Using CCMAdmin, the telephone number can be added. Only the user object was created in eDirectory, but we find that CCMAdmin associates the Ciscoocuser auxiliary class with the user and creates the additional CCN-Profile attributes and objects at this time.

Figure 32: Additional attributes and objects

Figure 33: Additional attributes and objects, ConsoleOne view

The profile objects are exactly the same as those for a user totally created with CCMAdmin, except for two attributes which are not set. These are ciscoCCNatAAKeyPadMapping and ciscoCCNatAAPromptName. It is not clear what these are used for, but the expectation is that should the appropriate function be chosen in CCMAdmin then they would become set if needed.

Conclusion

Netscape directory and Microsoft Active Directory are the only directories supported by Cisco for Call Manager Integration. CCM communicates with its own internal DC Directory and with these external corporate directories using LDAP. The LDIF files intended for integration with Netscape directory have been imported into Novell eDirectory with only minor modification. After this, the Cisco Directory Integration plug-in was used with the option to integrate with Netscape directory but providing the credentials for the eDirectory server.

The integration apparently succeeds, and CCM seems to function normally. Objects may be created with the CCMAdmin tool that are indistinguishable from those created in the internal DCDirectory. User objects can be created in eDirectory, and these become visible in CCMAdmin. When attributes such as telephone number are added, CCMAdmin completes the creation of the supporting profile objects and adds the necessary extra user attributes. The integration appears to be completely successful.

Caveat: Because direct integration of CCM and eDirectory is not supported by Cisco, this procedure was carried out against Call Manager software running under VMWare on a test system. No live telephone calls were made, and it was therefore not possible to verify all of the functions.

References


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell