Hi,
Our organization is currently using a passwd-file user database for our Dovecot installs. However, we now want to provide simple username aliases.
We currently use usernames that are -not- equal to the email address, but due to the fact that many major email clients/providers do not even allow you to specifiy a username, we now want to provide aliases where the username is equal to the email address.
A simple solution would be to duplicate the lines in the passwd-file, with the email address as the username, but this does not seem be ideal due to data duplication.
Ideally, there would be a secondary 'alias' userdb, which on a match would then restart the search in the primary passwd-file userdb using the new username. Is this possible?
What would be the best way to go about this?
On 25.09.2018 16:24, Eirik Rye wrote:
Hi,
Our organization is currently using a passwd-file user database for our Dovecot installs. However, we now want to provide simple username aliases.
We currently use usernames that are -not- equal to the email address, but due to the fact that many major email clients/providers do not even allow you to specifiy a username, we now want to provide aliases where the username is equal to the email address.
A simple solution would be to duplicate the lines in the passwd-file, with the email address as the username, but this does not seem be ideal due to data duplication.
Ideally, there would be a secondary 'alias' userdb, which on a match would then restart the search in the primary passwd-file userdb using the new username. Is this possible?
What would be the best way to go about this?
# before current passbd passdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases }
# into /etc/dovecot/aliases alias@user:::::::user=real_username noauthenticate
This hopefully works.
Aki
On Wed, Sep 26, 2018 at 09:34:07AM +0300, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
# before current passbd passdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases }
# into /etc/dovecot/aliases alias@user:::::::user=real_username noauthenticate
This hopefully works.
This seems to work fine and I had the idea of doing something similar for the userdb, but there it appears that the user name change doesn't happen.
auth_debug=yes userdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases result_success = continue-ok } userdb { driver = passwd-file args = username_format=%u /etc/passwd }
When I perform a lookup with doveadm user 'test@xinu.at'
I get many
empty fields since the alias file doesn't have them set. I expected that
they would be fetched from the next userdb (/etc/passwd), but that
doesn't seem to happen. I get this in the log:
dovecot[10118]: auth: Debug: master in: USER 1 test@xinu.at service=doveadm debug dovecot[10118]: auth: Debug: passwd-file(test@xinu.at): lookup: user=test@xinu.at file=/etc/dovecot/aliases dovecot[10118]: auth: Debug: passwd-file(test@xinu.at): lookup: user=test@xinu.at file=/etc/passwd dovecot[10118]: auth: passwd-file(test@xinu.at): unknown user dovecot[10118]: auth: Debug: userdb out: USER 1 test@xinu.at
So it looks like the user name change doesn't get applied with userdb, while it works as expected with passdb. Is this expected or is this a bug?
Just for comparison, the passdb config is this:
passdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases } passdb { driver = pam }
And when logging in with doveadm auth test test@xinu.at
the log looks like this:
dovecot[10118]: auth: Debug: auth client connected (pid=0) dovecot[10118]: auth: Debug: client in: AUTH 1 PLAIN service=doveadm debug resp=<hidden> dovecot[10118]: auth: Debug: passwd-file(test@xinu.at): lookup: user=test@xinu.at file=/etc/dovecot/aliases dovecot[10118]: auth: Debug: passwd-file(test@xinu.at): username changed test@xinu.at -> flo dovecot[10118]: auth: Debug: passwd-file(flo): Allowing any password dovecot[10118]: auth: Debug: passwd-file(flo): Not performing authentication (noauthenticate set) dovecot[10118]: auth-worker(10356): Debug: pam(flo): lookup service=dovecot dovecot[10118]: auth-worker(10356): Debug: pam(flo): #1/1 style=1 msg=Password: dovecot[10118]: auth: Debug: client passdb out: OK 1 user=flo original_user=test@xinu.at
Florian
Full config:
# 2.3.2.1 (0719df592): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.2 (7704de5e) # OS: Linux 4.18.5-arch1-1-ARCH x86_64 Arch Linux # Hostname: calima auth_debug = yes mail_location = mdbox:~/.mdbox mail_plugins = zlib managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext mmap_disable = yes namespace { hidden = no inbox = yes location = prefix = INBOX. separator = . type = private } passdb { args = username_format=%Lu /etc/dovecot/aliases driver = passwd-file } passdb { driver = pam } plugin { mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_fields = uid box msgid size quota = count:User quota quota_status_nouser = DUNNO quota_status_overquota = 552 5.2.2 Mailbox is full quota_status_success = DUNNO quota_vsizes = yes sieve = ~/.dovecot.sieve sieve_dir = ~/.sieve sieve_global_dir = /etc/dovecot/sieve/global/ sieve_global_path = /etc/dovecot/sieve/default.sieve } protocols = imap lmtp service auth { user = root } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0660 user = postfix } } service quota-status { client_limit = 1 executable = quota-status -p postfix unix_listener /var/spool/postfix/private/quota-status { group = postfix mode = 0660 user = postfix } } ssl_cert = </etc/letsencrypt/live/calima.server-speed.net/fullchain.pem ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it ssl_options = no_compression ssl_prefer_server_ciphers = yes userdb { args = username_format=%Lu /etc/dovecot/aliases driver = passwd-file result_success = continue-ok } userdb { args = username_format=%u /etc/passwd driver = passwd-file } protocol lmtp { mail_plugins = zlib sieve postmaster_address = postmaster@server-speed.net } protocol imap { imap_client_workarounds = tb-extra-mailbox-sep }
On 28.09.2018 00:08, Florian Pritz wrote:
On Wed, Sep 26, 2018 at 09:34:07AM +0300, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
# before current passbd passdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases }
# into /etc/dovecot/aliases alias@user:::::::user=real_username noauthenticate
This hopefully works. This seems to work fine and I had the idea of doing something similar for the userdb, but there it appears that the user name change doesn't happen.
auth_debug=yes userdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases result_success = continue-ok } userdb { driver = passwd-file args = username_format=%u /etc/passwd } When I perform a lookup with
doveadm user 'test@xinu.at'
I get many empty fields since the alias file doesn't have them set. I expected that they would be fetched from the next userdb (/etc/passwd), but that doesn't seem to happen. I get this in the log:dovecot[10118]: auth: Debug: master in: USER 1 test@xinu.at service=doveadm debug dovecot[10118]: auth: Debug: passwd-file(test@xinu.at): lookup: user=test@xinu.at file=/etc/dovecot/aliases dovecot[10118]: auth: Debug: passwd-file(test@xinu.at): lookup: user=test@xinu.at file=/etc/passwd dovecot[10118]: auth: passwd-file(test@xinu.at): unknown user dovecot[10118]: auth: Debug: userdb out: USER 1 test@xinu.at So it looks like the user name change doesn't get applied with userdb, while it works as expected with passdb. Is this expected or is this a bug?
Just for comparison, the passdb config is this:
passdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases } passdb { driver = pam } And when logging in with
doveadm auth test test@xinu.at
the log looks like this:dovecot[10118]: auth: Debug: auth client connected (pid=0) dovecot[10118]: auth: Debug: client in: AUTH 1 PLAIN service=doveadm debug resp=<hidden> dovecot[10118]: auth: Debug: passwd-file(test@xinu.at): lookup: user=test@xinu.at file=/etc/dovecot/aliases dovecot[10118]: auth: Debug: passwd-file(test@xinu.at): username changed test@xinu.at -> flo dovecot[10118]: auth: Debug: passwd-file(flo): Allowing any password dovecot[10118]: auth: Debug: passwd-file(flo): Not performing authentication (noauthenticate set) dovecot[10118]: auth-worker(10356): Debug: pam(flo): lookup service=dovecot dovecot[10118]: auth-worker(10356): Debug: pam(flo): #1/1 style=1 msg=Password: dovecot[10118]: auth: Debug: client passdb out: OK 1 user=flo original_user=test@xinu.at Florian
Full config:
# 2.3.2.1 (0719df592): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.2 (7704de5e) # OS: Linux 4.18.5-arch1-1-ARCH x86_64 Arch Linux # Hostname: calima auth_debug = yes mail_location = mdbox:~/.mdbox mail_plugins = zlib managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext mmap_disable = yes namespace { hidden = no inbox = yes location = prefix = INBOX. separator = . type = private } passdb { args = username_format=%Lu /etc/dovecot/aliases driver = passwd-file } passdb { driver = pam } plugin { mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_fields = uid box msgid size quota = count:User quota quota_status_nouser = DUNNO quota_status_overquota = 552 5.2.2 Mailbox is full quota_status_success = DUNNO quota_vsizes = yes sieve = ~/.dovecot.sieve sieve_dir = ~/.sieve sieve_global_dir = /etc/dovecot/sieve/global/ sieve_global_path = /etc/dovecot/sieve/default.sieve } protocols = imap lmtp service auth { user = root } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0660 user = postfix } } service quota-status { client_limit = 1 executable = quota-status -p postfix unix_listener /var/spool/postfix/private/quota-status { group = postfix mode = 0660 user = postfix } } ssl_cert = </etc/letsencrypt/live/calima.server-speed.net/fullchain.pem ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it ssl_options = no_compression ssl_prefer_server_ciphers = yes userdb { args = username_format=%Lu /etc/dovecot/aliases driver = passwd-file result_success = continue-ok } userdb { args = username_format=%u /etc/passwd driver = passwd-file } protocol lmtp { mail_plugins = zlib sieve postmaster_address = postmaster@server-speed.net } protocol imap { imap_client_workarounds = tb-extra-mailbox-sep }
Username change should've occured in userdb too, although with passwd_file you probably need to return it as userdb_user.
Aki
On Fri, Sep 28, 2018 at 08:57:44AM +0300, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 28.09.2018 00:08, Florian Pritz wrote:
On Wed, Sep 26, 2018 at 09:34:07AM +0300, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
# before current passbd passdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases }
# into /etc/dovecot/aliases alias@user:::::::user=real_username noauthenticate
Username change should've occured in userdb too, although with passwd_file you probably need to return it as userdb_user.
That works. Thanks!
In case anyone else is interested, put this in the alias file if you want to use it for both:
test@xinu.at:::::::user=flo userdb_user=flo noauthenticate
Florian
On 26/09/2018 08:34, Aki Tuomi wrote:
# before current passbd passdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases }
# into /etc/dovecot/aliases alias@user:::::::user=real_username noauthenticate
This hopefully works.
Aki
This does appear to work, thanks!
As an optimization of the alias file, we tried setting "override_fields = noauthenticate" in the passdb instead of placing it as an extra field for every entry, however this does not work.
Setting "default_fields = noauthenticate" does work, however.
Why is this? According to the documentation, default_fields and override_fields are the same, except the latter one will override fields returned by the passdb? I would expect either configuration to set the "noauthenticate" flag.
Does override_fields only override fields that have already been set?
Finally, the dovecot debug log logs the statement "Allowing any password" before logging "Not performing authentication (noauthenticate set)" which sounds somewhat ominous, but this may just be a product of the way "noauthenticate" is implemented?
-- Eirik
On 04.10.2018 14:23, Eirik Rye wrote:
On 26/09/2018 08:34, Aki Tuomi wrote:
# before current passbd passdb { driver = passwd-file args = username_format=%Lu /etc/dovecot/aliases }
# into /etc/dovecot/aliases alias@user:::::::user=real_username noauthenticate
This hopefully works.
Aki
This does appear to work, thanks!
As an optimization of the alias file, we tried setting "override_fields = noauthenticate" in the passdb instead of placing it as an extra field for every entry, however this does not work.
Setting "default_fields = noauthenticate" does work, however.
Why is this? According to the documentation, default_fields and override_fields are the same, except the latter one will override fields returned by the passdb? I would expect either configuration to set the "noauthenticate" flag.
Does override_fields only override fields that have already been set?
Finally, the dovecot debug log logs the statement "Allowing any password" before logging "Not performing authentication (noauthenticate set)" which sounds somewhat ominous, but this may just be a product of the way "noauthenticate" is implemented?
I think that this has been fixed on latest release.
Aki
participants (4)
-
Aki Tuomi
-
Eirik Rye
-
Eirik Rye
-
Florian Pritz