This is a rare occurance but I feel the need to disagree with Jaime here. Jabber Guest is a browser-based (currently a plug-in is required) audio/video client, not chat. It's sole purpose is to allow any unauthenticated party outside the firewall to call a CUCM/VCS endpoint inside the firewall. It can only initiate calls, not receive them.
I.e. a Jabber/XMPP Openfire clients external to the organisation to go through the firewall and hit our cisco presence server. Only IM functionality is required.
The thread originator specifically called out that only XMPP (i.e. chat) is required, not voice/video calls and Jabber Guest does not help you address this objective. In fact, there is no native Cisco product that does. Here are the options that I can imagine:
- Open TCP 5222 (xmpp-client), and probably ensure your IM&P server(s) DNS FQDN matches your public domain. Use an XMPP client of your choosing. I'm uncertain whether any application-layer NAT inspection is required for XMPP though so this would require some testing.
This is not recommended by Cisco. While the servers are reasonably hardened with SElinux and iptables, Cisco assumes they are run on trusted internal networks. For example, I am not aware of any protection mechanisms built into the XCP process that would prevent DoS or brute force authentication attacks. - Deploy Collaboration Edge (what Jaime was probably meaning to say) which will allow Jabber clients to create a TLS-protected tunnel across the firewall to the internal servers.
- Use Cisco AnyConnect or another VPN solution.
Federation is out of the equation, as our organisation are security/compliance conscious that gtalk / AOL / iChat have the ability to log messages outside the organisation.
Two comments: 1) unless you have absolute control over the client environment similar to Snap Chat, far-end logging is always possible. Nearly every XMPP client I'm aware of has this feature. 2) You can whitelist specific DNS domains that you want to allow federation with. It's not an all-or-nothing policy. In fact, you could even setup an OSS XMPP server in another domain namespace and federate with it for these "external clients."
Also, as the external clients are not part of the organisation, is there any way to create a user that is not imported from CUCM.
CUCM 9.0(1) and above allow you to have a mixture of local and LDAP-synced user accounts. You would need to use UDS in this design to ensure that Jabber could resolve all accounts, not only those in LDAP.
Please remember to rate helpful responses and identify helpful or correct answers.
