dovecot - Apr 2009 - Disabling users whilst still allowing logins with a 'master password'

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

Hi Dominic,
> 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.
Would it be feasible to chown the mailstore to some special user and use the
account of that user to access the mailbox instead of the master password? Or,
alternatively, run a second instance of dovecot-imapd (running as that
special) to let the migration process access the mailboxes?

Not very pretty, but since this is only for migration, I'd say it would
suffice if it works?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090430/eae6190d/attachment-0002.bin>

On Thu, 2009-04-30 at 17:33 +0100, Dominic Hargreaves
wrote:
> 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?
GSSAPI code is a bit of a mystery to me. :) I guess it would be possible
to change it like that.

But, anyway, how about using mail_executable script that checks if the
logging in user is a master or user not, and if not check if the user is
in some deny database. http://wiki.dovecot.org/PostLoginScripting


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090501/2afc3ec5/attachment-0002.bin>

On Fri, May 01, 2009 at 04:38:46PM -0400, Timo Sirainen
wrote:
> GSSAPI code is a bit of a mystery to me. :) I guess it would be possible
> to change it like that.
> 
> But, anyway, how about using mail_executable script that checks if the
> logging in user is a master or user not, and if not check if the user is
> in some deny database. http://wiki.dovecot.org/PostLoginScripting
Yes, I think that's going to be the best idea. Thanks for pointing
out what seems pretty obvious now :)

Dominic.

-- 
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford

On Fri, May 01, 2009 at 04:38:46PM -0400, Timo Sirainen
wrote:
> But, anyway, how about using mail_executable script that checks if the
> logging in user is a master or user not, and if not check if the user is
> in some deny database. http://wiki.dovecot.org/PostLoginScripting
One question about thie mechanism that isn't made explicit, although
certainly implied by the examples: are $USER and $IP guaranteed to exist
and be sanitised?

Thanks,
Dominic.

-- 
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford