#459 Unescape JIDs before passing to Cyrus SASL

Reporter murray.crane
Owner MattJ
Stars ★★ (2)  
  • Priority-Medium
  • Type-Defect
  • Status-Accepted
  1. murray.crane on

    Running Prosody 0.9.7 on Ubuntu 12.04 LTS, using Cyrus to authenticate users against our Windows 2003 AD. The one user we have with a space in their username/JID cannot authenticate (one of the company directors, so I'm not keen on having to tell him the user name he's been using for longer than I've been with the company has to be changed), but the same Cyrus configuration with Openfire on the server and the exact same Pidgin client configuration worked just fine. I am aware of your statement on the XEP page that XEP-0106 is client-side, so it should work, but for me/my user it isn't.

  2. murray.crane on

    Just to add, the error that Pidgin gives back is "Not authorised" for JIDs with "\20" in them. Other than the account I made as part of the installation, I've not had to make accounts on the server, the mods have taken care of everything beautifully up to this point.

  3. murray.crane on

    Further to last, I've just been "playing" with testsaslauthd to see if SASLAuthD understands \20, which it doesn't:- murray@svr-svn01:~$ sudo testsaslauthd -u murray\20c -p xxxxxxxx -s xmpp 0: NO "authentication failed" murray@svr-svn01:~$ sudo testsaslauthd -u "murray c" -p xxxxxxxx -s xmpp 0: OK "Success." Clearly, it needs the username passing in quotes with the space as a space. Not sure if this helps any with either diagnosis or correction of the issue.

  4. murray.crane on

    Last from me for a bit, I've enabled the debug window in Pidgin to check what is going on from it's point of view, and it sends the JID with "\20" in it, which suggests to me that mod_cyrus (?) isn't correctly handling the conversion of the JID to a sensible username. Happy to provide my configs if required.

  5. MattJ on

    Thanks for the extensive debugging you've been doing here! I think whether Prosody "unescapes" the username before passing it to Cyrus is beyond the scope of the specifications, as it's not a protocol issue - it's dependent on how you store your data in your authentication database. And it makes sense to store it unescaped there. Any chance you could try the attached patch?

    Attachments Changes
    • owner MattJ
    • title Unescape JIDs before passing to Cyrus SASL
    • tags Status-Accepted
  6. murray.crane on

    More than happy to help in any way I can. Assuming I don't need to restart the server/service, that patch didn't change anything obvious, however I note that the unescape call sits inside a test for set_canon_cb (and there's a logging line straight after it which has not tripped in our current logs), so I guess I need to set a variable somewhere to make it canonicalise the user name?

  7. murray.crane on

    Spent a little bit more time reading the code (and the config file) and realised that the log hadn't tripped because it wasn't set to debug. Have set such, restarted Prosody to load everything and can report that usernames with spaces are unescaped according to the log; only problem now is that Pidgin still says "Not Authenticated". Wild guess (I really don't know lua), is the string that's passed to cyrus quoted? (Yes, clutching at straws...)

  8. murray.crane on

    For "Not Authenticated" above read "Not Authorised" (just noticed while doing a little more testing to see if anything turned up in the Windows Event Logs on the AD; nothing... Would make this so much easier if I could see what is arriving at the AD server to be matched...)

  9. MattJ on

    Is the connection between Cyrus SASL and AD over SSL? If not, maybe you could get a packet capture using Wireshark/tcpdump? Other than that, I'm not sure what to suggest - the canon_cb mechanism is precisely for applying transformations like this, so I think we're in the right place.

  10. paul.aurich on

    FWIW, I'm not sure this was an accurate test: murray@svr-svn01:~$ sudo testsaslauthd -u murray\20c -p xxxxxxxx -s xmpp 0: NO "authentication failed" You probably wanted murray\\20c: % echo murray\20c murray20c % echo murray\\20c murray\20c Anyway: If you still have debug logging enabled, I don't suppose you could show concurrent Pidgin debug log and Prosody debug logs from trying (unsuccessfully) to log in? If it's sensitive, you could send it via email (e.g. to developers@prosody.im), and Matthew knows how to get in touch with me. (I'd suggest emailing it directly to me, but you don't know who I am, and have no reason to trust me :) )

  11. murray.crane on

    @MWild1 - Hadn't even considered wireshark (doh!). We don't SSL internally and I have a capture now, and TBH I'm even more confused: the LDAP search/bind sequence looks pretty much identical for both the space/no space attempts, and both responses to the bind attempts are "success", so why Pidgin is saying it's a fail I do not know (perhaps it's not Prosody that is "failing" now). I'll have to get concurrent capture/server/client logs I think to progress the debugging. @paul - The FWIW results are identical for single and double backslash; "authentication failed". As mentioned above, I am going to try getting all three logs/captures and look for correlations. Yes, there will almost certainly be things in those three thaht I wouldn't want going outside the company, but I will get them and go through them as a first step.

  12. murray.crane on

    Hahaha... #WINNING and so forth. I just had an extra fine dig through the prosody log (yes, still got debugging on) before I prepped to get all logs simultaneously and I think the following snippet is somewhat self-explanatory:- Jan 21 09:31:39 socket debug server.lua: accepted new client connection from to 5222 ... Jan 21 09:31:39 sasl_cyrus debug Canonicalizing username murray\20c to murray c Jan 21 09:31:39 ggpsystems.co.uk:saslauth warn SASL succeeded but username was invalid Jan 21 09:31:39 ggpsystems.co.uk:saslauth debug sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/><text>User authenticated successfully, but username was invalid</text></failure> Jan 21 09:31:39 socket debug server.lua: client read error: closed Jan 21 09:31:39 c2s8efa650 info Client disconnected: closed Jan 21 09:31:39 c2s8efa650 debug Destroying session for (unknown) ((unknown)@ggpsystems.co.uk): closed Jan 21 09:31:39 socket debug server.lua: closed client handler and removed socket from list Do I still need to get concurrent logs/captures, or is this enough to be going on with?

  13. MattJ on

    Oh excellent, you're right - it's obvious what is happening now :) I'll take a look at the best way to fix it.

New comment