Squid Auth question for machines not belonging to a AD domain

[Markus Moeller]

Does anybody know how a Windows client determines the right authentication
mechanism ?  I have a case where most clients are on a Windows domain and
squid_kerb_auth works fine. Now I have clients from visitors which have
never been on the domain. Can I send to these clients a list of
authentication mechanisms (e.g. Negotiate Digest Basic) ?  If so would the
client choose always Negotiate with NTLM ?

Thank you
Markus

[Amos Jeffries-2]

Markus Moeller wrote:

> Does anybody know how a Windows client determines the right
> authentication mechanism ?  I have a case where most clients are on a
> Windows domain and squid_kerb_auth works fine. Now I have clients from
> visitors which have never been on the domain. Can I send to these
> clients a list of authentication mechanisms (e.g. Negotiate Digest
> Basic) ?  If so would the client choose always Negotiate with NTLM ?
>
> Thank you
> Markus
>

IIRC it's first-known mechanism from the list of headers received in
line-order.

Depends on the windows API or library the app is built against as to
what is supported. The old API only does Basic or NTLM, the newer IE or
.NET based libraries (I'm ot sure which) seem to do Negotiate as well. I
suspect from the talk of deprecating NTLM that there is probably a new
API in Vista++ which does or will do only Basic + Negotiate.

Digest may fit in there too somehow.


IME, I think sending the correct realm or domain in the NTLM or
Negotiate auth headers may prevent clients attempting auth with a known
mechanism if they are not part of the domain.

Amos
--
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.14

[Henrik Nordstrom-5]

mån 2009-11-02 klockan 23:42 +1300 skrev Amos Jeffries:

> IME, I think sending the correct realm or domain in the NTLM or
> Negotiate auth headers may prevent clients attempting auth with a known
> mechanism if they are not part of the domain.

If Microsoft had thought about using the required realm parameter in
their NTLM and Negotiate over HTTP schemes maybe, but as it is now those
two "smells like HTTP auth but is not" authentication schemes do not
support realms and will probably never do.

Regards
Henrik

[Markus Moeller]

"Henrik Nordstrom" <henrik@...> wrote in message
news:1257212761.2980.2.camel@......

> mån 2009-11-02 klockan 23:42 +1300 skrev Amos Jeffries:
>
>> IME, I think sending the correct realm or domain in the NTLM or
>> Negotiate auth headers may prevent clients attempting auth with a known
>> mechanism if they are not part of the domain.
>
> If Microsoft had thought about using the required realm parameter in
> their NTLM and Negotiate over HTTP schemes maybe, but as it is now those
> two "smells like HTTP auth but is not" authentication schemes do not
> support realms and will probably never do.
>

I tested with Firefox and IE 8 and it looks like that when squid returns a
list like Negotiate Digest Firefox will try Negotiate with NTLM and when
this fails tries Digest and stays with Digest when successful.  IE 8 just
tries Negotiate with NTLM.  So IE 8 will never be able to authenticate non
domain machines or is there a way to verify a NTLM password from a
standalone machine ?

Does anybody know how MS intends to deal with this (e.g. guests in a company
network) in a MS only environment with ISA proxy ?

Thank you
Markus

> Regards
> Henrik
>
>
>
>

[Henrik Nordstrom-5]

tis 2009-11-03 klockan 13:21 +0000 skrev Markus Moeller:

> Does anybody know how MS intends to deal with this (e.g. guests in a company
> network) in a MS only environment with ISA proxy ?

Supposedly by having guest accounts in the Windows domain.

Regards
Henrik

[Henrik Nordstrom-5]

tis 2009-11-03 klockan 19:44 +0000 skrev Markus Moeller:

> But how would that work if the guest uses his own machine e.g. Kerberos (no
> ticket available) nor NTLM (no shared machine key available) can be used or
> ?  and ISA (or squid) sends Negotiate as the first auth option ?

NTLM works without shared machine key by manual entry of login+password
+domain when needed in the browser settion. Only the proxy needs a
machine key to verify the login (not verified by browser).

Negotiate also works as long as the client station can talk to the KDC
and request a ticket, on the same premises. Maybe the ticket is even
issued via the proxy in such case (not entirely sure).

Neither NTLM or Negotiate strictly requires the user to be logged on to
the domain, it just won't be automatic if he is not.

Regards
Henrik

[Markus Moeller]

"Henrik Nordstrom" <henrik@...> wrote in message
news:1257278257.20561.5.camel@......

> tis 2009-11-03 klockan 19:44 +0000 skrev Markus Moeller:
>
>> But how would that work if the guest uses his own machine e.g. Kerberos
>> (no
>> ticket available) nor NTLM (no shared machine key available) can be used
>> or
>> ?  and ISA (or squid) sends Negotiate as the first auth option ?
>
> NTLM works without shared machine key by manual entry of login+password
> +domain when needed in the browser settion. Only the proxy needs a
> machine key to verify the login (not verified by browser).
>

Sorry, but it isn't clear to me.  So basically the proxy can not verify the
password as the proxy will never have the machine key to verify the login ?

> Negotiate also works as long as the client station can talk to the KDC
> and request a ticket, on the same premises. Maybe the ticket is even
> issued via the proxy in such case (not entirely sure).
>

Ok this might work. The client should in theory be able to ask for a kdc
through SRV records and authenticate the user and get a TGS.

> Neither NTLM or Negotiate strictly requires the user to be logged on to
> the domain, it just won't be automatic if he is not.
>
> Regards
> Henrik
>
>
>