[Dovecot] Default fallback behaviour
Hello list,
Here is the problem: I have few: passdb { #1 } passdb { #2 } And relative userdb sections. If user not found in 1) section it fallbacks to next one - it's expected and right, IMHO. But when the user exists in both section and password verification fails on 1) database it successfully authenticated on next one. I think this behaviour should be configured. The main goal of 1) section for this server is to overwrite users in main (section2) database.
Maybe I missed something and this option is already in dovecot code and I can't find it ? Or if not - will it be added in the future ?
Dovecot version 2.1.10.
Il 23/11/2012 08:46, Nikita Koshikov ha scritto:
Hello list,
Here is the problem: I have few: passdb { #1 } passdb { #2 } And relative userdb sections. If user not found in 1) section it fallbacks to next one - it's expected and right, IMHO. But when the user exists in both section and password verification fails on 1) database it successfully authenticated on next one. I think this behaviour should be configured. The main goal of 1) section for this server is to overwrite users in main (section2) database.
Maybe I missed something and this option is already in dovecot code and I can't find it ? Or if not - will it be added in the future ?
Dovecot version 2.1.10.
You can enable this features by adding "deny=yes" in the passdb extra_fields of specific users.
You can find more information here: http://wiki2.dovecot.org/AuthDatabase/PasswdFile ot you can use the "auth-deny.conf.ext" example configuration.
Ciao
-- Alessio Cecchi is: @ ILS -> http://www.linux.it/~alessice/ on LinkedIn -> http://www.linkedin.com/in/alessice Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz/ @ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it
On Fri, 23 Nov 2012 12:20:23 +0100 Alessio Cecchi wrote:
Il 23/11/2012 08:46, Nikita Koshikov ha scritto:
Hello list,
Here is the problem: I have few: passdb { #1 } passdb { #2 } And relative userdb sections. If user not found in 1) section it fallbacks to next one - it's expected and right, IMHO. But when the user exists in both section and password verification fails on 1) database it successfully authenticated on next one. I think this behaviour should be configured. The main goal of 1) section for this server is to overwrite users in main (section2) database.
Maybe I missed something and this option is already in dovecot code and I can't find it ? Or if not - will it be added in the future ?
Dovecot version 2.1.10.
You can enable this features by adding "deny=yes" in the passdb extra_fields of specific users.
You can find more information here: http://wiki2.dovecot.org/AuthDatabase/PasswdFile ot you can use the "auth-deny.conf.ext" example configuration.
Ciao
Maybe I was not so clear - but this is not what I'm searching for. deny=yes will deny user in corresponding database - I want - allow user to login, if and only if, users password matches and if it fail(in current passdb) - not trying next passdb for checking his password, even if user exists in the next database.
On 23.11.2012, at 9.46, Nikita Koshikov wrote:
Hello list,
Here is the problem: I have few: passdb { #1 } passdb { #2 } And relative userdb sections. If user not found in 1) section it fallbacks to next one - it's expected and right, IMHO. But when the user exists in both section and password verification fails on 1) database it successfully authenticated on next one. I think this behaviour should be configured. The main goal of 1) section for this server is to overwrite users in main (section2) database.
It's not always possible to know why #1 failed. For example PAM doesn't always tell if the password was wrong or if the user didn't exist.
Maybe I missed something and this option is already in dovecot code and I can't find it ? Or if not - will it be added in the future ?
I'm not very interested in adding it, especially because it can't be done reliably.
On Tue, Nov 27, 2012 at 3:04 AM, Timo Sirainen <tss@iki.fi> wrote:
On 23.11.2012, at 9.46, Nikita Koshikov wrote:
Hello list,
Here is the problem: I have few: passdb { #1 } passdb { #2 } And relative userdb sections. If user not found in 1) section it fallbacks to next one - it's expected and right, IMHO. But when the user exists in both section and password verification fails on 1) database it successfully authenticated on next one. I think this behaviour should be configured. The main goal of 1) section for this server is to overwrite users in main (section2) database.
It's not always possible to know why #1 failed. For example PAM doesn't always tell if the password was wrong or if the user didn't exist.
Maybe I missed something and this option is already in dovecot code and I can't find it ? Or if not - will it be added in the future ?
I'm not very interested in adding it, especially because it can't be done reliably.
Thank's for the anwer. It's a pity to hear, because it's security feature I need to provide. The problem - that main passdb - is ldap and there are about - 5-7 people who can edit it and simply to login as different users. Yes, activity is logged - but mailbox can be read\stolen. The main goal for passwd-file database is to revrite ldap very critical mailboxes to local file. It can be edited only but 1 person - it is nativly to trust 1, but not to 7.
On 27.11.2012, at 9.37, Nikita Koshikov wrote:
Here is the problem: I have few: passdb { #1 } passdb { #2 } And relative userdb sections. If user not found in 1) section it fallbacks to next one - it's expected and right, IMHO. But when the user exists in both section and password verification fails on 1) database it successfully authenticated on next one. I think this behaviour should be configured. The main goal of 1) section for this server is to overwrite users in main (section2) database.
Thank's for the anwer. It's a pity to hear, because it's security feature I need to provide. The problem - that main passdb - is ldap and there are about - 5-7 people who can edit it and simply to login as different users. Yes, activity is logged - but mailbox can be read\stolen. The main goal for passwd-file database is to revrite ldap very critical mailboxes to local file. It can be edited only but 1 person - it is nativly to trust 1, but not to 7.
Try if a modified version of Alessio's suggestion works:
passdb { driver = passwd-file args = /etc/passwd.important } passdb { driver = passwd-file args = /etc/passwd.important deny = yes } passdb { driver = ldap }
participants (3)
-
Alessio Cecchi
-
Nikita Koshikov
-
Timo Sirainen