## SquidGuard

HOME | Downloads | Documentation | Development | Blacklists | Contributions | Contact
--- | --- | --- | --- | --- | --- | ---

## 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:

1. 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

Getting started
Destination ACLs
Source ACLs
Redirect Rule
Time Constraints
Authentication
Regular Expressions
Examples

Runtime Options

About blocking

Troubleshooting

Known Issues

Other Sources

© Powered by Shalla Secure Services 2007-2008