OC_User_IMAP Dovecot (no auth attempts in 0 secs)

[benbrummer]

After upgrading to 0.6.0 and modifying the config.php external users are not able to login. In the maillog only one line gets logged, after entering the credentials. Mar 25 02:31:22 mail dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=46.163.73.154, lip=46.163.73.154, TLS, session=<JmSBKeGE2Owuo0ma>

Nextcloud logs {"reqId":"XJgwzy6jSZoAADDtgekAAAAF","level":2,"time":"2019-03-25T01:37:26+00:00","remoteAddr":"92.117.153.184","user":"--","app":"core","method":"POST","url":"/login?user=user%40domain.com","message":"Login failed: 'user@domain.com' (Remote IP: '92.117.153.184')","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0","version":"15.0.5.3","id":"5c9832441bd5d"}

Nextcloud 15.0.5 with php 7.2 on Ubuntu 16.04 with mailserver on one machine (vserver with plesk)

User_backend from config.php 'user_backends' => array ( 0 => array ( 'class' => 'OC_User_IMAP', 'arguments' => array ( 'my-mail-server.com', 993, 'ssl', '' ), ), ),

[benbrummer]

When switching dovecot to courier Mar 25 03:59:30 mail courier-imaps: couriertls: accept: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca php 7.3 same error

[benbrummer]

https://github.com/nextcloud/user_external/issues/52#issuecomment-473671934 another user with same problem

[violoncelloCH]

52 (comment) another user with same problem

yes, thank you for reporting! I would like to keep this issue open to discuss it here cc @PaulFreund

[tweibert]

Same issue here (Login failed; "no auth attemps" in Dovecot log). After an hour of trying different options, and comparing to my Roundcube configuration, I was able to solve it by manually specifying CRAM-MD5 as authentication type by manually editing imap.php from

$params = ["port"=>$this->port, "timeout"=>10];

to:

$params = ["port"=>$this->port, "timeout"=>10, "auth_type" => "CRAM-MD5"];

This is probably because I'm using CRAM-MD5 passwords (the default?) in my Dovecot passdb. Likewise, I have to use

$config['imap_auth_type'] = 'CRAM-MD5';

in my Roundcube configuration.

Bottom line: The Roundcube IMAP class supports a lot of more parameters than just "port" and "timeout", and we need a way to specify them in the user_backends configuration please.

[benbrummer]

@tweibert thanks this fixed it on my side, too

[violoncelloCH]

thank you @tweibert for investigating into this! I'll try to find the best way to allow to pass additional parameters.

[tweibert]

I propose you add a fifth, optional, parameter which is an associative array that is merged into $params.

[violoncelloCH]

yes, that should be doable... would you like to do this @tweibert? I would be happy to merge a PR :) (this would greatly accelerate it, because my time as a student is limited and there are lots of other things to do for user_external)

[tweibert]

I wish I could do a PR, but I don't do PHP development normally, and I have absolutely no knowledge about the structure of the project. I don't feel fit for the job. Will probably break things instead of fixing them ;)

And when it comes to available time - I wish I had as much today as I had as a student (being a father of two, and a self-employed software dev - no PHP though).

[violoncelloCH]

I see...time is precious (however you could learn new things ;) )

if anyone wants to try (just state so here): The relevant lines would be https://github.com/nextcloud/user_external/blob/master/lib/imap.php#L20-L40 (where we need to make sure, that additional parameter array from config.php will be passed into the class by the constructor) and then https://github.com/nextcloud/user_external/blob/master/lib/imap.php#L73 (where the parameters are passed to roundcube)... If you have questions - just ask.

[tweibert]

That would be fairly simple to add that stuff there. But I don't even know how I could test it, how the unit tests work... Don't even have a proper test environment, only my production server.

It's hard to make a single contribution to such a large project, especially to a module which is not self-contained...

[philipflohr]

While it's a good idea to have the possibility to specify an auth_method, I don't understand why it fixes the problem.

in the roundcube class this code handles the parameter - and if none specified chooses one of the available ones for you.

`$auth_method = $this->prefs['auth_type']; $auth_methods = array(); $result = null;

// check for supported auth methods if (!$auth_method || $auth_method === 'CHECK') { if ($auth_caps = $this->getCapability('AUTH')) { $auth_methods = $auth_caps; } ... foreach ($all_methods as $auth_method) { if (in_array($auth_method, $auth_methods)) { break; } }`

[tweibert]

