We help IT Professionals succeed at work.

Problem using squid_ldap_auth against AD domain

ilarge asked
Houston, we have a problem...

I'm not sure whether anybody has seen this before; hopefully someone will be able to go "this is your problem, you silly boy!" but authentication has suddenly failed on our setup. Nothing has changed anywhere - or at least nobody is admitting to changing anything - but now, my squid_ldap_auth returns:

      -b "dc=basedn,dc=domain,dc=com"
      -D "cn=Ldap User,ou=Users,ou=Site,ou=UK,dc=domain,dc=com"
      -w ********
      -f "(&(CN=%s)(memberOf=CN=InternetUsers,OU=Groups,OU=Site,DC=domain,DC=com))"
      -h 10.1.x.x

username password
squid_ldap_auth: WARNING, LDAP search error 'Operations error'
squid_ldap_auth: WARNING, LDAP search error 'Operations error'

The above command has been running faultlessly for quite some time, authenticating against Active Directory. I've confirmed that none of the objects have been moved to different OUs or renamed and that the bind username/password is correct. None of the accounts are locked out. We have two servers authenticating against two different servers on two different sites. Clearly, squid isn't the problem here as such since I *know* nothing has changed on them apart from the fact that I've commented out the authentication stuff from squid.conf...

I found a similar issue on the archives here that I don't know the end result of and it went to a bug report after trying adding the -O and -v 3 command line options. On the build here, -v doesn't seem to make any difference and -O gives an error; it needs STABLE7 iirc.

Both squid boxes are IBM Netfinity 5100s, 2 x 1GHz PIII, 2GB RAM and both AD servers are more or less identically configured W2003 servers.
Any ideas would be welcomed....


Ian Large


RHEL 3.0, kernel 2.4.21-32.ELsmp
squid-2.5.STABLE3-6.3E.9 (latest Red Hat build)

Output from squid -v if anyone is interested:

Squid Cache: Version 2.5.STABLE3
configure options:  --host=i386-redhat-linux --build=i386-redhat-linux --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --exec_prefix=/usr --bindir=/usr/sbin --libexecdir=/usr/lib/squid --localstatedir=/var --sysconfdir=/etc/squid --enable-poll --enable-snmp --enable-removal-policies=heap,lru --enable-storeio=aufs,coss,diskd,null,ufs --enable-ssl --with-openssl=/usr/kerberos --enable-delay-pools --enable-linux-netfilter --with-pthreads --enable-basic-auth-helpers=LDAP,NCSA,PAM,SMB,SASL,MSNT,winbind --enable-ntlm-auth-helpers=SMB,winbind,fakeauth --enable-external-acl-helpers=ip_user,ldap_group,unix_group,wbinfo_group,winbind_group --enable-auth=basic,ntlm --enable-useragent-log --enable-referer-log
Watch Question

idmiskSolution manager

try with

    Debug mode where each step taken will get reported in detail. Useful for understanding what goes wrong if the results is not what is expected.



Coupla things. Firstly, -d isn't a valid option for this app so that didn't really help, but thanks for the input. I was really pulling my hair out on this one.

Secondly, I've got it going...

I still don't know *why* exactly, but for some reason the AD boxes were denying access on port 389. I found a resource on a different web site that was similar and their solution was to ensure that the authenticating AD boxes were configured to have a Global Catalog and to bind on port 3268. This worked for me!

I still don't know why 389 was working and then stopped suddenly, especially considering that there doesn't appear to have been anything changed within the AD that should have any bearing on it but a solution is a solution...

So, problem solved but I suspect I'll not be able to collect my own points for this which is a shame... ;o)

Closed, 500 points refunded.

Community Support Moderator