why is dovecot "Allowing any password"
Hi,
I noticed the following in the logs of our debian wheezy server:
The line second last line "Allowing any password" comes as a surprise..? Why would dovecot Allow any password..?
We had the following bit in our config, but I removed it now:
Could anyone expain the "Allowing any password"?
And lastly our current doveconf -n:
MJ
Hi AKi,
Thanks for the quick answer!
On 03/21/2018 05:24 PM, Aki Tuomi wrote:
This is what 'nopassword=y' does. I'm guessing this is an attempt to allow logging in from localhost without password, but I'd use master password (for applications or webmails), or
Yes, the config is taken from the SOGo configuration guide, which can be seen here: https://sogo.nu/files/docs/v2/SOGoNativeOutlookConfigurationGuide.html
Yes, but we have args = nopassword=y allow_nets=127.0.0.1/32 so it should only allow passwordless logins from localhost, right..?
And in "Debug: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): Allowing any password" 1.2.3.4 is NOT localhost...
(obviously 1.2.3.4 is not the *real* ip, bit it's a *real* ip from the internet, NOT localhost...
MJ
Looking at the code for v2.2.13, it would seem that
a) when using nopassword, it will log the debug row in any case b) allow_nets will fail the authentication by setting request failed
Mar 21 07:13:48 mail dovecot: auth: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): allow_nets check failed: IP not in allowed networks
this indicates that the request is marked failed.
I would, still, recommend using doveadm exec imap -u instead of the static passdb.
Aki
Hi Aki,
On 03/21/2018 05:43 PM, Aki Tuomi wrote:
Mar 21 07:13:48 mail dovecot: auth: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): allow_nets check failed: IP not in allowed networks
this indicates that the request is marked failed.
So, what you are saying is: the logline "Allowing any password" is 'wrong'? Access was actually DENIED, even though it says "Allowing any password" and even though one line later it says: "auth: Debug: auth client connected (pid=6174)"?
This is all very misleading....
MJ
ok, fyi:
I have now also tested/confirmed this, while looking at the logs, and indeed:
Even when the connection is denied because of a wrong password, the message "Allowing any password" is showing up in the logs.
Perhaps it is because we have set debug options:
It would be nice if the "Allowing any password" could be rephrased, or taken out. It really had me scared for a while.
Thanks Aki, MJ
On 2018-03-21 (14:15 MDT), mj <lists@merit.unu.edu> wrote:
Even when the connection is denied because of a wrong password, the message "Allowing any password" is showing up in the logs.
The question is does it allow remote users to login with no password?
If not, then the message ie nearly notification that login without a password is potentially possible.
I have no idea why you would have nopassword=y set in the first place, so it seems the simplest way to eliminate this problem is to take that out and have a secure environment for sending mail.
-- They say whisky'll kill you, but I don't think it will I'm ridin' with you to the top of the hill
On 03/21/2018 10:34 PM, @lbutlr wrote:
The question is does it allow remote users to login with no password? Yes, and the answer is: no.
If not, then the message ie nearly notification that login without a password is potentially possible. Yes, but a worrying one. That's why i decided to post here.
I have no idea why you would have nopassword=y set in the first place, so it seems the simplest way to eliminate this problem is to take that out and have a secure environment for sending mail.
Yes, however, for SOGo with Native Outlook compatibility or SAML logon, the config is required.
(https://sogo.nu/files/docs/v2/SOGoNativeOutlookConfigurationGuide.html)
Thanks, MJ
On 03/22/2018 09:34 AM, Aki Tuomi wrote:
I have no idea*WHY* it is required by SOGo. It does not make sense.
Well, the thing is: SOGo has this ability to behave like a *real* exchange server, as if it's running on a windows server. And this enables Outlook to connect to it like it would to an exchange server. (so: not in imap mode, and not using regular username/password authentication)
Normally, SOGo simply reuses the provided username/password to connect to the imap server, but in the above scenario, these are not available.
The same goes for a SAML2 authenticated SOGo webmail logon.
In these scenarios, SOGo uses the 127.0.0.1 connection, to logon to imap. Since it does know the username.
I guess a better solution would be for SOGo to be able to do 'transformations' to the username/password, to change the regular username/unknownpassword into username*master/masterpassword, and get rid of the 127.0.0.1 passwordless listener.
Right?
But SOGo doesn't do that. (afaik)
MJ
On 03/22/2018 09:34 AM, Aki Tuomi wrote:
The configuration guide describes (in 4.3.) a scenario where SOGo's user population backend (LDAP) is set up from scratch, which implies that the preexisting IMAP server supposedly is *not* using the same backend/data/passwords.
I'ld guess that *if* you have the IMAP server configured to look up the same backend/data (including support for exotic authentication methods, "Exchange style" cross-user access rights management, yadda yadda), the requirement to defeat authentication from SOGo to the IMAP server may become moot.
But until then - Exchange takes its entire auth from AD, and SOGo's LDAP, *not* the IMAP server's passdb, is the analogue of that.
Regards,
Jochen Bern Systemingenieur
www.binect.de www.facebook.de/binect
On 03/22/2018 11:34 AM, Jochen Bern wrote:
I have read the above again and again, but I don't understand what you are trying to say, I'm sorry.
Chapter 4.3 doesn't apply to us and my question, since we are (and were) always using (samba) AD.
Everything connects to this same AD backend, including SOGo and imap.
MJ
On 2018-03-22 (02:30 MDT), mj <lists@merit.unu.edu> wrote:
Yes, however, for SOGo with Native Outlook compatibility or SAML logon, the config is required.
(https://sogo.nu/files/docs/v2/SOGoNativeOutlookConfigurationGuide.html)
I don't know what that is, but that is a terrible requirement that makes me very suspicious someone is being either lazy or intentionally breaking security for nefarious purposes. I'd walk away.
-- Lister: What d'ya think of Betty? Cat: Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma. Lister: This is crazy. Why are we talking about going to bed with Wilma Flintstone? Cat: You're right. We're nuts. This is an insane conversation. Lister: She'll never leave Fred, and we know it.
On 2018-03-22 (02:48 MDT), "@lbutlr" <kremels@kreme.com> wrote:
read more:
"For any other IMAP server, refer to the product’s documentation. If such capability is not offered, you can alternatively define the cleartext password for each user."
OM EFFING G!
No. A thousand times no. This is… just no, this is inexcusable, irresponsible, and in any opinion should be criminal. No, I'm not joking.
-- A: You're wrong Q: I've never found that to be true A: Because it make following messages more difficult Q: Why is top-posting evil?
participants (4)
-
＠lbutlr
-
Aki Tuomi
-
Jochen Bern
-
mj