After reading @philipflohr 's comment, I looked a little closer at my configuration, and now I do think it is/was caused by a configuration error of my Dovecot IMAP server. I connected through OpenSSL and checked what authentication protocols it advertised:

openssl s_client -crlf -connect mail.somedomain.com:993

And the result was:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN AUTH=CRAM-MD5 AUTH=DIGEST-MD5] Dovecot ready.

So it offered DIGEST-MD5 auth to the client, which, for whatever reason, the Roundcube lib prefers of the other methods. But as the passwords are stored as CRAM-MD5 hashes in my Dovecot passdb, it was unable to check the password. Absolutely makes sense.

So I disabled digest-md5 auth in the Dovecot config from

auth_mechanisms = plain login cram-md5 digest-md5

to:

auth_mechanisms = plain login cram-md5

And now it works without the tweak I mentioned above.

Bottom line: Yes, it was caused by a configuration error of mine, together with the fact that the Roundcube IMAP client seems to have a favor for DIGEST-MD5 if it's advertised. Other IMAP clients (including Thunderbird/Postbox, iOS, ... - and php-imap in the previous version of user_external!) never had any issue with this configuration.

That being said, I was lucky enough that the Dovecot server is under my control and I was able to fix it myself - but some users may have to authenticate against 3rd party servers that are not under their control, so I do think it is a good idea to offer a way to pass custom options to the IMAP client to work around such a situation.

Edit: Here is the part of the Dovecot documentation that I had deliberately ignored:

If you want to allow both CRAM-MD5 and DIGEST-MD5, the password must be stored in plaintext.

https://wiki.dovecot.org/Authentication/PasswordSchemes

[benbrummer]

My vserver is managed with Plesk and after the fix i found this page which says that roundcube does not support DIGEST-MD5 https://support.plesk.com/hc/en-us/articles/115003975753-Failed-authentication-via-Roundcube-AUTHENTICATE-DIGEST-MD5.

[tweibert]

Generally, I think it does - look at the code in imap_rcube.php which explicitly mentions DIGEST-MD5.

In my case, the error was definitely caused by Dovecot which offered DIGEST-MD5 auth even though the passwords in the passdb file were not plaintext.

[benbrummer]

OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready.

auth_mechanisms = plain login cram-md5 digest-md5 apop

Same configuration and same error on a new 18.04 Ubuntu with plesk.

[tweibert]

It depends on the way you store the passwords in your Dovecot user database. If it‘s plaintext - all good. If it‘s CRAM-MD5 hashes, DIGEST-MD5 auth will not work obviously, so turn it off in the Dovecot config.

[matthias-scheler]

The problem is in this code in "imap_rcube.php": protected function authenticate($user, $pass, $type = 'PLAIN') { if ($type === 'CRAM-MD5' || $type === 'DIGEST-MD5') { if ($type === 'DIGEST-MD5' && !class_exists('Auth_SASL')) { return $this->setError(self::ERROR_BYE, "The Auth_SASL package is required for DIGEST-MD5 authentication"); } So Digest-MD5 authentication only works if the 'Auth_SASL' class exist. But this class is not bundled with External Users. So IMAP authentication will fail against any IMAP server which offers DIGEST-MD5.

[tweibert]

Ok, so there might be other reasons why the new code fails. But in my case, it was definitely because Dovecot was advertising an auth method that it was unabled to handle (given the way I'm storing my password).

[matthias-scheler]

But in my case, it was definitely because Dovecot was advertising an auth method that it was unabled to handle

No, it wasn't. If that had been the problem Dovecot would have reported authentication failures. The fact that the client never attempted authentication indicates that your setup was affected by exactly the same client side bug.

You are of course right about DIGEST-MD5 authentication not working on your setup. But the IMAP client never got far enough to be affected by this bug.

[matthias-scheler]

A possible fix would be to move the check for the existence of the Auth_SASL class behind this line ...

$all_methods = array('DIGEST-MD5', 'CRAM-MD5', 'CRAM_MD5', 'PLAIN', 'LOGIN');

... and remove the first entry if the class doesn't exist. It is also possible the error handling which differs from Roundcube's original code isn't correct and prevents a retry. But I could be wrong because I'm not a PHP programmer.

[ictinc]

Same issue here (Login failed; "no auth attemps" in Dovecot log). After an hour of trying different options, and comparing to my Roundcube configuration, I was able to solve it by manually specifying CRAM-MD5 as authentication type by manually editing imap.php from

$params = ["port"=>$this->port, "timeout"=>10];

to:

$params = ["port"=>$this->port, "timeout"=>10, "auth_type" => "CRAM-MD5"];

This is probably because I'm using CRAM-MD5 passwords (the default?) in my Dovecot passdb. Likewise, I have to use

$config['imap_auth_type'] = 'CRAM-MD5';

in my Roundcube configuration.

Bottom line: The Roundcube IMAP class supports a lot of more parameters than just "port" and "timeout", and we need a way to specify them in the user_backends configuration please.

Hi, I'm facing the same issue however my IMAP server is using SHA-512. I've tried your change and added SHA512 in different ways but without any success. Any suggestion on how to achieve this with SHA512?

[matthias-scheler]

If you use SHA512 hashed passwords you need to disable DIGEST-MD5 (and CRAM-MD5) in your Dovecot configuration anyway which would fix this problem.

The following Dovecot configuration entry should do the job:

auth_mechanisms = plain login

If DIGEST-MD5 authentication actually works with your IMAP server (not sure how with hashed passwords) try changing the following line in "apps/user_external/lib/imap/imap_rcube.php" ...

$all_methods = array('DIGEST-MD5', 'CRAM-MD5', 'CRAM_MD5', 'PLAIN', 'LOGIN');

... to this:

$all_methods = array('CRAM-MD5', 'CRAM_MD5', 'PLAIN', 'LOGIN');

[MaxKorsak]

Блять, всем классно последнее обновление, только не работает. :)))) Как так можно... Я не представляю.

