imapc and masteruser

Computerisms Corporation
2017-09-29T21:58:53Z

Hi Sami

>> I followed this before, and it seemed the solution was to set
>>
>> imapc_password = %w
>>
>> However, dovecot will not start with this configuration.
>>
>> In Sven's email, he places the imapc_password = %w as a
default_field in the userdb on the primary instance.  If I remove the default
field, I get the invalid credentials reported as above.  However, I still think
this is correct way to pass %w, because if I remove 'imapc_user =
authapps' from the global config *and*  'imapc_password = %w' from
the default_fields in the userdb, the logs on the shared instance show that the
user password is not being passed in the imapc login:
>>
>>
>> 2017-09-28 12:57:10.409884500 Sep 28 12:57:10 auth: Debug:
static(bob.test,192.168.120.70,<rvFSUEVaxLfAqHhG>): lookup
>> 2017-09-28 12:57:10.409903500 Sep 28 12:57:10 auth: Debug:
static(bob.test,192.168.120.70,<rvFSUEVaxLfAqHhG>): username changed
bob.test -> authapps
>> 2017-09-28 12:57:10.409905500 Sep 28 12:57:10 auth: Info:
static(authapps,192.168.120.70,<rvFSUEVaxLfAqHhG>): No password returned
(and no nopassword)
>> 2017-09-28 12:57:12.412437500 Sep 28 12:57:12 auth: Debug: client
passdb out: FAIL	11	user=authapps	original_user=bob.test
>>
> Now this starts to be a bit complex. Not sure if you can get this working
by returning imapc_password = %w from the first passdb. Atleast if it works it
will only work with PLAIN auth scheme.
> What I would do here is to just trust that the user is already
authenticated with the first ldap passdb in the primary server and then switch
the imapc connection to both master user and master password.
>
> So just put imapc_password=masterpassword in dovecot.conf of the primary
server and on secondary server modify ldap config not to fetch the user password
but always return password=masterpassword.

It took me a while to wrap my head around what you are saying here, but
once I got it I find it a simple, elegant and absolutely brilliant solution.

In thinking about it, it occurred to me I could maybe do the same
without even doing an ldap look up, so I changed the userdb/passdb
stanzas on the shared instance like so:

userdb {
   args = uid=vmail gid=vmail home=/CTFN/SharedMailboxes/CTFN/
   driver = static
}
passdb {
   args = user=%u password=XXXXXXX
   driver = static
   master = yes
}
passdb {
   driver = static
}


Where the password is the value set for imapc_password on the primary
instance.

The logs now show on the shared server that the user is authapps, and it
has the correct effective uid/gid/home values, and the master user and
the acl username is that of the user logging into the primary instance.

So looks like this will work!

Thank you, Sami, a bottle of Canada's finest is at your disposal...



>
> and maybe protect the authentication scheme with allow_nets=127.0.0.1 from
external abuse
>
> Sami
>
>