MIT Kerberos problem with Windows clients

[Morgan Patou]

Hi all,

I'm currently trying to setup SSO in our company using MIT Kerberos. We have a KDC (on xyz.realm.com), some kerberized applications (uvw.realm.com ; rst.realm.com ; ...) and all theses Virtual Machines are on a VPN (checkpoint SNX). Some users (principal: te...@REALM.COM ; te...@REALM.COM ; root/ad...@REALM.COM ; ...) and kerberized applications (principal: HTTP/uvw.re...@REALM.COM ; HTTP/rst.re...@REALM.COM ; ...) are registered in the KDC.

All kerberized applications and the KDC are in Linux VM on the VPN. All /etc/krb5.conf and C:/ProgramData/MIT/Kerberos5/krb5.ini files have the following content:

[libdefaults]
default_realm = REALM.COM

[realms]
REALM.COM = {
kdc = xyz.realm.com:88
admin_server = xyz.realm.com:749
default_domain = realm.com
}

[domain_realm]
.realm.com = REALM.COM
realm.com = REALM.COM

>From a Windows client (with MIT Kerberos) or a Unix client (in fact it's a VM on the VPN because I don't have a Linux physical machine), I can get an initial ticket with Kinit. The log file of the KDC show the following line:
Jan 16 15:53:44 xyz.realm.com krb5kdc[1767](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) <VPN Internal IP>: ISSUE: authtime 1389884024, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for krbtgt/REAL...@REALM.COM

* Unix client:

F rom a Unix client, I can execute a Klist command to see that I have a valid ticket (expires in 10h). So the next step is to access to the kerberized application with a web browser. In Mozilla Firefox, I've set the following configuration:

* network.negotiate-auth.delegation-uris user set string .REALM.COM
* network.negotiate-auth.trusted-uris user set string .REALM.COM
* network.negotiate-auth.using-native-gsslib user set boolean false


Then I access to http://uvw.realm.com and miracle, I'm connected. The KDC log file show the following lines:
Jan 16 16:10:51 xyz.realm.com krb5kdc[1767](info): TGS_REQ (4 etypes {18 17 16 23}) <Client IP>: ISSUE: authtime 1389885003, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for HTTP/uvw.re...@REALM.COM
Jan 16 16:10:51 xyz.realm.com krb5kdc[1767](info): TGS_REQ (1 etypes {18}) <Client IP>: ISSUE: authtime 1389885003, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for krbtgt/REAL...@REALM.COM



The kerberized application log file (apache error.log) show the following:

[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1628): [client <Client IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1628): [client <Client IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1240): [client <Client IP>] Acquiring creds for HTTP/uvw.re...@REALM.COM
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1385): [client <Client IP>] Verifying client data using KRB5 GSS-API
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1401): [client <Client IP>] Client delegated us their credential
[Thu Jan 16 16:28:41 2014] [debug] src/mod_auth_kerb.c(1420): [client <Client IP>] GSS-API token of length 22 bytes will be sent back
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1628): [client <Client IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: http://uvw.realm.com/
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1240): [client <Client IP>] Acquiring creds for HTTP/uvw.re...@REALM.COM, referer: http://uvw.realm.com/
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1385): [client <Client IP>] Verifying client data using KRB5 GSS-API , referer: http://uvw.realm.com/
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1401): [client <Client IP>] Client delegated us their credential, referer: http://uvw.realm.com/
[Thu Jan 16 16:28:43 2014] [debug] src/mod_auth_kerb.c(1420): [client <Client IP>] GSS-API token of length 22 bytes will be sent back, referer: http://uvw.realm.com/






* Windows client:

>From a Windows client, I can use MIT Kerberos to get the initial ticket for te...@REALM.COM (expires in 10h too). The KDC log file show the same line than from a Unix client. I've set the same configuration in the about:config of Firefox but when I tried to access to http://uvw.realm.com, I'm not connected. The log file of the KDC doesn't say anything, there is no TGS_REQ.

So I checked the kerberized application log file (apache error.log):

