Re: under some kind of attack
mourik jan c heupink
lists at merit.unu.edu
Mon Jul 24 20:46:23 EEST 2017
Hi Joseph
On 07/24/2017 04:51 AM, Joseph Tam wrote:> You are essentially writing your own backend by taking over
> authentication. You'll be accepting user/password inputs into your
> checkpassword executable, then use the LDAP API (or some other system...snip
> and source address, which will be adversely affect performance on a
> busy server as authentication data cannot be cached.
While this sounds awesome, it can do much more than what I was/am after, and appears lot more complicated to setup than what I had figured myself.
Shouldn't I be able to do something like this:
passdb {
driver = passwd-file
# application specific passwd-file should work from anywhere
# (so: no allow_nets)
args = /etc/dovecot/dovecot-application-specific
}
passdb {
# only allowed to use this from within local 192.168.1.0/24
args = /etc/dovecot/dovecot-ldap.conf.ext allow_nets=192.168.1.0/24
driver = ldap
}
Where I would generate lines in dovecot-application-specific using a script or some webpage, and generate lines like:
username1:randomONE:vmail:vmail::/var/vmail/username1:
username1:randomTWO:vmail:vmail::/var/vmail/username1:
username2:randomTHREE:vmail:vmail::/var/vmail/username2:
username2:randomFOUR:vmail:vmail::/var/vmail/username2:
And the result would be: username1 can login from anywhere, using passwords "randomONE" & "randomTWO", plus the password in ldap when coming from the internal network.
We have only one domain, one 'set of users', one ldap database.and
In my tests, I can't get the allow_nets to work, so I'm doing something wrong. Can anyone point out what is wrong with the above logic?
Or perhaps convert the above pseudo-conf into *real* dovecot.conf?
MJ
More information about the dovecot
mailing list