Background
Introduction
  Full Re-Synchronization Mechanism
Call Manager 5.1.1
Authentication Example
Call Manager 6.0
Analysis of Results
Call Manager 5 (and 6) Revisited
Conclusion
  Acknowledgements
  References

Background

Cisco Unified Call Manager versions 5 and 6 are the latest IP telephony products from Cisco. They differ substantially from Call Manager 4 in that they no longer have their own internal X500 directory, with user information being stored within the same database as the devices. Integration with a corporate directory through a one way non-invasive LDAP download is possible, as is authentication against that directory to enable a user to access his telephone management web pages. However, one similarity with Call Manager 4 is that directory integration is only offered against Microsoft Active Directory or SunOne/iPlanet - Novell eDirectory is specifically excluded. This AppNote describes a mechanism for integrating Cisco Unified Call Managers 5 and 6 directly with Novell eDirectory and explores some of the pitfalls to avoid in doing so.

Introduction

When we deployed Cisco Call manager version 4 as our IP Telephony solution, directory integration was high on our agenda. Our goal was one-place management of telephone numbers, preferably in eDirectory, and authentication to a user's telephone management web page using the standard LDAP login name and password. Unfortunately, we found that Cisco does not support eDirectory as one of the allowed LDAP targets, which include only Microsoft AD, SunOne, Netscape, and iPlanet. In a previous Cool Solutions AppNote [1] I described how I was able to demonstrate that it was, in fact, possible to integrate Cisco Call Manager 4 with eDirectory, with only a few modifications to the documented procedure for Netscape, et al (SunOne/iPlanet). Unfortunately, we found ourselves unable to follow the procedure with our production service, since it was not supported by Cisco.

We decided to accept the Cisco-supported approach by integrating our Call Manager with Active Directory (AD) and then using Novell IDM to ensure synchronization between AD and our eDirectory tree. We initiated a project to achieve this synchronization, but then the project was shelved for the following reasons:

a) It was found that in the Call Manager there was no link between a telephone number set as a user attribute in the directory and the number appearing on the actual device associated with that user - we would still be in a position of having to manage numbers in multiple places.

b) The IP telephones themselves receive an on-phone directory for looking up users and numbers, which is normally sourced from the Call Manager. However, this returns only first name, surname and number, and we wanted a richer set of information to permit accurate identification of users (which John Smith do you want?). A service has been developed in-house that delivers more useful information, including titles and departments sourced from eDirectory. This shifted focus towards maintenance of telephone numbers there. The telephone console - ArcConsole - was also configured to take its data from eDirectory by nightly download [4, 5], again shifting emphasis to eDirectory as the primary repository for this information.

c) Call Manager 5 was on the horizon, and it was reported that this did away completely with an internal directory. It would just use LDAP to perform a one-way synchronization from a corporate directory, in the same way, in fact, we were already using ArcConsole.

By integrating call manager with AD, it would have been possible to achieve user authentication to telephone web pages with standard credentials, even if we would not achieve single-point management of numbers. However, the question was then raised - why go to all of the trouble integrating Call Manager 4 with AD (and have to integrate that to eDirectory with IDM) when Call Manager 5 seemed to be going to offer the same functionality far more elegantly? A decision was taken to wait until Call Manager 5 became available before proceeding.

There are a number of significant differences between Cisco Call Manager 4 and 5, not the least that CCM4 was based on a Windows 2000 platform and 5 is based on Linux ( a variant of Red Hat). The new Call Manager, now called Cisco Unified Call Manager (CUCM) is, in fact, an "appliance" - there is no access at all to the operating system, which can be completely disregarded. It is not even possible to log in to the console, although there is a restricted "shell" that would be familiar to users of other Cisco products, such as routers and switches. The internal differences are more significant, in that Version 5 and beyond have completely dispensed with the directory. Version 4 had an SQL database containing information about devices (telephones, etc.) and an X500 directory (DCDirectory) that contained information about users (including the telephone number, albeit little-used). DCDirectory was used to deliver number information to the directory visible on the telephone and to provide authentication to a user's web page for controlling certain parameters. In version 5 there is no directory, and information about users is now stored in the database.