[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1240): [client <VPN Internal IP>] Acquiring creds for HTTP/uvw.re...@REALM.COM
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1385): [client <VPN Internal IP>] Verifying client data using KRB5 GSS-API
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1401): [client <VPN Internal IP>] Client didn't delegate us their credential
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1429): [client <VPN Internal IP>] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1101): [client <VPN Internal IP>] GSS-API major_status:00010000, minor_status:00000000
[Thu Jan 16 16:19:12 2014] [error] [client <VPN Internal IP>] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)


I don't understand what I'm doing wrong... It would be wonderful if someone could help me to resolve this issue! We don't have Active Directory (Windows client belongs to Workgroup:WORKGROUP) and no entries have been set to the DNS as we use krb5.conf/krb5.ini for this test infrastructure.



Regards,
Morgan

[Robert Wehn]

Hello Morgan,

the Windows MIT client isn't integrated in the Windows system, so no
application you install on a Windows machine knows anything about the
MIT Kerberos installed on the system.

The reason for that is:
There ist a system integrated KRB5 client in Windows (at least the Pro
Versions), Namely the "Microsoft Active Directory" client components. AD
uses Kerberos for Authenticating the users.

Maybe there's a trick to tell the system or applications to use MIT
Kerberos instead of the integrated funktion, but I don't know about that.

If you want to Use Single-Sign-On with Kerberos on a Windows machine you
have usually two options:
A) Have an AD (which can be provided ba a Windows Server or a SAMBA 4 AD
Server)
B) Make local Users on the Computers and map the local users to an
kerberos identity (ksetup /mapuser)

For B) start reading this
http://social.technet.microsoft.com/wiki/contents/articles/2751.kerberos-interoperability-step-by-step-guide-for-windows-server-2003.aspx
specially
http://social.technet.microsoft.com/wiki/contents/articles/2751.kerberos-interoperability-step-by-step-guide-for-windows-server-2003.aspx#Using_an_MIT_KDC_with_a_Stand-alone_Windows_Server_TwentyOhThree_Client
Though the documentation is for Server 2003/XP, the options you need are
still there in modern Windows versions like Windows 7/8 and Server
2008/2012 (also the R2 Versions)
http://technet.microsoft.com/en-US/library/hh240190.aspx

If you have done A) or B) the user gets an initial KRB5 Ticket when he
locks in, and the applications (like Firefox, if you set the corret
options) aware of Kerberos can use it for Single-Sign-On.

regards,
Robert.

> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

--

Dr. Robert Wehn ........................ http://www.rz.uni-augsburg.de
Universit�t Augsburg, Rechenzentrum ............. Tel. (0821) 598-2047
86135 Augsburg .................................. Fax. (0821) 598-2028

[hu...@fanduel.com]

On Thursday, 16 January 2014 15:54:45 UTC, Morgan Patou wrote:
> Hi all,
>
> ...

>
> [Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
>
> [Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
>
> [Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1240): [client <VPN Internal IP>] Acquiring creds for HTTP/uvw.re...@REALM.COM
>
> [Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1385): [client <VPN Internal IP>] Verifying client data using KRB5 GSS-API
>
> [Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1401): [client <VPN Internal IP>] Client didn't delegate us their credential
>
> [Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1429): [client <VPN Internal IP>] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
>
> [Thu Jan 16 16:19:12 2014] [debug] src/mod_auth_kerb.c(1101): [client <VPN Internal IP>] GSS-API major_status:00010000, minor_status:00000000
>
> [Thu Jan 16 16:19:12 2014] [error] [client <VPN Internal IP>] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)
>
>

> ...

This might be caused by Firefox on Windows using the native Windows SSPI instead of the the MIT Kerberos GSS-API library.
You can tell Firefox to use GSS-API instead of SSPI by setting the about:config key "network.auth-use-sspi" to false.
You can also get the Kerberos code in SSPI to work as a client with a MIT KDC, using "ksetup", but it's more complicated (refer to Robert Wehn's post)

[Benjamin Kaduk]

On Thu, 16 Jan 2014, Morgan Patou wrote:

> From a Unix client, I can execute a Klist command to see that I have a

