Jabber-config.xml security

[scr.sybex1]

Dear,

I have cucm 8.6 and cups 8.6. I write xml that needed for jabber client and upload it on cucm tftp.

any client that can use jabber, can get(see) the jabber-config.xml file on cucm. i use an access-list to deny access to 6970 port on cucm but when i do that the jabber client can't download that too and not work for this scenario.

i need solution to deny access to that xml file beacause some configuration and password is in that file.

Thanks,

[Jaime Valencia]

There is nothing built in to do what you're asking, CUCM has no way to prevent you from downloading the file, or seeing it on your machine.

[prasenjitb]

Hi Jaime,

How can i confirm that the updated jabber-config.xml file is downloaded successfully in my jabber client (be it windows or android or Iphone). Which folder in the client to search for in each case and what will be the file name.

[Jonathan Schulenberg]

I do not believe the actual jabber-config.xml file is kept locally anymore; however, the files that Jabber does generate are here: %USERPROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config.

If you see the updated XML file by typing http://cucm.fqdn:6970/jabber-config.xml into your browser then Jabber will get that the next time you quit and relaunch it. Don't forget to check all TFTP nodes in your CUCM cluster.

[prasenjitb]

Hi Jonathan,

Thanks for the update, many confusions got cleared.

Actually in my present deployment we have split DNS where the user login with userid@internal-domain to jabber both from within the corporate network and also from internet (MRA). The internal-domain is not routable while ExpE sits on the routable domain. The jabber-config.xml file is populated with the voice service domain as the external routable domain. Jabber login is successful both from within the corporate network and internet (MRA). However when Jabber client is connected through MRA dialing to other extensions and PSTN is happening (rining and ring back) but it is complete silence at both ends when the call gets connected. Also call hold / MOH is not working and the call gets disconnected when hold is pressed in the windows Jabber client 11.5.4. In our deplyment ExpE (X8.6) is with dual NIC and i think its a issue with the firewall rules / ports. I have followed the cisco doc (attached) but not able to figure out how the rules will be when ExpE has dual NIC. Can you please guide me in the right direction. Also we have B2B calling and Jabber Guest implementation with ExpE dual NIC. There is separate Expressway pair for MRA + B2B and Jabber guest. Can i have a detailed config guide covering both B2B and Jabber guest detailing search rules, zone configuration and other necessary steps.

Thanks

[Jonathan Schulenberg]

In addition to Jaime's answer, Cisco has deprecated support for putting LDAP bind credentials in the jabber-config.xml file with Jabber 11.8. Be careful not to upgrade to that version or newer without also upgrading CUPS to a current release and updating your configuration.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/11_8/RN/cjab_b_release-notes-for-cisco-jabber-windows-118.html#reference_56DD8276CCB81719795237B3B1469577

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/11_8/cjab_b_planning-guide-jabber-118/cjab_b_planning-guide-jabber-118_chapter_0101.html

Going forward, the use of UDS, UDS with LDAP Proxy in 11.5, or CDI with the native Windows APIs are preferred. If you need to bind to LDAP with credentials Jabber 11.8 can be configured to reuse the Jabber login credentials of the user, assuming your not using SSO, or for the user to manually supply them in File > Options. Of course, anonymous bind is also supported. For the same security reasons you're concerned over, the use of a generic/shared LDAP bind account is being deprecated.

Assuming they record it, you may want to watch BRKUCC-2076 - Understanding Jabber User ID planning and directory integration. (2017 Berlin) when it's posted after Cisco Live Berlin is finished. The slide deck will be posted fairly quickly but recordings sometimes take a few weeks to show up.

[Gordon Ross]

The problem (for me) is that the UDS LDAP proxy is *very* limited, and doesn't have the same capabilities as the the native LDAP interface in Jabber. So much so, that we can't integrate into our LDAP directory now, without building some kind of LDAP translator

:-(

GTG

[Jonathan Schulenberg]

The CDI approach still supports direct LDAP binds. The only thing that has changed is the deprecation of the separate BDI parameters and support for hard-coding a set of credentials in the XML file. CDI supports both what was formally known as EDI and BDI.