Chapter 20 of the CUCM systems guide [2, 3] describes the new way CUCM maintains and uses user data. The concept of the Dirsync service is introduced, where CUCM may be configured to periodically download the users from a particular LDAP target at regular intervals. Once LDAP synchronization is configured and operational, administrators may then configure LDAP authentication. When a user accesses his telephone management web pages, his corporate directory username and password are then used for authentication, rather than using a password held within the Call Manager.

The detailed configuration of Call Manager to achieve this is documented in [6, 7, 8]. The one-way Dirsync process now means that no schema extensions are required in the campus directory and that the integration is totally non-invasive. Much of the documentation refers to LDAP in a standard, non-vendor-specific way. Even where specific vendors are mentioned in [6], the reference is to LDAP Server Type, which was read as meaning a generic type of either Microsoft Active Directory type or Netscape LDAP Server type, (i.e., everything else). This gave great hope that CUCM could be easily integrated with eDirectory in a supported manner, but then the following excerpt on page 11 of [8] was found:

"The following directories are supported by Unified CM for synchronization:
- Microsoft Active Directory (AD) 2000 and 2003
- Netscape Directory Server 4.x, iPlanet Directory Server 5.1, and Sun ONE Directory Server 5.2"

Novell eDirectory is still excluded with only AD or Netscape being mentioned. Still, because of the non-invasive way in which the directory is now used, and because eDirectory is a very good standard LDAP implementation, there was much to hope that it would, in fact, actually work.

Full Re-Synchronization Mechanism

A further study of [8] reveals an interesting distinction in the mechanism used for directory synchronization between AD and Netscape et al. With AD the synchronization at each scheduled period is described as a "full re-synchronization." Any changes, additions, or removals to the corporate directory are not reflected in the Call Manager user base until the next scheduled synchronization. Netscape, et al, are reported to support "incremental synchronization," in which changes to the directory are synchronized to the Call Manager almost immediately after they occur, and long before the next scheduled synchronization period. How is this achieved? Around the year 2000 an Internet-Draft was published that described an incremental synchronization mechanism for LDAP, called Persistent Search [10]. A Novell AppNote was subsequently published, [11], which described how this feature had been introduced in eDirectory 8.6.1 and later. It is this feature (unsupported in AD) that provides the incremental update with Netscape, et al, and there were great hopes that it would also work with eDirectory.

Rather than attempt to use Call Manager implemented as a VM again as had been done with the Call Manager 4 integration [1] and perhaps introduce artifacts, we obtained a "real" Call Manager running on approved hardware. This was dual boot with Call Manager versions 5.1.1.3000-5 and 6.0.1.1000-37, and both versions were tested against eDirectory 8.7.3 running on Windows.

Call Manager 5.1.1

In order to initialize the LDAP system in Call Manager, you must first specify which type of LDAP server will be used.

1. From the System menu, choose LDAP > LDAP System.



Figure 1 - Call Manager LDAP System option

2. At the choice between Microsoft AD and Netscape, choose Netscape.

3. Specify your LDAP System Information choices.



Figure 2 - LDAP System Information

4. Having selected the type of directory you want, create an LDAP directory setting to initiate a download, as shown below.



Figure 3 - LDAP Directory Information

There is nothing particularly unusual about this page to anyone who has configured an LDAP client:

a) Supply a username and password that will be used to access the directory.

b) Specify a search base or starting point below which users will be found.

c) Create a schedule to download data upwards from every 7 hours.

d) You can specify the attributes that will be downloaded, although there is no control over these, apart from the email address attribute.

e) Enter the address of the server(s), with the possibility of entering multiple redundant servers for this download. Although the default is to use port 389, you can specify 636 and SSL.

5. Click Save to save these details.

An initial connection to the LDAP server is made, and a simple one-level search of the target OU is performed to verify the credentials and search base that has been supplied.

