[Dovecot] Disabling users whilst still allowing logins with a 'master password'

[Dominic Hargreaves]

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