RE: NTLM authentication

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Wednesday, 2 August 2000 3:01 AM
> To: Chemolli Francesco (USI)
> Cc: Robert Collins; squid-dev@squid-cache.org
> Subject: Re: NTLM authentication
>
>
> Chemolli Francesco (USI) wrote:
>
> > Yes, you are.
> > It first presents its workstation name and domain, and even
> > that not always.
> > Before you ask: yes, I have network traces showing such a behaviour.
>
> Are you sure the user is logged in to the domain when this happens?

The ntlm_negotiate which is sent to start the authentication has no user
field. Also windows 95 and 98 machines can't be domain members but do
support ntlm authentication so I suspect the domain membership is a side
issue for us.

> > > which makes sense to me as I thought you need to know the
> > > user domain to
> > > be able to get the challenge from the correct domain controller...

The challenge is not user specific.
/* Negotiation request sent by client */
struct ntlm_negotiate {
        ntlmhdr hdr; /* NTLM header */
        int32_t flags; /* Request flags */
        strhdr domain; /* Domain we wish to authenticate in */
        strhdr workstation; /* Client workstation name */
        char pad[256]; /* String data */
};

I believe the DC uses the workstation and domain to decide if it is able
to produce a challenge, or if the request has to go to a trusted domain.
Also if the workstation is not in the domain that _may_ alter the DC's
behaviour. Not our problem however, as that is a NT/ms environment
issue.

> > Correct. I am puzzled as to what happens when the client offers no
> > such information, maybe the proxy is supposed to ask a
> challenge to his
> > own DC, or his local authentication service.

The client has to offer the flags so the DC knows whether to send
unicode/ascii for starters. I also don't know what is _meant_ to happen
if that isn't offered. I suspect that if the client just sends
proxy-auth: NTLM
we should deny that as a matter of course.
 
> But.. his own DC or authentication service won't know the
> password hash,
> so how is the password validated then?
>
> /Henrik

Much the same as unix with it's salt and crypt. Both the client and the
DC perform the same operation on a known value, using the hash of the
password to do it. The client sends it's result over the wire, and the
DC compares the results. If they match the user knew the password.

This is how it works:

P: proxy
C: client
DC: domain controller

c>p : get xyz
p>c : deny, offer ntlm and basic auth types
c>p : get xyz, send workstation, domain in ntlm_negotiate struct
p>dc: pass on the ntlm_negotiate and request a challenge. (Francesco can
tell you exactly what is getting passed over - he did that code). The
challenge is just a 4 byte number.
dc>p: sends a challenge
p>c : deny, proxy-auth NTLM challengedata (see include/ntlm.h from CVS)
c>p : get xyz NTLM ntlm_authenticate_struct (see below) which includes
the username.
p>dc: pass on the authenticate_struct
dc>p: user ok, user not ok
p>c : fulfil request, or deny and offer ntlm and basic auth types.

/* Authentication request sent by client in response to challenge */
struct ntlm_authenticate {
        ntlmhdr hdr; /* NTLM header */
        strhdr lmresponse; /* LANMAN challenge response */
        strhdr ntresponse; /* NT challenge response */
        strhdr domain; /* Domain to authenticate against */
        strhdr user; /* Username */
        strhdr workstation; /* Workstation name */
        strhdr sessionkey; /* Session key for server's use */
        int32_t flags; /* Request flags */
        char pad[256*6]; /* String data */
};

the ntresponse's and lmresponse's are used by different security
levels/backward compatability and the like.

Loosely speaking, the ntresponse is created by DES encrypting the
"challenge" with the ?MD5? (I can't remember just now) hash of the
password.

The DC validates the user by comparing the ntresponse with the result of
the same calculation performed at it's end. The DC has a copy of the
user's password's hash in it's SAM (Active directory for win 2k).

so in a nutshell - the dc needs the user name when it gets the result of
it's challenge, not before, and that is probably why it's not in the
initial packet.

Rob
Received on Tue Aug 01 2000 - 22:15:29 MDT