Following this, there is no further activity until the time and date that had been set earlier is reached. After that, the synchronization starts.

A container was created in the tree, containing a representative sample of users:



Figure 4 - Container with sample users

After the synchronization occurs, inspection of the Call Manager Users reveals the following:



Figure 5 - Users synchronized from eDirectory

These users have synchronized over from eDirectory. There is one user marked as Inactive - this was a locally created user who will be purged from the system once LDAP synchronization starts, as you cannot have any
users entered manually when you are downloading users by LDAP. Deletion of users is handled by a janitor process that runs overnight, so in the interim a user to be purged is flagged as inactive.

These users may now access their telephone management pages after some further configuration is performed.

6. Select LDAP Authentication from the initial System Configuration tab.



Figure 6 - LDAP Authentication and Server Information

A simpler set of details is requested here, and the normal mechanism for LDAP authentication is used:

a) Supply a privileged username and password. This is used to look up a user's CN (entered by them) to provide the Fully Distinguished Name. This is then used by the Call Manager to bind to the server using the user supplied password.

b) The server specified here need not be the same as the one used for the LDAP synchronization. It doesn't even need to be in the same tree; the only requirement is that the UID attribute be the same in both.

7. Click Save to save the settings.

Authentication Example

Now we can see the authentication in action. In the example below, user ALSwiffin has been associated with a telephone and wants to manage certain actions:



Figure 7 - User logon screen

He goes to the management URL, and when prompted, enters the normal campus login name and password. Presto - he is presented with the management page:



Figure 8 - User Management page

Clearly, everything is working, or at least we seem to have good functionality. However, an investigation of what is happening behind the scenes reveals that all is not quite as it should have been.

A review of the LDAP settings shows the following:



Figure 9 - LDAP Settings: sync not completed

The sync process does not seem to have completed, although the next Re-Sync time has moved on. Investigation of the packet trace between the Call Manager and the LDAP server shows a large and increasing number of packets have been exchanged:



Figure 10 - Packet trace information

The imanager DSTrace output shows that in fact the synchronization is looping and never completing. Hence, all is definitely not well with CUCM version 5.1 synchronization against eDirectory.

Call Manager 6.0

The interface of CUCM 6 is very similar to that seen with version 5.1. LDAP configuration follows the same process, and the documentation for LDAP integration for version 6 seems to be nearly the same as for 5, with the number 5 globally replaced by the number 6!

The integration with eDirectory was set up as with Call Manager version 5:



Figure 11 - LDAP Directory information, CUCM 6.0

As can be seen, there is only cosmetic difference between this and the configuration for 5. The configuration of LDAP authentication was also functionally identical. The big difference was observed in the packet trace when the synchronization period was reached - this time, the synchronization seemed to work correctly, and it completed. The users appeared in the End User list, and it was possible to authenticate to the CCMuser page. But did the synchronization work perfectly? Here is the DSTrace (edited highlights, with some annotation):

First, CUCM makes the connection and binds:

09:35:54 894 LDAP: New cleartext connection 0xda2340 from 10.1.2.1:34769, monitor = 0x0, index = 1
09:35:54 994 LDAP: (10.1.2.1:34769)(0x0001:0x60) DoBind on connection 0xda2340
09:35:54 994 LDAP: (10.1.2.1:34769)(0x0001:0x60) Bind name:cn=admin,ou=system,o=dundee, version:3, authentication:simple

After some preliminaries, it initiates a search at the specified point in the tree:

09:35:55 970 LDAP: (10.1.2.1:34769)(0x0002:0x63) DoSearch on connection 0xda2340
09:35:55 970 LDAP: (10.1.2.1:34769)(0x0002:0x63) Search request:
 base: "ou=test2,ou=test,o=dundee"
 scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
 filter: "(objectclass=inetOrgPerson)"
 attribute: "uid"
 attribute: "givenname"
 attribute: "initials"
 attribute: "sn"
 attribute: "manager"
 attribute: "departmentnumber"
 attribute: "telephonenumber"
 attribute: "mail"
 attribute: "title"
 attribute: "homephone"
 attribute: "mobile"
 attribute: "pager"

