We have a customer running CCM 7.1.3 and CUPS 8.6.4. CUPC works fine, but now they want Jabber for Windows.
Question 1. Does "Use LDAP Authentication for End Users" have to be selected in CCM?
Question 2. Can they continue to map "UserID" to "employeeNumber" or must it be "sAMAccountName"? (employeer number makes EM easier!)
LDAP Authentication of End Users in CUCM is strongly recommended for CUPC/Jabber. When you login to CUPC/Jabber it authenticates against CUCM. If LDAP doesn't have the same password (i.e. CUCM isn't synced from LDAP) the client won't be able to do LDAP queries if using BDI. This is because it re-uses the same credentials when it attempts to bind to LDAP. If Jabber is configured for EDI, which is only even possible on Jabber for Windows running on domain-joined workstations, then this is not as critical since it would use the Windows ADSI API in the context of the logged-in user. Using EDI exclusively would rule out Jabber for Mac, iOS, Android, and Windows on a non-domain joined workstation though.
As for usernames: You can continue to use employeeNumber if you wish. You'll need to ensure that the jabber-config.xml file maps the username to this value for everything to work. Note that this will be their XMPP URI: firstname.lastname@example.org so be sure that you're comfortable with employee numbers being public.
Just to clarify, CCM is synced to LDAP - with UserID mapped to employeeNumber (which is their DN number). In CCM, LDAP Authentication is currently set to off. My understanding is that if we turn this on - we can only use sAMAccountName, as LDAP cannot authenticate against other fields. Hence, we'd like to keep it off.
As we are on CCM 7.1 we need ot use EDI as UDS is not available until 8.6. I've created the following xml file:
Should this work okay?
Update: This is now working fine. CCM autentication to LDAP is off. User ID is mapped to employeenumber. The only change was this line in the config file:
I'm having some issues that seems like this one.
CUCM and CUPS on 8.6
My UserID on CUCM is "employeeNumber" instead os sAMAccountName.
And I am using LDAP authentication too.
The problem is when logging into Jabber for Windows.
On Jabber login I am using the employeeNumber as User, and the Network password which is set on AD.
First problem is that is taking too long to login and sometimes it doesn't, it gives a "cant communicato to server/timeout".
When you are able to login, instead of bringing the name of the person, it is getting "employeeNumber@domain.com".
And also, I cannot find other online people.
The LDAP search seems to be ok, the problem seems to be that the CUPS is not correlating the employeeNumber login with the actual user, since I can find myself on the search and it shows me as offline.
Any ideas on this?
Have you configured the jabber-config.xml accordingly ? Check this part of the configuration guide
You need to tell jabber to use the employeenumber as the user id
Not sure why your post is not showing up here, but yes, I did this as part of researching.
The jabber-config.xml file I've uploaded is this one at this point:
I also tried changing the "UserID" field under Application --> Cisco Jabber --> Settings on CUPS admin to "employeeNumber" too.
But I still can't see anyone online and not getting the name.
Not sure why it was deleted indeed. I see that you don't have any userid to authenticate to directory. Usually we use the
ConnectionUsername and ConnectionPassword for this. In the sniffer capture do you see any issues binding to active directory ?
Next step would be to check the jabber problem report.
I assume that is because I was on the default "UseWindowsCredentials" setting.
To be sure I modified that also, as I understood from documentation, this user is a general user with read-only privileges right?
This is what I added on the XML file:
Still the same issue.
Therer is no problem reported on the Jabber client, in fact, Connection Status shows everything Successfully connected, including Directory.
The Snifer you mentioned would be on the end user desktop?
Do you know already some sort of filter I can use to look at that?
I guess I did find something on the cs-unfied.log from Problem report on client.
I see the following line:
[csf.person.adsource] [WriteLogMessage] - Query::RunQuery - [LDAP-FILTER] Executing query with filter: (&(objectCategory=person)(sAMAccountName=8262))
Obviously it won't find any user on that sAMAccountName, and after that I have:
[ceareaplugin\PresenceAreaWindow.cpp(318)] [plugin-runtime] [OnClientUserDisplayNameChanged] - Setting new display name: email@example.com
I think I need to find a way to make this query on employeeNumber instead of sAMAccountName, but I still don't see where and why it is doing this Query.
I managed to map the employee ID attribute to the account name by using the jabber-config XML file. One thing to check is to see whether the Windows client is receiving the jabber file correctly. You can find this under the app data folder which is a hidden directory under the user folder within the C drive. Once there go to the Cisco jabber roaming settings. When you start the client from fresh the file should get written to that directory and you can read it in notepad etc.
That's a good idea. The full path for the jabber-config.xml in win7 is the following
You might want to delete the cache just in case. Simply delete the following folders
Hi, the problem is almost fixed!
I had already done this checking on the xml and it was updating OK.
Reading another discussion I decide to change Directory from EDI (I guess it is the default) to UDS.
I still need to study to understand the differences between, but now I get the correct names displayed and can find and chat with other users.
The xml modification done was:
Now the problem that remains is within the login, I need to try multiple time to get in.
Since my client is in Portuguese I'm not sure about the message in English, but it is something like this:
"Not able to communicate with server. Connection timeout"
I ended up opening a TAC before this last change since was in a bit of a hurry, so let´s see if I can get some help on this too.
Thanks all so far.
Thanks for the information! However I don't see why this shouldn't work with EDI while it works with UDS. I can try to reproduce but you can persue this with a separate SR if you want.