Cannot authenticate users on prosody

[mazlumtoprak]

After a couple of retries i have managed to get the BOSH Server running over SSL.

When I want to Authenticate my nextcloud users, which are authenticated over LDAP and are in the following format "user@domain", I get a couple of Errors:

Jul 18 15:36:57 domain.ch:auth_external warn Auth process exited unexpectedly with exit 1, restarting Jul 18 15:36:57 domain.ch:auth_external warn Error while waiting for result from auth process: unknown error Jul 18 15:36:57 c2s247fe20 info c2s stream for <172.20.4.17> closed: session closed Jul 18 15:36:57 c2s247fe20 info Client disconnected: connection closed

Also what I have seen is, that the installation guide has not been adjusted to the most recent version of xmpp-cloud-auth.

A local test using xcauth.py gives me the following error: ./xcauth.py -t prosody -A 'user' 'domain.ch' 'UserPassword

2017-07-18 16:04:58,498 DEBUG: Start external auth script 0.9.0+ for prosody with endpoint: https://domain.ch/index.php/apps/ojsxc/ajax/externalApi.php 2017-07-18 16:04:58,501 DEBUG: Token is too short: 7 != 23 (maybe not a token?) 2017-07-18 16:04:58,507 INFO: Starting new HTTPS connection (1): domain.ch 2017-07-18 16:04:58,587 DEBUG: "POST /index.php/apps/ojsxc/ajax/externalApi.php HTTP/1.1" 500 61 2017-07-18 16:04:58,594 INFO: UNREACHABLE: Cache says password for user@domain.ch is False False

I am Using nextcloud 12.0 on an ubuntu 16.04.

When you need some more informations, I can gladly server them to you.

Thank you!

[MarcelWaldvogel]

The thing that jumps right into my eye is that there is a 500 error code from the POST request. One of the reasons might be the API secret being wrong. There are two debug options:

• The log files (HTTP server, Nextcloud) might tell you more.
• Can you try to submit it on the command line (will override configuration files) and if it works, check whether it is wrong in the config file as well.

Note, that earlier versions looked for config files in the directory where the executable lives as well.

A lot of things have been added in the past few weeks, and as @sualko found out the hard way, there are some inconsistencies in the documentation now. Some of them were fixed in the past few days, but I would be glad for pointers at where things do go wrong (or pull requests).

[mazlumtoprak]

Hello Marcel,

I resolved the issue with the Secret key. I had for testing purposes put some quotas to the secret key. Now i get the following error:

./xcauth.py -t prosody -A 'user' 'domain.ch' 'UserPassword'

2017-07-21 11:57:12,880 DEBUG: Start external auth script 0.9.0+ for prosody with endpoint: https://domain.ch/index.php/apps/ojsxc/ajax/externalApi.php 2017-07-21 11:57:12,882 DEBUG: Token is too short: 7 != 23 (maybe not a token?) 2017-07-21 11:57:12,888 INFO: Starting new HTTPS connection (1): domain.ch 2017-07-21 11:57:12,980 DEBUG: "POST /index.php/apps/ojsxc/ajax/externalApi.php HTTP/1.1" 200 19 2017-07-21 11:57:12,984 INFO: FAILURE: Could not authenticate user user@domain.ch: noauth False

As my users are logging in with username@domain.ch, i tried to use the following command: ./xcauth.py -t prosody -A 'user@domain.ch' 'domain.ch' 'UserPassword' which gave me a succesful response:

2017-07-21 12:03:03,574 INFO: SUCCESS: Cloud says password for user@domain.ch@domain.ch is valid True

When I try to connect via Nextcloud with the provided and tested credentials the step above, it just says "connecting".

This is the Prosody Logfile:

