What to do with Active Directory Referals?
If your Active Directory Servers answers an LDAP request with
referals the autentication is likely to fail.
Below you find user responses how they got around this problem:
- By Alan Walker, Sep 2008:
Just an FYI for the record in case somebody else sees the same issue in the
future:
Our squidGuard has been performing well for months now, with Squid performing
NTLM authentication and squidGuard performing LDAP lookups to check whether a
particular user is in a particular group, and so block certain sites to
certain users and allow them to others. However, once in a while the
squidGuard logs would report:
2008-09-03 09:18:53 [2962] (squidGuard): ldap_search_ext_s failed:
Operations error (params: dc=ticgroup,dc=local, 2,
(&(memberof=CN=InternetGeneral,OU=Groups,OU=Altona,DC=ticgroup,DC=local)
(sAMAccountName=awalker)), sAMAccountName)
Which would result in a blocked page, and the user would have to close the
browser and wait a few minutes before resuming happily. Minor inconvenience,
but not too bad.
However, yesterday, for no apparent reason, this error started happening on
EVERY account, so nobody could access the web.
To cut a long story short, I think that the Windows Active Directory server
which was being searched by SquidGuard started generating referrals to other
systems (for more complete information) for any searches in the active
directory at the root level (although for lower levels it was happy to supply
the information with no referrals, I really don't know why, I'm just treading
water at this depth), and the system did not have the
credentials/trusts/whatever (Kerberos?) setup required to follow the referral
to wherever it needed to go (don't ask me where, I still don't fully
understand this).
The workaround/solution was to stop using a regular AD server to perform the
searches and go straight to the domain Controller (is there really such a
thing in AD?) and query the Global Catalog on port 3268 instead of the regular
LDAP query port of 389. Apparently the Global catalog does not do referrals,
it just supplies all of the information itself (Thank you Global Catalog).
Maybe just setting up Kerberos properly would be a better solution, but that's
in the "too hard" basket at the moment.
So my search line in the squidguard.conf changed from:
ldapusersearch
ldap://ticmelb1/dc=ticgroup,dc=local?sAMAccountName?sub?(&(memberof=CN=InternetGeneral%2cOU=Groups%2cOU=Altona%2cDC=ticgroup%2cDC=local)(sAMAccountName=%s))
|
to:
ldapusersearch
ldap://tic_group_dc.ticgroup.local:3268/dc=ticgroup,dc=local?sAMAccountName?sub?(&(memberof=CN=InternetGeneral%2cOU=Groups%2cOU=Altona%2cDC=ticgroup%2cDC=local)(sAMAccountName=%s))
|
and now the system is happy again.
Hope this helps somebody. (Also hope it keeps on working for me.)
|
|
|
Documentation
Installation
Configuration
Runtime
Options
About blocking
Troubleshooting
Known Issues
Other Sources
|