Авторизация на squid через active directory

Введение

Существует проверенная временем связка для прокси сервера — squid + sams. Я настраивал ее еще лет 8 назад на Freebsd. Недавно у меня появилась необходимость настроить что-то подобное на CentOS 7, и я с удивлением обнаружил, что ничего принципиально нового с тех пор не появилось. Никакой более удобной и информативной web панели к squid не придумали.

Так что будем настраивать проверенный временем набор программ. Ко всему прочему, удобнее его сразу интегрировать с виндовым доменом, для простой авторизации на прокси с помощью учетных записей домена. Так проще будет смотреть статистику и давать доступ. Особенно это актуально, если у вас есть терминальные пользователи, работающие с одного ip. Здесь у вас вообще нет других вариантов, если вам нужна статистика и ограничение доступа по пользователям.

Приступим к настройке. В своей работе я буду подразумевать, что вы установили и настроили centos по моим рекомендациям. Советую ознакомиться с материалом. Это позволит здесь не тратить время на второстепенные настройки, которые не имеют прямого отношения к теме статьи.

Настройка SQUID с ntlm авторизацией через домен

Дальше будет попроще. Если на предыдущем этапе вы все сделали правильно, то squid заработает без проблем. Устанавливаем его:

# yum -y install squid

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

auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=XS
auth_param ntlm children 10
auth_param ntlm keep_alive off
acl auth proxy_auth REQUIRED

Не забудьте указать свой домен

Обращаю внимание на первую строку. В большинстве инструкций в интернете она выглядит немного не так, в ней нет дополнительных параметров

Без них у меня ntlm авторизация не хотела работать, я очень долго ее мучал.

Дальше находим в конфиге строку:

http_access allow localnet

Комментируем ее, она позволяет получить доступ всем компьютерам из локальной сети. После этой строки добавляем новую:

http_access allow auth

Разрешаем доступ только тем, кто прошел авторизацию. Запускаем squid и добавляем в автозагрузку:

# systemctl start squid
# systemctl enable squid

Все, можно идти проверять. Открываем браузер у какого-нибудь компьютера и указываем в качестве прокси ip адрес сервера, порт 3128. Пробуйте выйти в интернет.

Как понять, что все работает правильно:

1. Пользователя должно пустить в интернет.
2. В лог файле сквида должна быть информация об имени пользователя, который получает доступ. У меня это выглядит примерно вот так при открытии страницы яндекса:

# cat /var/log/squid/access.log | grep control

1449261311.346 9 10.1.4.189 TCP_MISS/304 438 GET http://yastatic.net/islands/_/S1-qWWyv85yFAtoHVvuxJXpOKA4.svg control HIER_DIRECT/178.154.131.217 -
 1449261311.351 11 10.1.4.189 TCP_MISS/200 622 GET http://yastatic.net/www/_/_/y/ljN5poHcx67T3HSZuHbvf2NNk.png control HIER_DIRECT/178.154.131.217 image/png
 1449261311.404 9 10.1.4.189 TCP_MISS/304 440 GET http://yastatic.net/morda-logo/i/disaster/metro11072015.png control HIER_DIRECT/178.154.131.217 -
 1449261311.488 97 10.1.4.189 TCP_MISS/302 355 GET http://kiks.yandex.ru/fu control HIER_DIRECT/213.180.204.143 -
 1449261311.507 9 10.1.4.189 TCP_MISS/304 341 GET http://kiks.yandex.ru/system/fc07.swf control HIER_DIRECT/213.180.204.143 -

В данном случае control — доменная учетная запись.

У нас получилась полностью дефолтная конфигурация, в которую мы просто добавили ntlm авторизацию и разрешили доступ в интернет только для тех, кто эту авторизацию прошел. Если компьютер находится не в домене, то при работе через прокси выскочит окно с авторизацией, в которую нужно будет ввести данные от учетной записи домена, чтобы получить доступ в интернет.

В таком виде конфигурация сервера уже вполне рабочая, можно пользоваться, подключать пользователей. Но это неудобно. Нужно средство для удобного управления списками доступа и просмотра статистики пользователей.

Configuring Squid