The LDAP server sends the results (extra entries removed for clarity):

09:35:55 970 LDAP: (10.1.2.1:34769)(0x0002:0x63) Sending search result entry "cn=ALSwiffin,ou=test,o=dundee" to connection 0xda2340
...
09:35:55 970 LDAP: (10.1.2.1:34769)(0x0002:0x63) Sending operation result 0:"":"" to connection 0xda2340

CUCM asks for a limited search at the next higher level in the tree (not shown). Then it initiates another search at our specified level, asking for extra attributes and setting up the persistent search connection:

09:36:00 8A4 LDAP: (10.1.2.1:34769)(0x0004:0x63) DoSearch on connection 0xda2340
09:36:00 8A4 LDAP: (10.1.2.1:34769)(0x0004:0x63) Search request:
 base: "ou=test,o=dundee"
 scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
 filter: "(objectclass=inetOrgPerson)"
 attribute: "uid"
 attribute: "givenname"
 attribute: "initials"
 attribute: "sn"
 attribute: "manager"
 attribute: "departmentnumber"
 attribute: "telephonenumber"
 attribute: "mail"
 attribute: "title"
 attribute: "homephone"
 attribute: "mobile"
 attribute: "pager"
 attribute: "objectClass"
 attribute: "javaSerializedData"
 attribute: "javaClassName"
 attribute: "javaFactory"
 attribute: "javaCodeBase"
 attribute: "javaReferenceAddress"
 attribute: "javaClassNames"
 attribute: "javaRemoteLocation"

But the server doesn't like this and responds saying:

09:36:00 8A4 LDAP: (10.1.2.1:34769)(0x0004:0x63) Persistent Search doesn't work when dereferencing aliases under the base
09:36:00 8A4 LDAP: (10.1.2.1:34769)(0x0004:0x63) Sending operation result 80:"":"" to connection 0xda2340

Result 80 is a slap on the wrist - "I cannot do this." Following this response, CUCM then unbinds the connection.

Let's look a bit more closely at the actual search request packets, as there is a little more detail visible than is provided in the DSTrace.

First, here's the packet that elicits a correct response and retrieves all of the values:

Frame 70 (262 bytes on wire, 262 bytes captured)
Ethernet II, Src: CompaqHp_cb:7d:6a (00:0b:cd:cb:7d:6a), Dst: Vmware_c3:be:17 (00:0c:29:c3:be:17)
Internet Protocol, Src: 10.1.2.1 (10.1.2.1), Dst: 10.1.2.5 (10.1.2.5)
Transmission Control Protocol, Src Port: 54810 (54810), Dst Port: ldap (389), Seq: 47, Ack: 15, Len: 196
Lightweight-Directory-Access-Protocol
 LDAPMessage searchRequest(2) "ou=test2,ou=test,o=dundee" wholeSubtree
  messageID: 2
  protocolOp: searchRequest (3)
   searchRequest
    baseObject: ou=test2,ou=test,o=dundee
    scope: wholeSubtree (2)
    derefAliases: derefAlways (3)
    sizeLimit: 0
    timeLimit: 0
    typesOnly: False
    Filter: (objectclass=inetOrgPerson)
     filter: equalityMatch (3)
      equalityMatch
    attributes: 12 items
     Item: uid
     Item: givenname
     Item: initials
     Item: sn
     Item: manager
     Item: departmentnumber
     Item: telephonenumber
     Item: mail
     Item: title
     Item: homephone
     Item: mobile
     Item: pager
  [Response In: 71]

The only item of note here is the attributes that are requested; home phone, mobile and pager were neither in the list specified at configuration nor are specified in the documentation - should CUCM be asking for attributes without permission? However, this elicits a correct response from the server, with all of the users and their attributes that are populated returned.

