У прокси-сервера 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:

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» (может потребоваться в многодоменной инфраструктуре).

Автор первичной редакции:
Алексей Максимов
Время публикации: 19.03.2017 11:16