MIT Kerberos problem with Windows clients

Fri Jan 17 09:33:02 EST 2014

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 at 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}, test1 at REALM.COM for krbtgt/REALM.COM at 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}, test1 at REALM.COM for host/test1.realm.com at 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.realm.com at 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.realm.com at 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
86135 Augsburg .................................. Fax. (0821) 598-2028