Re: [Dovecot] Disabling users whilst still allowing logins with a 'master password'
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
Re: [Dovecot] Disabling users whilst still allowing logins with a 'master password'
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
Re: [Dovecot] Disabling users whilst still allowing logins with a 'master password'
On May 5, 2009, at 10:24 AM, Dominic Hargreaves wrote: 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? Yes.
Re: [Dovecot] Disabling users whilst still allowing logins with a 'master password'
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 signature.asc Description: This is a digitally signed message part
[Dovecot] 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
Re: [Dovecot] Disabling users whilst still allowing logins with a 'master password'
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 signature.asc Description: Digital signature
