Hi,
I'm having trouble coming up with an authentication configuration that does what we want with dovecot, and thought it would be worth passing it by the list in case anyone can spot an easy fix, or confirm my suspicions that code changes are required.
You should probably be aware that this is to support a migration away from Dovecot to a certain Microsoft-provided mail platform, so if this makes you feel uncomfortable, you may choose not to respond ;)
We have the following configuration:
- the passdb in use is pam (for pam_krb5)
- the userdb in use is passwd (for nss_ldap)
- GSSAPI is also supported
- We support both IMAP and POP
- Dovecot 1.0.9
- users have their own uid/gid
and the following requirement, in order to support the migration process:
- Access to mailstore should be allowed by means of a master password or user (ideally configurable, so we have a fine degree of control over which users are exposed to the migration process at a given time)
- Migration process accesses mailstore via IMAP
- During migration, users should not be allowed to log in with their Kerberos password, nor with GSSAPI
We've achieved the first requirement with master passwords roughly as described at the bottom of http://wiki.dovecot.org/Authentication/MasterUsers by configuring another passdb with the master password hash in place for the users we want to be enabled to migrate.
Our standard auth config looks like:
auth default {
gssapi_hostname = imap210.herald.ox.ac.uk mechanisms = plain login gssapi
passdb pam { }
userdb passwd { args = blocking=yes }
socket listen { master { path = /var/run/dovecot/auth-master } } }
and my first try at satisfying my requirements was:
auth default {
gssapi_hostname = imap-dev.herald.ox.ac.uk mechanisms = plain login gssapi
passdb sql { args = /etc/dovecot/dovecot-sql-master.conf }
passdb sql { args = /etc/dovecot/dovecot-sql-deny.conf deny = yes }
passdb pam { }
userdb passwd { args = blocking=yes }
socket listen { master { path = /var/run/dovecot/auth-master } } }
where /etc/dovecot/dovecot-sql-master.conf describes a query representing those users accessible by the master password (and a hash of the master password) and /etc/dovecot/dovecot-deny.conf describes a query representing those users who should not be allowed to log in with their normal password (or GSSAPI).
This almost works, but unfortunately (as documented) the GSSAPI mechanism does not check any passdbs, so does not get checked against the deny passdb.
Normally to disable logins for a user we chmod their mail store to 0 so they can't access it, which has the same effect, but this obviously also prevents the master password from being able to access it.
It would seem to be generally useful to be able to check GSSAPI logins against a deny passdb, but is this a valid code change?
Alternatively, could the *userdbs* could be extended to cope with the idea of a deny form, since the GSSAPI login process already uses them (although it would have to return USERDB_RESULT_USER_UNKNOWN).
Alternatively, does anyone have any other ideas about how I could achieve the same effect?
Thanks for listening.
Dominic.
-- Dominic Hargreaves, Systems Development and Support Team Computing Services, University of Oxford