[Dovecot] auth_default_realm for different listeners
We provide POP3 service for several realms, each of which has a substantial number of users logging in with no realm (bare username). We would like to use Dovecot, but I haven't been able to findout how to vary auth_default_realm for each listener.
My most recent attempt was to set up one auth {} block for each realm with a different auth_default_realm and socket master path. I then set up one protocol pop3 {} block for each realm, listening on different IP addresses and with a auth_socket_path corresponding to the auth block for that listener.
I'm not sure if I'm on the right track here, but I'm seeing two problems:
- When dovecot starts, I get:
Sep 5 18:32:21 pop01 dovecot: auth(otherdomain): Socket already exists: /var/run/dovecot/auth-otherdomain
for each additional auth {} block.
dovecot won't start with auth_socket_path specified in a protocl pop3 {} block:
Error in configuration file /etc/dovecot/dovecot.conf line 654: Unknown setting: socket_path
Is there a way to vary auth_default_realm for each listener, so I can have multiple realms log in with bare usernames?
thanks, john
John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
On Wed, 2007-09-05 at 15:00 -0400, John Morrissey wrote:
We provide POP3 service for several realms, each of which has a substantial number of users logging in with no realm (bare username). We would like to use Dovecot, but I haven't been able to findout how to vary auth_default_realm for each listener.
Unfortunately Dovecot doesn't directly support this. With v2.0 the configuration file will hopefully be flexible enough to allow it.
You can do this in your passdb though. For example with checkpassword or SQL passdb you're able to check if there's @ in username and if not add it based on the local IP address.
http://wiki.dovecot.org/PasswordDatabase/ExtraFields/User http://wiki.dovecot.org/PasswordDatabase/CheckPassword http://wiki.dovecot.org/Variables
On Sun, Sep 09, 2007 at 04:19:16AM +0300, Timo Sirainen wrote:
On Wed, 2007-09-05 at 15:00 -0400, John Morrissey wrote:
We provide POP3 service for several realms, each of which has a substantial number of users logging in with no realm (bare username). We would like to use Dovecot, but I haven't been able to findout how to vary auth_default_realm for each listener.
Unfortunately Dovecot doesn't directly support this. With v2.0 the configuration file will hopefully be flexible enough to allow it.
So having multiple auth {} blocks is a dead end that I shouldn't bother considering? IOW, the "default" keyword doesn't have any significance? I would just drop it, but it looks so tempting. :-)
You can do this in your passdb though. For example with checkpassword or SQL passdb you're able to check if there's @ in username and if not add it based on the local IP address.
We're using LDAP for authentication, so it seems we're out of luck unless we write our own checkpassword handler that does LDAP auth itself?
john
John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
On Mon, 2007-09-10 at 10:58 -0400, John Morrissey wrote:
On Sun, Sep 09, 2007 at 04:19:16AM +0300, Timo Sirainen wrote:
On Wed, 2007-09-05 at 15:00 -0400, John Morrissey wrote:
We provide POP3 service for several realms, each of which has a substantial number of users logging in with no realm (bare username). We would like to use Dovecot, but I haven't been able to findout how to vary auth_default_realm for each listener.
Unfortunately Dovecot doesn't directly support this. With v2.0 the configuration file will hopefully be flexible enough to allow it.
So having multiple auth {} blocks is a dead end that I shouldn't bother considering? IOW, the "default" keyword doesn't have any significance? I would just drop it, but it looks so tempting. :-)
Multiple auth blocks will only cause problems. Dovecot will more or less randomly select one of those and use it (and only it) for authentication. The only use for them is if you want to configure different auth mechanisms with different settings, which pretty much no-one wants to do.
You can do this in your passdb though. For example with checkpassword or SQL passdb you're able to check if there's @ in username and if not add it based on the local IP address.
We're using LDAP for authentication, so it seems we're out of luck unless we write our own checkpassword handler that does LDAP auth itself?
Right.
participants (2)
-
John Morrissey
-
Timo Sirainen