I got it to work! I'll explain how in case anyone else is interested:

First, the documentation is wrong about the username format. The config file documentation said <username><separator><master username>, but I had to reverse that to <master username><separator><username>.

Second, I had some extra passdb lines that worked before, but once I turned on master=yes, they broke Dovecot. Before, right after my LDAP passdb line, I had:

passdb passwd { }

passdb shadow { }

userdb passwd ( }

...because I wanted to first check LDAP, and if a user wasn't found, check the local system users as well. But I think the problem was I have the system setup to use LDAP nameservices as well, so maybe it was complaining about me having two LDAP queries? I don't know. It used to work fine until I threw in the master user option. So, I replaced the above with:

passdb passwd-file { args = /etc/shadow }

userdb passwd-file { args = /etc/passwd }

...and everything worked. That's probably better anyway. The above still loads my local user accounts, after first checking LDAP, and allows master users.

# telnet localhost imap Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.

• OK IMAP server ready. 1 login testuser*realuser "testpass" 1 OK Logged in.

~Adam

On Mon, 3 Apr 2006, Adam M. Dunn wrote:

Hi. I'm testing out the new 'master users' feature, and I'm not having any luck getting it to work. Anyone out there using it yet?

Here's what I have so far:

dovecot.conf:

auth_master_user_separator = *

auth default {

passdb passwd-file { # Master users that can login as anyone else args = /etc/dovecot/dovecot.masterusers master = yes pass = yes }

# LDAP database passdb ldap { args = /etc/dovecot/dovecot-ldap.conf }

... ... }

dovecot.masterusers:

testuser:{plain}testpass

# telnet localhost imap Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.

• OK IMAP server ready. 1 login realuser*testuser "testpass" 1 NO Authentication failed.

As you can see I get authentication failed. The log shows it fails for the 'realuser' that exists in ldap. Any ideas out there? I have the 'testuser' also setup in /etc/passwd.

Thanks Adam