I created an Active Directory Group to control who gets access to the proxy. Check the man pages for ntlm_auth for options.
Edit your /etc/squid/squid.conf to enable the helper and adjust our_networks accordingly:

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of=EXAMPLE+ADGROUP
auth_param ntlm children 5
auth_param ntlm keep_alive on

acl our_networks 192.168.0.0/24 192.168.1.0/24

acl ntlm proxy_auth REQUIRED
http_access allow our_networks ntlm

This is not an inclusive set of parameters for Squid to function but is what is required for the authentication portion.

Настройка squid на проверку подлинности через Kerberos в домене Windows 2008 R2.

Для того чтобы сквид знал, какой кейтаб использовать, ему нужно указать, где он лежит. Для этого нужно создать и заполнить файл /etc/default/squid3 следующим содержимым (задать переменную, хранящую путь к кейтаб файлу, которую читает сквид):

squid ~ # cat /etc/default/squid3
KRB5_KTNAME=/etc/squid3/squid.keytab
export KRB5_KTNAME

Так же, необходимо в squid.conf настроить схему аутентификации, для этого нужно добавить следующие строки:

# указание, какой хелпер использовать с каким SPN
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL
# сколько параллельных потоков запускать для обслуживания аутентификации клиентов
auth_param negotiate children 10
# указывает поддерживать связь, а не обрывать, когда браузер опрашивает схемы аутентификации
auth_param negotiate keep_alive on

В некоторых конфигурациях в «сети» приводятся примеры без указания параметра -s и SPN, но у меня такая конфигурация не заработала. Так же, не забываем о наличии строк, разрешающим доступ для авторизованных пользователей:

acl lan proxy_auth REQUIRED
http_access allow lan

Примечание: вместо SPN можно использовать значение GSS_C_NO_NAME, в данном случае, squid будет использовать любой (какой? в какой последовательности?) SPN из keytab файла. Строка будет выглядеть так: <…>ate program /usr/lib/squid3/squid_kerb_auth -s GSS_C_NO_NAME(спасибо за дополнение комментатору selivan)

На этом можно считать настойку сквида законченной (не забудте сделать рестарт сквида). Если необходимо пускать не в всех пользователей в интернет, а только избранных, то в acl необходимо указать имя пользователя в том формате, в котором squid распознает пользователя. Этот формат можно посмотреть в логе access.log. Например для нашего случая имя пользователя имеет следующий вид:

1330858897.314 86 10.0.1.48 TCP_MISS/200 491 GET http://www.google-analytics.com/__utm.gif? test2@DOMAIN.LOCAL DIRECT/173.194.69.113 image/gif
1330858898.296 94 10.0.1.48 TCP_MISS/204 192 GET http://support.google.com/accounts/bin/stats? test2@DOMAIN.LOCAL DIRECT/173.194.69.100 -

то есть имя пользователя имеет формат имя_пользователя@ОБЛАСТЬ_ДОМЕНА. При этом, как показала практика, регистр букв имеет значение, то есть если в acl указать имя пользователя tEst2@DOMAIN.LOCAL или test2@DOMAIN.local, а в AD он заведен как test2 и область домена в верхнем регистре, то доступ пользователю предоставлен не будет. То есть нужно быть внимательным при указании пользователя в acl. Так же, можно задать список пользователей, перечислив их в отдельном файле и указав этот файл как значение для acl, например:

squid ~ # cat /etc/squid3/usersallow
ultest@DOMAIN.LOCAL
test2@DOMAIN.LOCAL
...
testn@DOMAIN.LOCAL
squid ~ # grep allow /etc/squid3/squid.conf
acl allowinet proxy_auth "/etc/squid3/usersallow"
http_access allow allowinet

Кроме данного способа, есть возможность предоставить доступ пользователей к интернету на основе членства в доменных группах. Но для данной задачи используется отдельный хелпер и список доступа в формате external_acl и хелпер /usr/lib/squid3/squid_ldap_group. В сети можно найти много примеров. Конфигурацию на основе доменных групп я постараюсь рассмотреть в следующих статьях.

Details

Every network and installation have their own criteria for operation. The squid developers and community do not have the time or inclination to write code for every minor situation. Instead we provide ways to easily extend various operations with local add-on scripts or programs we call helpers.

