Авторизация на SQUID через Active Directory

Обновлено Обновлено: Опубликовано Опубликовано:

Тематические термины: Squid, AD, CentOS.

Инструкция подразумевает, что у нас уже есть рабочий Squid-сервер. В противном случае, настраиваем, используя инструкцию Установка и настройка Squid на CentOS.

Наш сервер будет принимать как наиболее безопасную Kerberos-авторизацию, так и NTLM. Все команды выполняются на примере системы Linux CentOS 7.

Подготовка

Настройка времени

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

yum install ntpdate

* если ее нет, будет предложено установить соответствующий пакет.

Редактируем crontab:

crontab -e

0 0 * * * /usr/sbin/ntpdate dc.domain.local

* где 0 0 * * * — выполнять задачу каждый день в 00:00; dc.domain.local — сервер контроллера домена.

Вручную синхронизируем время:

ntpdate dc.domain.local

Имя сервера

Задаем имя сервера следующей командой:

hostnamectl set-hostname proxy.domain.local

* где proxy — имя сервера; domain.local — доменное имя, иcпользуемое в сети.

Настройка на контроллере домена

Создание учетной записи

Открываем консоль управления пользователями и добавляем нового со стандартными правами. От этой учетной записи будут выполняться запросы к AD DS.

В своем примере мы создаем пользователя squid.

Учетная запись должна быть размещена по пути, в котором присутствуют названия только на латинице. Подразделения и контейнеры не должны быть на русском.

Создание keytab-файла

В двух словах, данный файл позволяет установить легитимность нашего Linux-сервера. Создается он на контроллере домена и копируется на последний.

Для создания файла переходим на контроллер домена и от имени администратора запускаем Powershell или обычную командную строку. Вводим:

ktpass /princ HTTP/proxy.domain.local@DOMAIN.LOCAL /mapuser squid@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass "password" /out C:\proxy.keytab

* где proxy.domain.local — полное имя нашего squid-сервера; DOMAIN.LOCAL — наш домен; squid@DOMAIN.LOCAL — учетная запись в AD для выполнения запросов (создана на шаге выше); password — пароль, который будет задан пользователю (должен соответствовать требованию AD).
* регистр важен.

В нашем примере, после выполнения команды на контроллере домена в корне диска С появится файл proxy.keytab. Его копируем на Linux-сервер, например, при помощи WinSCP.

Настройка CentOS

Kerberos

Устанавливаем следующие пакеты:

yum install cyrus-sasl-gssapi krb5-workstation krb5-devel

Открываем конфигурационный файл Kerberos:

vi /etc/krb5.conf

Редактируем следующие строки:

[libdefaults]
  ...
  default_realm = DOMAIN.LOCAL
  ..

[realms]
  DOMAIN.LOCAL = {
    kdc = 192.168.0.15
    kdc = 192.168.0.16
    kdc = 192.168.0.17
    admin_server = domain.local
  }

DOMAIN.LOCAL — наш домен; kdc — перечень контроллеров домена; admin_server — первичный контроллер (в данном примере будет использоваться случайный).

Проверяем настройки krb, запросив тикет:

kinit domainuser

klist

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

Ticket cache: KEYRING:persistent:0:0
Default principal: domainuser@DOMAIN.LOCAL

Valid starting       Expires              Service principal
15.05.2018 10:08:33  15.05.2018 20:08:33  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 22.05.2018 10:08:30

Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:

kinit -V -k -t /etc/squid/proxy.keytab HTTP/proxy.domain.local@DOMAIN.LOCAL

* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/proxy.domain.local@DOMAIN.LOCAL — принципал, который был задан при создании файла.

И снова:

klist

Картина, примерно, следующая:

Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8
Default principal: HTTP/proxy.domain.local@DOMAIN.LOCAL

Valid starting       Expires              Service principal
16.05.2018 09:35:20  16.05.2018 19:35:20  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 23.05.2018 09:35:20

Зададим файлу следующие права:

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

chmod u+rwx,g+rx /etc/squid/proxy.keytab

NTLM

Устанавливаем следующие пакеты:

yum install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation

Конфигурируем 

authconfig --enablekrb5 --krb5kdc=domain.local --krb5adminserver=domain.local --krb5realm=domain.LOCAL --enablewinbind --enablewinbindauth --smbsecurity=ads --smbrealm=domain.LOCAL --smbservers=domain.local --smbworkgroup=domain --winbindtemplatehomedir=/home/%U --winbindtemplateshell=/bin/bash --enablemkhomedir --enablewinbindusedefaultdomain --update