CUCM then asks for a single-level search at the next level up and elicits the attributes of that container, after which it again asks for a search at our search base:

Frame 76 (443 bytes on wire, 443 bytes captured)
Ethernet II, Src: CompaqHp_cb:7d:6a (00:0b:cd:cb:7d:6a), Dst: Vmware_c3:be:17 (00:0c:29:c3:be:17)
Internet Protocol, Src: 10.1.2.1 (10.1.2.1), Dst: 10.1.2.5 (10.1.2.5)
Transmission Control Protocol, Src Port: 54810 (54810), Dst Port: ldap (389), Seq: 298, Ack: 1344, Len: 377
Lightweight-Directory-Access-Protocol
 LDAPMessage searchRequest(4) "ou=test2,ou=test,o=dundee" wholeSubtree
  messageID: 4
  protocolOp: searchRequest (3)
   searchRequest
    baseObject: ou=test2,ou=test,o=dundee
    scope: wholeSubtree (2)
    derefAliases: derefAlways (3)
    sizeLimit: 0
    timeLimit: 0
    typesOnly: False
    Filter: (objectclass=inetOrgPerson)
     filter: equalityMatch (3)
      equalityMatch
    attributes: 20 items
     Item: uid
     Item: givenname
     Item: initials
     Item: sn
     Item: manager
     Item: departmentnumber
     Item: telephonenumber
     Item: mail
     Item: title
     Item: homephone
     Item: mobile
     Item: pager
     Item: objectClass
     Item: javaSerializedData
     Item: javaClassName
     Item: javaFactory
     Item: javaCodeBase
     Item: javaReferenceAddress
     Item: javaClassNames
     Item: javaRemoteLocation
  [Response In: 77]
  controls: 1 item
   Item joint-iso-ccitt.16.840.1.113730.3.4.3
    controlType: 2.16.840.1.113730.3.4.3 (joint-iso-ccitt.16.840.1.113730.3.4.3)
    criticality: True
    controlValue: 300902010F0101FF0101FF

Items to note are the list of attributes that are requested, which include all the ones starting with "java". It is unclear as to why these are requested. The most significant section is the controls section at the end. The IETF documentation for persistent search [10] describes this for controlType 2.16.840.1.113730.3.4.3.

Unfortunately, eDirectory returns a failure message (resultCode 80) at this point:

Frame 77 (80 bytes on wire, 80 bytes captured)
Ethernet II, Src: Vmware_c3:be:17 (00:0c:29:c3:be:17), Dst: CompaqHp_cb:7d:6a (00:0b:cd:cb:7d:6a)
Internet Protocol, Src: 10.1.2.5 (10.1.2.5), Dst: 10.1.2.1 (10.1.2.1)
Transmission Control Protocol, Src Port: ldap (389), Dst Port: 54810 (54810), Seq: 1344, Ack: 675, Len: 14
Lightweight-Directory-Access-Protocol
 LDAPMessage searchResDone(4) other () [0 results]
  messageID: 4
  protocolOp: searchResDone (5)
   searchResDone
    resultCode: other (80)
    matchedDN: 
    errorMessage: 
  [Response To: 76]
  [Time: 0.000477000 seconds]

And CUCM, realizing that the "game is up," unbinds:

Frame 79 (73 bytes on wire, 73 bytes captured)
Ethernet II, Src: CompaqHp_cb:7d:6a (00:0b:cd:cb:7d:6a), Dst: Vmware_c3:be:17 (00:0c:29:c3:be:17)
Internet Protocol, Src: 10.1.2.1 (10.1.2.1), Dst: 10.1.2.5 (10.1.2.5)
Transmission Control Protocol, Src Port: 54810 (54810), Dst Port: ldap (389), Seq: 675, Ack: 1358, Len: 7
Lightweight-Directory-Access-Protocol
 LDAPMessage unbindRequest(5)
  messageID: 5
  protocolOp: unbindRequest (2)
   unbindRequest

Why is this failing? It has already been seen in [11] that eDirectory supports Persistent Search, but the answer is on the final page, which says:

