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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users