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:
/squid_ldap_auth
-b "dc=cs-plc,dc=salvesen,dc=com"
-D "cn=Ldap User,ou=Users,ou=Salvesen House (slh /
wel),ou=UK,dc=cs-plc,dc=salvesen,dc=com"
-w ********
-f "(&(CN=%s)(memberOf=CN=InternetUsers,OU=Groups,OU=Salvesen
House (slh / wel),OU=UK,DC=cs-plc,DC=salvesen,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'
ERR
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....
Regards,
Ian Large
INFORMATION:
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
--------------------------------------------------------------------------------
For information on Christian Salvesen visit our website at www.salvesen.com.
The information contained in this e-mail is strictly confidential and for the use of the addressee only; it may also be legally privileged and / or price sensitive. Notice is hereby given that any disclosure, use or copying of the information by anyone other than the intended recipient is prohibited and may be illegal. If you have received this message in error, please notify the sender immediately by return e-mail.
Christian Salvesen has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment.
Christian Salvesen is a trading name of the Christian Salvesen Group. Christian Salvesen PLC (Company number SC7173) is the ultimate holding company within the Christian Salvesen Group whose registered office is at 16 Charlotte Square, Edinburgh EH2 4DF.
