[Dovecot] Automatically Cleaning Kerberos Credential Cache Files

[Maura Dailey]

I'm in a situation here at work where I'm trying to support a mixed 
network of OS X and RHEL desktop machines with a Postfix/Dovecot 
combination.
   - user account information is stored in LDAP
   - user credentials are in MIT Kerberos
   - server is running RHEL 6/Dovecot 2.0.9/Postfix 2.6.6

I am currently using the PAM passdb module to authenticate my users (I 
began to have trouble with using GSSAPI directly). After I implemented 
it, a few weeks later, I noticed that some users were no longer getting 
their mail if they hadn't logged in during the past day. Postfix's mailq 
showed that hundreds of messages were backing up in the queue. I 
eventually tracked it down to leftover Kerberos credential cache files 
(/tmp/krb5cc_????) sitting in /tmp on the mail server. The presence of 
expired credential files was preventing Postfix from delivering mail to 
those users' mail spools. If I delete the credential files manually, 
Postfix immediately delivers the queued emails.

Currently, I have a cron job deleting the files manually every night. 
Obviously, this is a cruddy solution. I have Dovecot configured on a 
RHEL 6 box. The Pam stack on a RHEL 6 machine uses sssd (pam_sss.so) for 
authentication with Kerberos, not pam_krb5.so. I'm trying to track down 
which piece of the puzzle is responsible for cleaning up leftover 
credential caches. Is there a configuration option I can pass to 
Dovecot's passdb directly to clean up these cache files? Do others 
generally have more success using a custom PAM stack with pam_krb5.so 
instead of pam_sss.so? Poring over sssd's configuration options didn't 
reveal anything useful. I'm still not sure why Postfix even cares if 
there are expired credential cache files in /tmp at all.

I'm back to trying GSSAPI directly again as well in the meantime on a 
few test clients. When I used that in the past, users were getting 
issued duplicate Kerberos tickets and users were forced to log into the 
mail server directly using SSH after a day in order to get their mail to 
work (seemingly a related issue). If I get those same errors again, I'll 
start another thread.

The output of doveconf -N:

# 2.0.9: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-279.14.1.el6.x86_64 x86_64 Red Hat Enterprise Linux 
Server release 6.3 (Santiago) ext4
auth_cache_size = 10 k
auth_cache_ttl = 5 hours
auth_default_realm = server.com
auth_gssapi_hostname = hostname.server.com
auth_krb5_keytab = /etc/dovecot/dovecot.keytab
auth_mechanisms = gssapi plain
auth_realms = server.com
auth_username_format = %n
auth_verbose = no
disable_plaintext_auth = yes
listen = *
mail_location = maildir:/var/spool/mail/%u
mail_privileged_group = mail
mbox_read_locks = fcntl
mbox_write_locks = fcntl
namespace {
   inbox = yes
   location =
   prefix =
   separator = /
   type = private
}
passdb {
   driver = pam
}
protocols = pop3 imap
service auth {
   unix_listener /var/spool/postfix/private/auth {
     group = postfix
     mode = 0666
     user = postfix
   }
}
ssl = yes
ssl_cert = </usr/share/ssl/private/mail.server.com.pem
ssl_key = </usr/share/ssl/private/mail.server.com.pem
userdb {
   driver = passwd
}
protocol imap {
   imap_client_workarounds = tb-extra-mailbox-sep
   mail_plugins = " listescape"
}

Thanks for any pointers,
Maura Dailey
maura at eclipse.ncsc.mil