On Aug 31, 2011, at 10:55 AM, Stanislav Klinkov wrote:
Thank you for sharing a very interesting experience, David.
It seemed like running ktpass multiple times invalidated the previous keytabs. OK. Let us assume. But then how can you explain the fact that the setting <
> in dovecot config solves all mentioned troubles at once?
That is a very good question that I sadly don't have the answer to and I fear I misunderstood the initial problem. It's my understanding that auth_gssapi_hostname controls which entries in the keytab file dovecot will allow itself to use. If you enable debug auth logging in dovecot, do you see anything about which entry in your keytab file it's attempting to use? Also, do you see anything in your AD logs when you get the "invalid principal" error from the IP of your dovecot host?
As well I just have run the following experiment. I re-generated one more keytab for service "imap/test.efim.local" only. So, it became the last-generated key. Then I copied it onto my dovecot server as the only "krb.keytab" file, and nothing changed.
Also, I issued the following command on my AD domain controller: C:\Windows\system32>setspn -L dovecot
And the result was:
Registered ServicePrincipalNames for CN=dovecot,OU=Agents,DC=romashka,DC=lan: imap/efim.test.local smtp/efim.test.local pop/efim.test.local
Please note, that I have not apllied any magic to servicePrincipalName of AD user "dovecot" by setspn or other AD snap-ins.
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.
Sorry, I might have not mentioned above. I run Mozilla Thunderbird on my Windows XP workstation.