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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