"The Persistent Search operation is incapable of de-referencing alias entries in the directory. So if the Persistent Search request specifies de-referencing while searching entries or finding the base object, such a request will not be honored by the LDAP server and an error code of 80 (LDAP other) will be sent back to the client."

We clearly see the error code of 80 being returned. Inspection of the search request frame 76 (above) shows the following:

Lightweight-Directory-Access-Protocol
 LDAPMessage searchRequest(4) "ou=test2,ou=test,o=dundee" wholeSubtree
  messageID: 4
  protocolOp: searchRequest (3)
   searchRequest
    baseObject: ou=test2,ou=test,o=dundee
    scope: wholeSubtree (2)
    derefAliases: derefAlways (3)

It is most likely that the derefAliases setting is what is causing the problem, and we have no control over this.

To see this feature operating correctly, an LDAP synchronization was set up against an iPlanet directory. After the persistent search request was initiated, the connection was not closed. A new user object was then created in the directory, one attribute at a time. Each modification generated an event, which caused all of the requested attributes (those so far populated) to be pushed down from the directory to the Call Manager. However, the object only actually appeared in the CUCM End User list when the necessary naming attribute, "uid", was added, generating this packet:

Frame 1068 (355 bytes on wire, 355 bytes captured)
Ethernet II, Src: Vmware_c8:aa:da (00:0c:29:c8:aa:da), Dst: CompaqHp_cb:7d:6a (00:0b:cd:cb:7d:6a)
Internet Protocol, Src: 10.1.2.6 (10.1.2.6), Dst: 10.1.2.1 (10.1.2.1)
Transmission Control Protocol, Src Port: ldap (389), Dst Port: 57086 (57086), Seq: 2217, Ack: 634, Len: 289
Lightweight-Directory-Access-Protocol
 LDAPMessage searchResEntry(4) "cn=WThePooh, ou=People,dc=dundee" [8 results]
  messageID: 4
  protocolOp: searchResEntry (4)
   searchResEntry
    objectName: cn=WThePooh, ou=People,dc=dundee
    attributes: 6 items
     Item uid
      type: uid
      vals: 1 item
       WThePooh
     Item givenname
      type: givenname
      vals: 1 item
       Winnie
     Item sn
      type: sn
      vals: 1 item
       ThePooh
     Item departmentnumber
      type: departmentnumber
      vals: 1 item
       Institute for Honey Studies
     Item telephonenumber
      type: telephonenumber
      vals: 1 item
       123123
     Item objectClass
      type: objectClass
      vals: 4 items
       top
       person
       inetOrgPerson
       organizationalPerson
  [Response To: 292]
  [Time: 564.484574000 seconds]
  controls: 1 item
   Item joint-iso-ccitt.16.840.1.113730.3.4.7
    controlType: 2.16.840.1.113730.3.4.7 (joint-iso-ccitt.16.840.1.113730.3.4.7)
    controlValue: 30030A0104

Every single subsequent modification to the object, even if the attribute being modified was of no interest (OU for example, or a timestamp), generated a further searchResEntry packet. This packet was sent from the LDAP server to Call Manager, containing exactly the same information as we see above. This is a facility that would have to be used with great care, to avoid swamping the Call Manager with irrelevant traffic!

Analysis of Results

Whatever directory is used, with either version of Call Manager, the process used for LDAP synchronization follows the same basic pattern, as described below. Initiation from CUCM is indicated by C and by the LDAP server by L:

1) C: Bind1
2) C: Bind2
3) C: Search at the base level with Bind1
4) L: Return schema and directory information
5) C: Unbind1
6) C: Search ou=test2,ou=test,o=dundee
7) L: Return users
8) C: Search ou=test,o=Dundee
9) L: Return container information
10) C: Search ou=test2,ou=test,o=Dundee with Persistent Search
11) L: Acknowledge, Wait, but return incremental updates as and when they occur

This is the ideal situation, and we see that with iplanet and SunOne directories.

