On Mon, 2015-09-07 at 17:07 +0200, Benny Pedersen wrote:

Kanwar Ranbir Sandhu skrev den 2015-09-07 16:47:

...

Kerberos + Dovecot apparently works really well, but not for me...yet. :(

you choiced to use a precompiled problem from redhat, no ?

Yes. Well, not Red Hat directly - I'm using CentOS.

back to your problem, are you sure maintainer at redhat enabled kerberos auth login ?

Yes, I can see AUTH=GSSAPI when I telnet to the server and get a list of Dovecot's capabilities.

if need more help ask the maintainer for the rpm package, or still convenced its a bug in dovecot show dovecot -n, i have lost if you already have, but lets take it from there on

I don't think it's a bug in Dovecot. I have feeling I have a misconfiguration, but I can't figure out what it is.

I sent my config in a reply to another list member's message. Maybe the broken part will jump out now.

Thanks,

Ranbir

-- Kanwar R.S. Sandhu

On Mon, 2015-09-07 at 09:14 -0600, Manuel Delgado wrote:

Hi Ranbir

I've worked with freeIPA a little, but without your doveconf or some other context information, it is difficult to identify the issue.

Crap...I meant to include that. Here's what it looks like when I enable GSSAPI:

# 2.2.10: /etc/dovecot/dovecot.conf # OS: Linux 3.10.0-229.11.1.el7.x86_64 x86_64 CentOS Linux release 7.1.1503 (Core)
auth_default_realm = theinside.rnr auth_gssapi_hostname = mailman02.theinside.rnr auth_krb5_keytab = /etc/imap.keytab auth_mechanisms = gssapi auth_realms = theinside.rnr hostname = imap.thesandhufamily.ca listen = 1.1.0.0 mail_gid = virtual mail_location = maildir:~/Maildir mail_plugins = quota acl mail_uid = virtual managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave mbox_write_locks = fcntl namespace { location = maildir:/var/spool/mail/thesandhufamily.ca/public prefix = Public. separator = . subscriptions = no type = public } namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } plugin { acl = vfile quota = maildir:User quota quota_rule = *:storage=500M sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } postmaster_address = postmaster@%d protocols = imap lmtp service auth-worker { user = $default_internal_user } service auth { inet_listener { address = 1.1.0.0 port = 17900 } unix_listener auth-userdb { group = virtual mode = 0600 user = virtual } } service imap-login { process_min_avail = 5 } service imap { process_limit = 10 } service lmtp { inet_listener lmtp { address = 1.1.0.0 port = 24 } } ssl = required ssl_cert =

-- Kanwar R.S. Sandhu

On Mon, 2015-09-07 at 18:39 +0200, Benny Pedersen wrote:

Kanwar Ranbir Sandhu skrev den 2015-09-07 18:02:

...

args = uid=virtual gid=virtual home=/var/spool/mail/%d/%n/

uid and gid must be nummeric just like output from id

id virtual

make the args have same info

That's never caused any issues before. In fact, in my normal configuration (i.e. no GSSAPI auth) it works just fine.

Is GSSAPI auth the only auth method that needs a numeric ID?

Regards,

Ranbir

-- Kanwar R.S. Sandhu

On Mon, 2015-09-07 at 13:29 -0400, Kanwar Ranbir Sandhu wrote:

I tried it for shits and giggles: no change. :( I'm still seeing the same problem.

I forget to add some additional errors I've seen in the logs:

http://pastebin.ca/3155329

-- Kanwar R.S. Sandhu

Am 2015-09-07 um 19:47 schrieb Benny Pedersen:

Kanwar Ranbir Sandhu skrev den 2015-09-07 19:29:

...

I tried it for shits and giggles: no change. :( I'm still seeing the same problem.

dovecot is buildt with security in mind...

using namebased gid or uid is not secure

it might just still works, but its not secure

Benny, where did you learn all this?

-- peter

From the first message I noted this:

mailman02 dovecot: imap-login: Disconnected (tried to use unsupported auth

mechanism): user=<>, method=PLAIN, rip=1.1.1.1, lip=2.2.2.2, TLS, session=<QhWSqxofyAAKyAkM>

It seems that your client is not using GSSAPI, but PLAIN instead.

About your config:

On Mon, Sep 7, 2015 at 10:02 AM, Kanwar Ranbir Sandhu < m3freak@thesandhufamily.ca> wrote:

auth_default_realm = theinside.rnr auth_realms = theinside.rnr

In my configs I was forced to use REALM in uppercase. When I used it lowercase I had issues mainly with PAM.

auth_krb5_keytab = /etc/imap.keytab

Double-check that your keytab is correctly authorized in IPA and it's still valid. In my case I had to setup a cron to refresh the keytab. (Remember chown it, so Dovecot can read it)

Regards, Manuel Delgado

*Usuario Linux* *#520940 http://counter.li.org/*

Mag. Computación e Informática Universidad de Costa Rica Centro de Informática

On Mon, 2015-09-07 at 20:37 +0300, Timo Sirainen wrote:

It says "tried to use unsupported auth mechanism". In your later mail you say that telnet shows AUTH=GSSAPI in capabilities. So that would mean that the client isn't using AUTHENTICATE GSSAPI but something else.

I'd been considering that perhaps my version of Evolution was too old, so I upgraded from Fedora 20 to Fedora 22: still doesn't work. :/

Set auth_debug=yes and/or see what the client actually does by enabling pre-login rawlog: http://wiki2.dovecot.org/Debugging/Rawlog

Alright, I enabled it. I have some logs, but I'm not clear on what I should and shouldn't include here. Can I just copy and paste both in and out logs verbatim without inadvertently giving up my passwords or something??

Regards,

Ranbir

-- Kanwar R.S. Sandhu

On Mon, 2015-09-07 at 23:15 +0200, Benny Pedersen wrote:

change password before debug logs

then run debug

change password

paste it

is safe

Here's the in rawlog:

1441680001.046492 B00001 AUTHENTICATE GSSAPI 1441680001.051720 YIICZQYJKoZIhvcSAQICAQBuggJUMIICUKADAgEFoQMCAQ6iBwMFACAAAACjggFlYYIBYTC CAV2gAwIBBaEPGw1USEVJTlNJREUuUk5SoiowKKADAgEDoSEwHxsEaW1hcBsXbWFpbG1hbj AyLnRoZWluc2lkZS5ybnKjggEXMIIBE6ADAgESoQMCAQKiggEFBIIBAQc2ZO0LqkT03rNse kmt522hC/aiXw/TLsQmI687pJUmMCky/aeyFpOr4SL3fcvd7PD4FXh193hgo+XUfky8eoCc L8Ajd3ck/wg0qGd3sHmiwJAmrRNf/eCrENv6GbHqKjIq+S7fo9UesVWFuF+UgRVLWmOBZfM fX7oj6i4U4vBT5SwxHZ+YQtxf7oDl1cXPz7s+53AXe7rr9HoCheavTu7h682l2nPkw8+U1j ZiwXXstZtf5eG/K+wDe8omDzehDB5SaqeZ2nQNtr7CeRxgBGpDjtajVf5jkFf2GBDsZDeoG ABLAF++RcLxdyDQvVRFe0EeLs1qUXxX9ThNwTmnbCfRpIHRMIHOoAMCARKigcYEgcP4Mqy1 HrNRK79HY89oRG9tpP0FyDuWd38xXd/pKfqFl0NDkENdBHXUSsyOVKYsNFSncf1EIRL2s1s fWnV1Folk2HB/JvtEJD3eA1+f5wSXiT5pcmc/5tE+Bdf8n8wC0ExGx3RrM0cffjr/CgR7SE 6z9MHUn2UPGIFyoq7zDFrD5ILV5KyZd2zm86prr8tziEZ3wmYQbVsx3rEG1lJ193Z++S2yj 57+fGoJ7jA56GXNChfB/hFNx4xs2QSzCjccy0D+3RI= 1441680001.087279 1441680001.087982 BQQE/wAMAAAAAAAAFP2szwH///9yYW5iaXKB/Devj+/oz2utdNs=

Here's the out rawlog:

1441680000.950204 * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN -REFERRALS ID ENABLE IDLE LOGINDISABLED AUTH=GSSAPI] Dovecot ready. 1441680001.049592 + 1441680001.085562 + YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRv03ycmqWKFL9 foDag8BqF5je64ekOG0UCpcDfT4v3ZwNLLhZL/Fo0THb+xD09LJcGM2AtTzRMFFV8V7YHSV L1q+/X9exo0mxU6tMeHmXhMDq71PDcqB5zKdCpTmhakqny5x/vLM47xlnzj+oqwgnY 1441680001.087338 + BQQF/wAMAAAAAAAAJbP26AH///8IAt4FH+6nauwY4Oc= 1441680001.096713 B00001 NO [UNAVAILABLE] Temporary authentication failure. [mailman02.theinside.rnr:2015-09-08 02:40:01] 1441680001.096726 * OK Waiting for authentication process to respond..

Ranbir

-- Kanwar R.S. Sandhu

On Tue, 2015-09-08 at 13:11 +0300, Timo Sirainen wrote:

I guess it's now crashing with this:

auth: Panic: file auth-request.c: line 733 (auth_request_is_disabled_master_user): assertion failed: (request ->requested_login_user != NULL)

That's a bug in the Dovecot version you're using. Upgrade.

That's just awesome. I saw that in the debug log before I posted to the list, but I was hoping it was being triggered by a bad configuration on my part. :/

Ima screwed until an update is release by the CentOS team and they'll be waiting until Red Hat does something about it.

:: cries ::

Thanks to everyone for the help! At least now I know it's not my fault.

Regards,

Ranbir

-- Kanwar R.S. Sandhu

On Tue, 2015-09-08 at 19:27 +0300, Timo Sirainen wrote:

You can probably work around that by configuring something like:

passdb { driver = passwd-file args = /etc/dovecot/passwd.master master = yes }

The passwd.master file itself can be empty.

Where do I add this config: in auth-static.conf.ext?

I take it a master user isn't absolutely required, but to workaround this bug, one must be configured?

Ranbir

-- Kanwar R.S. Sandhu