On 19/07/2013 11:24 p.m., Eugene M. Zheganin wrote:
Hi.
I'm moving some of my caches to 3.3.x (from 3.1.x and 3.2.x).
I'm using SPNEGO on some (along with kerberos_ldap_group helper).
I noticed an important behaviour change comparing to the 3.1.x and 3.2.x:
- squid 3.3.x requires the visible_hostname to be set to the kerberos
ticket principal he's using for SPNEGO
- squid 3.3.x requires the hostname of the proxy in the browser to be set
No, Squid cannot places any such restriction on the browser. This is
probably a side effect of how the Browser locates keytab.
- squid 3.3.x requires the hostname of the proxy in the browser to be
exactly the same as kerberos principal in the ticket
Same here.
If you have 3.1 on a machine and working, you should see *zero*
difference to whether the browser can still login by turning off that
3.1 and starting an identically configured 3.3 in its place. It is ony
if you change configurations or machine locations that you may expect
any problems.
If any of these conditions aren't met, the authentication fails. If
these conditions are met, the authentication functions as in the
previous versions (my caches are running same configs with minor
alterations). But I find those requirements a bit uncomfortable.
When SPNEGO isn't used, these requirements aren't needed.
Is this a feature or I'm hitting some bug ?
I'm not aware of anything specifically done to generate such a change in
behaviour.
The change appearing between 3.2 to 3.3 would seem to eliminate HTTP/1.1
behaviour (in both Squid and Browser) and Squid code behaviour as a
reason - there were no significant changes to Negotiate 3.2->3.3, just
between 3.1 and 3.2. Leaving changes to the helpers and their libraries
as possible causes. Or changes in your specific configurations.
Amos