> valid ticket (expires in 10h). So the next step is to access to the
> kerberized application with a web browser. In Mozilla Firefox, I've set
> the following configuration:
>
> * network.negotiate-auth.delegation-uris user set string .REALM.COM
> * network.negotiate-auth.trusted-uris user set string .REALM.COM
> * network.negotiate-auth.using-native-gsslib user set boolean false

When doing negotiate auth in firefox on windows using MIT kerberos, I've
always had to set network.auth.use-sspi=false to get firefox to use the
gssapi library from MIT kerberos.

Other things to pay attention to are whether firefox is 32- or 64-bit (I
expect it's 32-bit) and that the version of MIT Kerberos installed
provides the appropriate bittedness gssapi library. (This is only an
issue with KfW 3.x and older; KfW 4.x installs both libraries on 64-bit
machines.)

-Ben Kaduk

[Morgan Patou]

Hi Robert & Benjamin

First of all, thank you for your answers!

@Benjamin: I set 'network.auth.use-sspi=false' in the about:config, restart firefox and indeed it worked!

But now I have another issue which is certainly caused by the use of the Checkpoint VPN. When accessing to a kerberized application, in the Apache logs, the same sequence is repeated so many times and the only thing that changes is the 'referer':

[Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1628): [client < VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1240): [client < VPN Internal IP>] Acquiring creds for HTTP/ uvw.realm.com at REALM.COM
[Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1385): [client < VPN Internal IP>] Verifying client data using KRB5 GSS-API
[Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1401): [client < VPN Internal IP>] Client delegated us their credential
[Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1420): [client < VPN Internal IP>] GSS-API token of length 22 bytes will be sent back

[Thu Jan 17 09:28:45 2014] [debug] src/mod_auth_kerb.c(1628): [client < VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: http://uvw.realm.com/
[Thu Jan 17 09:28:45 2014] [debug] src/mod_auth_kerb.c(1240): [client < VPN Internal IP>] Acquiring creds for HTTP/ uvw.realm.com at REALM.COM , referer: http://uvw.realm.com/
[Thu Jan 17 09:28:45 2014] [debug] src/mod_auth_kerb.c(1385): [client < VPN Internal IP>] Verifying client data using KRB5 GSS-API , referer: http://uvw.realm.com/
[Thu Jan 17 09:28:45 2014] [debug] src/mod_auth_kerb.c(1401): [client < VPN Internal IP>] Client delegated us their credential , referer: http://uvw.realm.com/
[Thu Jan 17 09:28:45 2014] [debug] src/mod_auth_kerb.c(1420): [client < VPN Internal IP>] GSS-API token of length 22 bytes will be sent back , referer: http://uvw.realm.com/

[Thu Jan 17 09:29:01 2014] [debug] src/mod_auth_kerb.c(1628): [client < VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: http://uvw.realm.com/ theme/css/main.css?...
[Thu Jan 17 09:29:01 2014] [debug] src/mod_auth_kerb.c(1240): [client < VPN Internal IP>] Acquiring creds for HTTP/ uvw.realm.com at REALM.COM , referer: http://uvw.realm.com/ theme/css/main.css?...
[Thu Jan 17 09:29:01 2014] [debug] src/mod_auth_kerb.c(1385): [client < VPN Internal IP>] Verifying client data using KRB5 GSS-API , referer: http://uvw.realm.com/ theme/css/main.css?...
[Thu Jan 17 09:29:01 2014] [debug] src/mod_auth_kerb.c(1401): [client < VPN Internal IP>] Client delegated us their credential, referer: http://uvw.realm.com/ theme/css/main.css?...
[Thu Jan 17 09:29:01 2014] [debug] src/mod_auth_kerb.c(1420): [client < VPN Internal IP>] GSS-API token of length 22 bytes will be sent back, referer: http://uvw.realm.com/ theme/css/main.css?...

.....aso.....

It's just like if firefox have to give the ticket to the Apache for each element that have to be loaded in the browser (css, images, js, ...). So the page take at least 5 minutes to be completely loaded.


@Robert: I already tried your solution B) but I think that doesn't work for me. To access to the KDC, I have to open a SSL Network Extender (Checkpoint SNX) in my browser. So I need to be logged on my computer as a local user and not as a member of a domain or realm or whatever. Then I open the SNX applet (from the browser) and the next step is to get the initial ticket. So I used the ksetup to get the same configuration as a krb5.conf in Linux.

Then I tried to switch the current user (test1\test1) to REALM.COM\test1 (where test1 is my local user name). On the KDC log file, I see:

Jan 17 11:31:09 xyz.realm.com krb5kdc[1767](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) <VPN Internal IP>: ISSUE: authtime 1389954669, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for krbtgt/REAL...@REALM.COM
Jan 17 11:31:10 xyz.realm .com krb5kdc[1767](info): TGS_REQ (5 etypes {18 17 23 24 -135}) <VPN Internal IP> : ISSUE: authtime 1389954669, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for host/test1.r...@REALM.COM

So it seems I have a ticket, right? How could I see this ticket? Then if I try to access to uvw.realm.com, nothing append. The only line that appears on the Apache log if 'network.auth.use-sspi=false' is the first one:

[Thu Jan 17 11:40:43 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos

Apparently, the kerberized application doesn't try to get credentials in this case. If 'network.auth.use-sspi=true' (default value), then I get the same issue than before:

[Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN Internal IP> ] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1240): [client <VPN Internal IP> ] Acquiring creds for HTTP/uvw.re...@REALM.COM
[Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1385): [client <VPN Internal IP> ] Verifying client data using KRB5 GSS-API
[Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1401): [client <VPN Internal IP> ] Client didn't delegate us their credential
[Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1429): [client <VPN Internal IP> ] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1101): [client <VPN Internal IP> ] GSS-API major_status:00010000, minor_status:00000000
[Fri Jan 17 11:54:24 2014] [error] [client <VPN Internal IP> ] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)