Jul 21 12:10:12 mod_bosh info New BOSH session, assigned it sid '4f4505c3-e927-44c8-9f4d-e9bc320674a5' Jul 21 12:10:12 domain.ch:auth_external warn Auth process exited unexpectedly with exit 1, restarting Jul 21 12:10:12 domain.ch:auth_external warn Error while waiting for result from auth process: unknown error Jul 21 12:10:53 mod_bosh info New BOSH session, assigned it sid '0d5f651e-e3f5-45b2-8aa8-6198e366840b' Jul 21 12:10:53 domain.ch:auth_external warn Auth process exited unexpectedly with exit 1, restarting Jul 21 12:10:53 domain.ch:auth_external warn Error while waiting for result from auth process: unknown error

Thanks.

EDIT

Pidgin gives me following Error, when trying to connect:

(12:31:31) account: Connecting to account admin@domain.ch/. (12:31:31) connection: Connecting. gc = 050B31E0 (12:31:31) dnssrv: querying SRV record for domain.ch: _xmpp-client._tcp.domain.ch (12:31:31) dnssrv: found 1 SRV entries (12:31:31) dnsquery: Performing DNS lookup for sub.domain.ch (12:31:31) dnsquery: IP resolved for sub.domain.ch (12:31:31) proxy: Attempting connection to SRV_IP (12:31:31) proxy: Connecting to sub.domain.ch:5222 with no proxy (12:31:31) proxy: Connection in progress (12:31:31) proxy: Connecting to sub.domain.ch:5222. (12:31:31) proxy: Connected to sub.domain.ch:5222. (12:31:31) jabber: Sending (admin@domain.ch): <?xml version='1.0' ?> (12:31:31) jabber: Sending (admin@domain.ch): (12:31:31) jabber: Recv (305): <?xml version='1.0'?></stream:features> (12:31:31) jabber: Sending (admin@domain.ch): (12:31:31) jabber: Recv (50): (12:31:31) nss: SSL version 3.3 using 256-bit AES with 160-bit SHA1 MAC Server Auth: 2048-bit RSA, Key Exchange: 384-bit ECDHE, Compression: NULL Cipher Suite Name: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (12:31:31) nss: subject=CN=sub.domain.ch,OU=PositiveSSL,OU=Domain Control Validated issuer=CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB (12:31:31) nss: partial certificate chain (12:31:31) certificate/x509/tls_cached: Starting verify for domain.ch (12:31:31) certificate/x509/tls_cached: Checking for cached cert... (12:31:31) certificate/x509/tls_cached: ...Found cached cert (12:31:31) nss/x509: Loading certificate from C:\Users\admin\AppData\Roaming.purple\certificates\x509\tls_peers\domain.ch (12:31:31) certificate/x509/tls_cached: Peer cert matched cached (12:31:31) nss/x509: Exporting certificate to C:\Users\admin\AppData\Roaming.purple\certificates\x509\tls_peers\domain.ch (12:31:31) util: Writing file C:\Users\admin\AppData\Roaming.purple\certificates\x509\tls_peers\domain.ch (12:31:32) nss: Trusting CN=sub.domain.ch,OU=PositiveSSL,OU=Domain Control Validated (12:31:32) certificate: Successfully verified certificate for domain.ch (12:31:32) jabber: Sending (ssl) (admin@domain.ch): (12:31:32) jabber: Recv (ssl)(327): <?xml version='1.0'?>PLAIN</stream:features> (12:31:32) sasl: Mechs found: PLAIN (12:31:32) jabber: Sending (ssl) (admin@domain.ch): password removed (12:31:32) jabber: Recv (ssl)(167): Unable to authorize you with the authentication credentials you've sent. (12:31:32) connection: Connection error on 050B31E0 (reason: 2 description: Not Authorized) (12:31:32) account: Disconnecting account admin@domain.ch/ (005121A8) (12:31:32) connection: Disconnecting connection 050B31E0 (12:31:32) jabber: Sending (ssl) (admin@domain.ch): </stream:stream> (12:31:32) connection: Destroying connection 050B31E0

[MarcelWaldvogel]

There seem to be several problems. I presume you are running JSXC 3.2.1 on Nextcloud. What is the output for git branch -v for your xmpp-cloud-auth repository?

