[Freeipa-users] Dovecot imap authentication with IPA/Kerberos

Tue Jan 31 16:07:26 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

howdy all

just another update from me.

I have a workable gssapi setup working with dovecot for imap... (i
didn't test pop.... yet).
the below setup was tested against rhel6.2

# enable dovecot on startup
chkconfig dovecot on

# set dovecot to listen on imap
sed -i 's/#protocols = imap pop3 lmtp/protocols = imap/g'
/etc/dovecot/dovecot.conf

# set mailbost location
echo "mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u" >>
/etc/dovecot/dovecot.conf

# enable user/mailbox lookups
echo "userdb {" >> /etc/dovecot/conf.d/10-auth.conf
echo "  driver = static" >> /etc/dovecot/conf.d/10-auth.conf
echo "  args = uid=dovecot gid=dovecot home=/var/spool/mail/%u" >>
/etc/dovecot/conf.d/10-auth.conf
echo "}" >> /etc/dovecot/conf.d/10-auth.conf

# set all gssapi goodies for SSO against IPA
sed -i 's/auth_mechanisms = plain/auth_mechanisms = gssapi/g'
/etc/dovecot/conf.d/10-auth.conf
sed -i "s/#auth_gssapi_hostname =/auth_gssapi_hostname = $(hostname)/g"
/etc/dovecot/conf.d/10-auth.conf
sed -i "s-#auth_krb5_keytab =-auth_krb5_keytab = /etc/krb5.keytab-g"
/etc/dovecot/conf.d/10-auth.conf
sed -i "s/#auth_realms =/auth_realms = $(hostname --domain)/g"
/etc/dovecot/conf.d/10-auth.conf
sed -i "s/#auth_default_realm =/auth_default_realm = $(hostname
--domain)/g" /etc/dovecot/conf.d/10-auth.conf

# create keytab for service principles.
kinit admin
ipa service-add imap/mail02.example.com
ipa service-add imaps/mail02.example.com
ipa-getkeytab -s ds01.example.com -p imap/mail02.example.com -k
/etc/krb5.keytab
ipa-getkeytab -s ds01.example.com -p imaps/mail02.example.com -k
/etc/krb5.keytab
setfacl -m u:dovecot:r /etc/krb5.keytab

service dovecot restart

there 2 things I want to get resolved before i put the details on the
wiki and thats around selinux and automated deployments (kickstart)..

when selinux is enforcing, i receive these messages in /var/log/maillog.
The second line shows the error.

Jan 31 15:54:28 mail02 dovecot: imap-login: Login:
user=<user1 at example.com>, method=GSSAPI, rip=192.168.122.61,
lip=192.168.122.32, mpid=20737, TLS
Jan 31 15:54:28 mail02 dovecot: imap(user1): Error:
open(/home/user1/mail/.imap/INBOX/dovecot.index.log) failed: Permission
denied (euid=1201600003(user1) egid=1201600003(user1) missing +r perm:
/home/user1/mail/.imap/INBOX/dovecot.index.log, euid is not dir owner)

the first line shows the successful gssapi authentication. (gotta love
not entering passwords).

I am no guru on dovecot, but does anyone have any recommendations for
the second line? I presume it has to do with the format that I am
setting the mail_location variable.

I reproduced this twice to verify the settings. The only part that I
can't automate via kickstart, is the kinit admin section, of course
because we have to enter a password here..

any thoughts?

Dale