[paulieas]

Same deal here. I had to recreate my VPS. Decided to switch from Ubuntu 16 and an older version of Nextcloud, and it had no problems authenticating against Dovecot before the upgrade. Since the, I've upgraded to all the recent stable versions. I used SHA512 for both old and new servers; and had already set up Dovecot with (also in both old and new):

auth_mechanisms = plain login

I had no problems using Thunderbird or Roundcube. Nextcloud is the only one not having any success. Please help. I really liked the IMAP authentication functionality!!

[tweibert]

@paulieas Do you use a flat passdb file for your user accounts in Dovecot? Or a database? Are passwords stored in plaintext or hashed as MD5 etc.?

[paulieas]

I use Postfix, Dovecot, PostgreSQL with virtual mailboxes on Ubuntu. Passwords stored as salted hash (sha512) in pgsql db.

[MaxKorsak]

Заменил строчку:

$all_methods = array('DIGEST-MD5', 'CRAM-MD5', 'CRAM_MD5', 'PLAIN', 'LOGIN');

на более короткую, с протоколами, которые мне нравятся. Оставил только PLAIN и LOGIN и всё завелось.

Автору в любом случае спасибо. Но блин надёжности это не прибавило. Мои абоненты в диком недовольстве.

[violoncelloCH]

@MaxKorsak please write in English here, otherwise only a small amount of people in here will understand your comments; that doesn't help...

[kevo-gt]

Has anyone found a workaround for this in the meantime before the 0.7.1 release?

[matthias-scheler]

Yes, I've posted the work around above:

https://github.com/nextcloud/user_external/issues/59#issuecomment-500067609

[kevo-gt]

Yes, I've posted the work around above:

#59 (comment)

Thanks but this did not work for me still. I get the same error on the Dovecot server and then the following error on Nextcloud:

Failed to enable crypto at user_external\/lib\/imap\/imap_rcube.php#999"

and

message":"ERROR: Could not connect via roundcube lib: Could not connect to ssl:\/\/X.X.X.X:993: Unknown reason"

Any pointers on what could cause this and how I could fix?

[violoncelloCH]

hi everyone we have a nice new approach for IMAP authentication which hopefully also fixes this issue from @rollbrettler in #122 (Thanks a lot to them!) now we're looking for as much volunteers as possible to test this out, so please take a look at #122 - further info (also on how to proceed) will be following there...

[violoncelloCH]

please take a look at this comment with info on how to proceed: https://github.com/nextcloud/user_external/pull/122#issuecomment-582109772

[stefangweichinger]

I know this one is closed, but I am unsure where to mention my issue with your app. I also see these "no auth attempts" lines, but with version 0.9.1, inside a docker container. See https://github.com/nextcloud/docker/issues/1086 for my initial ticket, pls advise, thanks a lot. (I already looked at the dovecot servers, they both only offer "AUTH=PLAIN", btw)