[cisco-voip] multiple domain support for jabber (both)

Tue Jun 19 15:40:16 EDT 2018

To add something to what Adam was saying about looking up different formats
of user names, I have a customer using flexible JID, because their User IDs
are numeric.

E.g., 45633 is Anthony Holloway

And their email addresses are alpha character based.

E.g., Anthony Holloway is at aholloway at company.com

No where in the current environment does the user use the User ID (45633)
with the domain (company.com).

E.g., This would be out of place: 45633 at company.com.

So, we switched them to flexible JID, so we could leverage email like
formatting for JIDs, though I must admit, since the introduction of
Automatic UPN discovery, it's kind of pointless.

For contractors, they do not get a numeric User ID (which is based on the
employee ID), and instead get the alpha User ID.  So say Alexander Holloway
was a contractor, then his User ID would be aholloway (no conflict with
Anthony [45633]), but his email would be aholloway2 at company.com,
since Anthony Holloway, the employee, already has aholloway at company.com.

Now, when Anthony goes to login to Jabber, he cannot, because Jabber strips
the user portion of the UPN when performing a lookup on the user, and
returns a conflict.  In the logs you will see this when Anthony tries to
login:

12:24:30.333 | debug| TokenAuthUtils::executeUserFromIMaddressQuery: IMDB
(userid) query successful: [SELECT pkid, userid FROM validendusers WHERE
userid='aholloway';]
12:24:30.333 | error| TokenAuthUtils::executeUserFromIMaddressQuery: imaddress
and userid queries returned conflicting rows. Returning error

When Alex the contractor's account is deleted, you will instead see this in
the logs when Anthony logs in successfully:

11:47:51.505 | debug| TokenAuthUtils::executeUserFromIMaddressQuery: IMDB
(userid) query successful: [SELECT pkid, userid FROM validendusers WHERE
userid='aholloway';]
11:47:51.505 | debug| TokenAuthUtils::executeUserFromIMaddressQuery: imaddress
query returned row but not userid.
11:47:51.505 | debug| TokenAuthUtils::executeUserFromIMaddressQuery: userid
set as [45633]

Jabber no longer has a conflict with Alex's username, but it does notice
that the user portion of the UPN is not the userid for Anthony, and then
progresses the login, using the now discovered user id.

*Summary*
You have two users, you're using flexible JID based on Directory URI, and
Directory URI is based on email address.  User 1 cannot login, because the
user portion of their UPN matches User 2's User ID.  User 2 can login,
since the user portion of their UPN does not match any user's User ID in
the system.

*User 1*
Name = Anthony Holloway
User ID = 45633
Email = aholloway at company.com

*User 2*
Name = Alexander Holloway
User ID = aholloway
Email = aholloway2 at company.com

At least, that was my experience pre-fast login.  Jabber is ever changing,
and so who knows how it behaves at any given point in time? Certainly not
me.

On Thu, May 24, 2018 at 3:57 PM Lelio Fulgenzi <lelio at uoguelph.ca> wrote:

