[cisco-voip] IM&P Jabber Flexible JID and Failed Logins

[Anthony Holloway]

All,

This is more of a PSA, but I also wanted to know if anyone has seen this
weird issue before.

*The Setup*

   - CUCM and IM&P 11.0(1)
   - Jabber 11.5(2)
   - CUCM LDAP maps Directory URI to mail
   - Flexible JID (based on Directory URI) is enabled on IM&P
   - AD User IDs are a mixture of numeric IDs (representing employee ID)
   and names (for contractors and interns).


*The Problem*

I had a few users say that they couldn't login to Jabber.  They were
getting "Cannot Communicate With Server"

Let's focus on this one user: Anthony Holloway (me)

   - User ID = 1001
   - Directory URI/Mail/JID = aholloway at company.com
   - IM Chat Alias = aholloway

So, I did the typical stuff: network, DNS, telnet, UDS access, self-care
portal access, enabled for IM&P, etc.  Nothing.  Then, I pulled client logs
and found the following error:

INFO  [CXmppClient::logEscapedMessage] - @XmppSDK: #0, 86, Recv:<failure
xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><temporary-auth-failure
/></failure>
ERROR [CXmppClient::handleLog] - @XmppSDK: #0, SASL authentication failed!


That's super helpful.  So, I enabled some server side traces: Cisco Tomcat
Security, Cisco Client Profile Agent, Cisco XCP Authentication Service,
Cisco XCP Connection Manager, and Cisco XCP Router; then reproduced the
problem.  I was then able to see the successful authentication via Tomcat
Security logs, towards AD, for my 1001 user:

DEBUG [http-bio-443-exec-391] impl.AuthenticationLDAP - auth: Creating new
InitialDirContext using dn = CN=1001, OU=Users, DC=company, DC=com
DEBUG [http-bio-443-exec-391] impl.AuthenticationLDAP - auth: successful
for dn CN=1001, OU=Users, DC=company, DC=com


Ok, so that's interesting.  I was then able to see the failure in the Cisco
XCP Authentication Service logs, as the following:

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


Hmm, that's weird that it was using my alias to find me by user ID.
Afterall, my user ID is 1001, and not aholloway.  Well, what values did the
SQL return then?  Maybe we can just execute that SQL query on the CLI and
find out for ourselves....let's see.

admin:run pe sql ttroute SELECT pkid, userid FROM validendusers WHERE
userid = 'aholloway'
<msg><type>TTROUTE</type><table>validendusers</table><action>Q</action><time>0</time><old><1>276f67cc-f43d-4027-bcb5-c7c693438abf</1><5>1</5><4>e4b65fcc-c6ae-62c2-2a6d-d27db6ba5005</4><0>00000001:57bdc1b4:00064a6b:00000a97</0><3>aholloway</3><2>aholloway</2><6>
andrew.holloway at company.com</6></old></msg>


Now we can see the root cause starting to take shape.  The server attempted
to locate my user record, based on my alias, but my user ID is actually
1001 and not aholloway.  User ID aholloway belongs to a contractor named
Andrew Holloway.

That would explain this line in the error:

imaddress and userid queries returned conflicting rows


When I looked for a user where this sharing of alias and user ID does not
exist (John Smith (1002) jsmith at company.com), the outcome looked like this:

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


So, the server was able to recover itself from incorrectly looking up the
user ID as the alias, and then falling back to the actual users ID (all
numeric).

That was it then.  I simply disabled Andrew Holloway's ability to log into
Jabber by unchecking the box on his end user page, and then Anthony
Holloway, or I, could login just fine.

I think most businesses would avoid having two people: where one's
sAMAccountName matches the mail alias of the other, so this may not be all
that common, but I wanted to share it nonetheless.  Maybe some TAC folks on
the list would be interested in this (Raj?). ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160825/27ee6b0c/attachment.html>