1. Logins with user@domain should be working. Can you check your Nextcloud logs (raise to maximum level first)? There should be "ExAPI: Check password for user:" and some other entries related to that username.
2. "Auth process exited unexpectedly with exit 1, restarting" could indicate that there is a permission problem when starting the process. Could you check the output of sudo -sHu prosody /opt/xmpp-cloud-auth/xcauth.py (assuming you are running it as user prosody)
3. Not related to these problems: "nss: partial certificate chain" indicates your Prosody is not returning the full chain, but just the top-level certificate. For my Let's Encrypt certificate in the Prosody test installation, I use the following. Your paths will of course be different.

   ssl = {
   key = "/etc/letsencrypt/live/example.ch/privkey.pem";
   certificate = "/etc/letsencrypt/live/example.ch/fullchain.pem";
   }

[mazlumtoprak]

The Output of git branch -v for my xmpp-cloud-auth repo is:

root@SRV:/opt/xmpp-cloud-auth# git branch -v

• master 333ed68 No more ./xcauth.conf show 333ed68 No more ./xcauth.conf xmpp-cloud-auth 333ed68 No more ./xcauth.conf

1. After enabling LogLevel 0 (debug Mode) on nextcloud and executing the command ./xcauth.py -t prosody -A 'admin' 'domain.ch' 'UserPassword' i only see the following Entry in the LogFiles:

Info | ojsxc | ExAPI: Check password for user: admin-- | -- | --

2.Checking for permissions gave me an error on the logfiles:

IOError: [Errno 13] Permission denied: '/var/log/xcauth/xcauth.log' IOError: [Errno 13] Permission denied: '/var/log/xcauth/xcauth.err'

I corrected the permissions and on an second execution theres no error on sudo -sHu prosody /opt/xmpp-cloud-auth/xcauth.py

Checking the xcauth.err logfiles though gave me new, interessting errors:

Traceback (most recent call last): File "/opt/xmpp-cloud-auth/xcauth.py", line 387, in CACHE_DB = anydbm.open(args.cache_db, 'c', 0600) File "/usr/lib/python2.7/anydbm.py", line 85, in open return mod.open(file, flag, mode) File "/usr/lib/python2.7/dbhash.py", line 18, in open return bsddb.hashopen(file, flag, mode) File "/usr/lib/python2.7/bsddb/init.py", line 364, in hashopen d.open(file, db.DB_HASH, flags, mode) bsddb.db.DBAccessError: (13, 'Permission denied')

3. Thought the same > Should not affect the problem. I will solve this issue later. By the way im using an Comod certificate.

Thanks

[MarcelWaldvogel]

1. The -- | -- | -- are verbatim? No admin@<empty> or admin@domain.ch? Which version of the Nextcloud JSXC app?

2. The caching file or directory seems to have permission problems as well. The easiest is to comment out cache-db= in xcauth.conf. [1]

3. As I do not know how Comodo names certificate in the logs, but I do not know how they name their certificates or chains. Just append their intermediate certificate to the server certificate if users should not

[1] I have changed some cache defaults since your last git clone/git pull and made cache non-default just now. To activate it again, please run mkdir /var/cache/xcauth; chmod prosody /var/cache/xcauth and set the cache-db=/var/cache/xcauth/user-cache.db in /etc/xcauth.conf.

[mazlumtoprak]

1. No, the dashes are only beeing created when copying it out of the frontend into this comment window. Thats the full Output when copying with the date for an LDAP User. Funny though, it shows it as a table in github right now.

Info	ojsxc	ExAPI: Check password for user: user@domain.ch	2017-07-24T11:09:12+0200

I'm running Version 3.2.1

2. For the sake of the purpose, I commented out the cache-db= Parameter in xcauth.conf.

3. I'll face the certificate Problem later, as it should not affect the current problem.

