"Livio B" <lbs...@gmail.com> wrote in message
news:31f0d2c51003050619o6d3a78b9uaf319d8e63aa7...@mail.gmail.com...
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