What language are helper meant to be written in?

Helpers can be written in any language you like. They can be executable programs or interpreted scripts.

The helpers bundled with Squid are currently written in Bash shell script, awk script, perl script, and C++. There are also frameworks available for helpers built in Python or Ruby.

There are several languages which encounter difficulties though:
Perl, Python
Certain methods of writing output to stdout automatically append newline characters. Care must be taken that only one set of newlines are output with the response.

PHP

Various versions of the Zend 5.x engine have bugs related to I/O and execution timeouts. Others have bugs in configuration settings used to control these timeouts. In general it is best to avoid PHP entirely unless one wants to spend a great deal of time testing and finding workaround for these issues. Some of these bugs do not have solutions.

Go

read() operation seems to have some form of timeout on threads which returns socket-closed signals. Causing a multi-threaded concurrent helper to exit if its least-used thread times out. There is no known workaround or solution for this. As of Go version 1.12.1 the issue appears to be resolved.

How do the helpers communicate with Squid?

The interface with Squid is very simple. The helper is passed a limited amount of information on stdin to perform their expected task. The result is passed back to Squid via stdout. With any errors or debugging traces sent back on stderr.

• The helper is expected to wait for input before responding. Early responses or unexpected lines arriving to Squid on stdin will result in the helper being shut down with errors. If that happens often Squid may terminate as well.
• The helper is expected to handle multiple lookups by Squid. It is a terrible drag on HTTP speed to be constantly re-starting helpers. If that happens often enough Squid may terminate as well.

See the particular interface protocols below for details about the line syntax the helper is expected to receive and send on each interface.

Why is my helper not starting up with Squid?

Squid-3.2 and newer support dynamic helper initialization. That means the helper is only started if it needs to be. If Squid is configured with startup=N value greater than 0 you can expect that many of your helper to be started when Squid starts. But this is not necessarily a desirable thing for Squid needing fast startup or restart times.

With startup=0 configured the first HTTP request through Squid is expected to start at least one instance for most of the helpers. But if for example an external ACL is configured and is only tested on rare occasions its helper will not be started until that rare occasion happens for the first time.

What happens when Squid shuts down or reconfigures?

When shutting down, reconfiguring, or in other times Squid needs to shutdown a helper Squid schedules closure of the stdin connection of the helper. When all the in-progress lookups are completed the helper should receive this close signal when reading stdin.

Shutting down or restarting are limited by the shutdown_timeout which may cause Squid to abort earlier than receiving all the responses. If this happens the client connections are also being terminated just as abruptly as the helper — so the lost helper responses are not an issue.

Can I write a helper that talks to Squid on more than one interface?

You can. In a way.

Squid runs the configured helper for each interface as a separate child process. Your helper can be written to detect other running instances of itself and communicate between them, effectively sharing memory and/or state outside of Squid regardless of the interface Squid is using to run each instance.

NP: Just keep in mind that the number of instances (children) running on each interface is configurable and could be anything from zero to many hundreds. So do not make any assumptions about which interface another instance is running on.

Helper states

An individual helper process may be in one or more of the following states:

The above table does not reflect some esoteric corner cases, especially when it comes for conditions for ending a helper state. For example, a stateful helper process may stop being RESERVED for reasons other than writing the entire request data to the helper process.

Squid Cache Manager reports individual helper states on helper-specific pages such as mgr:store_io.

Особенности работы squid при авторизации на основе доменных групп LDAP

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

1. если пользователь входит в несколько групп, которым предоставлен доступ в интернет в конфигурационном файле squid, то он (пользователь) будет иметь то разрешение, которое первым совпадет с правилом http_access. То есть если некоторый авторизованный пользователь pupkin входит и в группу squid и в группу squid-list, то при том конфиге, что показан выше, он получит доступ согласно группе squid, потому что правило  http_access allow users расположено первым.
2. В каждом из OU (Склады, Кадры, Юристы и другие подразделения того же уровня) имеют в подчинении свои группы, включающие в себя подчиненные им же (подразделениям) пользователей. То есть подразделение Закупки имеет подчиненный объект Закупки, который является группой включающей в себя всех пользователей подразделения, и если эту группу включить в группу с именем squid (то есть группу Закупки сделать членом группы squid), то пользователи из группы Закупки не получат доступ к интернету, пока этих пользователей индивидуально не включишь в группу squid.
3. После добавления пользователя в группу работа пользователя начинается через некоторое время, а точнее через время, которое равно значению по-умолчанию в параметре ttl в external_acl_type и равно оно 3600 сек (1 час). Если есть желание ускорить процесс, то нужно уменьшить ttl, например так: external_acl_type ldap_check ttl=1200 %LOGIN /usr/…

