Unescape JIDs before passing to Cyrus SASL

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by murray.c...@gmail.com on 15 Jan 2015 at 2:09

[GoogleCodeExporter]

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.

Original comment by murray.c...@gmail.com on 15 Jan 2015 at 2:14

[GoogleCodeExporter]

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.

Original comment by murray.c...@gmail.com on 15 Jan 2015 at 2:33

[GoogleCodeExporter]

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.

Original comment by murray.c...@gmail.com on 15 Jan 2015 at 2:52

[GoogleCodeExporter]

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?

Original comment by MWild1 on 19 Jan 2015 at 11:46

• Changed title: Unescape JIDs before passing to Cyrus SASL
• Changed state: Accepted

Attachments:

• prosody-cyrus-unescape.patch

[GoogleCodeExporter]

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?

Original comment by murray.c...@gmail.com on 20 Jan 2015 at 4:10

[GoogleCodeExporter]

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...)

Original comment by murray.c...@gmail.com on 20 Jan 2015 at 5:43

[GoogleCodeExporter]

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...)

Original comment by murray.c...@gmail.com on 20 Jan 2015 at 5:53

[GoogleCodeExporter]

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.

Original comment by MWild1 on 20 Jan 2015 at 6:10

[GoogleCodeExporter]

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 :) )

Original comment by paul.aur...@gmail.com on 20 Jan 2015 at 7:07

[GoogleCodeExporter]

@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.

Original comment by murray.c...@gmail.com on 21 Jan 2015 at 9:51

[GoogleCodeExporter]

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 
10.0.0.100:55314 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 10.0.0.100:55314 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?

Original comment by murray.c...@gmail.com on 21 Jan 2015 at 10:14

[GoogleCodeExporter]

Oh excellent, you're right - it's obvious what is happening now :)

I'll take a look at the best way to fix it.

Original comment by MWild1 on 21 Jan 2015 at 2:23