On Thursday 17 of November 2016, Aki Tuomi wrote:> On 17.11.2016 10:14, Arkadiusz Mi?kiewicz wrote: > > Hello. > > > > dovecot 2.2.26.0 > > > > When testing nopassword extra field > > (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields) with CRAM-MD5 > > dovecot doesn't allow any password (while it should) and returns > > > > " Authentication failed" > > > > while in logs: > > > > Nov 17 08:22:34 auth-worker(1551): Info: > > sql(pepe,127.0.0.1,<Y8amDXpBptV/AAAB>): Requested CRAM-MD5 scheme, but we > > have a NULL password > > > > NULL is there because our sql query returns empty password just like wiki > > says "nopassword: you want to allow all passwords, use an empty > > password and this field. " > > > > > > If password is returned in sql query then it fails, too: > > > > Nov 17 09:00:49 auth-worker(2206): Error: > > sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is > > non- empty > > > > So looks to be a bug. > > It's not a bug. CRAM-MD5 does in fact require *some* password to work,Provide fake/random one for nopassword internally.> you can either store it with doveadm pw -S CRAM-MD5 or as plain text > password.Then I get> > sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is > > non- emptySo that doesn't help btw. doveadm pw -S is not documented, so no idea what it does> Aki-- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )
On 17.11.2016 10:30, Arkadiusz Mi?kiewicz wrote:> On Thursday 17 of November 2016, Aki Tuomi wrote: >> On 17.11.2016 10:14, Arkadiusz Mi?kiewicz wrote: >>> Hello. >>> >>> dovecot 2.2.26.0 >>> >>> When testing nopassword extra field >>> (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields) with CRAM-MD5 >>> dovecot doesn't allow any password (while it should) and returns >>> >>> " Authentication failed" >>> >>> while in logs: >>> >>> Nov 17 08:22:34 auth-worker(1551): Info: >>> sql(pepe,127.0.0.1,<Y8amDXpBptV/AAAB>): Requested CRAM-MD5 scheme, but we >>> have a NULL password >>> >>> NULL is there because our sql query returns empty password just like wiki >>> says "nopassword: you want to allow all passwords, use an empty >>> password and this field. " >>> >>> >>> If password is returned in sql query then it fails, too: >>> >>> Nov 17 09:00:49 auth-worker(2206): Error: >>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is >>> non- empty >>> >>> So looks to be a bug. >> It's not a bug. CRAM-MD5 does in fact require *some* password to work, > Provide fake/random one for nopassword internally. > >> you can either store it with doveadm pw -S CRAM-MD5 or as plain text >> password. > Then I get > >>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is >>> non- empty > So that doesn't help > > btw. doveadm pw -S is not documented, so no idea what it does > >> Akisorry, typo. Ment doveadm pw -s CRAM-MD5 How do you perceive user login works with CRAM-MD5 if you do not provide *any* password for the user? Some passdb backend must provide a password for the user, if you want to load extra attributes from alternative backend, use noauthenticate instead of nopassword, but make sure the last passdb can authenticate the user. Aki
On Thursday 17 of November 2016, Aki Tuomi wrote:> On 17.11.2016 10:30, Arkadiusz Mi?kiewicz wrote: > > On Thursday 17 of November 2016, Aki Tuomi wrote: > >> On 17.11.2016 10:14, Arkadiusz Mi?kiewicz wrote: > >>> Hello. > >>> > >>> dovecot 2.2.26.0 > >>> > >>> When testing nopassword extra field > >>> (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields) with CRAM-MD5 > >>> dovecot doesn't allow any password (while it should) and returns > >>> > >>> " Authentication failed" > >>> > >>> while in logs: > >>> > >>> Nov 17 08:22:34 auth-worker(1551): Info: > >>> sql(pepe,127.0.0.1,<Y8amDXpBptV/AAAB>): Requested CRAM-MD5 scheme, but > >>> we have a NULL password > >>> > >>> NULL is there because our sql query returns empty password just like > >>> wiki says "nopassword: you want to allow all passwords, use an empty > >>> password and this field. " > >>> > >>> > >>> If password is returned in sql query then it fails, too: > >>> > >>> Nov 17 09:00:49 auth-worker(2206): Error: > >>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is > >>> non- empty > >>> > >>> So looks to be a bug. > >> > >> It's not a bug. CRAM-MD5 does in fact require *some* password to work, > > > > Provide fake/random one for nopassword internally. > > > >> you can either store it with doveadm pw -S CRAM-MD5 or as plain text > >> password. > > > > Then I get > > > >>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is > >>> non- empty > > > > So that doesn't help > > > > btw. doveadm pw -S is not documented, so no idea what it does > > > >> Aki > > sorry, typo. > > Ment doveadm pw -s CRAM-MD5 > > How do you perceive user login works with CRAM-MD5 if you do not provide > *any* password for the user?I can provide it and I want to do that but nopassword doesn't let me.> Some passdb backend must provide a password > for the user, if you want to load extra attributes from alternative > backend, use noauthenticate instead of nopassword, but make sure the > last passdb can authenticate the user.Ok, I'll try noauthenticate.> > Aki-- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )
On 17.11.2016 10:30, Arkadiusz Mi?kiewicz wrote:> On Thursday 17 of November 2016, Aki Tuomi wrote: >> On 17.11.2016 10:14, Arkadiusz Mi?kiewicz wrote: >>> Hello. >>> >>> dovecot 2.2.26.0 >>> >>> When testing nopassword extra field >>> (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields) with CRAM-MD5 >>> dovecot doesn't allow any password (while it should) and returns >>> >>> " Authentication failed" >>> >>> while in logs: >>> >>> Nov 17 08:22:34 auth-worker(1551): Info: >>> sql(pepe,127.0.0.1,<Y8amDXpBptV/AAAB>): Requested CRAM-MD5 scheme, but we >>> have a NULL password >>> >>> NULL is there because our sql query returns empty password just like wiki >>> says "nopassword: you want to allow all passwords, use an empty >>> password and this field. " >>> >>> >>> If password is returned in sql query then it fails, too: >>> >>> Nov 17 09:00:49 auth-worker(2206): Error: >>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is >>> non- empty >>> >>> So looks to be a bug. >> It's not a bug. CRAM-MD5 does in fact require *some* password to work, > Provide fake/random one for nopassword internally. > >> you can either store it with doveadm pw -S CRAM-MD5 or as plain text >> password. > Then I get > >>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is >>> non- empty > So that doesn't help > > btw. doveadm pw -S is not documented, so no idea what it does > >> AkiSorry to bump into your conversation but Aki is defending too hard something that is realy a bug. I have signaled myself this issue in the "very old" version 2.2.9(!) nopassword means ANY password (including none). One cannot store something like ANY with doveadm, SQL or anything. So with "nopassword" the query should simply ignore the password field (missing, NULL or set to anything else). Why would an user login with nopassword? This is an administrator decision and is not subject for comments. My problem was with LDA who refuses to store mail in INBOX if the user is not properly authenticated (nopassword) so you cannot receive mails for "hidden" users that cannot login, maybe to redirect mails later or do some other things with. Adrian
On 17.11.2016 10:49, Adrian POPA wrote:> On 17.11.2016 10:30, Arkadiusz Mi?kiewicz wrote: >> On Thursday 17 of November 2016, Aki Tuomi wrote: >>> On 17.11.2016 10:14, Arkadiusz Mi?kiewicz wrote: >>>> Hello. >>>> >>>> dovecot 2.2.26.0 >>>> >>>> When testing nopassword extra field >>>> (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields) with CRAM-MD5 >>>> dovecot doesn't allow any password (while it should) and returns >>>> >>>> " Authentication failed" >>>> >>>> while in logs: >>>> >>>> Nov 17 08:22:34 auth-worker(1551): Info: >>>> sql(pepe,127.0.0.1,<Y8amDXpBptV/AAAB>): Requested CRAM-MD5 scheme, >>>> but we >>>> have a NULL password >>>> >>>> NULL is there because our sql query returns empty password just >>>> like wiki >>>> says "nopassword: you want to allow all passwords, use an empty >>>> password and this field. " >>>> >>>> >>>> If password is returned in sql query then it fails, too: >>>> >>>> Nov 17 09:00:49 auth-worker(2206): Error: >>>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is >>>> non- empty >>>> >>>> So looks to be a bug. >>> It's not a bug. CRAM-MD5 does in fact require *some* password to work, >> Provide fake/random one for nopassword internally. >> >>> you can either store it with doveadm pw -S CRAM-MD5 or as plain text >>> password. >> Then I get >> >>>> sql(pepe,127.0.0.1,<eO5vlnpBtNd/AAAB>): nopassword set but password is >>>> non- empty >> So that doesn't help >> >> btw. doveadm pw -S is not documented, so no idea what it does >> >>> Aki > Sorry to bump into your conversation but Aki is defending too hard > something that is realy a bug. > I have signaled myself this issue in the "very old" version 2.2.9(!) > nopassword means ANY password (including none). One cannot store > something like ANY with doveadm, SQL or anything. > So with "nopassword" the query should simply ignore the password field > (missing, NULL or set to anything else). > Why would an user login with nopassword? This is an administrator > decision and is not subject for comments. > My problem was with LDA who refuses to store mail in INBOX if the user > is not properly authenticated (nopassword) so you cannot receive mails > for "hidden" users that cannot login, maybe to redirect mails later or > do some other things with. > > AdrianYou can also, if you are using nopassword flag, abstain from actually returning any field called 'password' from your SQL database. The reason this check is done is to ensure that you know what you are doing. We do not want to prevent you from logging in w/o password, that's fine for us and it will work just as you want as long as you do not return 'password' attribute from your database. Aki