After the recent migration I was experiencing a number of issues. In this case almost every user had their internet browsing slowed significantly (like 30 seconds between click and load). After running various monitoring and testing I found that the delay was in the original connection setup. Chrome would say “waiting for proxy tunnel” and the developer tools would show 30+ seconds under “stalled” for the page loading.
So after logging DNS I came across a number of queries that were not desired. These were from the “Customer Experience Improvement Program”. So we set about removing these “features” from every desktop. This had little improvement in the internet speed. See this article and this one.
The server being used as a proxy is from 2012 but I also had a second server that was from 2017. The slow down was on both servers but not for all users. It seems like every one using the original server was slowed. When I tested some users by switching to the second server, speed was back to normal. This change also had some side effects. Three users that were changed had their IE stop working: 2 just open & close right away, 1 just freezes.
So I installed a new server (bigger, better, faster) and struggled with the authentication settings. I followed the guide from here, here, and here. This got it mostly working but authentication still failed as all three of these guides are for older versions or do not have enough information for me to work with (as in the third guide where it was for a unique product). I eventually remembered that my second server already accounted for some of these differences. However, both server 1 and 2 used the old LDAP server from the old Samba PDC. After a day of frustration I ended up deploying the new server using authentication settings from server 2 just to get things working for the end users. This also gives me some time to experiment without being harassed constantly.
After changing some users proxy settings to use the new server their experience went way up. Two users had their Internet Explorer die where it just flashes and then immediately closes down. Another user had IE just freeze. For this user we put the proxy settings back to the original server and it worked again. It even went back to normal speed, WTF??
So far, at least 1 user has picked up the new proxy server automatically. I have not knowingly told the system about the server. I have no Group Policies yet, the WPAD I did set up years ago leads to a trap. So unless kerboros is doing something this is another WTF!
I did finally get the squid helper to validate a user to the AD-DC. I had to first get LDAP to communicate. I tried ldapsearch and failed continuously until I edited /etc/ldap/ldap.conf to include “TLS_REQCERT = allow”. The working command was:
ldapsearch -D "CN=squid-connect,CN=Users,DC=samdom,DC=example,dc=net" -w "password" -s sub -x -ZZ -LLL '(&(objectClass=user)(!(objectClass=computer))(!(userAccountControl:1.2.840.113518.104.22.1683:=2)))'
For the squid helper I changed “squid_ldap_auth” to “basic_ldap_auth”. The config ended up as:
basic_ldap_auth -h 192.168.0.24 -b "dc=samdom,dc=example,dc=net" -D "CN=squid-connect,CN=Users,DC=samdom,DC=example,dc=net" -w "plantino" -s sub -R -d -u sAMAccountName -f "sAMAccountName=%s" -Z
Manually keying in the user account and password generates the appropriate responses for good and bad entries. I’ll have to test this live after business hours.
I was able to get the helper ext_wbinfo_group_acl to run after setting up Samba’s winbindd. The settings require me to use the “DOMAIN\user” format for the account. I have yet to try this in production.
The group membership check is done using ext_ldap_group_acl not squid_ldap_group as in the guides. Manually testing the helper with the following command worked:
ext_ldap_group_acl -h 192.168.0.24 -b "dc=samdom,dc=example,dc=net" -D "CN=squid-connect,CN=Users,DC=samdom,DC=example,dc=net" -w "password" -s sub -R -d -f "(&(objectclass=person)(sAMAccountName=%v)(memberof=CN=Proxy,CN=Users,DC=samdom,DC=example,DC=net))" -Z
So now I need to get the negotiate method to work. This involves kerberos. But more on this later.
For all of this I have been using Debian 9.6, samba 4.9, and squid 4.4. Names have been changed to protect the guilty.
I am hoping that some of the things I’ve learned here will be useful when I get around to updating my email servers (postfix, cyrus, and axigen) as each of these uses LDAP for various lookups.