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'

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

# 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" >>
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'
sed -i "s/#auth_gssapi_hostname =/auth_gssapi_hostname = $(hostname)/g"
sed -i "s-#auth_krb5_keytab =-auth_krb5_keytab = /etc/krb5.keytab-g"
sed -i "s/#auth_realms =/auth_realms = $(hostname --domain)/g"
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
ipa-getkeytab -s ds01.example.com -p imaps/mail02.example.com -k
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=<us...@example.com>, method=GSSAPI, rip=,
lip=, 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?


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
>>>>> 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
>>>>> service principles for the other host name, and the following
>>>>> 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
>>> 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.
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Attachment: 0xB5B41FAA.asc
Description: application/pgp-keys

Attachment: 0xB5B41FAA.asc.sig
Description: PGP signature

Freeipa-users mailing list

Reply via email to