On Sat, Feb 05, 2011 at 08:49:21PM -0700, Trever L. Adams wrote:
It appears that the script you recommended doesn't do the trick. Does /usr/libexec/dovecot/auth clear the environment. Even doing it manually from the command line the openldap stuff doesn't seem to pick up the KRB5_KTNAME environment variable. Isn't it called KRB5CCNAME? Yes. Some things (Amanda, at least from the directions, I haven't done it yet) actually still use service principals which are KRB5_KTNAME. For credentials in most clients, yes, KRB5CCNAME and that does work.
Amanda is doing what I described below internally. The keytab file contains kerberos shared secrets so Amanda uses that to get a TGT. You can't use kerberos without a TGT. The fact it is using a SPN or UPN shared secret doesn't matter at the client.
However! Be aware that the TGT must be refreshed periodically, that is just how kerberos works. Yes, this refresh is EXACTLY what I have been trying to avoid with service principals. I am starting to wish that Samba 4 supported SASL CRAM-MD5 or something so that I could just use that; no refresh.
Put the kinit -k line in a crontab. That command gets a fresh TGT for the machine account.
Service principles just avoid having to create a new UPN in MIT kerberos. In AD kerberos a SPN cannot get a TGT so that is undoable. The machine account works in very similarly to how a SPN would be used in MIT kerberos except that it is a UPN at the KDC. Samba writes a keytab entry for the machine account that contains the shared secret which lets kinit -k work.
Thank you for all your input. I am afraid this is the same problem I am going to hit with Postfix (it does a similar setup to Dovecot, I am just not running the recent version yet that supports it).
Yes. Same answer, run it pointing to the same CC cache you setup for dovecot.
Be aware that both the keytab and the creditial cache are 'password equilvients' and must be protected.
Jason