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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
