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.

Attachment: signature.asc
Description: This is a digitally signed message part

Freeipa-users mailing list

Reply via email to