4. I finally got managed to use pidgin with the XMPP Server at Nextcloud. I used to have a typo in my firewall rules and opened the wrong Port (not 5269). Maybe a pull for documentation? > Make the users aware of opening Firewall Ports.

   2017-07-24 11:46:34,686 INFO: Starting new HTTPS connection (1): sub.domain.ch 2017-07-24 11:46:34,813 INFO: SUCCESS: Cloud says password for user@domain.ch is valid

Looks like we're not far away from a working XMPP Chat.

5. I had an /etc/hosts entry, where the Nextcloud Instance Domain had a the internal IP of the server. When uncommenting, I got some Proxy errors:

[Mon Jul 24 12:19:39.050590 2017] [proxy:error] [pid 2982] (110)Connection timed out: AH00957: HTTPS: attempt to connect to XXX.XXX.XXX.15:5281 (sub.domain.ch) failed [Mon Jul 24 12:19:39.050687 2017] [proxy:error] [pid 2982] AH00959: ap_proxy_connect_backend disabling worker for (sub.domain.ch) for 0s [Mon Jul 24 12:19:39.050710 2017] [proxy_http:error] [pid 2982] [client XXX.XXX.XXX.113:60988] AH01114: HTTP: failed to make connection to backend: sub.domain.ch

Thanks.

EDIT [1]: I could not manage to call https://sub.domain.ch/http-bind/ when deleting the hosts record. Gotta lookup what the matter is. Now I've set the hosts record again and tried couple of settings. My Main problem now is, that the UID's in nextcloud are user@domain.ch. Now when a user tries to log in, it fails. If i change the Username to a "non-email" Username, the user can login without problems. Is it possible to let the UID's as they are and managexmpp-cloud-auth to login with those creds?

EDIT [2]: As a workaround i added only the username of the mailadress as an extensionattribute1 in LDAP and add those attributes as "login Atrributes" in nextcloud LDAP Module. When i try to login i now get the following errors:

Warning	core	Login failed: 'username' (Remote IP: 'ServerIP')	2017-07-25T11:28:25+0200
Warning	user_ldap	Bind failed: 49: Invalid credentials	2017-07-25T11:28:25+0200
Debug	user_ldap	LDAP error Invalid credentials (49) after calling ldap_bind	2017-07-25T11:28:25+0200
Warning	user_ldap	Bind failed: 49: Invalid credentials	2017-07-25T11:28:25+0200
Debug	user_ldap	LDAP error Invalid credentials (49) after calling ldap_bind	2017-07-25T11:28:25+0200
Info	ojsxc	ExAPI: Check password for user: username	2017-07-25T11:28:25+0200

While checking the configs with the -A parameter gives me no error: ./xcauth.py -t prosody -A 'username' 'domain.ch' 'UserPassword' Even works without specifying "domain.ch" ./xcauth.py -t prosody -A 'username' '' 'UserPassword' and with domain specified at username: ./xcauth.py -t prosody -A 'username@domain.ch' '' 'UserPassword'

[Aquariu]

Dear all,

I have also a connection issue between my prosody server and the auth module.

• NC 12 running on Debian 9
• Prosody 0.9.12 on the same server
• xmpp-cloud-auth pulled from git yesterday
• all usernames are like this: "username@domain.fr"

Commands like:

sudo -u prosody ./xcauth.py -t prosody -A 'username' 'domain.fr' 'UserPassword' return successfully (debug lines, then "True") so I guess I have the Script-->NC connection ok.

Now, for the prosody--> script call, my client cannot connect, so I'm a bit lost. Basically the server sends to my client (Conversation app on Android) an error message (sorry it's in french) "Mécanisme SASL dégradé" (which I would translate "Degraded SASL mecanism") while Pidgin says "Not authorized" While I try that, the xcauth script logs:

2017-08-15 23:24:13,126 INFO: FAILURE: Could not authenticate user user@domain.fr: noauth And the prosody server logs:

Aug 15 23:24:13 c2s55fc992aa7d0 debug Received[c2s_unauthed]: <auth mechanism='PLAIN' http://www.google.com/talk/protocol/auth
client-uses-full-bind-result='true' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Aug 15 23:24:13 domain.fr:auth_external debug Response: 0

