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.
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.
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.
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.
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?
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?
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...)
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...)
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.
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 :) )
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.
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 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?
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.
Zash
on
mod_auth_cyrus moved to community modules
is this issue still relevant?
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.
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.
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.
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.
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- prosody-cyrus-unescape.patch
ChangesMore 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?
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...)
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...)
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.
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 :) )
@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.
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?
Oh excellent, you're right - it's obvious what is happening now :) I'll take a look at the best way to fix it.
mod_auth_cyrus moved to community modules is this issue still relevant?
Changes