kerberos authentication for apache on windows
Frank Balluffi
frank.balluffi at db.com
Mon Jun 6 11:05:29 EDT 2005
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£F0B ¡
>
> so I believe the requested principal is
> HTTP/adcassard.jas.aql.fr at ADCASSARD.JAS.AQL.FR, which doesn't match what
is
> inside the keytab
> (HTTP/adcassard.jas.aql.fr at SRV1.ADCASSARD.JAS.AQL.FR). 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/adcassard.jas.aql.fr at ADCASSARD.JAS.AQL.FR -- 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
More information about the Kerberos
mailing list