David,
In case you're still hitting up against this problem, it's actually rather simple to fix. But it's not documented ANYWHERE, and it took me ages to sort it out in my environment. Everything you've done is good, and it's what I'd call a bug in how IE gets it's WPAD info and connects to the web server.
First of all, you can't use a CNAME record for WPAD. Use an A record. Silly, I know, and it shouldn't make any difference, but it's definitely the case. So remove your CNAME in your DNS, and make an A record for the IP Address of the web server.
Secondly (and this may be more tricky for you), you need to have the WPAD.DAT file located on the root of the default website that's listening on the IP Address that you've assigned above. This is the key. It WILL NOT work with a host-header field or anything like that.
Explanation: What IE does is resolve the name WPAD to an IP Address. It's got to be able to resolve it directly to an IP Address. If it resolves as a CNAME query does to a different name, it won't work. So once IE's got the IP address that WPAD resolves to, what it actually does is connect to http://<>/WPAD.dat. If you've got a different website set up on the same webserver, listening on port 80 but using a host header field like I had (IE, "default web site", as well as "WPAD Website"), then you'll have everything set up correctly, but it won't work for that very reason. Put a copy of your WPAD.DAT file on the root of your default website, and things should start working.
Of course, if you can't get access to the root of that website (or you can't secure the root of that website), then you may need to look at moving your WPAD site to a different server where it can be at the root of the IP Address assigned to that server.
Give that a shot anyway. That's the process that worked for me. It took me ages to get it working, but it's been reliably working now for a long time. All the above though is simply my understanding of how IE works in relation to WPAD.DAT files, and might not be correct - it's simply based on the observation of what it does in my own environment. Yours may be different, but I'd put some money at least on that fixing your issue.
Let me know how you get on!
Matto :)
I assume you are using an Active Directory server. We have done something similar and the easiest way was to use the ntlm_auth helper like this (part of my squid.conf):
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 10
auth_param ntlm keep_alive on
You will have to install Samba and join your Windows domain. Your smb.conf will have to use these settings:
security = ADS
realm = your-dns-domain
password server = your-active-directory-server
winbind enum groups = yes
winbind enum users = yes
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind use default domain = yes
I believe it was also necessary to alter the /etc/krb5.conf:
[libdefaults]
default_realm = your-dns-domain
[realms]
your-dns-domain = {
kdc = your-ad-server
}
Then you should be able to join your Windows domain:
net rpc join -S PDC -U Administrator
In the end you should have a setup that uses single-sign login from Windows. Both the Internet Explorer (in case you should seriously use it) as well as Firefox know how to send the authentication credentials.
For applications that don't know NTLM you may need to add a fallback to basic authentication, too. I haven't tested that, yet.
Links:
Best Answer
Internet Explorer does not support any kind of Authentication with HTTPS proxies. (Tested IE 6 through 10)