Добавляем сервер в домен:

net ads join -U administrator

* где administrator — учетная запись в AD с правами на ввод компьютеров в домен.

Разрешаем автозапуск winbind и запускаем его:

systemctl enable winbind

systemctl start winbind

Проверяем, что наш сервер умеет обращаться к службе каталогов:

wbinfo -t

wbinfo -g

* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся к каталоге.

Настройка SQUID

Для скрипта запуска squid добавим следующее:

vi /etc/default/squid

KRB5_KTNAME=/etc/squid/proxy.keytab
export KRB5_KTNAME

* в данном случае, мы задаем переменную KRB5_KTNAME, в которой указан путь до кейтаб файла.

Открываем конфигурационный файл squid:

vi /etc/squid/squid.conf

И добавляем:

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -s HTTP/proxy.domain.local@DOMAIN.LOCAL
auth_param negotiate children 20
auth_param negotiate keep_alive on

auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=DOMAIN
auth_param ntlm children 10
auth_param ntlm keep_alive off

* где /usr/lib64/squid/negotiate_kerberos_auth — путь до библиотеки аутентификации по kerberos, ее путь может отличаться — это зависит от версии системы; HTTP/proxy.domain.local@DOMAIN.LOCAL — учетная запись в keytab.

Также настраиваем, чтобы squid требовал аутентификацию. Для этого в секции acl добавим:

acl auth proxy_auth REQUIRED

Далее это:

http_access allow localnet

Меняем на:

http_access allow auth

* в нашем случае acl localnet использовалась для предоставления доступа.

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

squid -k parse

И если ошибок нет:

squid -k reconfigure

Проверка

Для проверки на сервере открываем лог:

tail -f /var/log/squid/access.log | grep dmosk

* dmosk — учетная запись в AD, от которой будем проверять работу squid.

Теперь на клиентском компьютере заходим в систему под нашей учетной записью (в данном примере, dmosk) и грузим любой сайт.

На сервер в логах должны появиться записи, примерно, такого вида:

1526474100.078    240 192.168.1.16 TCP_TUNNEL/200 934 CONNECT syndication.twitter.com:443 dmosk HIER_DIRECT/134.144.40.72 -
1526474100.743     45 192.168.1.16 TCP_TUNNEL/200 559 CONNECT login.vk.com:443 dmosk HIER_DIRECT/187.244.139.145 -

Авторизация на основе групп AD

Ранее, мы предоставили доступ к сети Интернет любому пользователю Active Directory. Теперь ограничим доступ с помощью групп AD DS.

Открываем конфигурационный файл squid:

vi /etc/squid/squid.conf

Добавляем после настройки аутентификации:

external_acl_type squid_users_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g administrators@DOMAIN.LOCAL
external_acl_type squid_users_from_ad_ntlm %LOGIN /usr/lib64/squid/ext_wbinfo_group_acl -d

squid_users_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе administrators; squid_users_from_ad_ntlm — произвольное название acl, авторизованных пользователей в AD через NTLM.

В секции acl:

#acl auth proxy_auth REQUIRED
acl squid_users_acl_krb external squid_users_from_ad_krb
acl squid_users_acl_ntlm external squid_users_from_ad_ntlm unixadmin

squid_users_acl_krb — произвольное название acl для всех, кто входит в squid_users_from_ad_krb; squid_users_acl_ntlm — произвольное название acl для всех, кто входит в squid_users_from_ad_ntlm; unixadmin — группа пользователей в AD.
* предыдущую acl для общей аутентификации комментируем.

В секции allow:

#http_access allow auth
http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm

* разрешаем доступ для acl squid_users_acl_krb и squid_users_acl_ntlm; предыдущее разрешение для всех пользователей AD запрещаем.

Возможные ошибки

1. Password set failed! 0x00000020

Возникает при попытке создать keytab на контроллере домена.

Причина: учетная запись, которая используется в ключе /mapuser находится в одном из подразделений, названных с применением кириллицы.

Решение: перенесите учетную запись для связывания в подразделение, названное на латинице, например, CN=Users,dc=domain,dc=local.

# Сети # Серверы # Интернет # Безопасность # CentOS
Дмитрий Моск — частный мастер
Была ли полезна вам эта инструкция?

Да            Нет