Re: Authenticating Virtual Users without domain
On 12/30/2014 6:49 PM, Leon Kyneur wrote:
Hi,
I'm trying to migrate a large number of users to a new Dovecot
cluster. The existing mail system allows a user to authenticate with a
bare username if they have connected to the correct local IP on the
server.
e.g.
imap.somedomain.com = 1.1.1.1
imap.anotheromain.com = 2.2.2.2
charlie@somedomain can authnenticate as 'charlie' or
'char...@somedomain.com' as long as he is connected to
imap.somedomain.com (1.1.1.1)
likewise for bare usernames if they connect to imap.anotherdomain.com.
A previous colleague actually achieved this by hacking with the
Dovecot source code and writing in a lookup table feature. The code is
very old and won't patch cleanly to the latest 2.2.15 source. Another
platform we are using (commercial product) also has this feature but
we also need to migrate these users to Dovecot.
I already have a Dovecot proxy layer for mailbox lookup - so ideally I
would like to do this on my Dovecot proxies.
I know I can also do this kind of thing if I swapped my dovecot proxy
for Perdition, however I don't really want to do that.
I've looked into checkpassword scripts and could possibly make
something work (albeit ugly) - is this the right direction to take
here?
Using SQL as the user database, set up a table for the mail users. The
following example uses the table named "mail_users" with the following
fields:
user_name = part left of @ in email address (EX: joe)
user_domain = part right of @ in email address( EX: mydomain.com)
domain_ip = the IP they connect to for their domain (EX: 1.1.1.1)
password = hashed password
home = full path to user's home directory
uid = user's uid
gid = user's gid
In dovecot-sql.conf.ext: (line breaks and indenting are added to improve
readability but your statement should be all one line in the
dovecot-sql.conf.ext file)
password_query =
SELECT
CONCAT(user_name, '@', user_domain) AS user,
password,
home AS userdb_home,
CONCAT('maildir:', home) AS userdb_mail,
uid AS userdb_uid,
gid AS userdb_gid
FROM mail_users
WHERE user_name = '%Lu'
AND domain_ip = '%l'
NOTE: %Lu is used on purpose, rather than %Ln. %Lu will fail the lookup
if the user provides a full email address, and this is deliberate. If
you also want to allow the user to connect to *any* IP with their full
email address as their login, use:
password_query =
SELECT
CONCAT(user_name, '@', user_domain) AS user,
password,
home AS userdb_home,
CONCAT('maildir:', home) AS userdb_mail,
uid AS userdb_uid,
gid AS userdb_gid
FROM mail_users
WHERE ( user_name = '%Lu' AND domain_ip = '%l' )
OR ( user_name = '%Ln' AND user_domain = '%Ld' )
With this query, the user can log in as "joe" by connecting to their
domain's specific IP, or they can log in as j...@mydomain.com by
connecting to any IP the server is listening on.
This is just a simple example to get started. You will probably want to
expand this by adding fields to specify if the account is active and so
on. Also, you can put the domain to local IP mapping in another table
and use a JOIN in your SELECT query, so you can eliminate the
"domain_ip" field from the "mail_users" table. This is an exercise left
to the reader. The "mail_users" table should have a primary index on
the combined "user_name" and "user_domain" fields, which should be unique.
In your dovecot-sql.conf.ext file, you will need to create a
"user_query" statement similar to your finalized "password_query"
statement, as well as an appropriate "iterate_query" statement. See the
Dovecot documentation.
Cheers.
Dem
Authenticating Virtual Users without domain
Hi, I'm trying to migrate a large number of users to a new Dovecot cluster. The existing mail system allows a user to authenticate with a bare username if they have connected to the correct local IP on the server. e.g. imap.somedomain.com = 1.1.1.1 imap.anotheromain.com = 2.2.2.2 charlie@somedomain can authnenticate as 'charlie' or 'char...@somedomain.com' as long as he is connected to imap.somedomain.com (1.1.1.1) likewise for bare usernames if they connect to imap.anotherdomain.com. A previous colleague actually achieved this by hacking with the Dovecot source code and writing in a lookup table feature. The code is very old and won't patch cleanly to the latest 2.2.15 source. Another platform we are using (commercial product) also has this feature but we also need to migrate these users to Dovecot. I already have a Dovecot proxy layer for mailbox lookup - so ideally I would like to do this on my Dovecot proxies. I know I can also do this kind of thing if I swapped my dovecot proxy for Perdition, however I don't really want to do that. I've looked into checkpassword scripts and could possibly make something work (albeit ugly) - is this the right direction to take here? Thanks, Leon
Re: Segmentation fault in pigeonhole lib-sieve
On 12/30/2014 03:04 PM, Stephan Bosch wrote: On 12/29/2014 10:02 PM, Orion Poplawski wrote: The sieve plugin for Thundirbird likes to rapidly compile work in progress sieve scripts to continually give feedback on any errors in the script. This can trigger segmentation faults in lib-sieve with certain pathologically incomplete sieve scripts. One example: Yes. This is a very straightforward problem. Here's a completely naive attempt at a patch: That is a good fix. However, lib-sieve has a utility function for verifications like this and that should have been used. Comparator handling predates this function, so I must have forgot to change comparator validation accordingly, which would have fixed this problem implicitly. Well, it is fixed now: http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/b6c55ac6460d Thanks! Regards, Stephan. Excellent, thanks for the quick fix! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: Segmentation fault in pigeonhole lib-sieve
On 12/29/2014 10:02 PM, Orion Poplawski wrote: > The sieve plugin for Thundirbird likes to rapidly compile work in > progress sieve scripts to continually give feedback on any errors in > the script. This can trigger segmentation faults in lib-sieve with > certain pathologically incomplete sieve scripts. One example: Yes. This is a very straightforward problem. > Here's a completely naive attempt at a patch: That is a good fix. However, lib-sieve has a utility function for verifications like this and that should have been used. Comparator handling predates this function, so I must have forgot to change comparator validation accordingly, which would have fixed this problem implicitly. Well, it is fixed now: http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/b6c55ac6460d Thanks! Regards, Stephan.
PAM issues on OS X Yosemite
Hi,
I have been running dovecot successfully on OS X Mavericks for several
months. After upgrading to Yosemite, however, PAM authentication for
dovecot is failing. Or rather, creating the PAM session is failing. Either
way, I can't get to my e-mail.
$ /usr/pkg/sbin/dovecot --version
2.2.15
$ /usr/pkg/sbin/dovecot -n
# 2.2.15: /usr/pkg/etc/dovecot/dovecot.conf
# OS: Darwin 14.0.0 x86_64 hfs
auth_debug = yes
auth_verbose = yes
mail_location = maildir:/Volumes/Secure/%u/Maildir
mail_privileged_group = mail
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = session=yes dovecot
driver = pam
}
ssl_cert =
Dec 30 13:21:51 my.host.name dovecot[49247]: auth-worker(49286): Debug:
pam(markus,::1): lookup service=dovecot
Dec 30 13:21:51 my.host.name dovecot[49247]: auth-worker(49286): Debug:
pam(markus,::1): #1/1 style=1 msg=Password:
Dec 30 13:21:51 my.host.name dovecot[49247]: auth-worker(49286): Error:
pam(markus,::1): pam_open_session() failed: session failure
Dec 30 13:21:53 my.host.name dovecot[49247]: auth: Debug: client passdb
out: FAIL1 user=markus
It does successfully verify my password. If I purposefully enter a wrong
password the error becomes "pam_authenticate() failed: authentication error
(password mismatch?)". So that portion is okay.
Do you have any suggestions how I might find out why pam_open_session() is
failing? The auth process *is* running as root.
I have tried these two PAM configurations. The first one based on
Maverick's /etc/pam.d/login and used to work fine on Mavericks.
# dovecot: auth account password session
auth optional pam_krb5.so use_kcminit
auth optional pam_ntlm.so try_first_pass
auth optional pam_mount.so try_first_pass
auth required pam_opendirectory.so try_first_pass
accountrequired pam_nologin.so
accountrequired pam_opendirectory.so
password required pam_opendirectory.so
sessionrequired pam_launchd.so
sessionrequired pam_uwtmp.so
sessionoptional pam_mount.so
I tried to simplify it by using the one suggested on dovecot's PAM wiki.
# dovecot: auth account password session
auth required pam_opendirectory.so try_first_pass
accountrequired pam_nologin.so
accountrequired pam_opendirectory.so
password required pam_opendirectory.so
On Yosemite, neither works. Or, quite possibly, both configurations are
fine and the problem lies elsewhere.
Any pointers would be greatly appreciated. In the mean time I'll be using
auth-passwdfile, since that works.
Thanks,
-Markus
Re: Authcache and user changing
2014-12-30 15:04 GMT+01:00 Lazy : > 2014-12-29 12:47 GMT+01:00 Lazy : >> Hi, >> >> >> I have noticed that during auth cache hits usernames are not updated. >> (We use ldap backend >> and change username with >> user_attrs = uid=user, mailMessageStore=home, >> mailQuotaSize=quota_rule=*:bytes=%$ >> >> cold cache >> >> lmtp(14414): Debug: auth input: testmon_testmon >> home=/vmail/te/testmon_testmon quota_rule=*:bytes=104857600 >> lmtp(14414): Debug: changed username to testmon_testmon >> lmtp(14414): Debug: Added userdb setting: plugin/quota_rule=*:bytes=104857600 >> >> >> hot cache >> >> lmtp(14715): Debug: auth input: iq...@mon.test.pl >> home=/vmail/iq/testmon_testmon quota_rule=*:bytes=104857600 >> lmtp(14715): Debug: Added userdb setting: plugin/quota_rule=*:bytes=104857600 > > auth replays are > > > USER\t2\ttestmon_testmon\thome=/vmail/te/testmon_testmon\tquota_rule=*:bytes=104857600\n > on a cache miss > > and > > USER\t3\ttest...@mon.test.pl\thome=/vmail/te/testmon_testmon\tquota_rule=*:bytes=104857600\n > with a cache hit > > > without cache user is rewriten as expected, with cache it isn't requests made by imap or pop3 are always rewriting the usernames is it a bug or is it intentional ? -- Michal Grzedzicki
Re: Authcache and user changing
2014-12-29 12:47 GMT+01:00 Lazy : > Hi, > > > I have noticed that during auth cache hits usernames are not updated. > (We use ldap backend > and change username with > user_attrs = uid=user, mailMessageStore=home, > mailQuotaSize=quota_rule=*:bytes=%$ > > cold cache > > lmtp(14414): Debug: auth input: testmon_testmon > home=/vmail/te/testmon_testmon quota_rule=*:bytes=104857600 > lmtp(14414): Debug: changed username to testmon_testmon > lmtp(14414): Debug: Added userdb setting: plugin/quota_rule=*:bytes=104857600 > > > hot cache > > lmtp(14715): Debug: auth input: iq...@mon.test.pl > home=/vmail/iq/testmon_testmon quota_rule=*:bytes=104857600 > lmtp(14715): Debug: Added userdb setting: plugin/quota_rule=*:bytes=104857600 auth replays are USER\t2\ttestmon_testmon\thome=/vmail/te/testmon_testmon\tquota_rule=*:bytes=104857600\n on a cache miss and USER\t3\ttest...@mon.test.pl\thome=/vmail/te/testmon_testmon\tquota_rule=*:bytes=104857600\n with a cache hit without cache user is rewriten as expected, with cache it isn't -- Michal Grzedzicki
