Re: "negotiate" auth with fallback to other schemes

From: Markus Moeller <>
Date: Fri, 5 Mar 2010 20:44:55 -0000

"Livio B" <> wrote in message
> Hi,
>>> In particular, if I want only transparent auth, it wouldn't make sense
>>> to retry the authentication because either the helper would get the
>>> same SSO (denied) credentials or the user would get prompted (which I
>>> don't want). On a different scenario, where it is ok to prompt the
>>> user for alternative credentials, it would make sense to retry the
>>> negotiate.
>> Yes, and how would the helper know when this is? That knowledge is
>> better in Squid..
> Well that would have to be a parameter to the helper command.
> So, to summarize, adding this fall-back option would either require 1)
> a backward compatible protocol update, or 2) a backward compatible
> auth_param syntax extension.
> Option 1) would have the advantage that the helper could behave
> differently basing on client responses;
> option 2) would have the advantage that it doesn't require changes to
> helpers.
> You are clearly advocating option 2.
>>> This seem a little unflexible. For example, currently there is no
>>> helper that can handle both negotiate/kerberos and negotiate/ntlm so
>>> if I need to support both I need a negotiate helper and a NTLM helper
>>> and might want to disable just one. And of course new protocols can
>>> eventually surface.
>> Is the flexibility really needed in this case?
>> Negotiate and NTLM is very closely related, and will always connect to
>> the same backend (windows ADS / domain controller) at least in sane
>> setups. If one fails then there is very limited use of trying the other.
> This is not completely fair. Kerberos may fail just because the client
> has no connectivity with the KDC, and in this case NTLM could be a
> useful second choice.

I don't understand this part. Usually the kdc is on AD so how can NTLM work
and Kerberos not ?

>> Additionally I as a user and network admin would not be comfortable
>> with digest auth automatically falling back on basic on authentication
>> failure, due to the non-existing security of basic auth. If the client
>> supports digest then it should stick to that until the user says
>> otherwise.
> Agree.
> So I'll work on a patch to support a new auth_param option (any
> suggested syntax?) and tracking the list of "disabled" protocols in
> the "request" or "connection" object, keeping the connection open even
> when authentication fails.
> Regards,
> Livio
Received on Fri Mar 05 2010 - 21:03:25 MST

This archive was generated by hypermail 2.2.0 : Sat Mar 06 2010 - 12:00:03 MST