On 01/31/2012 02:23 PM, Simo Sorce wrote:
> On Tue, 2012-01-31 at 07:32 -0500, Stephen Gallagher wrote:
>> On Tue, 2012-01-31 at 10:22 +0100, Ondrej Valousek wrote:
>>>
>>>>> Hey sounds good to me, just glad it is working for you :). The only
>>>>> other question/suggestion I have is that it looks like you aren't
>>>>> leveraging kerberos in your configuration for SSO, You might want to
>>>>> think about doing this as it can be a pretty nice configuration.
>>>>>
>>>>> Essentially you would just need to add service principles for the host
>>>>> in the form of imap and or pop, and change the auth line in your
dovecot
>>>>> config to allow for gssapi auth, like so:
>>>>>
>>>>> sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&"
>>>>>
>>>>> Then assuming your user has a ticket, and their client is properly
>>>>> configured, they no longer need to do anything upon logging into their
>>>>> system, kerb will auth the rest.
>>>>>
>>>>> If you are on a multihomed system, you will need two additional
changes,
>>>>> service principles for the other host name, and the following
modification:
>>>>> sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&'
>>>>>
>>>>> I got a little caught up when you referenced the /etc/krb5.keytab file
>>>>> as possibly part of the problem so I thought this was more a kerb
issue.
>>>>>
>>> Exactly, I was confused by this as well - I would like to see this
>>> working, too. But I would say we would need to do something with the
>>> permissions on /etc/krb5.keytab which is now (by default) only
>>> readable by root. We need to address this problem more in general as
>>> when inegrating Bind DNS server, you hit the same thing.
>>> I would say something like ACL entry would help.
>>
>>
>> I fail to see why non-root processes should be trying to
>> read /etc/krb5.keytab at all. You should be generating a per-service
>> keytab with only the keys necessary for that service to authenticate
>> itself to the KDC. So you might have /etc/dovecot/dovecot.keytab which
>> is readable only by the dovecot user.
>>
>> The problem with allowing access to /etc/krb5.keytab is that it means
>> that an exploit in another process (especially a mail server!) could
>> gain access to the keys necessary to impersonate your host in kerberized
>> applications on the network. That's really dangerous.
>
> Just to make it clear how bad it is.
> The host/ key is used to validate logins, if an attacker gets it it can
> successfuly MITM a login attempt by hijacking KDC replies to AS-REQ and
> TGS-REQ by forging a TGT and then forging a ticket for the host using
> the host key.
>
> It is *very* bad, so try to reduce the number of applications that can
> access the host/ keys.
>
> Simo.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPKBGvAAoJEAJsWS61tB+qERMQAIyz/8ZTJYOJv0c1O6QtFMUY
kznbbGwT3ydjCNWCIWiuZs+sg9rOKWueGsM1wUA0OPZKHon261E6X8DMdXpvOfRr
/Y7Suub4XJxIlLDEvjSwbUIkniTlM6mbnHrxuEvGw+51fBjXZCXR1LPsFtcz8qAh
HXYnpEyFgsBTapQ0foO5anM2CtM1g+qrqkIeSkWV9aHk4UYBG5tR+OWJeUVBeQUV
9Ch/9xcBGOJcaCeKDxgWfvOfgJFP5YX4tuEYNGJNYpJP3fosMP1+Uf0Hsnn+b2sV
DuOlZIsMT45GsswsNIATbxfnmCn76jT2PTrFGFGFFjt47Mw7vPt5Ago6SxpmVlWN
cMRNuC1Z3bjp7jIIBJvOV6cQDVpaEhss0wuq/TWMfD9NadYCruPoil48UX+focLd
TlfOrK4iZ9qeSwlh0nnn9eSqCMJQjizPo1EqNrMm+vImccR9eSM8GSRvaO/3vHtJ
0pEVcUEQvJydOiUV9lNH5Z0goujWQveRirYImuiyEA3aK/P1pP49agVkNvD4e9Mf
UWyrWstuYXTAjS8QRTGMXmzQz41u7KnBwjMSKQq7qcMFIOcP3IoZWXvc+OdlfgnZ
YeVEHTL83Zs5ZyzeS71TJE9l3R7jp4ztEdtjJuwPkMXSZTqWT26/9WD75vIQLVON
i7Z+nM1U0MvqViwuzGBW
=wwcq
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB5B41FAA.asc
Type: application/pgp-keys
Size: 5790 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120131/788ee9b2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB5B41FAA.asc.sig
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120131/788ee9b2/attachment.sig>