Пошаговые руководства, шпаргалки, полезные ссылки...
БлогФорумАвторы
Полезные Online-сервисы
Перечень Бесплатного ПО
Подписка на RSS-канал
У прокси-сервера Squid имеется целый ряд программ «хелперов», обеспечивающих разные механизмы аутентификации. В большинстве случаев используются хелперы, обеспечивающие безопасные способы аутентификации, например ntlm_auth или negotiate_kerberos_auth, так как эти хелперы позволяют защитить передаваемые по сети учётные данные аутентифицируемых на прокси пользователей. Однако в любой ИТ инфраструктуре найдутся какие-то приложения, которые вынуждают администраторов дополнительно включать на Squid поддержку Basic-аутентификации. Мало того, что Basic-аутентификация сама по себе является небезопасным способом аутентификации, так как учётные данные аутентифицируемого на прокси пользователя передаются по сети в открытом виде, так ещё и большинство хелперов Basic-аутентификации, имеющихся в Squid, для подключения к удалённым системам хранения учётных данных используют незащищённые протоколы.
Например, ранее рассматриваемый нами хелпер basic_ldap_auth, позволяет подключаться к контроллерам домена Active Directory для аутентификации пользователей на прокси и делает он это посредствам открытого незащищённого соединения по протоколу LDAP. То есть учётные данные служебного доменного пользователя, которые используются хелпером для подключения к LDAP-каталогу передаются по сети в открытом виде.
Вместо хелпера basic_ldap_auth, для Basic-аутентификации в домене Active Directory мы можем использовать хелпер basic_pam_auth, который в связке с настроенной службой sssd на прокси-сервере Squid позволит нам исключить такой этап, как передача в открытом виде по сети учётных данных для подключения к каталогу Active Directory.
Для использования хелпера basic_pam_auth в рассматриваемой далее конфигурации предполагает, что на сервере Squid уже установлена и настроена служба sssd, а также произведено подключение сервера к домену Active Directory. Настройка в нашем примере выполняется на Debian 8 (Jessie). Пример такой настройки описан в статье Подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd.
Итак, создадим на сервере Squid отдельную политику PAM, с которой будет работать хелпер basic_pam_auth. Эта политика будет вызывать библиотеку pam_sss.so для аутентификации пользователей:
# cat > /etc/pam.d/squid-sss <<EOF auth required pam_sss.so account required pam_sss.so EOF # chown root:root /etc/pam.d/squid-sss # chmod 644 /etc/pam.d/squid-sss
Теперь посмотрим то, какие параметры может принимать хелпер basic_pam_auth:
# /usr/lib/squid/basic_pam_auth -?
Параметров не так много:
Usage: /usr/lib/squid/basic_pam_auth [options..] -n service_name The PAM service name (default "squid") -t ttl PAM connection ttl in seconds (default 0) during this time the same connection will be reused to authenticate all users -o Do not perform account mgmt (account expiration etc) -1 Only one user authentication per PAM connection -r Detect and remove Negotiate/NTLM realm from username
Тестируем работу хелпера, вызвав его с параметром отсечения доменной части (-r) и указав ему имя созданной PAM-политики (-n)
# /usr/lib/squid/basic_pam_auth -r -n "squid-sss" -o
После выполнения команды отправляем работающему хелперу связку имя пользователя и пароль (через пробел). При этом проверяем реакцию хелпера на разные форматы предоставления имени пользователя.
chapaev-vi Pa$sw0rd OK KOM\chapaev-vi Pa$sw0rd OK chapaev-vi@KOM Pa$sw0rd OK chapaev-vi@holding.com Pa$sw0rd OK chapaev-vi Wr0ngPa$sw0rd ERR
Как видим, хелпер вполне справляется со своей задачей - проверкой предоставленных учётных данных пользователя в домене Active Directory.
Добавляем конфигурацию вызова хелпера в squid.conf:
... ### Basic authentication via PAM # auth_param basic program /usr/lib/squid/basic_pam_auth -n squid-sss -r -o auth_param basic children 20 auth_param basic realm "Non-secure Basic authentication for Proxy Server" auth_param basic credentialsttl 2 hours ...
Проверяем результат в клиентском браузере.
Несмотря на то, что при тесте имя пользователя в формате «KOM\chapaev-vi» отрабатывает успешно, на практике из клиентского браузера до хелпера это имя доходит в формате «KOM\\chapaev-vi» и хелпер не может его правильно обработать. Поэтому простым решением данной проблемы будет либо использование клиентами короткого имени «chapaev-vi», либо полного с доменной частью «chapaev-vi@holding.com» (может потребоваться в многодоменной инфраструктуре).
KOM\chapaev-vi
KOM\\chapaev-vi
chapaev-vi
chapaev-vi@holding.com
Автор первичной редакции: Алексей Максимов Время публикации: 19.03.2017 11:16