Когда-то давным-давно в Южной Америке были красивые теплые виртуальные джунгли, и там жил кальмар. вот перцептивный образ сети:
<the Internet>
|
|
A | B
Users <---------> [squid-Server] <---> [LDAP-Server]
Когда Users запросить доступ в Интернет, squid спросите их имя и паспорт, подтвердите их LDAP и если ldap их одобрил, то он их предоставил.
Все были счастливы, пока несколько снифферов не украли паспорт на пути между пользователями и squid [путь A]. Эта катастрофа произошла из-за того, что кальмар использовал Basic-Authentication метод.
Люди джунглей собрались, чтобы решить проблему. Некоторым кроликам предлагалось использовать NTLM метода. Змеи предпочитали Digest-Authentication пока Kerberos рекомендуется деревьями.
Ведь многие решения предложили люди джунглей и все запутались! Лев решил положить конец ситуации. Он выкрикивал правила для решений:
Затем очень разумное, всеобъемлющее и умное решение, предложенное обезьяной, сделало ее новым королем джунглей!
Вы можете догадаться, какое было решение?
Наконечник: Путь между squid и LDAP защищен львом, поэтому решение не должно его обезопасить.
Примечание: извините, если история скучная и запутанная, но по большей части это правда! знак равно
/~\/~\/~\ /\~/~\/~\/~\/~\ ((/~\/~\/~\/~\/~\)) (/~\/~\/~\/~\/~\/~\/~\) (//// ~ ~ \\\\) (\\\\( (0) (0) )////) (\\\\( __\-/__ )////) (\\\( /-\ )///) (\\\( (""""") )///) (\\\( \^^^/ )///) (\\\( )///) (\/~\/~\/~\/) ** (\/~\/~\/) *####* | | **** /| | | |\ \\ _/ | | | | \_ _________// Thanks! (,,)(,,)_(,,)(,,)--------'
Массимо объяснил, что метод аутентификации между Users-squid и squid-LDAP не обязательно должно быть таким же. мы можем использовать произвольный метод для получения информации об аутентификации от пользователей и произвольный метод для аутентификации собранных данных.
Но есть проблема: ввод / вывод всех типов аутентификаторов неодинаков. Например:
Basic аутентификатор должен прочитать пару «имя пользователя и пароль» в строке и ответить OK если пользовательский пароль правильный или ERRDigest аутентификатор должен прочитать username:realm и ответьте шестнадцатеричным кодом HA(A1) или ERR. Хотя нет прямой связи между методом client-squid и методом squid-ldap, собранные данные от клиента должны быть совместимы с методом, используемым в части squid-ldap. Следовательно, если мы изменим метод аутентификации на стороне пользователя, нам, возможно, следует также изменить наш аутентификатор.
Таким образом, проблема упрощается до:
На первом уровне я (обезьяна!) Ищу хороший метод аутентификации на стороне пользователя. Какой метод вы порекомендуете безопасен и поддерживается большинством браузеров? я не понимаю NTLM, Kerberos и Digest.
Где я могу найти аутентификатор, который поддерживает учетные данные выбранного метода и аутентифицируется через LDAP.
Одна интересная особенность, которая может вам здесь помочь, заключается в том, что метод, который Squid использует для запроса аутентификации у браузера клиента (путь A), совсем не обязательно должен быть связан с методом, который он использует для фактической проверки учетных данных, предоставленных пользователем (путь B ). Это означает, например, что вы можете заставить Squid «разговаривать» о NTLM с клиентскими браузерами, но тогда он может очень хорошо проверять пользователей по внутренней базе данных пользователей Linux (/ etc / passwd). Там есть нет необходимость в учетных данных, полученных с помощью NTLM (на пути A), для фактической проверки в домене Windows (на пути B). То же самое относится к любой возможной комбинации методов аутентификации на стороне клиента и методов аутентификации на стороне сервера.
В вашем случае это означает, что f.e. вы можете безопасно настроить Squid на запрос NTLM-аутентификации из клиентских браузеров вместо базовой аутентификации, и это никоим образом не потребует от вас фактического использования Samba / WinBind / AD / чего угодно.
Таким образом, вы можете выбрать любой метод аутентификации на стороне клиента, но по-прежнему проверять пользователей на сервере 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 digest, вместо того, чтобы использовать его в «auth_param basic», где он находится сейчас.
Вам обязательно стоит использовать 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.
Kerberos не подходит для проверки подлинности HTTP. NTLM не поддерживается ни в одном браузере, кроме IE. Базовый небезопасен, если вы не поместите его за HTTPS, чего не может сделать AFAIK squid. Итак, у вас остался дайджест.