[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@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@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@hostname". However wiki says to create the principal named "imap/hostname@REALM".
Please, clarify where is the error: in source code, in wiki, or I have misunderstood something.
Respectfully, Stanislav Klinkov.
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@hostname". However wiki says to create the principal named "imap/hostname@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@EXAMPLE.COM Make sure your realm name are all CAPS, otherwise it won't work.
On 30.08.2011 9:24, Stanislav Klinkov wrote:
Your principial in keytab should look like this - imap/mail.example.com@EXAMPLE.COM Make sure your realm name are all CAPS, otherwise it won't work. Thank you, Captain Obvious.
Why such hostility? A lot people miss that, nothing special here. And I did answer your second question about how principal should looks like.
Because mech-gssapi.c wasn't changed in years, so I doubt anything changed in 2.0 version compare to 1.2 series in GSSAPI. Maybe I wrong, not running yet 2.0.
Make sure your client requesting correct principal in first place. "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.
On 08/30/2011 12:50 PM, Nikolay Shopik wrote:
On 30.08.2011 9:24, Stanislav Klinkov wrote:
Your principial in keytab should look like this - imap/mail.example.com@EXAMPLE.COM Make sure your realm name are all CAPS, otherwise it won't work. Thank you, Captain Obvious.
Why such hostility? A lot people miss that, nothing special here. And I did answer your second question about how principal should looks like.
Agreed. I am unlikely to help with this problem now due to lack of common courtesy.
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@host" agree with keytab entries in form of "service/host@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@ROMASHKA.LAN 2 5 pop/efim.test.local@ROMASHKA.LAN 3 6 smtp/efim.test.local@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.
On Aug 31, 2011, at 8:27 AM, Stanislav Klinkov wrote:
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@host" agree with keytab entries in form of "service/host@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.
I take these Thunderbird log entries to mean your workstation was able to get a kerberos ticket for imap/efim.test.local
"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@ROMASHKA.LAN 2 5 pop/efim.test.local@ROMASHKA.LAN 3 6 smtp/efim.test.local@ROMASHKA.LAN
The fact that you have different KVNOs for multiple services on the same host seems curious. How did you generate those keys and put them into krb5.keytab? Are you using Active Directory for Kerberos? If I ran ktpass multiple times to generate a new key for imap and then smtp, I would get the "wrong principal in request" error. When I ran ktpass once for IMAP 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 as ktpass generated the first time, then dovecot and smtp started working. I suppose that's weaker for security but chances are your mail SPNs (imap/pop/smtp) are tied to a single user or machine account anyway...
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.
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
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"?
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
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.
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?
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.
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.
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<
> 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@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.
On 08/31/2011 10:30 AM, Nikolay Shopik wrote:
Can you do kinit -k imap/imap/efim.test.local@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.
Under active directory, you cannot kinit as an SPN, only UPN (including MACHINE$ accounts). At least this is my experience.
Trever
"Selfishness is really self-destruction in slow motion." -— Elder Neal A. Maxwell - Ensign, May 1999, 23
On 08/31/2011 07:35 AM, Stanislav Klinkov wrote:
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 have only followed part of this. It the original poster's problem is that the LDAP database is not being able to be accessed with an SPN ticket, this is because SPNs are not allowed to log in in AD. You need to use a user account (including MACHINE$ accounts). It took me forever to figure this out. To use this, you need a cron job that creates/renews tickets from time to time for the user/machine account. Then you use Dovecot's environment setup configuration to set the KRB5_CC (or whatever it is called, my head is elsewhere) env variable to that Kerberos ticket cache that was created in the cronjob. This cache needs to be readable by dovecot and should be owned by its user.
Trever
First Law of System Requirements: "Anything is possible if you don't know what you're talking about..." -- Unknown
On Wed, Aug 31, 2011 at 09:28:50AM -0600, Trever L. Adams wrote:
I have only followed part of this. It the original poster's problem is that the LDAP database is not being able to be accessed with an SPN ticket, this is because SPNs are not allowed to log in in AD. You need to use a user account (including MACHINE$ accounts). It took me forever to figure this out. To use this, you need a cron job that creates/renews tickets from time to time for the user/machine account. Then you use Dovecot's environment setup configuration to set the KRB5_CC (or whatever it is called, my head is elsewhere) env variable to that Kerberos ticket cache that was created in the cronjob. This cache needs to be readable by dovecot and should be owned by its user.
This all works a 1000% better if you use Samba to join the domain and create your keytab with the right SPNs. See my prior posts to this list for a formula. Using the MS kerberos compatability tools is painful, complicated and tends to make a mess.
Samba will create a machine UPN and populate the system keytab appropriately. From a cron job you can use 'kinit -k' to maintain an active ticket for the machine UPN which dovecot can use for LDAP operations.
Jason
On Wed, 31 Aug 2011 14:39:56 -0600 Jason Gunthorpe articulated:
On Wed, Aug 31, 2011 at 09:28:50AM -0600, Trever L. Adams wrote:
I have only followed part of this. It the original poster's problem is that the LDAP database is not being able to be accessed with an SPN ticket, this is because SPNs are not allowed to log in in AD. You need to use a user account (including MACHINE$ accounts). It took me forever to figure this out. To use this, you need a cron job that creates/renews tickets from time to time for the user/machine account. Then you use Dovecot's environment setup configuration to set the KRB5_CC (or whatever it is called, my head is elsewhere) env variable to that Kerberos ticket cache that was created in the cronjob. This cache needs to be readable by dovecot and should be owned by its user.
This all works a 1000% better if you use Samba to join the domain and create your keytab with the right SPNs. See my prior posts to this list for a formula. Using the MS kerberos compatability tools is painful, complicated and tends to make a mess.
Samba will create a machine UPN and populate the system keytab appropriately. From a cron job you can use 'kinit -k' to maintain an active ticket for the machine UPN which dovecot can use for LDAP operations.
I just got this link from a friend who uses Kerberos on several systems.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8350
I have no idea if it will work or help you or not.
-- Jerry ✌ Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
Everlasting peace will come to the world when the last man has slain the last but one.
Adolf HitlerOn Aug 31, 2011, at 4:39 PM, Jason Gunthorpe wrote:
On Wed, Aug 31, 2011 at 09:28:50AM -0600, Trever L. Adams wrote:
I have only followed part of this. It the original poster's problem is that the LDAP database is not being able to be accessed with an SPN ticket, this is because SPNs are not allowed to log in in AD. You need to use a user account (including MACHINE$ accounts). It took me forever to figure this out. To use this, you need a cron job that creates/renews tickets from time to time for the user/machine account. Then you use Dovecot's environment setup configuration to set the KRB5_CC (or whatever it is called, my head is elsewhere) env variable to that Kerberos ticket cache that was created in the cronjob. This cache needs to be readable by dovecot and should be owned by its user.
This all works a 1000% better if you use Samba to join the domain and create your keytab with the right SPNs. See my prior posts to this list for a formula. Using the MS kerberos compatability tools is painful, complicated and tends to make a mess.
Samba will create a machine UPN and populate the system keytab appropriately. From a cron job you can use 'kinit -k' to maintain an active ticket for the machine UPN which dovecot can use for LDAP operations.
I would agree with that is easier unless/until you are load balancing connections on a single hostname to multiple physical machines. In that scenario you can't add SPNs for the shared hostname to the machine accounts (since SPNs must be unique) and you're still looking at futzing with ktpass.
Jason
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.
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 :)
Thanks for sharing solved problem.
Thanks for participation too.
But I think this question better to forward to Kerberos mailing list.
Unfortunately, I have difficulties with making a competent wording of my question. Source codes of KRB5 libs explode my brain. I cant understand them deeply and find the exact function that is directly dependent on network configuration. So, if someone would give me a hint, I'll try to continue my "investigation" to get to the truth. :)
participants (7)
-
David Warden
-
Jason Gunthorpe
-
Jerry
-
Nikolay Shopik
-
Stanislav Klinkov
-
Trever L. Adams
-
Willie Gillespie