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£‚F0‚B ¡
> 
> 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