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