> Thanks for the feedback. It will take me a while to digest. But very good
> info!
>
> The one thing I will comment on is your approach regarding everyone seeing
> the collab edge. I thought about this for a while, basically making
> everyone "off-prem" regardless of whether they were on-prem or not. I
> decided against this design for a few reasons: (a) it's not the norm, (b)
> it took some finagling of DNS to get to work, and (c) MRA feature parity
> was not quite there when we were looking at it (it's getting better, but
> still not there).
>
> The biggest reason I wanted to explore MRA Everywhere (tm) was to avoid
> having to worry about network access control lists. Right now, that's a big
> issue for us. Depending on how things go, I may have to suggest the MRA
> Everywhere (tm) option again.
>
> Thinking about it though, I was pretty sure there was a stumbling block
> somewhere along the way with the separate DNS servers for the C servers.
> I'm not quite sure what it was, but I think it had something to do with
> additional entries needed, i.e. you couldn't set up a pointer on the
> isolated DNS server to point to your general DNS servers, so any address
> you needed would have to be populated on the isolated DNS, i.e. syslog
> hosts, ntp hosts, etc. Or just use IP addresses?
>
> But I swear there was something else.... a circular reference issue I
> couldn't resolve.
>
> I might have to bug you about this later. 😉
>
> ---
> Lelio Fulgenzi, B.A. | Senior Analyst
> Computing and Communications Services | University of Guelph
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
> 519-824-4120 Ext. 56354 <(519)%20824-4120> | lelio at uoguelph.ca
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> -----Original Message-----
> From: cisco-voip <cisco-voip-bounces at puck.nether.net> On Behalf Of
> Pawlowski, Adam
> Sent: Thursday, May 24, 2018 3:47 PM
> To: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] multiple domain support for jabber (both)
>
> > We use a special discovery domain in order for on-prem and off-prem to
> work properly, i.e. MRA/Eway. We don?t have split view DNS enabled, so we
> deployed a set of DNS servers for a subzone which do have split view
> enabled, e.g. jabber.acme.com.
>
> We also don't have a split DNS view / zone for our domain, which seems to
> be pretty common.
>
> I used our ISRs that are used for TDM gateway to serve DNS only to the
> Expressway-C , and added the _cisco-uds record to the ISR. This way all the
> clients only see collab edge but the Expressway sees the UDS record it
> needs to reach the UCM for the client. Works great.
>
> When I tried the idea of a separate domain, what I ended up with was that
> Jabber would begin to connect on prem but then would see the domain
> everything really was on, and then it would eventually become half broken.
> Plus the idea of having to reset the client and hose around with it to move
> between prem/MRA seemed to be not so good from the customer side of things.
>
> > Curious why I would need to add it to the IM&P and CUCM certs.
>
> IM and Presence I believe needs to be able to secure itself for the
> domains that it serves for XMPP, so a premise client connecting to the IM
> and Presence host would need to see the domain represented in a SAN in
> order to accept it - or the client is prompted. I don't recall the UCM
> certificate mattering in this case but you do have to configure it to
> respond to SIP requests for those domains otherwise it doesn't do anything
> for direct requests. Not really a MRA function but it is for B2B.
>
> > I?m still not 100% clear on JID vs ??? and how that affects stuff. When
> users enter their userID at discoverydomain.acme.com<mailto:
> userID at discoverydomain.acme.com> in the first prompt, it flips and
> removes the FQDN information and just replaces it with their userID and the
> prompt for their password. But I believe if we stick with ?you must login
> with your userID? we will be safe.
>
> See this is not consistent in my experience. Sometimes it just goes to
> userID only with the prompt, but generally the full JID remains in the box.
>
> I did some digging on the MRA via Expressway thing and many of the cases
> seem to be centered around that the JID != URI in that your URI is
> some.user at company.com, but, your userID is actually suser. So
> some.user at company.com does a UDS lookup with that full string (UPN?) and
> fails, then tries some.user and fails, so it doesn't find a home cluster
> and nothing happens it just dies. If your userid is suser, and your URI
> based on mail is suser at company.com, then it works just fine. But my
> understanding of these things and flex JID is that you can flex the
> presence domain but not the userID. If it does let you flex the userID
> portion then I guess that makes sense why it doesn't work.
>
> In that scenario, suser at external.company.com or
> suser at telephony.company.com whatever you put there doesn't matter. It
> would be used for service discovery for a raw MRA login, and as long as DNS
> works, and a UCM serving that domain responds to "suser" as its home
> cluster it will proceed to authenticate the user based on userID and it
> should work.
>
> This would probably be a good opportunity to use the
> msRTCSIP-PrimaryUserAddress field in AD to populate suser at company.com and
> make that the URI, then programmatically stack email on top of it for B2B
> routing / use CPL/Transforms, but you're fighting the system at that point
> and it will be painful or annoying.
>
> The salt on that wound is Jabber re-orienting the customer's signin prompt
> to enter your company email address - so if your JID isn't your mail
> address, your customers would have to know what to do.
>
> I'm going to be getting into this now as I find that a domain I need to
> support can have potentially 25 other subdomains in use with mail, which
> means 25 domains worth of cert, config, and DNS, or I use the msRTCSIP
> workaround and explain them what to do. Fighting the architecture is sort
> of fun but in this case it will only cause pain.
>
>
> Adam
>
>
>
> ubject: Re: [cisco-voip] multiple domain support for jabber (both
>         internal and MRA)
> Message-ID:
>         <
> YQBPR0101MB0945BCBCD2779174949A9820AC6A0 at YQBPR0101MB0945.CANPRD01.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Just following up on this.
>
> We use a special discovery domain in order for on-prem and off-prem to
> work properly, i.e. MRA/Eway. We don?t have split view DNS enabled, so we
> deployed a set of DNS servers for a subzone which do have split view
> enabled, e.g. jabber.acme.com.
>
> I did add this domain to the e-way certs. Curious why I would need to add
> it to the IM&P and CUCM certs.
>
> On IM&P I created a clusterID, but no other reference to the discovery
> domain. And on CUCM, no reference at all to these discovery domains.
>
> I?m still not 100% clear on JID vs ??? and how that affects stuff. When
> users enter their userID at discoverydomain.acme.com<mailto:
> userID at discoverydomain.acme.com> in the first prompt, it flips and
> removes the FQDN information and just replaces it with their userID and the
> prompt for their password. But I believe if we stick with ?you must login
> with your userID? we will be safe.
>
> We?re still in pilot mode, considering mass deployment. Will have to
> consider the options around automatically assigning the discovery domain.
> But the more we do, the less the user knows. So, they?re stuck with
> whatever customization we make.
>
> Lelio
>
>
>
> ---
> Lelio Fulgenzi, B.A. | Senior Analyst
> Computing and Communications Services | University of Guelph Room 037
> Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
> 519-824-4120 Ext. 56354 <(519)%20824-4120> | lelio at uoguelph.ca<mailto:
> lelio at uoguelph.ca>
>
> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram,
> Twitter and Facebook
>
> [University of Guelph Cornerstone with Improve Life tagline]
>
> From: cisco-voip <cisco-voip-bounces at puck.nether.net> On Behalf Of Ryan
> Huff
> Sent: Sunday, May 20, 2018 10:20 AM
> To: naresh rathore <nareh84 at hotmail.com>; cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] multiple domain support for jabber (both
> internal and MRA)
>
> Hi Naresh!
>
> There is a lot that could be unpacked here, in terms of a reply, because
> this area of Cisco UC can be a bit of a big "if then, do else" decision
> matrix if you're not familiar with all the underlying players. From a
> 10,000 foot view, multi domain support will work pretty much like having a
> single domain; you'll just need to account for multiple domains in a couple
> of key areas.
>
> As a matter of preparation, I would start planing now for the second AND
> first domain being advertised as a Subject Alternative Name in the
> Expressway Edge and Control (juxtaposed to just having the first domain),
> CCM and CCM IM&P SSL certificates. Whether the certificates are self-signed
> or 3rd Party signed is immaterial.
>
> On the IM and Presence side, you'll be configuring multiple presence
> domains, one for each of your domains. In the Expressway Control server,
> you'll configure two domains as well; each will build a separate SSL tunnel
> (over port 2222) to the Expressway Edge server that will allow the Edge
> server to answer on port 8443 and accept registration for whichever domain
> is being requested.
>
> All the internal and external DNS HOST / SRV record requirements are
> needed for both domains, as should and would be expected. If you have an
> Expressway cluster, your DNS journey is about to get real fun ?!
>
> Regarding User ID in CCM; I'm assuming both domains are AD integrated into
> CCM (meaning that the LDAP sync'ed End User accounts could come from an OU
> in one or the other domain). Its worth noting that FJID (Flexible Jabber
> ID) is not supported through MRA. FJID is the ability to authenticate to
> the Jabber client with a User ID other than whats in the End User's UserID
> field the Presence and IM server is looking at for user authentication.
>
> FJID works with an internal login, but not through an MRA login. For your
> scenario, any changes desired in the way a Jabber user logs in (Ex. I want
> to login as rhuff at oneacmeone.com<mailto:rhuff at oneacmeone.com> instead of
> Ryan.Huff at oneacmeone.com<mailto:Ryan.Huff at oneacmeone.com>) should always
> be handled at and through the authentication source; in this case, Active
> Directory.
>
> Good Luck on your journey, you will learn a lot on this one!
>
> Presence and IM multiple domains:
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/11_5/CJAB_BK_C6FFF6D8_00_cisco-jabber-115-planning-guide/CJAB_BK_C6FFF6D8_00_cisco-jabber-115-planning-guide_chapter_0100.html#CJAB_RF_ICB63026_00
>
> Expressway Domain Configuration:
>
> https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-10/Cisco-Expressway-Basic-Configuration-Deployment-Guide-X8-10.pdf
> ________________________________
> From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:
> cisco-voip-bounces at puck.nether.net>> on behalf of naresh rathore <
> nareh84 at hotmail.com<mailto:nareh84 at hotmail.com>>
> Sent: Saturday, May 19, 2018 8:24 PM
> To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> Subject: [cisco-voip] multiple domain support for jabber (both internal
> and MRA)
>
>
> hi
>
>
>
>
>
> I have to configure Cisco Jabber for both Internal and MRA login. user
> information is already imported from LDAP. this environment take care of
> telephony requirement of two companies. so there are two domains (for e.g.
> oneacmeone.com and twoacmetwo.com). i have following queries.
>
>
>
>   1.   what configuration changes are required on im and presence?
>   2.   do i have to make changes on expressway e and c in regards to
> support of multiple domain?
>   3.   i think i have to change jabber-config file as well?
>
>
> I found following link. Pls suggest.
>
>
>
>
> https://www.cisco.com/c/en/us/support/docs/unified-communications/jabber-windows/118999-config-imaddress-jabber-00.html
> [https://www.cisco.com/web/fw/i/logo-open-graph.gif]<
> https://www.cisco.com/c/en/us/support/docs/unified-communications/jabber-windows/118999-config-imaddress-jabber-00.html
> >
>
> Configure the IM Address Scheme for Multiple Domain ...<
> https://www.cisco.com/c/en/us/support/docs/unified-communications/jabber-windows/118999-config-imaddress-jabber-00.html
> >
> www.cisco.com<http://www.cisco.com>
> This document describes the configurations required in order to use
> flexible instant messaging (IM) address scheme with Cisco Jabber. The
> feature is supported from Cisco Jabber version 10.6 and later and IM
> Presence server 10.x.
>
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://puck.nether.net/pipermail/cisco-voip/attachments/20180524/7fd670e8/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image001.png
> Type: image/png
> Size: 1297 bytes
> Desc: image001.png
> URL: <
> https://puck.nether.net/pipermail/cisco-voip/attachments/20180524/7fd670e8/attachment-0001.png
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> ------------------------------
>
> End of cisco-voip Digest, Vol 175, Issue 16
> *******************************************
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180619/02f62e63/attachment.html>