Do you think that putting the KDC outside of the VPN will improve the performance? It seems that it's the communication between the client and the kerberized application (with Apache) that take so much time. Or is there an option for the KDC? Forwardable? I don't know...


Regards,
Morgan

[Robert Wehn]

Hi Morgan,

Am 17.01.2014 14:02, schrieb Morgan Patou:
> But now I have another issue which is certainly caused by the use of the Checkpoint VPN. When accessing to a kerberized application, in the Apache logs, the same sequence is repeated so many times and the only thing that changes is the 'referer':
>
> [Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1628): [client < VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
> [Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1240): [client < VPN Internal IP>] Acquiring creds for HTTP/ uvw.realm.com at REALM.COM
> [Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1385): [client < VPN Internal IP>] Verifying client data using KRB5 GSS-API
> [Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1401): [client < VPN Internal IP>] Client delegated us their credential
> [Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1420): [client < VPN Internal IP>] GSS-API token of length 22 bytes will be sent back
>
> [Thu Jan 17 09:28:45 2014] [debug] src/mod_auth_kerb.c(1628): [client < VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: http://uvw.realm.com/
> [Thu Jan 17 09:28:45 2014] [debug] src/mod_auth_kerb.c(1240): [client < VPN Internal IP>] Acquiring creds for HTTP/ uvw.realm.com at REALM.COM , referer: http://uvw.realm.com/

> ...

> [Thu Jan 17 09:29:01 2014] [debug] src/mod_auth_kerb.c(1628): [client < VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: http://uvw.realm.com/ theme/css/main.css?...
> [Thu Jan 17 09:29:01 2014] [debug] src/mod_auth_kerb.c(1240): [client < VPN Internal IP>] Acquiring creds for HTTP/ uvw.realm.com at REALM.COM , referer: http://uvw.realm.com/ theme/css/main.css?...

> ...
>
> It's just like if firefox have to give the ticket to the Apache for each element that have to be loaded in the browser (css, images, js, ...). So the page take at least 5 minutes to be completely loaded.

Is this a windows specific issue or do you see this also on the linux
clients?

I would expect this to be a normal behavior.
As far as i understood http connections aren't established permanently
so the authentication (in this case using kerberos) has to be started
every time, as you don't use a session cookie which can be sent with
every request for every element of the webpage.
The only thing which should not happen every time is getting the service
ticket for http/server@REALM from the kdc, but this process can only be
seen in the communication/logs of client and kdc. There is no permanent
"session" for which a krb5 session ticket is valid all the time.

If you uns kerberos only for web-sso anyway, maybe a system like webauth
(http://webauth.stanford.edu/) or cosign (see a comparison on
http://webauth.stanford.edu/features.html) might be the thing you're
really looking for.
We use webauth in our university for many web applications: It's using
the principles of kerberos but stores the "TGT" and the "Service
Tickets" as browser cookies. So it's maybe faster...

> @Robert: I already tried your solution B) but I think that doesn't work for me. To access to the KDC, I have to open a SSL Network Extender (Checkpoint SNX) in my browser. So I need to be logged on my computer as a local user and not as a member of a domain or realm or whatever. Then I open the SNX applet (from the browser) and the next step is to get the initial ticket. So I used the ksetup to get the same configuration as a krb5.conf in Linux.

... didn't know that, we us active directory for the windows clients,
and tested around with cross-realm-trust to our MIT Kerberos
infrastructure. In this configuration the client caches the logon
password of the users for sth like 90 days, so a user can log on to a
laptop offline, too. Have no idea if this works when using the ksetup
method ...

> Then I tried to switch the current user (test1\test1) to REALM.COM\test1 (where test1 is my local user name). On the KDC log file, I see:
>
> Jan 17 11:31:09 xyz.realm.com krb5kdc[1767](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) <VPN Internal IP>: ISSUE: authtime 1389954669, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for krbtgt/REAL...@REALM.COM
> Jan 17 11:31:10 xyz.realm .com krb5kdc[1767](info): TGS_REQ (5 etypes {18 17 23 24 -135}) <VPN Internal IP> : ISSUE: authtime 1389954669, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for host/test1.r...@REALM.COM
>
> So it seems I have a ticket, right? How could I see this ticket? Then if I try to access to uvw.realm.com, nothing append. The only line that appears on the Apache log if 'network.auth.use-sspi=false' is the first one:

at lest you send a request for a session ticket to log on to the
computer (host/test1.r...@REALM.COM) so there should already be a
tgt from the first step.

> [Thu Jan 17 11:40:43 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN Internal IP>] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
>
> Apparently, the kerberized application doesn't try to get credentials in this case. If 'network.auth.use-sspi=true' (default value), then I get the same issue than before:
>
> [Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1628): [client <VPN Internal IP> ] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
> [Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1240): [client <VPN Internal IP> ] Acquiring creds for HTTP/uvw.re...@REALM.COM
> [Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1385): [client <VPN Internal IP> ] Verifying client data using KRB5 GSS-API
> [Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1401): [client <VPN Internal IP> ] Client didn't delegate us their credential
> [Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1429): [client <VPN Internal IP> ] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
> [Fri Jan 17 11:54:24 2014] [debug] src/mod_auth_kerb.c(1101): [client <VPN Internal IP> ] GSS-API major_status:00010000, minor_status:00000000
> [Fri Jan 17 11:54:24 2014] [error] [client <VPN Internal IP> ] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)

it looks like the client doesn't find out which ticket to fetch from kdc.
Can you see any attempt from the client to get a ticket (maybe for the
wrong service) form the kdc?
Can you check if the client tries to ask funny question (TXT records) to
its DNS server, maybe with wireshark/winpcap for Windows (which is a
good idea to debug kerberos problems anyway).

> Do you think that putting the KDC outside of the VPN will improve the performance? It seems that it's the communication between the client and the kerberized application (with Apache) that take so much time.

see above. I really wonder about the lack of speed.
We use Kerberized apache with our Sogo Groupware Test-Server for our
kerberized linux clients and don't see special speed problems regarding
kerberos. The Windows Clients use Basic https auth for the same Server
(Kerberos doing the auth im Backgroud, but not transparent for the
client) an i don't see an difference in speed.
So maybe the vpn is the problem.

Regards,
Robert.

--

Dr. Robert Wehn ........................ http://www.rz.uni-augsburg.de

Universität Augsburg, Rechenzentrum ............. Tel. (0821) 598-2047

[Morgan Patou]

Hi Robert,

> Is this a windows specific issue or do you see this also on the linux clients?

I've just created a Linux VM on my computer to test this from a Linux outside of the VPN. Indeed, the same thing append but it take between 5 and 10 seconds.


> If you uns kerberos only for web-sso anyway, maybe a system like webauth (http://webauth.stanford.edu/) or cosign (see a comparison on http://webauth.stanford.ed/features.html) might be the thing you're really looking for.

Thank you, I will check it out.

> it looks like the client doesn't find out which ticket to fetch from kdc. Can you see any attempt from the client to get a ticket (maybe for the wrong service) form the kdc? Can you check if the client tries to ask funny question (TXT records) to its DNS server, maybe with wireshark/winpcap for Windows (which is a good idea to debug kerberos problems anyway).

There is absolutely nothing in the KDC log file. I will try to see analyze the network traffic with wireshark.

Regards,
Morgan

[Greg Hudson]

On 01/17/2014 08:02 AM, Morgan Patou wrote:
> [Thu Jan 17 09:28:41 2014] [debug] src/mod_auth_kerb.c(1401): [client < VPN Internal IP>] Client delegated us their credential

[...]

> It's just like if firefox have to give the ticket to the Apache for each element that have to be loaded in the browser (css, images, js, ...). So the page take at least 5 minutes to be completely loaded.

Yeah, traditional Kerberos ticket delegation and HTTP negotiate auth do
not mix well. The client fetches a fresh TGT from the KDC for each
delegation, adding a bunch of round trips to each HTTP request.

If the server does not need a delegated TGT, then just remove the
network.negotiate-auth.delegation-uris setting in Firefox and you should
get dramatically better performance. If the server does need a
delegated TGT in order to act on the client's behalf for some other
service, then perhaps you can restrict the delegation-uris setting to
just the URLs where a TGT is needed.

[Morgan Patou]

Hi all,

> as Russ Allbery, one of the (main?) authors of webauth, is very active on this list, maybe you can ask a question like "i'm trying to use kerberos for the following situation, would webauth or cosign do a better or easier job for that" here and hope for an answer or a hint to the appropriate mailing list by him ;-)
> According your tests with kerberos directly: As my knowledge about apache and sso ends here, kerberos specialist like Greg Hudson and Benjamin Kaduk might help more.

I don't really know what's happened since Friday but it seems that now the Windows Kerberos began to work! I restarted the computer several times between Thursday and Sunday but it was only this morning that it decided to work.

Since this morning, when I start my computer, I'm able to connect to the account 'REALM.COM\test1'. After that, I open firefox and launch the VPN. As soon as the VPN is running, I see in the KDC logs the following two lines:

Jan 20 15:07:11 xyz.realm.com krb5kdc[1767](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) <VPN Internal IP>: ISSUE: authtime 1390226831, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for krbtgt/REAL...@REALM.COM
Jan 20 15:07:11 xyz.realm.com krb5kdc[1767](info): TGS_REQ (5 etypes {18 17 23 24 -135}) <VPN Internal IP>: ISSUE: authtime 1390226831, etypes {rep=18 tkt=18 ses=18}, te...@REALM.COM for host/xyz.re...@REALM.COM

And I can access a kerberized application fairly quickly (the page takes between 0.5 and 3 seconds to be loaded). With MIT Kerberos the page still takes 10 minutes to be loaded... So strange!

Anyway, here are my settings for firefox:

* network.negotiate-auth.delegation-uris -- user set -- string -- .REALM.COM
* network.negotiate-auth.trusted-uris -- user set -- string -- .REALM.COM
* network.negotiate-auth.using-native-gsslib -- user set -- boolean -- false
* network.auth.use-sspi -- default -- boolean -- true


I have another question about Windows's tickets. Is it possible to make this ticket "forwardable = true" and "proxiable = true"? One of our kerberized applications is Alfresco. Alfresco Share uses a proxy that redirects everything to Alfresco Explorer. From a Unix client, I just have to put these two settings in the /etc/krb5.conf file but in Windows, I haven't found how to set it up with ksetup. These two lines are already in the configuration file of the KDC but it need to be on the client's configuration file too.


Thanks for your help,
Regards,
Morgan