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