Резюме

В данной статье нам, надеюсь и вам, удалось заставить squid с помощью хелпера  squid_ldap_group извлекать из Active Directory информацию о принадлежности пользователя к заданной группе и на основе данной информации предоставлять или не предоставлять доступ к интернету. При этом, есть возможность так же для групп задать настройки скорости через delay pools и многие другие настройки и ограничения для доступа в интернет, основываясь на управлении списками доступа acl. До новых статей!

Настройка аутентификации

По умолчанию, 3proxy настроен на использование логина 3APA3A и пароля 3apa3a. Для редактирования настроек открываем конфигурационный файл:

vi /etc/3proxy.cfg

Находим опцию users и добавляем пользователей:

#users 3APA3A:CL:3apa3a «test:CR:$1$qwer$CHFTUFGqkjue9HyhcMHEe1»
users dmosk1:CL:password
users «dmosk2:CR:$1$UsbY5l$ufEATFfFVL3xZieuMtmqC0»

* в данном примере мы закомментировали пользователей по умолчанию и добавили 2-х новых: dmosk1 с открытым паролем password и dmosk2 с паролем dmosk2 в виде md5 и солью UsbY5l (Для получения хэша пароля можно воспользоваться командой openssl passwd -1 -salt UsbY5l, где в качестве соли можно использовать любую комбинацию).
* обратите внимание, при использовании знака $, строчка пишется в кавычках. * возможные типы паролей:

* возможные типы паролей:

• CL — текстовый пароль
• CR — зашифрованный пароль (md5)
• NT — пароль в формате NT.

Чтобы отключить запрос логина, необходимо задать значение для опции auth в none. Однако, опций auth в конфигурационном файле несколько. Нужно найти ту, что отвечает за авторизацию службы proxy:

auth none
# We want to protect internal interface
deny * * 127.0.0.1,192.168.1.1
# and llow HTTP and HTTPS traffic.
allow * * * 80-88,8080-8088 HTTP
allow * * * 443,8443 HTTPS
proxy -n

* в данном примере, мы поменяли auth на none, чтобы отключить запрос пароля.

* возможные варианты для auth:

• none — без авторизации.
• iponly — авторизация по IP-адресу клиента.
• nbname — по Netbios имени.
• strong — по логину и паролю.

Также можно использовать двойную авторизацию, например:

auth nbname strong

После внесения изменений, перезапускаем службу:

systemctl restart 3proxy

Заключение

Пришло время подвести итог того, что мы сделали. Проведена большая работа по настройке прокси сервера на базе CentOS 7. Были выполнены следующие шаги:

1. Сервер был введен в домен Windows для настройки авторизации доменных пользователей на прокси сервере.
2. Настроен прокси сервер squid для работы с доменными учетными записями.
3. Собран из исходников многофункциональный web интерфейс для управления squid — sams2 самой последней на текущий момент версии.

Первые два этапа сами по себе позволяют полноценно пользоваться прокси сервером, но не дают удобства и гибкости настройки. Иногда это и не нужно и можно не заморачиваться с установкой и настройкой sams. Как ни крути, но установка достаточно хлопотная и нет гарантии, что через некоторое время после смены версий каких-нибудь пакетов или исходников, не появятся новые нюансы, которые не будут отражены в этой статье. С ними придется разбираться заново.

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

Онлайн курс Основы сетевых технологий

Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:

• На каком уровне модели OSI могут работать коммутаторы;
• Как лучше организовать работу сети организации с множеством отделов;
• Для чего и как использовать технологию VLAN;
• Для чего сервера стоит выносить в DMZ;
• Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
• и многое другое.

Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .