UC Toolkit Part 1: LDAP Browsers to Support Cisco UC Integration

Author
William Bell
Vice President, Solutions and Products

Why Do I Need a LDAP Tool?

One answer to this question is: “if you have to ask, then maybe you don’t need a LDAP tool.” However, chances are high that you have or are looking to integrate one of your Cisco UC applications with your existing LDAP solution. Currently, Cisco supports some form of LDAP integration on most of their UC+Collaboration applications. 

When considering LDAP integration, it is usually a good idea to plan and it is an excellent idea for the “voice” guy to have a working knowledge of the LDAP structure. Personally, I think it is a mistake to punt your request to your systems folks and let them work it out. Collaboration requires a certain amount of mutual knowledge sharing.

As a consultant, I  have little choice in the matter. My clients expect me to be self-sufficient and to have a working knowledge of their environment. Sometimes, it is just easier if I go take a look for myself rather than wait for the LDAP admin to find time for me in his or her schedule.

Softerra LDAP Browser

When I started working with LDAP many moons ago, I was on a Windows platform.  I was searching for a free LDAP browser on Windows I tried a few solutions. I can’t remember them all at this time. I eventually settled on using Softerra LDAP Browser. Softerra’s (http://www.softerra.com/) LDAP Browser application is the lightweight and free version of Softerra’s LDAP Administrator tool.

The currently available version is 4.5. The last version I used heavily was version 2.6. I did load version 4.5 just to get a glimpse of the latest features before writing this blog. Version 4.5 is definitely a much improved version. It is much faster. The interface is pretty intuitive (as is/was 2.6). My favorite improvement is that the latest versions supports exporting data to multiple formats. In 2.6 I could export in LDIF format (not what I call user friendly). In version 4.5 I can export to various formats including Excel and CSV — very handy.

So, if you are a Windows user and you are looking for a good LDAP browser then I recommend taking a look at Softerra. Who knows, maybe you’ll opt for the big daddy version.

Apache Directory Studio

First, I should state that I would have limited the scope of this blog to Softerra if it wasn’t for the fact that I switched to a Mac over a year ago. Softerra doesn’t have a story for the Mac OS X. So, I had to go on the hunt again.

This time around I found Apache Directory Studio. The version I am currently using is 1.5.3. The Apache Directory Studio is a complete tool (not just read-only) that was specifically designed for ApacheDS. However, the tool is intended to be used with any LDAP server. I have used it with Windows 2003 and 2008 LDAP environments without issue.

Apache is built on Eclipse RCP, which is why the application is ported across Windows, Linux, and Mac OS X platforms. The Apache interface is easy to use. I actually like it a little more than Softerra. Both applications have been pretty stable and quite useful.

Examples?

I suppose it would be a good idea to offer up some examples on how I use these LDAP tools. First, whenever I am engaged with a customer on an assessment or design project I typically (like 95% of the time) need to get information about LDAP. In many cases, I am given a user ID in their LDAP domain (which is almost always MS AD, I said almost).

Since I have an LDAP user, I can typically browse the customer’s LDAP at will. However, I do exercise common courtesy and ask the customer for permission to peruse their directory. So, what am I looking for?

The nature of my discovery usually stems from gathering information necessary to either prepare for a new Cisco UC install where LDAP integration is required or to plan out a migration from a non-LDAP configuration to one where Cisco is fully integrated into LDAP. In both cases, I need to get a feel for the OU structure. That helps with determining where I should establish sync agreements and where I should create user or group objects (as required).

I also need to identify attributes I can filter on as well as those I should map to local attributes on specific UC applications. Related to attribute mapping is a “confidence factor” review. I pay particularly close attention to user object attributes to determine if information is consistently maintained. 

When doing a migration from a non-LDAP integrated Cisco deployment to one where the customer is fully LDAP integrated, we also need to look for discrepancies between user objects in LDAP and those in, say Unified Communications Manager (CUCM) for example. You may find that user IDs are not consistent or that user’s that exist in CUCM are no longer valid.

There are other uses for a good LDAP but we covered the core need here. To wrap it up, let’s walk through an example scenario. Say that I want to export the following attributes for a set of users in LDAP:

  • givenName (first name)
  • sn (last name)
  • mail (Email alias)
  • telephoneNumber (main phone number)
  • ipPhone (a MS AD attribute for IP phone number)
  • samAccountName (a MS AD attribute for user IDs)

Maybe I want these attributes in a single Excel spreadsheet so I can start preparing for a future migration. First, we launch Apache Directory Studio and connect to our LDAP service.

We browse through the tree structure to a specific organization unit (OU) where we run a quick search for the existence of the LDAP attribute ipPhone. I know that the users I care about have this attribute set. In the following screenshot, you can see we have 12 user objects with values assigned to the ipPhone attribute. I select the OU I want to search and type the query in the LDAPBrowser pane (left). The results are presented in a “Quick Search” tab in the middle.

Now that I have my search narrowed down, I want to export it into a format I can work with off line. For example, I want to dump a subset of the data to Excel for sorting, parsing, etc. I can right-click on my “Quick Search” results and choose to export the data.

From here, I follow a wizard to define what I want in the report. I keep the filter as (ipPhone=*) (BTW, there is a filter editor that can be quite useful). I also un-check “Export DN” and “All user attributes” option. You can use these options if you want a complete view and, actually, I usually dump everything. However, in this example we only want a handful of attributes so we type them out in a comma delimited list.

We only need to search one level here, but using “Scope” options we can search a whole sub-tree (nice). Make sure if you go this route that you make sure the count limit isn’t artificially “hiding” user objects.

Once we define our report parameters we identify the location to save the Excel spreadsheet (.xls format, BTW) and let it rip. Now I have a spreadsheet that can be passed around for the enjoyment of others.

Conclusions

In my experience, having a LDAP browser on hand is a necessary part of the UC Engineer’s toolkit. You won’t use it every day but it definitely comes in handy. Softerra makes a great product for the Windows platform. If you run something other than Windows then I definitely like Apache Directory Studio. Actually, now that I have found Apache I plan on using it on Window’s platforms as well. Cross-platform portability is a huge bonus.

2 responses to “UC Toolkit Part 1: LDAP Browsers to Support Cisco UC Integration

  1. Hi,

    Can we browse the ldap directory on cucm 7 or cucm 8 ? I don’t think it’s possible anymore… I tried to but I wasn’t able … And the port for ldap don’t seems to be opened on cucm

  2. Sebastien,

    Correct. Starting with CUCM 5.x and later, there is no X.500 directory repository hosted on the CUCM cluster nodes. The "DC Directory" repository has been removed. In the "appliance model" (as CUCM 5.x+ is characterized) end user information is stored in the informix database (in the enduser table).

    You can still get at the enduser data. The method used depends on your requirements. There are reports in BAT that can give you detailed end user information in a static (or scheduled) report. Requirements that demand a more dynamic approach would steer you to leveraging the AXL/SOAP interface.

    HTH.

    Regards,
    Bill

Leave a Reply