why is dovecot "Allowing any password"
Hi,
I noticed the following in the logs of our debian wheezy server:
Mar 21 07:13:47 mail dovecot: auth: Debug: ldap(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): bind search: base=CN=Users, DC=samba, DC=company, DC=com filter=(&(objectclass=person)(sAMA ccountName=username)(!(userAccountControl=514))) Mar 21 07:13:47 mail dovecot: auth: Debug: ldap(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): result: uid=username; uid unused Mar 21 07:13:47 mail dovecot: auth: Debug: ldap(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): result: uid=username Mar 21 07:13:48 mail dovecot: auth: ldap(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): invalid credentials (given password: invalid_password) Mar 21 07:13:48 mail dovecot: auth: Debug: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): lookup Mar 21 07:13:48 mail dovecot: auth: Debug: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): allow_nets: Matching for network 127.0.0.1/32 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 Mar 21 07:13:48 mail dovecot: auth: Debug: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): Allowing any password Mar 21 07:13:54 mail dovecot: auth: Debug: auth client connected (pid=6174)
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:
#passdb { # driver = static # args = nopassword=y allow_nets=127.0.0.1/32 #}
Could anyone expain the "Allowing any password"?
And lastly our current doveconf -n:
# 2.2.13: /etc/dovecot/dovecot.conf # OS: Linux 3.2.0-5-amd64 x86_64 Debian 7.11 xfs auth_debug = yes auth_debug_passwords = yes auth_failure_delay = 10 secs auth_master_user_separator = * auth_mechanisms = plain login auth_username_format = %Ln auth_verbose = yes auth_verbose_passwords = plain deliver_log_format = %f | %s | msgid=%m: %$ disable_plaintext_auth = no lda_mailbox_autocreate = yes lda_mailbox_autosubscribe = yes login_greeting = Dovecot ready. mail_gid = vmail mail_location = maildir:/var/vmail/%Ln/Maildir:LAYOUT=fs:DIRNAME=mAildir mail_plugins = acl lazy_expunge zlib quota mail_log notify mail_uid = vmail managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave namespace { list = children location = maildir:/var/vmail/%%u/Maildir:LAYOUT=fs:DIRNAME=mAildir:INDEX=/var/vmail/%u/shared/%%u prefix = shared/%%n/ separator = / subscriptions = no type = shared } namespace inbox { inbox = yes location = mailbox "Deleted items" { special_use = \Trash } mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent items" { special_use = \Sent } mailbox Trash { special_use = \Trash } mailbox inbox { auto = subscribe } prefix = separator = / type = private } passdb { args = /etc/dovecot/master-users driver = passwd-file master = yes } passdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap } plugin { acl = vfile acl_shared_dict = file:/var/lib/dovecot/db/shared-mailboxes.db mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename append mail_log_fields = uid box msgid from subject quota = maildir quota_rule = ?:storage=5G quota_rule2 = Trash:storage=+100M quota_warning = storage=97%% quota-warning 97 %u quota_warning2 = storage=95%% quota-warning 95 %u quota_warning3 = storage=90%% quota-warning 90 %u quota_warning4 = storage=85%% quota-warning 85 %u quota_warning5 = storage=80%% quota-warning 80 %u quota_warning6 = -storage=100%% quota-warning below %u sieve = ~/.dovecot.sieve sieve_default = /var/lib/dovecot/default.sieve sieve_dir = ~/sieve } protocols = imap lmtp sieve service auth { unix_listener /var/spool/postfix/private/auth { mode = 0666 } unix_listener auth-userdb { group = vmail mode = 0666 user = vmail } } service imap-login { process_limit = 500 process_min_avail = 2 } service quota-warning { executable = script /usr/local/bin/quota-warning.sh unix_listener quota-warning { user = vmail } user = dovecot } shutdown_clients = no ssl_ca = </etc/ssl/letsencrypt/fullchain.pem ssl_cert = </etc/ssl/letsencrypt/cert.pem ssl_key = </etc/ssl/letsencrypt/key.pem ssl_protocols = !SSLv2 !SSLv3 userdb { args = uid=vmail gid=vmail home=/var/vmail/%n allow_all_users=yes driver = static } verbose_proctitle = yes protocol lda { mail_plugins = acl lazy_expunge zlib quota mail_log notify sieve quota } protocol imap { imap_max_line_length = 2 M mail_max_userip_connections = 30 mail_plugins = acl lazy_expunge zlib quota mail_log notify imap_quota imap_acl }
MJ
On 21 March 2018 at 18:12 mj <lists@merit.unu.edu> wrote:
Hi,
I noticed the following in the logs of our debian wheezy server:
Mar 21 07:13:47 mail dovecot: auth: Debug: ldap(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): bind search: base=CN=Users, DC=samba, DC=company, DC=com filter=(&(objectclass=person)(sAMA ccountName=username)(!(userAccountControl=514))) Mar 21 07:13:47 mail dovecot: auth: Debug: ldap(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): result: uid=username; uid unused Mar 21 07:13:47 mail dovecot: auth: Debug: ldap(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): result: uid=username Mar 21 07:13:48 mail dovecot: auth: ldap(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): invalid credentials (given password: invalid_password) Mar 21 07:13:48 mail dovecot: auth: Debug: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): lookup Mar 21 07:13:48 mail dovecot: auth: Debug: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): allow_nets: Matching for network 127.0.0.1/32 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 Mar 21 07:13:48 mail dovecot: auth: Debug: static(username,1.2.3.4,<g2/rF+ZnjAAu5ceg>): Allowing any password Mar 21 07:13:54 mail dovecot: auth: Debug: auth client connected (pid=6174)
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:
#passdb { # driver = static # args = nopassword=y allow_nets=127.0.0.1/32 #}
Could anyone expain the "Allowing any password"?
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
doveadm exec imap -u victim
for admin use.
Aki
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
On 21 March 2018 at 18:31 mj <lists@merit.unu.edu> wrote:
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
On 21 March 2018 at 18:58 mj <lists@merit.unu.edu> wrote:
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)"?
The auth client connected does not mean that connection has been successfully authenticated, but, then again, it is still allowing any password, even though the request has been failed. Perhaps this can be improved in 2.3.x, maybe...
Aki
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:
auth_debug = yes auth_debug_passwords = yes auth_verbose = yes
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 22.03.2018 10:30, mj wrote:
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
I have no idea *WHY* it is required by SOGo. It does not make sense.
Aki
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 22.03.2018 10:55, mj wrote:
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
I would recommend using master password (that is, replace nopassword=y with password=staticpassword). I know that from localhost perspective this isn't much different, but it will reduce accidents.
Aki
On 03/22/2018 09:56 AM, Aki Tuomi wrote:
I would recommend using master password (that is, replace nopassword=y with password=staticpassword). I know that from localhost perspective this isn't much different, but it will reduce accidents.
ok, I'll see if I can get the SOGo developers attention on this. :-)
MJ
On 03/22/2018 09:34 AM, Aki Tuomi wrote:
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.
I have no idea *WHY* it is required by SOGo. It does not make sense.
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:
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.
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:
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.
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