Quoting Frank Balluffi <[EMAIL PROTECTED]>:
Julien ALLANOS said:
I've sniffed on port 88 but I didn't see any packet. Probably because
browser,
KDC and web server are on the same machine? (I have only 1 machine on
my domain
atm).
Yes, you will need to run a KDC on a separate machine to sniff the traffic
-- at least with Ethereal.
However, I can see the Authorization header (Negotiate + Base64 stuff)
in the
second GET request to the web server. The token begins with: 60 82 04 c7
06 06
2b 06 01 05 05 02, which seems to be a SPNEGO token.
Is the service name encoded somewhere in this token? If I look at it as
plain
text, I can see:
‚”0‚ ¡ADCASSARD.JAS..AQL.FR¢'0%
¡ 0 HTTPadcassard.jas.aql.fr£‚F0‚B ¡
so I believe the requested principal is
HTTP/[EMAIL PROTECTED], which doesn't match what
is
inside the keytab
(HTTP/[EMAIL PROTECTED]). Then I
created a new keytab with the new service name, but it didn't change
anything, I
still got the no match error.
Yes, the browser is sending a SPNEGO token containing a ticket to
HTTP/[EMAIL PROTECTED] -- you can figure this out
by looking at the ASN.1 in
draft-ietf-krb-wg-kerberos-clarifications-07.txt. Everything looks fine
except the Kerberos realm names do not match. You now need to figure out
why the ticket contains the realm ADCASSARD.JAS.AQL.FR and the keytab
contains the realm SRV1.ADCASSARD.JAS.AQL.FR.
Frank
As I said, I've created a new keytab with the
HTTP/[EMAIL PROTECTED] service name (using ktpass).
klist now shows the correct principal:
klist -k c:\WINDOWS\krb5kt
Keytab name: FILE:c:\WINDOWS\krb5kt
KVNO Principal
----
--------------------------------------------------------------------------
4 HTTP/[EMAIL PROTECTED]
I've restarted Apache, restarted Firefox on the client session and
requested the
URL again. I got the same error: no principal match.
--
Julien ALLANOS
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
