Hi Sami, Thank you for your reply.> yes you do need to define imapc_user if you want to switch user and master user around for imapc. like: > > imapc_user = authapps > imapc_master_user = %u > > without imapc_user dovecot would login to the secondary server like A bob.test*bob.test passwordWhen I add the 'imapc_user = authapps' option to the primary instance running on port 993, it passes the imapc_password as the password for the master user. here is what the logs on the shared instance show when I log into the primary instance: 2017-09-28 12:47:35.361064500 Sep 28 12:47:35 auth: Debug: ldap(bob.test,192.168.120.70,master,<hU/PLUVavLbAqHhG>): Master user lookup for login: authapps 2017-09-28 12:47:35.364892500 Sep 28 12:47:35 auth: Info: ldap(bob.test,192.168.120.70,master,<hU/PLUVavLbAqHhG>): invalid credentials (given password: XXXXXXXXX) 2017-09-28 12:47:37.367173500 Sep 28 12:47:37 auth: Debug: client passdb out: FAIL 2 user=bob.test The given password in the logs is the password supplied as imapc_password. if I change the imapc_password to be that of the bob.test user, the imapc login does succeed with bob.test as the master user. 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 so maybe I am not passing the %w in the correct spot? truly appreciate you taking a look at this, thank you.>> passdb { >> args = user=authapps password=XXXXXXXXXX >> driver = static >> } > > This is probably correct except that now user authapps can also login directly with password XXXXXXXXXX without master user login. > Which is probably OK as long as the password is kept secretOnce I get the imapc master user sorted out, I will play with the config to see what I can trim, but as of now, dropping just the password, or the entire args line, also causes the imapc login to fail... truly appreciate you taking a look at this, thank you.> > Sami >
> On 28 Sep 2017, at 23.08, Computerisms Corporation <bob at computerisms.ca> wrote: > > Hi Sami, > > Thank you for your reply. >> yes you do need to define imapc_user if you want to switch user and master user around for imapc. like: >> imapc_user = authapps >> imapc_master_user = %u >> without imapc_user dovecot would login to the secondary server like A bob.test*bob.test password > > When I add the 'imapc_user = authapps' option to the primary instance running on port 993, it passes the imapc_password as the password for the master user. here is what the logs on the shared instance show when I log into the primary instance: > > 2017-09-28 12:47:35.361064500 Sep 28 12:47:35 auth: Debug: ldap(bob.test,192.168.120.70,master,<hU/PLUVavLbAqHhG>): Master user lookup for login: authapps > 2017-09-28 12:47:35.364892500 Sep 28 12:47:35 auth: Info: ldap(bob.test,192.168.120.70,master,<hU/PLUVavLbAqHhG>): invalid credentials (given password: XXXXXXXXX) > 2017-09-28 12:47:37.367173500 Sep 28 12:47:37 auth: Debug: client passdb out: FAIL 2 user=bob.test > > > The given password in the logs is the password supplied as imapc_password. > > if I change the imapc_password to be that of the bob.test user, the imapc login does succeed with bob.test as the master user. > > 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 > > > so maybe I am not passing the %w in the correct spot? > > truly appreciate you taking a look at this, thank you.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. and maybe protect the authentication scheme with allow_nets=127.0.0.1 from external abuse Sami
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 > >