Windows Clients Won't Do Kerberos

[Michael B Allen]

On Thu, 29 Jun 2006 21:04:29 -0400
Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> On Thursday, June 29, 2006 07:12:53 PM -0400 Michael B Allen 
> <mba2000 at ioplex.com> wrote:
> 
> > I have confirmed with a packet capture that the client never tries
> > Kerberos. It just tries raw NTLMSSP. No SPNEGO.
> >
> > Finally, the installer on the Linux machine validates the keytab
> > credential with krb5_get_init_creds_keytab and then does a DCE/RPC group
> > lookup against the DC. It was successful. So the SPN and it's credential
> > is valid.
> 
> If it's never even trying negotiate, then one of these must be true:
> (1) It doesn't support it
> (2) It's configured not to use it
> (3) The server doesn't claim support it
> (4) It can't get a ticket
> 
> Since you have another client which also fails, (1) and (2) seem unlikely. 
> And, since you have other tickets, and you've demonstrated that the service 
> principal exists, (4) also seems unlikely.  So, I'm going to guess that 
> your server is broken, and doesn't claim to support that mechanism.

But the server isn't even given a chance to present the mechanisms it
supports. This form of HTTP authentication should look like the following
(assuming single step Kerberos for now):

  1 C -> S GET /whatever
  2 C <- S 401 Unauthorized
           WWW-Authenticate: Negotiate

  3 C -> S GET /whatever
           Authorization: Negotiate <base64token>
  4 C <- S 200 Success

The problem that I'm seeing is that at step 3 IE is submitting a raw
NTLMSSP token. It's not a SPNEGO token or a raw Kerberos token. So it's
not even giving the server an opportunity to do Kerberos. Therefore I
don't see how it could possibly be a problem with the server (3) since
all the server does up to that point is return
'WWW-Authenticate: Negotiate'.

I doubt it's (1). At least I've never heard of XP not supporting HTTP
authentication. XP Home edition perhaps but he's using XP Professional
and has tickets for all sorts of stuff.

It could be (2). But it's not specific to IE because the wsh script
generates the same error and it just uses the WinHttpRequest interface. So
it would have to be an machine level or "Global Policy" type of setting.

It could be (4) if there's something wrong with the account. As per my
instructions he created a Computer account and ran ktpass to generate
an "RC4-HMAC-NT" keytab. Maybe he should have used a User account and
DES? I've tested all of this with my very vanilla W2K3 KDC. Considering
the keytab credential was used successfully by the installer to query
an AD group I'm thinking this isn't the problem.

So if *I* had to guess I would say it's (2). There's some mysterious
security policy "GPO" or some odd MS thing I don't understand since I
spend 90% of my time in vi :-<

Mike

-- 
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/