This article explains how to relay the user credentials to Symantec.cloud authenticating with the Active Directory controller, using the Kerberos authentication method instead of NTLM.
The first step is to give the Client Site Proxy server a Fully Qualified Domain Name (FQDN) so that in the Internet Explorer settings you point to the FQDN not the internal IP or host name. This will involve possibly rolling out this on the local zone file on every machine, or by adding an A record within your local DNS server for example csp.exampledomain.local to point to the IP address of the server where your Client Site Proxy is installed on (this is a far more manageable solution if you have an internal DNS server available). Please note: depending on your internal DNS server configuration it may take a little while for this change to take effect. To check when this change has taken effect the new FQDN can be tested at the command prompt by pinging the FQDN (for example csp.exampledomain.local).
If you do not point Internet Explorer to a FQDN then when the user credentials are passed through to us they appear with the string [null] in front which will mean the users will not match any groups (if being used) and rules will not work if they have them applied to users and groups.
Once you have completed this you then change the authentication line in the squid.conf from:
auth_param ntlm program c:/clientsiteproxy/libexec/mswin_ntlm_auth.exe
auth_param ntlm children 40
auth_param ntlm keep_alive on
auth_param negotiate program c:/clientsiteproxy/libexec/mswin_negotiate_auth.exe
auth_param negotiate children 40
auth_param negotiate keep_alive on
After the changes have been completed save the changes to the squid.conf file, and restart the Client Site Proxy service on the server where the Client Site Proxy is installed.
Please also check this page as there are some prerequisites on AD also if you're using Linux:
Please Note: Internet Explorer does not support Kerberos authentication with proxy servers using Internet Explorer 6. Please see http://support.microsoft.com/kb/321728 (information below is directly quoted from this article).
This behavior occurs because Internet Explorer does not support Kerberos authentication with a proxy, and does not respond to a negotiate challenge from a proxy server. If Integrated Windows Authentication is turned on in Internet Explorer for Windows 2000 and Windows XP, you can complete Kerberos authentication with Web servers either directly or through a proxy server. However, Internet Explorer cannot use Kerberos to authenticate with the proxy server itself.
This limitation was removed in Internet Explorer 7, so upgrading to Internet Explorer 7 will resolve this issue.
Imported Document ID: TECH225724
Subscribing will provide email updates when this Article is updated. Login is required.