Aug 15 23:24:13 domain.fr:saslauth debug sasl reply: Unable to authorize you with the authentication credentials you've sent.

Why is the external auth attempt logged as trying SASL ? Am I doing something wrong ?
The xcauth user has access to /etc/xcauth.conf I guess that's enough, is it not ?

Note: I also read about [this Conversations bug](https://github.com/siacs/Conversations/issues/2498) but it seems unrelated to my issue as xcauth logs a failure and Pidgin also can't connect.

Kind regards,

Olivier

[Aquariu]

Hello, (Edited for clarity)

After reading the issues here, it looks like my Prosody instance is not using the updated mod_auth_external.lua. Although the line plugin_paths = { "/opt/xmpp-cloud-auth/prosody-modules/" } seems correct. (direct copy/paste from the howto). Is there a way I can force it to ?

Note: Initially, mod_auth_external.lua did not exist in /usr/lib/prosody/modules, so in addition to the above line, I ALSO made a copy of the file in there. Note that mod_auth_external.lua is not inscluded in Debian Stretch packages prosody and prosody-modules.

Regards,

Olivier

EDIT: I've fixed various (stupid) errors on my part, so now the respective logs for xcauth and prosody say:

2017-08-16 12:36:11,127 INFO: FAILURE: Could not authenticate user name@domain.fr: noauth

and

Aug 16 12:38:38 domain.fr:auth_external warn Error while waiting for result from auth process: unknown error Aug 16 12:38:38 domain.fr:saslauth debug sasl reply: Unable to authorize you with the authentication credentials you've sent. Aug 16 12:38:38 socket debug server.lua: client xx.xx.xx.x:xxxxx read error: closed Aug 16 12:38:38 c2s55bf32058600 info Client disconnected: closed Aug 16 12:38:38 c2s55bf32058600 debug Destroying session for (unknown) ((unknown)@domain.fr): closed Aug 16 12:38:38 socket debug server.lua: closed client handler and removed socket from list

Deleting the Conversation accounts and recreating it changes the error message to "Not Authorized", as expected relative to the Conversation issue.

[MarcelWaldvogel]

@Aquariu: has this been fixed for you, based on your comment in #13?

@Aquariu, @maesitopi: I cannot reproduce the username@domain problem on 3.3.0-beta.1. Could you try whether this fixes it?

@maesitopi: "SASL downgrade attack" (I think that is the English error message) definitely is an issue (siacs/Conversations#2498). However, the Conversations team insists to keep this as a security feature. Deleting and recreating the account on Conversations seems the only way to deal with that.

[mazlumtoprak]

@MarcelWaldvogel username@domain login works, as I did not change anything. Perhaps It needed some time.

The last mentioning was probably for @Aquariu ?

However I do have some Problems with creating groups. When creating Groups, the ID of the Group is unique and random as like group-a@"44k8jk4njFkj3n" and not as it should like when creating it within pidgin where it seems correct (group-a@sub.domain.ch). So after a relogin the user cannot reconnect to the same group, as it doesnt find it anymore because it gets another ID.

EDIT: I recreated the scenario and now try to describe it a bit more precise.

When creating a new group with USER1 and then joining with USER2 works. although the messages are not always send properly and it says USER1 is writing....

After getting the time-out and relogin with USER1 who created the Group and then relogin with USER2 who only joined, I get the following error, when trying to send a message with USER2: your message was not send because the room doesn't exist anymore.

The auto-disconnect happens due to BOSH-Client Silence for over 60 seconds. Maybe this can also be fixed or edited in a config file. Not tried to solve this problem yet.

In pidgin I also see, that there is a unique Session identifier (I guess), which could maybe lead to the problem of reconnecting to a group?

[Aquariu]

I, yes, the last remark was for me. In my case everything is now ok, including the login via the NC instance and the caching. I don't use groups (very small familly cloud)

[MarcelWaldvogel]

Closing due to inactivity. Reopen if needed.