Vlákno názorů k článku Integrace SQUID proxy serveru do Active Directory (2) od Jindra Šaur - Výjimky z praxe by mě taky zajímaly. Některé...

Vyjímka z čeho? Že to vůbec nemá jít přes proxinu (což je práce pro nastavení firewallu) nebo jít přes proxinu bez ověřování?
Hodně problémů v kombinaci s ověřováním NTLM a negotation je v ředě squid 2.x, protože proxina trvala na dodržení přesně příslušné specifikace, kterou klienti nedodržují (a ani sám Microsoft ve své proxině), přechod na squid 3.x to řeší.
Pokud ani to nepomáhá, tak nastavení, že stránka má projít bez ověřeni např:

# pust ESET na update bez autorizace
acl ESETUPDATE url_regex ^http://*.eset.cz/
acl ESETUPDATE url_regex ^http://*.eset.sk/
acl ESETUPDATE url_regex ^http://*.eset.com/
http_access allow ESETUPDATE

A tohle musí být nacpané před pravidlem tvrvajícím na tom ověřování (v článku by to bylo před "http_access deny !auth").

Jinak pro takové firemní nasazení by slušelo i řešení autokonfigurace nastavení použití proxiny (přislušné DNS a DHCP záznamy a wpad skript dostupný přs HTTP), aby to hlavně pro notebookáře fungovalo OK (jsem ve firmě-jedu přes proxinu, jsem někde venku-jedu přímo, připojím se VPNkou na firmu-opět se přepne na firemní proxinu). Tohle mi ještě nechodí OK v případě, že je i IPv6 síť ve firmě. :-(

Také mám na Eseta lokální zrcadlo. Tohle je pravidlo, co slouží právě pro ně, aby se dostalo ke zdroji. Nepřipouštíme, aby cokoliv komunikovalo jinak, než skrz proxinu. Takže takovéto ACL vyjímky jsou většinou pro takovéto blbosti typu eset, wsus, ...