Dovecot (unknown user)

Linux Server Administration
1

I’m using a combination of Dovecot 2.2.33.2 and Postfix 3.3.0 on Ubuntu server 18.04, and have recently (this has probably been going on since day one, which is - way back) been made aware that Dovecot preceeds every login with a line in dovecot-info.log complaining about an unknown user, (where email@domain.top is whatever client trying to connect and the IP varies accordingly for obvious reasons):

auth-worker(21760): Info: passwd(email@domain.top,176.10.248.196,): unknown user

This, as far as I can tell, is related to another message logged in the debug.log:

auth: Debug: pam(email@domain.top,176.10.248.196,): passdb doesn’t support credential lookups

which leads me to the obvious conclusion that there’s at least one lookup in the wrong place or a misconfigured password file. Relevant part of Dovecots configuration file would be (just to be clear; the file /etc/dovecot/passwd does exist and is using CRAMD5)

passdb {
driver = passwd-file
args = scheme=CRAMD5 /etc/dovecot/passwd
skip = never
result_failure = continue
result_internalfail = continue
result_success = return-ok
auth_verbose = default
}

Dovecot is accepting valid clients, but this one line in the log file mess things up for Fail2Ban, so I would like to have it sorted if at all possible.

Edit: Strange formatting.

Thank you.

2

Hi Iznougoud,

Strange issue. Does a verbose doveadm auth testing provide any additional hints on the process of authenticating a user?

3

The command “sudo doveadm -D auth test user@domain.top” gives me:

Debug: Loading modules from directory: /usr/lib/dovecot/modules/doveadm

Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: undefined symbol: acl_user_module (this is usually intentional, so just ignore this message)

Debug: Skipping module doveadm_expire_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: undefined symbol: expire_set_deinit (this is usually intentional, so just ignore this message)

Debug: Skipping module doveadm_quota_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so: undefined symbol: quota_user_module (this is usually intentional, so just ignore this message)

Debug: Module loaded: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_sieve_plugin.so

Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: undefined symbol: fts_user_get_language_list (this is usually intentional, so just ignore this message)

Debug: Skipping module doveadm_mail_crypt_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/libdoveadm_mail_crypt_plugin.so: undefined symbol: mail_crypt_box_get_pvt_digests (this is usually intentional, so just ignore this message)

Password:
passdb: user@domain.top auth failed
extra fields:
temp
**Warning: Auth connection closed with 1 pending requests (max 0 secs, pid=15330, EOF)
Fatal: Couldn’t connect to auth socket

Which essentially tells me that the user for whatever reason can’t be found in the password file defined in /etc/dovecot.conf. The file /etc/dovecot/passwd isn’t a database as such though, and simply lists users and their hashed passwords in the format user@domain.top:{CRAM-MD5}hashed_string so for all I know it’s quite possible that Dovecot is looking for the user somewhere else entirely at this point.

4

What I really don’t understand about the error message, is that it mentions pam, while you configured to use a passwd file directly. Is there maybe some default configuration somewhere that refers to pam as a driver?

5

Been there. Done that. Well, not really. But almost :). But you’re right, it is curoius. I haven’t been able to find any reference to PAM in Dovecots configuration files, so unless I’ve missed it (which of course is quite possible) it would have to be some sort of global setting overriding Dovecot. We do have /etc/pam.d/dovecot with these five lines:

"#%PAM-1.0

@include common-auth
@include common-account
@include common-session
auth required pam_unix.so nullok
account required pam_unix.so"

but as far as I can tell it’s only to be called upon if Dovecot is configured to use PAM. Nevertheless, I’ve tried removing it, but its absence has no effect whatsoever on Dovecots behavoiur.

Other than that, I honestly don’t know where to look.

Edit:

I had another look around and found a driver setting in /etc/dovecot/conf.d/auth-system.conf.ext:

passdb {
driver = pam
}

tried changing it to “shadow” which was the only other option, and the log message simply changed from:

auth-worker(15542): Info: pam(mail@domain.top,176.10.248.195,<hashed_password>): unknown user

to

auth-worker(15542): Info: shadow(mail@domain.top,176.10.248.195,<hashed_password>): unknown user

In both cases the user managed to successfully connect, send and receive mail after the initial authorization failure.

which points to something other than pam being the culprit here.

Edit 2 (solved):

As it turns out, the line !include auth-system.conf.ext in /etc/dovecot/conf.d/10-auth.conf was uncommented. Once said line was deactivated, Dovecot stopped looking for the user in all the wrong places (anyone who gets that reference is at least 40 years old and should be ashamed of (most likely) himself).

doveadm auth test still fails though, so there’s probably more to this than meets the eye.

And last (but not least); thank you for helping me out.

2 Likes