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 at user:::::::user=real_username noauthenticate This hopefully works. Aki
On Wed, Sep 26, 2018 at 09:34:07AM +0300, Aki Tuomi <aki.tuomi at open-xchange.com> wrote:> # before current passbd > passdb { > ? driver = passwd-file > ? args = username_format=%Lu /etc/dovecot/aliases > } > > # into /etc/dovecot/aliases > alias at 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 at 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 at xinu.at service=doveadm debug > dovecot[10118]: auth: Debug: passwd-file(test at xinu.at): lookup: user=test at xinu.at file=/etc/dovecot/aliases > dovecot[10118]: auth: Debug: passwd-file(test at xinu.at): lookup: user=test at xinu.at file=/etc/passwd > dovecot[10118]: auth: passwd-file(test at xinu.at): unknown user > dovecot[10118]: auth: Debug: userdb out: USER 1 test at xinu.atSo 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 at 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 at xinu.at): lookup: user=test at xinu.at file=/etc/dovecot/aliases > dovecot[10118]: auth: Debug: passwd-file(test at xinu.at): username changed test at 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 at xinu.atFlorian 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 at server-speed.net } protocol imap { imap_client_workarounds = tb-extra-mailbox-sep } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://dovecot.org/pipermail/dovecot/attachments/20180927/aaa711fa/attachment.sig>
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 at 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