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

Tue Jun 19 16:28:11 EDT 2018

Whoa. That’s just weird. A login should be an identical match. Looks like the SQL statement being used is a “like” or “subset”.

---
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 | 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: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Sent: Tuesday, June 19, 2018 3:40 PM
To: Lelio Fulgenzi <lelio at uoguelph.ca>
Cc: Pawlowski, Adam <ajp26 at buffalo.edu>; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] multiple domain support for jabber (both)

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<mailto:aholloway at company.com>

No where in the current environment does the user use the User ID (45633) with the domain (company.com<http://company.com>).

E.g., This would be out of place: 45633 at company.com<mailto: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<mailto:aholloway2 at company.com>, since Anthony Holloway, the employee, already has aholloway at company.com<mailto: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<mailto:aholloway at company.com>

User 2
Name = Alexander Holloway
User ID = aholloway
Email = aholloway2 at company.com<mailto: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<mailto: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<tel:(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

-----Original Message-----
From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto: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<mailto: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<http://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><mailto: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<mailto:some.user at company.com>, but, your userID is actually suser. So some.user at company.com<mailto: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<mailto: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<mailto:suser at external.company.com> or suser at telephony.company.com<mailto: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<mailto: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<mailto: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<http://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><mailto: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<tel:(519)%20824-4120> | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca><mailto:lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>>

www.uoguelph.ca/ccs<http://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<mailto: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<mailto:nareh84 at hotmail.com>>; cisco-voip at puck.nether.net<mailto: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><mailto:rhuff at oneacmeone.com<mailto:rhuff at oneacmeone.com>> instead of Ryan.Huff at oneacmeone.com<mailto:Ryan.Huff at oneacmeone.com><mailto: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><mailto: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><mailto: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><mailto: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<http://oneacmeone.com> and twoacmetwo.com<http://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><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<mailto: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<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto: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/b4093744/attachment.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/20180619/b4093744/attachment.png>