NTLM proxy authentication: update

Hi folks. Sorry for the delay in getting back to everyone on this, but
it's taken low priority up until now. I have to roll out IE5 to 600 users
across 10 sites within 2 days. There are a few different user groups with
different access requirements, so it sorta had to get done...

Currently:

- It seems fairly stable.
- Works with both IE4/IE5 on 95 and NT. The only difference between NT
  and 95 is that 95 doesn't like Unicode. NT works fine with ASCII though,
  so this isn't a problem.
- Doesn't do any real authentication per se; I'm only using it to get the
  username. That said, it does output all the needed info to an
  authentication process. Somebody with more experience of SMB can write
  that. The Samba code would probably prove a valuble reference.
- The code is full of nasty hacks (and NTLM breaks the HTTP standard if
  what I know is right). Squid really needs a mechanism to handle multiple
  authentication types cleanly.
- For every connection that IE opens, we get two TCP_DENIED messages in
  access.log while it authenticates (negotiation + authentication). This
  is a bit irritating.

How NTLM proxy authentication works follows. NTLM WWW authentication works
the same way. Since most of the structures used are from NT RPC, a Samba
person would probably understand it comfortably. Please note that this is
from memory (and I've got a bad hangover):

- The client connects and issues a request.

- The server returns the following string along with a 407 status code:
        Proxy-Authenticate: NTLM
  Interesting that no realm is specified.

- For the authorization string, the client returns a base64 encoded,
  little endian 'struct ntlm_negotiate'. This structure includes the
  workstation name and domain that the user is logged onto, along with
  some flags (I'm not clear on what these do. One of them specifies that
  the strings are encoded as Unicode/ASCII).

- The server replies with a base64 encoded, little endian 'struct
  ntlm_challenge' in it's Proxy-Authenticate header field. This structure
  includes the domain that the server is part of, an 8 byte challenge
  string, and some flags.

- The client replies with a base64 encoded, little endian 'struct
  ntlm_authenticate' in it's Proxy-Authentication field. This structure
  includes the username, domain name, workstation name, NT password hash,
  LM password hash and some flags.

- The server then accepts/declines the request.

I'll try to post a diff within a week. Anyway, feel free to ask questions.

- ad
Received on Sun Dec 12 1999 - 03:16:31 MST