kerberos authentication for apache on windows

[jas@aql.fr]

Selon Frank Balluffi <frank.balluffi at db.com>:

> Julien ALLANOS said:
>
>> I am now facing to the following problem: browsers don't send NTLM
> tokens
>> anymore but SPNEGO tokens (I believe). I don't really know what I did to
> make
>> it work, but heh, it works. That's good.
>
> For both NTLM and SPNEGO tokens, IE should send:
>
> Authorization: Negotiate
>
> followed by a base64-encoded token. To determine the type of token,
> capture and base64-decode the token. NTLM tokens begin with hex 4E 54 4C
> 4D 53 53 50 which corresponds to "NTLMSSP" and SPNEGO tokens begin with
> hex 60 ... 06 06 2B 06 01 05 05 02 where ... is between 1 and 3 bytes long
> (most commonly 3 bytes). 06 06 2B 06 01 05 05 02 means 1.3.6.1.5.5.2,
> which identifies the SPNEGO GSSAPI mechanism.
>
> Frank
>

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).

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.
-- 
Julien ALLANOS