Stanislav Klinkov
2011-Aug-29 13:39 UTC
[Dovecot] Kerberos GSSAPI - proper item name in keytab
Hello, ALL.
I am trying to organize a transparent single sign-on concept for my
Active Directory users into Dovecot via IMAP. On the user's desktop I
use Thunderbird 6.0 as a mail client (MUA), Windows XP as an operating
system. Domain is controlled by Windows 2008 Server SP2 with Active
Directory.
I have installed on my Mail server Debian GNU/Linux 6.0.2 (Squeeze) and
Dovecot 2.0.13 from official "wheezy" repositories of it with all
dependencies.
I ran into in a problem with generating proper "/etc/krb5.keytab" file
for successful kerberos authentication against AD controller. I has
performed all the steps described in official dovecot wiki here:
http://wiki2.dovecot.org/Authentication/Kerberos
I have generated a service ticket with name
"imap/efim.test.local at MYORG.LAN" exactly as described in wiki.
("MYORG.LAN" is my kerberos realm.) But this does not work. I see in
debug logs something like this:
******** main service logs ********
Aug 29 16:05:14 auth: Info: gssapi(?,192.168.4.12): While processing
incoming data: Unspecified GSS failure. Minor code may provide more
information
Aug 29 16:05:14 auth: Info: gssapi(?,192.168.4.12): While processing
incoming data: Wrong principal in request
*************************************
******** auth debug logs *********
Aug 29 16:05:14 auth: Debug: gssapi(?,192.168.4.12): Obtaining
credentials for imap at efim.test.local
Aug 29 16:05:14 auth: Debug: client out: CONT 1
Aug 29 16:05:14 auth: Debug: client in: CONT<hidden>
Aug 29 16:05:16 auth: Debug: client out: FAIL 1
*************************************
But (!). If I define << auth_gssapi_hostname = "$ALL" >>
instead of <<
auth_gssapi_hostname = efim.test.local >> then everything works fine. I
decided to find out where is the problem, so I dig into source code of
gssapi module, "mech-gssapi.c". For versions 2.0.13 and 2.0.14 of
dovecot I see there the following:
********* mech-gssapi.c *********
static OM_uint32
obtain_service_credentials(struct auth_request *request, gss_cred_id_t
*ret_r)
/* blah-blah-blah */
principal_name = t_str_new(128);
str_append(principal_name, service_name);
str_append_c(principal_name, '@');
str_append(principal_name, request->set->gssapi_hostname);
auth_request_log_debug(request, "gssapi",
"Obtaining credentials for %s", str_c(principal_name));
inbuf.length = str_len(principal_name);
inbuf.value = str_c_modifiable(principal_name);
major_status = gss_import_name(&minor_status, &inbuf,
GSS_C_NT_HOSTBASED_SERVICE,
&gss_principal);
*********************************
So, according to source code, Dovecot tries to find in krb5.keytab a
principal named "imap at hostname". However wiki says to create the
principal named "imap/hostname at REALM".
Please, clarify where is the error: in source code, in wiki, or I have
misunderstood something.
Respectfully,
Stanislav Klinkov.
Nikolay Shopik
2011-Aug-29 19:08 UTC
[Dovecot] Kerberos GSSAPI - proper item name in keytab
On 29.08.2011 17:39, Stanislav Klinkov wrote:> So, according to source code, Dovecot tries to find in krb5.keytab a > principal named "imap at hostname". However wiki says to create the > principal named "imap/hostname at REALM". > > Please, clarify where is the error: in source code, in wiki, or I have > misunderstood something.Your principial in keytab should look like this - imap/mail.example.com at EXAMPLE.COM Make sure your realm name are all CAPS, otherwise it won't work.
Nikolay Shopik
2011-Aug-31 16:30 UTC
[Dovecot] Kerberos GSSAPI - proper item name in keytab
On 31.08.2011 18:55, 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<<auth_gssapi_hostname = "$ALL">> in dovecot config solves all > mentioned troubles at once? > > 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.Early versions of ktpass only allowed only 1 serviceprincipialnames, thus every time you generate new it was overwrite old one. ktpass from win2008 seems fix this.> >> 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. > >Can you do kinit -k imap/imap/efim.test.local at ROMASHKA.LAN and then klist, does it work for you? I do recommend tcpdump kerberos traffic between your client and server, this is usually helps me much better then any logging, flow easy to read in wireshark.
Stanislav Klinkov
2011-Sep-01 13:53 UTC
[Dovecot] [Solved] Kerberos GSSAPI - proper item name in keytab
OK, gentlemen.
I have found the source of problem. It appears to be very unexpectedly.
My testing stand was deployed on a OpenVZ-bazed virtual machine with
Venet interface on board. Here are references to OpenVZ documentation:
http://wiki.openvz.org/Virtual_network_device
http://wiki.openvz.org/Differences_between_venet_and_veth
By design venet interface coressponds to a loopback interface with one
or more aliases and very foxy routing rules. For example, in Debian it
looks like this:
************** ifconfig output ****************
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:956 errors:0 dropped:0 overruns:0 frame:0
TX packets:956 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:134666 (131.5 KiB) TX bytes:134666 (131.5 KiB)
venet0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:160164 errors:0 dropped:0 overruns:0 frame:0
TX packets:106318 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:155480098 (148.2 MiB) TX bytes:17449831 (16.6 MiB)
venet0:0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.9.36 P-t-P:192.168.9.36 Bcast:0.0.0.0
Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
************************************************
In config file it looks like this:
*********** /etc/network/interfaces *********
# Auto generated lo interface
auto lo
iface lo inet loopback
# Auto generated venet0 interface
auto venet0
iface venet0 inet manual
up ifconfig venet0 up
up ifconfig venet0 0
up route add default dev venet0
down route del default dev venet0
down ifconfig venet0 down
iface venet0 inet6 manual
auto venet0:0
iface venet0:0 inet static
address 192.168.9.36
netmask 255.255.255.255
*********************************************
For most cases such type of emulation works fine. But this time either
krb5 libs, or dovecot, or someone else could not correctly define
hostname. So, someone of them (I beleive than krb5 libs) was unable to
compare proper IP with the proper stanza in keytab. And neither explicit
"listen" nor "auth_gssapi_hostname" directives became
helpful.
So, I changed equipped emulated interface from "Venet" to more
"brute"
Veth, and everything flies up.
Thank you all very much for such an interesting discussion. I shall
describe this situation in my howto's and known issues archive, for others.
In other words, my trouble is totally OpenVZ-specific. So, I may pretend
to be the first who bumped into it.
And then, there is a second question.
Can there be a way to continue using this crafty venet interface, but
force krb5 libs to look up for desired IP ?
Respectfully,
Stanislav Klinkov.
Nikolay Shopik
2011-Sep-01 15:40 UTC
[Dovecot] [Solved] Kerberos GSSAPI - proper item name in keytab
On 01.09.2011 17:53, Stanislav Klinkov wrote:> Can there be a way to continue using this crafty venet interface, but > force krb5 libs to look up for desired IP ?Thanks for sharing solved problem. But I think this question better to forward to Kerberos mailing list. You probably find more explicit answer there, maybe this is even some kind of bug in krb5 libs :)