On Aug 31, 2011, at 9:35 AM, Stanislav Klinkov wrote:
How did you generate those keys and put them into krb5.keytab? I logged onto my domain controller via RDP and issued the following commands:
**************** keytabs generation ********************* ktpass -princ imap/efim.test.local@ROMASHKA.LAN -mapuser dovecot -pass megasuperpassword -ptype KRB5_NT_SRV_HST -out imap.keytab
ktpass -princ pop/efim.test.local@ROMASHKA.LAN -mapuser dovecot -pass megasuperpassword -ptype KRB5_NT_SRV_HST -out pop.keytab
ktpass -princ smtp/efim.test.local@ROMASHKA.LAN -mapuser dovecot -pass megasuperpassword -ptype KRB5_NT_SRV_HST -out smtp.keytab
Then I moved "imap.keytab", "pop.keytab" and "smtp.keytab" onto my dovecot server machine and merged them into single file with "ktutil": ************** ktutil commands ************** rkt imap.keytab rkt pop.keytab rkt smtp.keytab wkt krb5.keytab quit
I did exactly what you did when I was trying to get IMAP and SMTP Kerberized with AD (although I used KRB5_NT_PRINCIPAL in ktpass) and got the same error you were getting. It seemed like running ktpass multiple times invalidated the previous keytabs. What I did to fix it was run ktpass once for imap/fqdn@REALM and copy the hex key, kvno and encryption type to a text file somewhere. (You could also get these from klist -Kek <imap keytab>) Then I used ktutil to rkt the imap keytab and did "addent -key -p smtp/fqdn@REALM -k <kvno> -e <enc type, probably arcfour-hmac>" and then paste the hex key I got from ktpass. Since you're not using +rndPass in ktpass, you may be able to use -password instead of key in the addent command in ktutil, but I haven't used that method before. Then wkt the ticket somewhere and klist -Kek <keytab> and make sure that all entries have the same KVNO, hex key, and enc type but different principals.
Then use your preferred method (setspn.exe or some graphical interface to AD's LDAP) to add entries to your dovecot user's servicePrincipalName attribute for each new principal you added to your keytab. The first ktpass should've put something there for you, just follow that example.
To make sure everything should work, hop on a box where you have a valid user Kerberos ticket and do kvno imap/efim.test.local and kvno smtp/efim.test.local. That should try to get tickets for each of those services. If that doesn't work, then something is probably wrong with the servicePrincipalName attribute. One thing I should mention: servicePrincipalNames must be unique in AD, but I don't believe there are any controls to prevent you from making duplicates since it's just an LDAP attribute.
The effect of this (as you can probably guess) is that IMAP, POP and SMTP effectively end up as aliases to the dovecot user in AD, using a single key.
Are you using Active Directory for Kerberos? Yes, I am.
and added the SPN for smtp using LDAP/setspn and used ktutil on the dovecot host to add an entry to my keytab with the same key and kvno Sorry, I'm not sure in realizing what you mean. What is "LDAP/setspn"?
I should've been more clear about LDAP/setspn. You can use setspn.exe command on one of your AD controllers, or Active Directory Users & Computers or AD & GP MMC interfaces (depending on if you have Win Server 2k3 or 2k8) to edit the servicePrincipalName attribute for your dovecot user in AD's LDAP store.