04-08-2015 10:50 AM - edited 03-17-2019 05:03 PM
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about Directory Integration of Cisco Jabber client.
Ask questions from Monday, April 13th, 2015 to Friday, April 24th, 2015
Cisco Jabber has the capability to obtain the directory information directly from either LDAP or CUCM server- using EDI, BDI or UDS. Enhanced Directory Integration (EDI) is an LDAP-based contact source for Cisco Jabber for Windows clients. Basic Directory Integration (BDI) is an LDAP-based contact source for non-Windows Jabber clients (MAC and Mobile).Cisco Unified Communications Manager UDS is a Cisco Unified Communications Manager contact source and is available as a contact source for all Cisco Jabber clients. UDS is the contact source used for Expressway Mobile and Remote Access.
The directory parameters can be configured using jabber-config.xml file or the service profile. Alternatively, Cisco Jabber for Windows can also automatically discover and connect to the directory server if the workstation on which you install Cisco Jabber is on the Microsoft Windows Active Directory domain.
Furthermore, Cisco Jabber can also search for contacts from the Personal Address book in Microsoft Outlook client using MAPI when both the clients co-exist in a PC.
This session aims in helping customers with the design, configuration and troubleshooting of Cisco Jabber Directory Integration.
Ritesh Tandon is currently a senior engineer on the collaboration team in Bangalore TAC. His areas of expertise include Cisco Unified Communications Manager and UC applications which integrates with it. Ritesh has over 5 years of experience in Unified Communications as a whole. He focuses on troubleshooting and working with various voice products and clients, including Cisco unified communication manager, Cisco Jabber, Cisco Im and Presence Server, Cisco Attendant Console Suite , Cisco Emergency Responder and many more. Prior to joining Cisco he has also worked on Nortel\Avaya PBX and Contact Center Deployments. He holds a Bachelor of Engineering degree in Electronics and Telecommunication from Punjab technical University.
Nirmal Issac is a customer support engineer in Cisco TAC team for Unified Communications technology based in Bangalore. His area of expertise include Cisco Unified Communications Manager, IM & Presence server, Cisco Jabber, Cisco Emergency Responder and Attendant Console. He has over 3 years of industry experience working with large enterprises and Cisco Partners. He holds a Bachelor of Engineering degree in TeleCommunication. He also holds CCIE certification (#45964) in Collaboration technology.
Find other https://supportforums.cisco.com/expert-corner/events.
**Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions
04-13-2015 12:42 PM
Good afternoon and thanks in advance for hosting this ask the expert.
Our current deployment is considered a hybrid-cloud model. We use WebEx Connect/Messenger for IM&P, with our onsite CUCM cluster providing voice/video integration. We also are using directory integration to create/manage our users in the WebEx Connect ORG.
My question is, can we also use UDS integration from CUCM to provide extra directory information for devices that are located in CUCM but not our WebEx Connect ORG? Will this interfere with the webex connect directory?
Also, it seems the documentation for a hybrid deployment such as our is limited, do you have any references to the feature differences between cloud and on-prem IM&P?
Thank you,
Tim
04-13-2015 01:40 PM
Hi Tim,
Thank you for your query. Although our session primarily focuses on Jabber On-Premise deployment, I will be more than happy to answer your questions.
a) Contact Source in Hybrid Deployment
Cisco Jabber only supports WebEx Cloud as the contact source in On-Cloud Hybrid deployment. UDS is not supported. Please refer the below document.
b) Feature comparison between On-Prem mode and On-Cloud mode
The Cisco Jabber planning guide provides an overview of the deployment scenarios.
However I will try to find a more comprehensive document highlighting all the feature differences, or I will make one. I will provide you the information soon.
I hope this is helpful. Please let me know if you have any additional questions.
Nirmal Issac
04-13-2015 01:57 PM
Nirmal Issac,
I appreciate you taking the time to respond. I will take a look at the links provided and watch for any other information you may come across.
Thanks,
Tim
04-20-2015 01:04 AM
Hi Guys
I am trying to enable SIP URI dialling for an on-premise IM&P solution but the local jabber-client does not appear to accept a valid locally installed jabber-config-user.xml or jabber-config.xml files uploaded to CUCM TFTP root and TFTP services restarted.
I have attempted to generate a file from the jabber-config.xml generator found in the support forums & also from my working Jabber (albeit i am using hybrid). There appears to be confusion regarding the syntax of SIPURIdial(l)ing - one l or 2 l's ? The generator produces one "l", my local file here is 2 "l"'s
<EnableSIPURIDialling>true</EnableSIPURIDialling>
OR
<EnableSIPURIDialing>true</EnableSIPURIDialing>
i have tried both formats with no success
I want to prove whether the issue is local PC/FIrewall/anti-virus with a known working file.
can one be posted here please?
thanks
Stuart
04-13-2015 11:32 PM
I'm new to Jabber technology, and I would like to understand in detail the differences between EDI, BDI and UDS.
04-14-2015 03:37 AM
Hi Sudharshan,
Thank you for that query.
To start with, let me explain you what a Directory Source is ,and will also give you a short description of each Directory Source jabber uses :-
When using a Jabber client, a user searches for contacts and creates a list of contacts and the client resolves contact details for incoming communication. To perform these functions the client must have access to contact data to search. Jabber refers to this source from which it gets user information, as a Directory contact source.This contact source can be an LDAP directory such as Microsoft Active directory or OpenLDAP.
Alternatively we can also search users from CUCM using UDS service running on CUCM.Jabber can also use local contact sources such a Microsoft Outlook on Microsoft Windows.
So to summarize we can have following Directory sources, from which jabber can search users :-
UDS ---> In which jabber searches users from CUCM. In this jabber queries the UDS service which is running on CUCM.
EDI ---> Enhanced Directory Integration is used by Jabber windows to search users on LDAP directory such as Microsoft Active directory or OpenLDAP. This is specific to Jabber windows only.
BDI ---> Basic Directory Integration is used by Jabber clients on non-windows platform (such as Jabber Android, jabber Iphone , Jabber mac) to connect to LDAP directory such as Microsoft Active directory or OpenLDAP.
Outlook ---> Only Applicable for jabber windows clients, which also have Outlook installed on the same system. Jabber uses MAPI to connect to Outlook in order to sync in users in Outlooks Personal Address Book.
More information on EDI and BDI :-
+++++++++ EDI Configuration required for Jabber windows ++++++++++++++++
Jabber windows can be enabled to search Active Directory by doing the following :-
PC where Jabber windows is on the same domain as that of the Active Directory :-
-- >> When the jabber client is in the same domain , as the LDAP server, it automatically detects the LDAP server and connects to it. No Explicit configuration required.
PC where Jabber windows is not on the same domain as that of the Active Directory :-
-- >> Under this scenario it is required to configure the jabber attributes for Directory Search, when the jabber client is not in the same domain as the LDAP server.
This is done on jabber-config.xml file which has to uploaded onto the CUCM TFTP. Jabber client then downloads it when it is launched the next time and takes all the configuration necessary to connect to the Active Directory.
Sample EDI configuration looks like :-
<DirectoryServerType>EDI</DirectoryServerType>
<ConnectionType>0</ConnectionType>
<PrimaryServerName>14.160.103.39</PrimaryServerName>
<ServerPort1>389</ServerPort1>
<UseWindowsCredentials>0</UseWindowsCredentials>
<ConnectionUsername>administrator</ConnectionUsername>
<ConnectionPassword>cisco</ConnectionPassword>
<SearchBase1>dc=lab,dc=local</SearchBase1>
<SearchTimeout>30</SearchTimeout>
<CommonName>cn</CommonName>
<DisplayName>displayName</DisplayName>
<Firstname>givenName</Firstname>
<Lastname>sn</Lastname>
<EmailAddress>mail</EmailAddress>
<BusinessPhone>telephoneNumber</BusinessPhone>
<MobilePhone>mobile</MobilePhone>
<HomePhone>homePhone</HomePhone>
<OtherPhone>ipPhone</OtherPhone>
+++++++++ BDI Configuration required for Jabber mac and other non-windows platform jabber runs on like jabber mobile for android and iPhone ++++++++++++++++
As jabber windows uses EDI configuration , jabber mac uses BDI configuration to connect AD.
The configuration is almost as same as EDI , except for the fact that the BDI configuration is prefixed by parameter ‘BDI’.
Both EDI and BDI configuration can exist in the same jabber-config.xml file.
Sample BDI configuration looks like :-
<DirectoryServerType>BDI</DirectoryServerType>
<BDILDAPServerType>AD</BDILDAPServerType>
<BDIPrimaryServerName>14.160.103.39</BDIPrimaryServerName>
<BDIPresenceDomain>lab.support</BDIPresenceDomain>
<BDIConnectionUserDN>administrator</BDIConnectionUserDN>
<BDIConnectionPassword>cisco</BDIConnectionPassword>
<BDIServerPort1>389</BDIServerPort1>
<BDISearchBase1>dc=lab,dc=local</BDISearchBase1>
<BDIBusinessPhone>telephoneNumber</BDIBusinessPhone>
<BDIMobilePhone>mobile</BDIMobilePhone>
<BDIHomePhone>homePhone</BDIHomePhone>
<BDIOtherPhone>ipPhone</BDIOtherPhone>
<BDIEmailAddress>mail</BDIEmailAddress>
You can read more on BDI configuration for jabber mac from here :-
You can read more on EDI configuration for jabber windows from here :-
Hope this helps in providing an overview.
Let me know if you have further queries
Thanks,
Ritesh Tandon
04-14-2015 02:46 AM
Hi,
We use EDI integration for our company using a common account to run directory services, username and password is defined in service account.
We are having issues that jabber suddenly feels to provide invalid credentials to the AD - so the directory common account gets blocked for to many failed login attempts. Hence the account gets locked, and directory services goes offline for 10minutes.
Why is this happening? Is it a common bug? What is the best practice here?
&&Marius
04-14-2015 04:01 AM
Hi Marius,
Thank you for the query. Please confirm if the version of Jabber in use is J4W 10.6.
At this moment, I would like to tell you that Cisco TAC/BU is aware of this issue reported in Cisco Jabber for Windows version 10.6. We have already opened an escalation with Cisco Jabber BU and this is currently work in progress.
Our engineers are working on isolating the root cause, and we will update you on the progress. Alternatively, you may also raise a TAC case to track this issue officially with the Cisco TAC.
Also, what we have seen is that this issue is not reported in the J4W versions 10.5.5 or earlier.
Please let me know if you have any additional queries.
Regards
Nirmal Issac
04-22-2015 01:25 AM
Hi,
Hello,
Do you have the bug id for this defect please? I ran into this issue recently. A Jabber client locked out the LDAP service account, which in turn prevented users from logging into the contact center! Separate accounts are now being used for the Jabber directory lookup and the Authentication LDAP user in CUCM.
Thanks
04-22-2015 07:06 AM
Hi Lee,
Thank you for the query. The defect 'CSCuu01267' is opened for this issue. You may track the progress on this issue from the below link.
https://tools.cisco.com/bugsearch/bug/CSCuu01267
Please let us know if you have any additional queries.
Regards
Nirmal Issac
04-22-2015 10:06 AM
Thanks Nirmal.
04-22-2015 08:52 AM
Can I ask how you are configuring Jabber to use common credentials? I know that you can hardcode a sAMAccountName and password into the jabber-config.xml file, but this is obviously not an ideal secure solution. I know the Username and Password on the UC Service Profile can be used for BDI clients (Jabber Mac), but have not yet had the time to test this with Windows.
Additionally, is it possible to configure Jabber to:
<UseWindowsCredentials>0</UseWindowsCredentials>
and use the "Use Logged On User Credentials" option? I really would like to stay away from the stored Username and Password (in either the Service Profile or jabber-config.xml) as every profile needs to be updated when the password for the service account is changed.
Long story short, all of our users have valid credentials in the same domain, it's just that their PC's may or may not be part of the domain in which UCM/CUP lives.
Thanks
Zack
04-22-2015 10:14 AM
Hi Zack,
The Service Profile can also be used for the Windows Clients as well. There is also the option to use logged on credentials in the service profile instead.
Whatever you configure on the Service Profile takes precendence over what is configured in the jabber-config.xml file.
04-22-2015 10:01 PM
Hi Zack,
Going through your description , I understand your setup and requirement as :-
++ I believe you have _cisco-uds SRV deployed in your environment, so when jabber logs in CUCM sends the service profile to the client.
++ You do not want to give a LDAP user account credentials (to be used by LDAP Bind by Jabber) either on the service profile or on the jabber-config.xml file.
++ All the windows PC\laptops on which jabber is running , are joined to the AD domain.
++ Users log on to these AD domain joined windows machine, using their ldap credentials.
Please do let me know if my above understanding is correct.
If yes , then since users are logging on to the windows machine , which is joined to the AD domain , then i believe no explicit configuration is required, either on the jabber-config.xml file or service profile for jabber windows.
Jabber would automatically discover the AD (since PC is joined to AD domain) and do a LDAP Bind with it using the credentials used by the user during windows log on.
You would not have to define this <UseWindowsCredentials>0</UseWindowsCredentials> , or anything else for jabber to take windows logon credentials.
Also to mention, if my above assumption from your query is wrong and in case not all PC's are joined to the AD domain, then on the service profile (assigned to the users) you can have "Use Logged On User Credentials" enabled.
To test if this works, I did the following test in my lab :-
My lab environment :-
CUCM\IM&P 10.5.1 , jabber windows 10.6.2 using _cisco-uds SRV , One PC on the AD domain, One PC not on AD domain.
Test 1 :-
++ Removed jabber-config.xml file (which had EDI configuration) from tftp.
++ On the service profile defined "UC profile" for Enhanced Directory , which is in turn is assigned to service profile.
++ Only had "Use Logged On User Credentials" enabled, no LDAP Bind credentials defined and no UDS enabled.
++ Logged into a PC which is not part of the AD domain, but the windows account is a valid ldap user.
++ Logged into jabber using UDS service discovery , after login I can see that LDAP Directory Bind is successful.
Test 2 :-
++ Removed jabber-config.xml file (which had EDI configuration) from tftp.
++ On the service profile defined "UC profile" for Enhanced Directory , which is in turn is assigned to service profile.
++ Only had "Use Logged On User Credentials" enabled, no LDAP Bind credentials defined and no UDS enabled.
++ Logged into a PC which is part of the AD domain, and the user is logged onto windows using his\her AD credentials.
++ Logged into jabber using UDS service discovery , after login I can see that LDAP Directory Bind is successful.
In the jabber logs for both the scenario's, I see this :-
++ 2015-04-23 09:25:43,804 DEBUG [0x00000fa0] [\Ucm90ConfigProviderWrapperImpl.cpp(481)] [service-discovery] [mapUcmConfigSetToStdMap] - Mapped Key:Value is : Directory/UseUserCredential : true
++ 2015-04-23 09:25:49,838 DEBUG [0x00000f18] [rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource] [WriteLogMessage] - ConnectionManager::GetDirectorySearcher - Using default windows credentials to connect [LDAP://14.160.103.46:389] with tokens [0]
So it looks like, this can be an option for you, if you want to go forward with.
Note : This will only work, if you are using _cisco-uds SRV service discovery to login into jabber windows.
Hope this information helps. You can check the same in your environment and revert back.
In case you have any further queries, let me know.
Thanks,
Ritesh Tandon
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide