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

[Stephen Gallagher]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120131/aaf89c43/attachment.sig>