When eDirectory is the target with Call Manager 6, we see this:

10) C: Search ou=test2,ou=test,o=Dundee with Persistent Search
11) L: Error 80 cannot do that (due to aliase dereferences)
12) C: Unbind

The synchronization continues normally again at the next periodic interval.

When Call Manager 5 is used with eDirectory, the situation becomes more complex:

10) C: Search ou=test2,ou=test,o=Dundee with Persistent Search
11) L: Error 80 cannot do that (due to aliase dereferences)
12) C: Loop from stage 1
13) C: Unbind the original connection
14) Continue looping.

Clearly 5.1 is not responding well to the failure in eDirectory to accept the Persistent Search request.

There is a known bug with 5.1 that causes similar behavior against SunOne directory. This manifests itself when an LDAP synchronization is configured to read users at the root of a tree, named perhaps dc=dundee,dc=ac,dc=uk. In this case the process fails earlier:

8) C: Search dc=ac,dc=uk
9) L: No such Object
10) C: Unbind and Loop back to 1) for ever

Comparing this with the situation with eDirectory, could it be that although the mode of failure is different the looping behavior, this is CUCM 5.1's response to any failure from the LDAP server?

At this stage we were set to conclude that CUCM 5.1 could not be used with eDirectory because of the infinite looping but that version 6 did work (with the caveat that the persistent search gave a minor error). However, a closer look at the packet trace, particularly at stage 4 where CUCM first queries the LDAP server for Schema and Directory information, hinted that perhaps all was not lost.

Call Manager 5 (and 6) Revisited

The process that CUCM uses to do a simple LDAP lookup for users looked at first sight unnecessarily complex. Why was the Call Manager querying the schema and directory information? What if it was making intelligent use of the information returned?

The "stage 4" response contains the following:

Frame 53 (1282 bytes on wire, 1282 bytes captured)
...
LDAPMessage searchResEntry(2) "" [1 result]
  messageID: 2
  protocolOp: searchResEntry (4)
  searchResEntry
   objectName: 
   attributes: 37 items
    Item subschemaSubentry
    Item supportedGroupingTypes
     Item namingContexts
     Item supportedExtension
     Item supportedControl
     type: supportedControl
      vals: 6 items
    OID: 2.16.840.1.113719.1.27.101.6 (joint-iso-ccitt.16.840.1.113719.1.27.101.6)
    OID: 2.16.840.1.113719.1.27.101.5 (joint-iso-ccitt.16.840.1.113719.1.27.101.5)
    OID: 2.16.840.1.113730.3.4.3 (joint-iso-ccitt.16.840.1.113730.3.4.3)
    OID: 2.16.840.1.113730.3.4.7 (joint-iso-ccitt.16.840.1.113730.3.4.7)
    OID: 2.16.840.1.113730.3.4.2 (joint-iso-ccitt.16.840.1.113730.3.4.2)
    OID: 2.16.840.1.113719.1.27.103.7 (joint-iso-ccitt.16.840.1.113719.1.27.103.7)
     Item supportedSASLMechanisms
     Item supportedLDAPVersion
     Etc etc

Note the entry for OID: 2.16.840.1.113730.3.4.3 (joint-iso-ccitt.16.840.1.113730.3.4.3), which is the controlType for Persistent Search. Could it be that Call Manager was looking for this information and would modify its behavior depending on it?

It's possible to turn off Persistent Search at the LDAP server settings, and so ConsoleOne was used here to make the appropriate change (the default is for this to be on).



Figure 12 - Turning off Persistent Search in ConsoleOne

In CUCM 5, LDAP synchronization was set up against eDirectory. Now we find that the search at the base gives the following:

  Item supportedControl
   type: supportedControl
    vals: 4 items
    OID: 2.16.840.1.113719.1.27.101.6 (joint-iso-ccitt.16.840.1.113719.1.27.101.6)
    OID: 2.16.840.1.113719.1.27.101.5 (joint-iso-ccitt.16.840.1.113719.1.27.101.5)
    OID: 2.16.840.1.113730.3.4.2 (joint-iso-ccitt.16.840.1.113730.3.4.2)
    OID: 2.16.840.1.113719.1.27.103.7 (joint-iso-ccitt.16.840.1.113719.1.27.103.7)

