[Dovecot] Kerberos GSSAPI - proper item name in keytab

[Stanislav Klinkov]

> Why such hostility?

I beg you pardon, sir. Nothing personal, but to the question like "My
car does not move" you provide the answer "Try to wipe screen and kick
wheels". How do you think, if one digs into source code, has not he
attempted more simple ways? Yes, I have read the manuals and wiki's
before posting here. And I know what is wireshark and how to use it.

> And I did answer your second question about how principal should looks
> like.

The matter of my question was how does the string in form of
"service at host" agree with keytab entries in form of
"service/host at REALM". Now I do know the answer. It is controlled by the
argument "GSS_C_NT_HOSTBASED_SERVICE" of function "gss_import_name".

>
> Maybe I wrong, not running yet 2.0.

You are wrong. There were some minor changes. See here, for example:
http://www.dovecot.org/list/dovecot-cvs/2010-June/017143.html

>
> Make sure your client requesting correct principal in first place.

Yes, I am sure. I examined logs of my Mozilla Thunderbird client. They
look like this:

******* Thunderbird logs **********
3712[5a9e240]:   nsAuthSSPI::Init
3712[5a9e240]:   InitSSPI
3712[5a9e240]: Using SPN of [imap/efim.test.local]
3712[5a9e240]: AcquireCredentialsHandle() succeeded.
3712[5a9e240]: entering nsAuthSSPI::GetNextToken()
3712[5a9e240]: InitializeSecurityContext: continue.
*************************************

> "Wrong principal in request", Usually means the principal in the
> system keytab for your system doesn't agree with the hostname or DNS
> name of the system.

It does agree. My host is named "efim.test.local". Here is the contents
of my krb5.keytab:

******* krb5.keytab ***********
slot KVNO Principal
---- ----
---------------------------------------------------------------------
   1    4      imap/efim.test.local at ROMASHKA.LAN
   2    5       pop/efim.test.local at ROMASHKA.LAN
   3    6      smtp/efim.test.local at ROMASHKA.LAN
*********************************

I have already found out, that denial is generated somewhere inside krb5
libraries, not in Dovecot's modules. But I see no way to trace or debug
kerberos calls. Source codes of kerberos libs are too complex for me to
analyze.

If you are interested in, you may join the parallel discussion of the
topic on iXBT forum here: http://forum.ixbt.com/topic.cgi?id=76:10089

With best regards,
Stanislav Klinkov.