SCROLL
5 лет назад
11 248 просмотров
11 комментариев
Среднее время на прочтение: 5 мин.

Интеграция Squid 4.9 с Active Directory на Debian 9. Реализация Kerberos аутентификации и LDAP авторизации.

Разберем как настроить связь Squid 4.9 c Active Directory через Kerberos аутентификацию и Basic LDAP авторизацию, для предоставления доступа в интернет по доменным учетным записям и разграничение прав согласно заданным группам безопасности Active Directory.

Исходные данные:

  • Контроллер домена DC1 на Windows Server 2012 R2, домен JAKONDA.LOCAL
  • Прокси-сервер squid на Debian 9 Stretch

Подготовка системы (Debian)

Перед началом выполнения ниже описанных действий обновляем систему до актуального состояния:

apt-get update && apt-get upgrade -y

Указываем FQDN (Fully Qualified Domain Name) имя системы, в файле /etc/hostname:

/etc/hostname
squid.jakonda.local

Так же файл /etc/hosts приводим к виду таким образом, чтобы в нём была запись с полным доменным именем компьютера и с коротким именем, ссылающаяся на один из внутренних IP:

/etc/hosts
127.0.0.1	localhost
127.0.1.1	squid.jakonda.local squid

Настраиваем синхронизацию времени с контроллером домена, выполняем установку NTP, выполняем синхронизацию времени с контроллером домена:

apt-get install ntp ntpdate

ntpdate dc1.jakonda.local
Более подробно о синхронизации времени на Debian можно почитать в статье — https://jakondo.ru/sinhronizatsiya-vremeni-ntp-na-debian-10-buster/

Настройка Active Directory (Windows Server 2012 R2)

В DNS зону JAKONDA.LOCAL, добавляем A-запись прокси-сервера:

Создаем служебного пользователя (прим. squid), с бесконечным срок действия пароля.

Создаем KEYTAB-файл (необходим для аутентификации пользователей в Active Directory). В командной строке с правами администраторы выполняем команду (соблюдая регистр):

ktpass -princ HTTP/squid.jakonda.local@JAKONDA.LOCAL -mapuser squid@JAKONDA.LOCAL -pass Aa1234567 -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out C:\squid.keytab

Полученный KEYTAB-файл, передаем любым удобным способом на файловый сервер (расположение KEYTAB-файла указываем — /etc/squid/squid.keytab). Как передать файл посредством утилиты PuTTY можно прочитать тут

Назначаем права доступа на KEYTAB-файл для использования его прокси-сервером:

chown proxy:proxy /etc/squid/squid.keytab 
chmod 640 /etc/squid/squid.keytab

Настройка Kerberos

Установка пакетов для поддержки аутентификации Kerberos:

apt-get install krb5-user libsasl2-modules-gssapi-mit
В ходе установки может появится запрос указать область по-умолчанию для Kerberos, область необходимо его указать в заглавном виде (прим. JAKONDA.LOCAL)

Файл конфигурации Kerberos /etc/krb5.conf, приводим к виду:

/etc/krb5.conf
[logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
[libdefaults]
    default_realm = JAKONDA.LOCAL
    default_keytab_name = /etc/squid/squid.keytab
    dns_lookup_kdc = false
    dns_lookup_realm = false
    forwardable = true
    ticket_lifetime = 24h
[realms]
    JAKONDA.LOCAL = { 
        kdc = dc1.jakonda.local 
        default_domain = JAKONDA.LOCAL 
        admin_server = dc1.jakonda.local 
    }
[domain_realm]
    .jakonda.local = JAKONDA.LOCAL 
    jakonda.local = JAKONDA.LOCAL
Соответственно подставляем название своего домена вместо jakonda.local/JAKONDA.LOCAL

Проверка работы Kerberos, выполним авторизацию в Active Directory:

kinit -kV -p HTTP/squid.jakonda.local

Using default cache: /tmp/krb5cc_0
Using principal: HTTP/squid.jakonda.local@JAKONDA.LOCAL
Authenticated to Kerberos v5

Удаляем полученный билет:

kdestroy

Настройка Squid

Сперва установим необходимые пакеты для корректной работы механизмов Kerberos и LDAP:

apt-get install libsasl2-modules-gssapi-mit ldap-utils

В стартовом скрипте /etc/init.d/squid добавим путь к keytab-файлу. В скрипте находим строку DESC="Squid HTTP Proxy" и ниже дописываем:

/etc/init.d/squid
KRB5_KTNAME=/etc/squid/squid.keytab
export KRB5_KTNAME

Применяем изменения в демоне и перезапускаем squid:

systemctl daemon-reload
/etc/init.d/squid restart

Для использования Kerberos аутентификации и LDAP авторизации, необходимо в файле конфигурации /etc/squid/squid.conf указать следующие параметры:

/etc/squid/squid.conf
# ACTIVE DIRECTORY AUTH (KERBEROS)
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s HTTP/squid.jakonda.local
auth_param negotiate children 30
auth_param negotiate keep_alive on

# ACTIVE DIRECTORY AUTH (LDAP)
auth_param basic program /usr/lib/squid/basic_ldap_auth -b "dc=jakonda,dc=local" -P -R -D "squid@jakonda.local" -w "Aa1234567" -f "sAMAccountName=%s" dc1.jakonda.local
auth_param basic realm Squid Basic Auth
auth_param basic children 30
auth_param basic credentialsttl 8 hours

acl auth proxy_auth REQUIRED

...
 
# http_access allow localnet

# ACTIVE DIRECTORY AUTH USERS
http_access allow auth
Обращаю внимание что в конфигурации строку http_access allow localnet необходимо закоментировать либо вовсе удалить из конфигурации.

Указанные параметры позволят выход в интернет только авторизованным в Active Directory пользователям. В случае если выход в интернет осуществляется из доменной системы и авторизованным доменным пользователем, то аутентификация будет проходить по методу SSO (Single Sign On), в противном случае будет запрошен ЛОГИН\ПАРОЛЬ (доменной учетной записи) для доступа в интернет.

Для более гибкого управления доступом в интернет конечно же необходимо задействовать Группы безопасности Active Directory. Рассмотрим пример использования групп безопасности в Squid.

Сперва создадим в Active Directory прим. следующие группы безопасности:

  • SQUID_FullAccess — Полный доступ
  • SQUID_RestrictedAccess — Ограниченный доступ
  • SQUID_BlockedAccess — Заблокированный доступ

Для проверки, что хелперы (Kerberos и Basic LDAP) отрабатывают корректно, выполним для каждого из них запрос, в котором проверим членство пользователя squid в группе безопасности SQUID_FullAccess.

Для Kerberos, выполним запрос:

/usr/lib/squid/ext_kerberos_ldap_group_acl -a -i -g SQUID_FullAccess -D JAKONDA.LOCAL
squid

kerberos_ldap_group.cc(432): pid=12787 :2020/01/29 16:30:59| kerberos_ldap_group: INFO: Got User: squid set default domain: JAKONDA.LOCAL
kerberos_ldap_group.cc(437): pid=12787 :2020/01/29 16:30:59| kerberos_ldap_group: INFO: Got User: squid Domain: JAKONDA.LOCAL
support_member.cc(127): pid=12787 :2020/01/29 16:30:59| kerberos_ldap_group: INFO: User squid is member of group@domain SQUID_FullAccess@NULL
OK

Для Basic LDAP, выполним запрос:

/usr/lib/squid/ext_ldap_group_acl -b "dc=jakonda,dc=local" -P -R -K -D "squid@jakonda.local" -w "Aa1234567" -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf=cn=%g,OU=Security Groups,DC=jakonda,DC=local))" -h dc1.jakonda.local -d
squid SQUID_FullAccess

ext_ldap_group_acl.cc(589): pid=11760 :Connected OK
ext_ldap_group_acl.cc(736): pid=11760 :group filter '(&(objectclass=person)(sAMAccountName=squid)(memberOf=cn=SQUID_FullAccess,OU=Security Groups,DC=jakonda,DC=local))', searchbase 'dc=jakonda,dc=local'
OK
В случае если все работает корректно, то ответ на запрос в случае положительного результата, будет OK или же ERR. В моем случае пользователь squid имеет членство в группе SQUID_FullAccess

Теперь в файле конфигурации /etc/squid/squid.conf укажем следующие параметры:

/etc/squid/squid.conf
# EXTENTION KERBEROS GROUP AUTH
external_acl_type kerberos_full_access ttl=900 negative_ttl=900 %LOGIN /usr/lib/squid/ext_kerberos_ldap_group_acl -a -g SQUID_FullAccess -D JAKONDA.LOCAL
external_acl_type kerberos_restricted_access ttl=900 negative_ttl=900 %LOGIN /usr/lib/squid/ext_kerberos_ldap_group_acl -a -g SQUID_RestrictedAccess -D JAKONDA.LOCAL
external_acl_type kerberos_blocked_access ttl=900 negative_ttl=900 %LOGIN /usr/lib/squid/ext_kerberos_ldap_group_acl -a -g SQUID_BlockedAccess -D JAKONDA.LOCAL

# EXTENTION LDAP GROUP AUTH
external_acl_type ldap_group ttl=900 %LOGIN /usr/lib/squid/ext_ldap_group_acl -b "dc=jakonda,dc=local" -P -R -K -D "squid@jakonda.local" -w "Aa1234567" -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf=cn=%g,OU=Security Groups,DC=jakonda,DC=local))" -h dc1.jakonda.local

# ACL KERBEROS GROUP
acl kerberos_full_access            external kerberos_full_access
acl kerberos_restricted_access      external kerberos_restricted_access
acl kerberos_blocked_access         external kerberos_blocked_access

# ACL LDAP GROUP
acl ldap_full_access            external ldap_group SQUID_FullAccess
acl ldap_restricted_access      external ldap_group SQUID_RestrictedAccess
acl ldap_blocked_access         external ldap_group SQUID_BlockedAccess

Для общего понимания указанных выше параметров, небольшое пояснение. Сперва описывается механизм работы хелпера Kerberos, в котором мы указываем в какой группе необходимо проверять членство пользователя. Для каждой группы указывается отдельный хелпер Kerberos.

Далее описывается механизм работы хелпера Basic LDAP, в котором указывается учетная запись (я использую ту для которой делался keytab-файл) с помощью которой будет просматриваться каталог LDAP, а так же задается область в которой находятся группы безопасности. Далее задаются ACL (Access Lists), которые сопоставляются с указанными хелперами.

Зададим порядок обработки определенных выше ACL:

http_access allow kerberos_full_access
http_access allow ldap_full_access

http_access deny kerberos_blocked_access
http_access deny ldap_blocked_access

http_access deny kerberos_restricted_access !allowedsites
http_access deny ldap_restricted_access !allowedsites

http_access deny blockedsites
http_access deny blockedsites

http_access allow auth
http_access deny all

Применяем внесенные изменения в файл конфигурации:

/etc/init.d/squid reload

На этом настройка squid завершена, можно приступать к проверке работы. Для этого на пользовательских ПК необходимо задать использование Прокси-сервера (Свойствах обозревателя - Подключения - Настройка сети). В поле «Адрес« указываем FQDN имя системы Squid, в моем случае это squid.jakonda.local и заданный порт.

При работе в прозрачном (transparent) режиме, аутентификация пользователей Active Directory невозможна! Подробнее: http://wiki.squid-cache.org/Features/Authentication#Authentication_in_interception_and_transparent_modes

Обсуждение

11 комментариев

  • Важно использовать имя хоста (FQDN) в настройках прокси, а не ip. У меня такая же проблема была.

    Ответить

  • Добрый день.
    Столкнулся с проблемой.
    При блокировке ресурса выходит окно авторизации (407). В фаили cache.log.
    kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
    current master transaction: master19830
    При этом авторизация настроена kerberos.
    Как то можно выключить проверку NTLM. Что бы этого запроса не было, а был ответ 403?
    В остальном все работает.
    Squid 5.5+Kerberos+ssl
    ось Ubuntu 20.04

    Ответить

  • Все ясно расписано. Поклон автору

    Ответить

  • С точки зрения «debian way» гораздо править не /etc/init.d/squid и потом делать systemctl daemon-reload, а всякую такую кустарщину вносить в /etc/default/squid.
    В init.d-скриптах (как правило) проверяется наличие такого файла и выполняется его содержимое.

    Ответить

  • ktpass -princ HTTP/datastore1.jakonda.local@JAKONDA.LOCAL -mapuser datastore1@JAKONDA.LOCAL -pass Aa1234567 -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out C:\datastore1.keytab
    здесь «datastore1» — это что?!!!

    Ответить
    • Автор
      Это ответ на комментарий Евгений

      поправил, там должно быть в моем случае вместо datastore1 — squid. У вас название машины может отличаться, там нужно указывать какое имя машины вы указываете.

      Ответить

  • Добрый день!

    Понятный, грамотный мануал. При AD авторизации сайты очень долго открываются, в /var/log/squid/access.log появляются ошибки TCP Denided 407

    1610023854.673 1 192.168.131.2 TCP_DENIED/407 4189 CONNECT pixel.rubiconproject.com:443 — HIER_NONE/- text/html
    1610023855.474 1 192.168.131.2 TCP_DENIED/407 4173 CONNECT dsum.casalemedia.com:443 — HIER_NONE/- text/html
    1610023855.645 1 192.168.131.2 TCP_DENIED/407 4133 CONNECT rtb.com.ru:443 — HIER_NONE/- text/html
    1610023858.774 1 192.168.131.2 TCP_DENIED/407 4169 CONNECT cdn.static.zdbb.net:443 — HIER_NONE/- text/html
    1610023858.918 6246 192.168.131.2 TCP_TUNNEL/200 5889 CONNECT sync.ipredictive.com:443 пользователь@ДОМЕН HIER_DIRECT/52.200.246.203 —
    1610023858.923 3385 192.168.131.2 TCP_TUNNEL/200 6015 CONNECT dsum.casalemedia.com:443 пользователь@ДОМЕН HIER_DIRECT/23.40.124.248 —
    1610023858.952 1 192.168.131.2 TCP_DENIED/407 4161 CONNECT stags.bluekai.com:443 — HIER_NONE/- text/html
    1610023858.954 1 192.168.131.2 TCP_DENIED/407 4193 CONNECT tpc.googlesyndication.com:443 — HIER_NONE/- text/html
    1610023859.109 6378 192.168.131.2 TCP_TUNNEL/200 8019 CONNECT pixel.rubiconproject.com:443 пользователь@ДОМЕН HIER_DIRECT/69.173.144.165 —
    1610023859.133 1 192.168.131.2 TCP_DENIED/407 4141 CONNECT cdn.krxd.net:443 — HIER_NONE/- text/html
    1610023859.525 6617 192.168.131.2 TCP_TUNNEL/200 4059 CONNECT pixel-a.sitescout.com:443 пользователь@ДОМЕН HIER_DIRECT/66.155.71.25 —
    1610023859.868 4151 192.168.131.2 TCP_TUNNEL/200 460 CONNECT rtb.com.ru:443 пользователь@ДОМЕН HIER_DIRECT/83.222.114.190 —
    1610023859.882 1 192.168.131.2 TCP_DENIED/407 4153 CONNECT beacon.krxd.net:443 — HIER_NONE/- text/html
    1610023859.885 0 192.168.131.2 TCP_DENIED/407 4157 CONNECT idsync.rlcdn.com:443 — HIER_NONE/- text/html
    1610023861.024 8366 192.168.131.2 TCP_TUNNEL/200 3877 CONNECT ad.turn.com:443 пользователь@ДОМЕН HIER_DIRECT/46.228.164.11 —

    Система Ubuntu Server 16.04.6 LTS squid 4.13

    Подскажите пожалуйста как ускорить загрузку сайтов

    Ответить

  • впринципе внятный мануал, правда я собирал кальмара из исходников на 9.13, сам кальмар 4.13, единственное это был бы внятный мануал по sams2 на сборку из исходников, увы все разрабы забили на ротаторы логов под кальмара, что увы печально(

    Ответить

  • Здравствуйте! не сталкивались с такой ошибкой cache.log:

    negotiate_kerberos_auth.cc(612): pid=1493 :2020/06/11 13:30:33| negotiate_kerberos_auth: DEBUG: Got ‘YR YII…HcA==’ from squid (length: 5659).
    negotiate_kerberos_auth.cc(679): pid=1493 :2020/06/11 13:30:33| negotiate_kerberos_auth: DEBUG: Decode ‘YII…HcA==’ (decoded length estimate: 4242).
    negotiate_kerberos_auth.cc(182): pid=1493 :2020/06/11 13:30:33| negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. Encryption type not permitted
    2020/06/11 13:30:33| negotiate_kerberos_auth: INFO: User not authenticated
    2020/06/11 13:30:33 kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. Encryption type not permitted; }}

    система CenOS 8, squid 4.4

    Ответить

  • Отличный мануал! Лучший во всем инете! Спасибо!!!

    Ответить

Похожие записи