No more persistent search! And when the LDAP synchronization started, it worked beautifully:

1) C: Bind1
2) C: Bind2 Again
3) C: Search at the base level
4) L: Return schema and directory information
5) C: Unbind1
6) C: Search ou=test2,ou=test,o=dundee
7) L: Return users
8) C: Unbind and wait till next time

The search at the next higher level in the tree no longer occurs, and the process does not loop. Users were added, removed and modified in the directory and the changes were found to synchronize perfectly at the next synchronization interval with both Call Manager 5.1 and 6.

Conclusion

Both Call Manager 5.1 and 6 integrate flawlessly with eDirectory provided that the LDAP server has persistent search turned off. The failure of Persistent Search to work as it does with iPlanet seems to be linked to the issue of the request in the LDAP search for Alias De-referencing, and there is no way to turn this off on CUCM. In Call Manager 6 the failure was graceful: when eDirectory responded with Error 80, CUCM just unbound and waited for the next synchronization period. Call Manager 5.1 did not handle this so well, and the infinite loop would make this unusable. However, the solution is simply to turn off Persistent Search at the eDirectory LDAP server.

Although Persistent Search did look quite interesting in the way it operated with iPlanet, there are some questions as to how it would be used. If it had worked with eDirectory, the directory that is used for synchronization would have to be selected carefully so as to have a low level of changes causing incremental synchronization. For instance, if a production file/print tree were to be used for this, every action such as a login/logout that changed a timestamp would initiate a synchronization of that user - no matter how irrelevant the attributes being changed are!

From these studies, we can see no clear reason why eDirectory should not be added to the Cisco list of supported directory types. Please note, however, that this technique has only been proven with the specified versions; future changes in the Cisco code base may cause this to fail. Even with these tested versions, eDirectory remains an unsupported option for CUCM integration, and care should be taken before attempting this in any production environment.

In our Call Manager, we find that the normal situation is for each user to be associated with just one device and to have just one telephone number. All that remains for us to achieve the Holy Grail of single-point user and telephone number management is for Cisco to add functionality such that a telephone number and identity which has been synchronized down from eDirectory be applied automatically to a user's device.

Acknowledgements

I would like to gratefully acknowledge the assistance received from Mr. Roy Donaldson of Cisco, and grateful thanks to Dr. James McLay for proof-reading the manuscript.

References

[1] Integrating eDirectory with Cisco Call Manager
http://www.novell.com/coolsolutions/appnote/16752.html

[2] Cisco Unified Communications Manager System Guide Release 6.0(1)
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_0_1/ccmsys/accm.pdf

[3] Cisco Unified CallManager System Guide, Release 5.1(3)
http://www.cisco.or.at/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00808a8792.html

[4] ARC LDAP Server User Guide. Version 3.1: Arc Solutions Ltd

[5] Arc LDAP Synchronisation Guide 3.1: Arc Solutions Ltd

[6] Cisco Unified Communications Manager Administration Guide: Chapter14 LDAP System Configuration
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_0_1/ccmcfg/bccm.pdf

[7] Cisco Unified Communications Manager Administration Guide: Chapter 15
LDAP Directory Configuration
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_0_1/ccmcfg/bccm.pdf

[8] Cisco Unified Communications Manager Administration Guide: Chapter 16
LDAP Authentication Configuration
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_0_1/ccmcfg/bccm.pdf

[9] Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x, Chapter 18: LDAP Directory Integration http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_book09186a008085eb0d.html

[10] Persistent Search: A Simple LDAP Change Notification Mechanism
http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-ldapext-psearch-03.txt

[11] Understanding and Using Persistent Search in Novell eDirectory
http://support.novell.com/techcenter/articles/dnd20030204.html