История безопасной аутентификации пользователя в сквиде
Только, чтобы быть анальным я не назвал бы вышеупомянутую конфигурацию сети многосетевой. Это просто передает между двумя сетями в том же AS. Многосетевой в эти дни действительно средства, подключенные к двум или больше соседям (AS) или по крайней мере нескольким маршрутам тому же восходящему соседу (AS), в случае листовой сети с единственным восходящим поставщиком возможности соединения.
Kerberos не является опцией для Аутентификации HTTP. NTLM не хорошо поддерживается ни в каком браузере кроме IE. Основной не безопасно, если Вы не помещаете его позади HTTPS, который не может сделать сквид AFAIK. Таким образом, Вас оставляют с Обзором.
Одна интересная функция, которая могла помочь Вам здесь, - то, что использование Сквида метода для просьбы клиентского браузера аутентификацию (соединяют A каналом) не должно вообще быть связано с методом, который это использует для фактической проверки учетных данных, предоставленных пользователем (соедините B каналом). Это означает, f.e., то, что можно сделать Сквид "разговором" NTLM с клиентскими браузерами, но затем он мог очень хорошо проверить пользователей против базы данных внутреннего пользователя Linux (/etc/passwd). Нет никакой потребности в учетных данных, полученных с помощью NTLM (на пути A), чтобы на самом деле быть проверенной против домена Windows (на пути B). То же относится к любой возможной комбинации клиентских методов аутентификации и аутентификации серверной стороны.
То, что это означает в Вашем случае, то, что f.e., можно безопасно настроить Сквид для запроса аутентификации NTLM от клиентских браузеров вместо стандартной аутентификации, и это ни в коем случае не потребует, чтобы Вы на самом деле использовали Samba/WinBind/AD/whatever.
Таким образом, можно выбрать любой метод, который Вы хотите для клиентской аутентификации, и все же продолжаете проверять пользователей против сервера LDAP после того, как они обеспечили свои учетные данные с помощью метода, который Вы выбрали.
Волшебство происходит, конечно, в squid.conf:
#auth_param negotiate program <uncomment and complete this line to activate>
#auth_param negotiate children 5
#auth_param negotiate keep_alive on
#auth_param ntlm program <uncomment and complete this line to activate>
#auth_param ntlm children 5
#auth_param ntlm keep_alive on
#auth_param digest program <uncomment and complete this line>
#auth_param digest children 5
#auth_param digest realm Squid proxy-caching web server
#auth_param digest nonce_garbage_interval 5 minutes
#auth_param digest nonce_max_duration 30 minutes
#auth_param digest nonce_max_count 50
#auth_param basic program <uncomment and complete this line>
#auth_param basic children 5
#auth_param basic realm Squid proxy-caching web server
#auth_param basic credentialsttl 2 hours
#auth_param basic casesensitive off
Каждый auth_param директива включает определенную аутентификацию для клиентских браузеров (соедините A каналом), в то время как часть "программы" устанавливает то, что Squid будет на самом деле использовать для проверки учетных данных, обеспеченных пользователями. Можно использовать любую программу аутентификатора, которую Вы хотите здесь (даже пользовательски записанный один), пока он может получить идентификатор пользователя и пароль и ответить на "да" или "нет".
Просто необходимо взять любой аутентификатор, который Вы используете, чтобы сделать Ваш запрос LDAP и засунуть его в "auth_param ntlm" или "auth_param обзор" операторы, вместо "auth_param основной" тот, где это теперь.
Обновление:
Необходимо определенно использовать squid_ldap_auth в качестве аутентификатора, но я не могу сказать Вам точно, как без любой детали об определенном сервере LDAP Вы используете.
Относительно клиентской аутентификации любой должен быть хорошим; я довольно доволен NTLM, и большинство браузеров поддерживает его в наше время.
Такая конфигурация была бы похожа на это в squid.conf:
auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>
Это попросит удостоверения пользователя (соедините A каналом), использующий NTLM, затем проверьте их против сервера LDAP (соедините B каналом); но те "параметры" строго зависят от Вашей реализации LDAP и конфигурации.
Это могло помочь, также: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html.