One of our core competency in identity and access management space is implementation of solutions based on Forefront Identity Manager platform. In the course of implementing several of such projects we have developed products and IP assets. Parts of these assets we are offering either as community asset (check our GitHub profile) or products available from Predica.
Judging by number of inquiries we are getting through our web page one of most popular element from our offering is Cisco Unified Communication Manager management agent. Our development lead – Maciej, took some time to provide a bit of insight on this MA. Enjoy …
As you have, or have not, already noticed Predica provides an interface to integrate Cisco Unified Communications Manager with FIM. This interface is of course dedicated Management Agent that can “talk” to CUCM AXL web services providing FIM with native connectivity interface to CUCM. Number of questions we get on the topic might be related to the fact that at this moment Predica is the only company offering such solution (see Google search result ). To help to understand our offering to those who looks for it we’ve decided to share our product in a greater depth on this blog.
CUCM instance data
This post is intended to be a small demo of our MA’s capabilities. Let’s start by introducing the data that will be used. First, let’s have a look at the users defined in our CUCM instance:
As you can see, we only have 3 users in the system (of course CUCM will usually have many more of them, probably several dozens thousand users, but this will suffice for our purposes).
Users in CUCM can be “connected” to phone numbers, which in most cases is what we are interesting to get from, in many ways. We support all of them (more on this later), but this scenario assumes that “phone lines” are associated with users by “Device profiles”. Here is a device profile associated with users “GCH060”:
It has two lines (“phone numbers”): 11 and 12.
Our MA is able to handle three types of CUCM objects for now: Users (called “End users” in CUCM), Phones (called “Devices” in CUCM) and Hunt Lists. Let’s see how it works in practice.
Creating Predica CUCM MA
First we need to create a new MA using FIM Synchronization Service Manager.
After starting “Create Management Agent” wizard I selected “Extensible Connectivity 2.0” as MA type. I also gave it a descriptive name so that later I know what I am using.
Note: This MA supports both ways to operate in FIM – ECMA 1.0 and ECMA 2.0. This demo uses 2.0 version, because 1.0 will become obsolete in the future.
Next I selected our dll that contains the MA: “Predica.FimExtensions.CCM.dll”. Naturally, I needed to copy it first to FIM extensions directory: “C:Program FilesMicrosoft Forefront Identity Manager2010Synchronization ServiceExtensions”. After selecting the dll I needed to press “Refresh interfaces” – it allows the tool to scan our assembly and verify that it in fact contains a correct MA definition:
Next screens contain configuration entries for our MA. I left all of them blank.
We provide two ways of configuring the agent. One way is to fill all the fields in Sync Manager. Another way is through a configuration file. I choose to follow this approach because it’s easier to change an XML file than to click through UI of Sync Manager. More on configuration file – later in this post.
In “Select Object Types” screen I choose to handle only User object type. It is easier to operate on a single type when presenting a simple demonstration.
I choose to use all user’s attributes.
Configuring a user Anchor is necessary – I use “ID” attribute which contains a GUID generated by CUCM.
We do not want CUCM to create new users in Metaverse, we only want to join users that are already present. So we configure a single Join rule and no Projection rules. UserId attribute needs to be equal to accountName in Metaverse in order to map CUCM users to users already handled by FIM.
For the purposes of this demo we will only define two Export attribute flows. First and Last Names, when modified through FIM portal, will be sent to CUCM, just to show that exporting data from FIM to CUCM is also supported:
And it’s done – our CUCM MA is almost ready to communicate with Cisco Call Manager.
As I mentioned before, we support two ways of configuring our MA. You can either fill in the fields in Sync Manager or create a simple XML file. You can also split the configuration using both approaches – values from Sync Manager always take precedence over the ones defined in config file.
To use configuration file, you first need to modify the sync engine config: “C:Program FilesMicrosoft Forefront Identity Manager2010Synchronization Servicedllhost.exe.config”.
Open it and add this entry in “configSections” section:
<section name="ccmSettings" type="System.Configuration.AppSettingsSection, System.Configuration, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" restartonexternalchanges="false" requirepermission="false"></section>
Then, add this entry just below “configSections” section:
<ccmSettings configSource="ccm_settings.config" />
These modifications tell the environment that it should look for CUCM-specific configuration entries in a file called “ccm_settings.config”. Go ahead and create it, next to the dllhost.exe.config. Here is the simplest configuration file content that is used in this demo:
<?xml version="1.0" encoding="utf-8" ?>
<add key="CCM.url" value="https://192.168.1.200:8443/axl/"/>
<add key="CCM.username" value="admin"/>
<add key="CCM.password" value="password"/>
<add key="CCM.soapActionHeader" value="CUCM:DB ver=7.0"/>
<add key="CCM.queries.users" value="u.pkid, u.userid, u.firstname, u.lastname, d.pkid phoneid, n.dnorpattern phonenumber from enduser as u left outer join enduserdevicemap as eudm on eudm.fkenduser=u.pkid left outer join device as d on d.pkid = eudm.fkdevice left outer join devicenumplanmap as dmap on dmap.fkdevice=d.pkid left outer join numplan as n on dmap.fknumplan = n.pkid where u.status == 1 and (eudm.defaultprofile is null or eudm.defaultprofile == ‘t’)" />
As out can see, it contains information “how to connect to CUCM” and a query that is used to fetch users from CUCM, along with their phone numbers. Remember how I stated that we support all ways of associating users with phones in CUCM? Well, here it is. It is all just a matter of a correct query sent to CUCM web services. Nothing is hard-coded, you have full control over the communication process and data sent to and from CUCM.
Testing our configuration
Now after initial setup let’s test our MA in simple import operation. Let’s configure Full import staging operation and pull users from our sample CUCM instance. As you can see below we have pulled three user’s objects from CUCM:
Among others we can see our test user GCH060 with some additional details:
In user details we can see multivalue attribute PhoneNumber, which provides information about line extensions assigned to user in Call Manager.
In similar manner we can pull and expose other information from CUCM as our agent is building connector space attributes based on the output from queries used to pull the data so it is not fixed in anyway in code base.
Also agent can retrieve references between objects and present it as reference attribute. This enabled scenarios where agent can present information about devices assigned to a user with device details and reference attribute which points to the user, or hunt list (line groups) information with list of users, who are members of these groups (actually who’s lines are assigned to these groups).
Through this agent we can also provision new users to CUCM and synchronize passwords and PINs to this target system. But this will be presented in second part of our CUCM description as this post has already become a bit longer than expected. Hopefully with benefit to all who may be interested in that kind of solution.
For further details on our CUCM MA and also on our experience of migration v1 Extensible MA to ECAMv2 … stay tuned to our blog.