<div dir="ltr">All,<div><br></div><div>This is more of a PSA, but I also wanted to know if anyone has seen this weird issue before.</div><div><br></div><div><b><u>The Setup</u></b></div><div><ul><li>CUCM and IM&P 11.0(1)<br></li><li>Jabber 11.5(2)<br></li><li>CUCM LDAP maps Directory URI to mail<br></li><li>Flexible JID (based on Directory URI) is enabled on IM&P<br></li><li>AD User IDs are a mixture of numeric IDs (representing employee ID) and names (for contractors and interns).<br></li></ul></div><div><br></div><div><b><u>The Problem</u></b></div><div><b><u><br></u></b></div><div>I had a few users say that they couldn't login to Jabber.  They were getting <span style="background-color:rgb(244,204,204)">"Cannot Communicate With Server"</span></div><div><br></div><div>Let's focus on this one user: Anthony Holloway (me)</div><div><ul><li>User ID = 1001<br></li><li>Directory URI/Mail/JID = <a href="mailto:aholloway@company.com">aholloway@company.com</a><br></li><li>IM Chat Alias = aholloway<br></li></ul></div><div>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:<br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">INFO  [CXmppClient::logEscapedMessage] - @XmppSDK: #0, 86, Recv:<failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><span style="background-color:rgb(244,204,204)"><temporary-auth-failure /></failure></span></font></div></div><div><div><font face="monospace, monospace">ERROR [CXmppClient::handleLog] - @XmppSDK: #0, SASL <span style="background-color:rgb(244,204,204)">authentication failed!</span></font></div></div></blockquote><div><br></div><div>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:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">DEBUG [http-bio-443-exec-391] impl.AuthenticationLDAP - auth: Creating new InitialDirContext using dn = CN=1001, OU=Users, DC=company, DC=com</font></div></div><div><div><font face="monospace, monospace">DEBUG [http-bio-443-exec-391] impl.AuthenticationLDAP - <span style="background-color:rgb(217,234,211)">auth: successful</span> for dn CN=1001, OU=Users, DC=company, DC=com</font></div></div></blockquote><div><br></div><div>Ok, so that's interesting.  I was then able to see the failure in the Cisco XCP Authentication Service logs, as the following:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">debug| TokenAuthUtils::executeUserFromIMaddressQuery: IMDB (userid) <span style="background-color:rgb(217,234,211)">query successful</span>: [SELECT pkid, userid FROM validendusers WHERE userid='aholloway';]</font></div></div><div><div><font face="monospace, monospace">error| TokenAuthUtils::executeUserFromIMaddressQuery: <span style="background-color:rgb(244,204,204)">imaddress and userid queries returned conflicting rows. Returning error</span></font></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace">admin:run pe sql ttroute SELECT pkid, userid FROM validendusers WHERE userid = 'aholloway'</font></div><div><div><span style="font-family:monospace,monospace"><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><span style="background-color:rgb(207,226,243)"><a href="mailto:andrew.holloway@company.com">andrew.holloway@company.com</a></span></6></old></msg></span></div></div></blockquote><div><div><br></div></div><div>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.</div><div><br></div><div>That would explain this line in the error:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace" style="background-color:rgb(244,204,204)">imaddress and userid queries returned conflicting rows</font></div></blockquote><div><br></div><div>When I looked for a user where this sharing of alias and user ID does not exist (John Smith (1002) <a href="mailto:jsmith@company.com">jsmith@company.com</a>), the outcome looked like this:</div><div><font face="monospace, monospace"><br></font></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">debug| TokenAuthUtils::executeUserFromIMaddressQuery: IMDB (userid) <span style="background-color:rgb(217,234,211)">query successful</span>: [SELECT pkid, userid FROM validendusers WHERE userid='jsmith';]</font></div></div><div><div><font face="monospace, monospace">debug| TokenAuthUtils::executeUserFromIMaddressQuery: <span style="background-color:rgb(244,204,204)">imaddress query returned row but not userid.</span></font></div></div><div><div><font face="monospace, monospace">debug| TokenAuthUtils::executeUserFromIMaddressQuery: <span style="background-color:rgb(217,234,211)">userid set as [1002]</span></font></div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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?). ;)</div><div></div></div>