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

Настраиваем Squid для работы с Active Directory. Часть 3 — Авторизация на основе групп AD

В прошлых частях нашего цикла мы рассмотрели, как настроить Squid для аутентификации пользователей через ActiveDirectory, однако просто проверять подлинность пользователя в большинстве случаев недостаточно.

Требуется гибко управлять доступом пользователей к сети интернет основываясь на их членстве в группах безопасности AD, такая схема позволит администраторам использовать привычную и понятную модель управления, в тоже время задействовав все возможности прокси-сервера Sqiud.

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

Аутентификация — проверка подлинности пользователя, которая позволяет убедиться, что он действительно тот, за кого себя выдает.

Авторизация — проверка прав аутентифицированного пользователя на доступ к тому или иному объекту.

Для авторизации на прокси-сервере мы будем использовать членство в группах Active Ditectory, при этом можно использовать как уже существующие, так и вновь созданные группы. Мы рекомендуем создать свой набор групп, чтобы избежать путаницы. Например, для разграничения пользователей по доступу к различным ресурсам можно создать группы (будут использоваться для примеров в дальнейшем):

  • squid-admin — администрация и IT-персонал, фильтрация не производится.
  • squid-user — остальные пользователи, фильтрация по общему списку.
  • squid-whitelist — ограниченная группа пользователей, доступ только к ресурсам из «белого» списка.

А для ограничения скорости группы:

  • squid-speed-unlim — группа без ограничения скорости.
  • squid-speed-2-10mb — ограничение скорости 2 Мбит/с на пользователя и 10 Мбит/с на группу

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

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

Расположив первыми наиболее ограниченные списки, мы будем обрабатывать пользователя по сценарию с наибольшими ограничениями, разместив их наоборот — получим наименее возможные ограничения.

Ну а если списки будут расположены как попало, результат может оказаться самым неожиданным.

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

Настройка Kerberos-авторизации на основе групп безопасности Active Directory

Для выполнения ряда действий: аутентификации, авторизации, редиректа, логгирования и т.п. Squid использует специальные программы — хелперы. Это позволяет гибко наращивать функциональность программы без ее усложнения, нужно — подключили, нужно — изменили, не нужно — выключили. С полным списком хелперов Squid можно ознакомиться здесь: Squid helpers.

Несмотря на то, что, начиная с версии Squid 3.2 (вышла в августе 2012 г.

) доступен хелпер ext_kerberos_ldap_group_acl, позволяющий получать данные о членстве пользователя в доменных группах с использованием протокола Kerberos, подавляющее большинство инструкций в сети продолжают использовать хелпер ext_ldap_group_acl, который передает учетные данные по сети в открытом виде, в лучшем случае через SSL.

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

Но не обошлось без ложки дегтя в бочке меда. В поставку Squid в Ubuntu Server 14.04 данный хелпер не входит. Попытка собрать его самостоятельно не увенчалась успехом, собранный нами хелпер радостно сообщал нам, что данный вид авторизации не поддерживается.

В тоже время аналогичная версия Squid в Debian 8 прекрасно работала с этим хелпером. Поэтому была предпринята попытка использовать в Ubuntu хелпер из поставки Debian, что оказалось верным решением. Ниже мы выкладываем хелпер для Squid 3.3.8 архитектуры amd64 (т.е. для 64-битных систем).

Скачать ext_kerberos_ldap_group_acl (Sqiud 3.3.8 amd64)

Если вы используете Debian, то следующие действия можете пропустить и сразу перейти к настройке хелпера.

Перейдем в домашнюю директорию и скачаем хелпер с данного сайта:

cd~
wget «https://interface31.ru/tech_it/files/squid3.3.8/ext_kerberos_ldap_group_acl»

После чего скопируем его в директорию с хелперами:

cp ext_kerberos_ldap_group_acl /usr/lib/squid3

и сделаем его исполняемым:

chmod +x /usr/lib/squid3/ext_kerberos_ldap_group_acl

Теперь приступим к его настройке (отсюда инструкция для Debian и Ubuntu снова общая). Сначала установим необходимые для работы с AD библиотеки:

apt-get install libsasl2-modules-gssapi-mit

После чего проверим хелпер запустив его отдельно:

/usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g squid-user -D INTERFACE31.LAB

Ключи -d и -i предназначены для отладки, -g указывает желаемую группу, членство в которой мы хотим проверить, -D обозначает область Kerberos в которой производим проверку. Запустив хелпер просто вводим имя пользователя и получаем результат проверки: OK — если пользователь входит в группу и ERR — если не входит.

Убедившись, что все работает как надо, перейдем к настройке Squid, в конфигурационном файле, в самом начале секции ACL добавим строки:

external_acl_type squid-admin ttl=300 negative_ttl=60 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g squid-admin -D INTERFACE31.LABexternal_acl_type squid-user ttl=300 negative_ttl=60 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g squid-user -D INTERFACE31.LAB

И так далее, пока не перечислим все необходимые нам группы. Чтобы избежать путаницы, мы дали внешним элементам ACL такие же имена, как и доменным группам, вы можете называть их на свое усмотрение.

Ниже зададим элементы ACL, соответствующие группам, названия также будут совпадать с именами групп в AD.

acl squid-admin external squid-admin
acl squid-user external squid-user

В секции списков доступа не забываем убрать список, который разрешал доступ всем аутентифицированным пользователям:

http_access allow auth

Для проверки можете его заменить на:

http_access allow squid-admin
http_access deny squid-user

Сохраним и проверим конфиг:

squid3 -k check

Перезапустим squid:

service squid3 restart

Проверяем, пользователям, входящим в группу squid-admin доступ будет разрешен, а членам группы squid-user — запрещен.

Пример разграничения доступа к ресурсам сети на основе URL-фильтрации

Чтобы не быть голословными рассмотрим несколько примеров, например, разграничим доступ к ресурсам на основе групп, как было указано в начале материала.

Подробнее о настройке URL-фильтрации читайте в соответствующей статье.

Допустим у нас есть несколько списков, которым соответствуют элементы ACL graylist — список нежелательных сайтов и whitelist — «белый» список для ограниченной группы.

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

http_access allow squid-adminhttp_access deny graylisthttp_access allow squid-userhttp_access allow squid-whitelist whitelist

http_access deny all

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

http_access allow squid-whitelist whitelisthttp_access deny squid-whitelisthttp_access deny squid-user graylisthttp_access allow squid-userhttp_access allow squid-admin

http_access deny all

Пользователям, не входящим ни в одну группу, доступ будет полностью запрещен.

Некоторым читателям могут показаться избыточными правила вида http_access deny squid-whitelist, ведь все равно данный пользователь должен попасть под правило http_access deny all, однако вспомним, что в начале статьи мы обращали ваше внимание на то, что все случаи нужно прописывать явно, так как если этого списка не будет, то пользователь, входящий сразу в несколько групп получит доступ по одному из следующих списков, чего в данном варианте быть не должно.

Пример ограничения скорости

Мы снова не будем останавливаться подробно на механизме ограничения скоростей, про это написано здесь. А перейдем к конкретной задаче.

В начале статьи мы создали две группы, для пользователей без ограничения скорости и группу с ограничением в 2 Мбит/с на пользователя и 10 Мбит/с на группу, не вошедшие в группы пользователи должны ограничиваться на уровне 1 Мбит/с на пользователя, 5 Мбит/с на группу. Будем также считать, что названия ACL соответствуют названиям доменных групп.

Перейдем в конфигурационном файле в раздел DELAY POOL PARAMETERS и создадим три пула четвертого класса.

delay_pools 3delay_class 1 4 # Unlim (100 Mbit)delay_class 2 4 # 2 Mbit user / 10 Mbit group

delay_class 3 4 # 1 Mbit user / 5 Mbit group

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

Ниже зададим списки доступа:

delay_access 1 allow squid-speed-unlimdelay_access 1 deny alldelay_access 2 allow squid-speed-2-10mbdelay_access 2 deny all

delay_acesss 3 allow all

При членстве сразу в нескольких группах пользователь получит максимально доступную скорость, так как первыми указаны правила для более быстрого пула, чтобы сделать наоборот просто поставьте списки для пула 2 выше, чем списки для пула 1.

Наконец зададим параметры пулов:

delay_parameters 1 -1/-1 -1/-1 -1/-1 12000000/12000000delay_parameters 2 -1/-1 -1/-1 -1/-1 250000/1250000delay_parameters 3 -1/-1 -1/-1 -1/-1 125000/625000

Напоминаем, что параметры скорости в пулах задаются в байтах, поэтому значение в битах/с необходимо разделить на 8, например, 2 Мбит/с = 250 КБ/с. Также в пулах четвертого класса не следует задавать последний параметр (скорость пользователя) в виде -1/-1, следует указать полную ширину канала или заведомо большее значение, в нашем случае задано значение 100 Мбит/с = 12 МБ/с.

Как видим, ничего сложного в авторизации пользователей Squid на основе групп AD нет, в тоже время использование данного механизма дает в руки администратора мощный инструмент по контролю и управлению доступом к сети.

Источник: https://interface31.ru/tech_it/2015/07/nastraivaem-squid-dlya-raboty-s-active-directory-chast-3-avtorizaciya-na-osnove-grupp-ad.html

Авторизация squid в Active Directory через kerberos

В данной статье рассматривается довольно сложная тема как подружить прокси сервер squid с Active Directory (AD) используя kerberos.
Почему был выбран kerberos — это один из самых безопасных сетевых протоколов аутентификации который используется в AD и можно использовать в linux системах.

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

Ещё в разных версиях squid любят переименовывать параметры и названия хелперов. И как обычно одна неправильная точка, запятая, или имя компьютера может изрядно попортить вам нервы так что будьте внимательны и аккуратны.

Итак что у нас есть:

1. Контроллеры домена на windows 2008 R2 или 2012 R2 — serverdc (192.168.0.8), serverdc2 (192.168.0.9) которые управляют доменном mydomain.local

2. Прокси сервер на debian (ubuntu server) — proxy (192.168.0.6)
Начнём с настройки прокси сервера.

3. Клиенты windows XP и/или windows 7,8,10

Обращаю особое внимание что на всех серверах ip адреса должны быть статическими на клиентах можно использовать и динамические.

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

Предполагается что контроллер домена уже настроен и все клиенты в него заведены. Нам нужно добавить A запись на DNS сервере:

proxy узел(A) 192.168.0.6

Проверим запись:

nslookup proxy.mydomain.local

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

В АД создаем пользователя например squid с вечным паролем и не блокируемым.

Генерим сам кейтаб для этого используем утилитку ktpass на контроллере доменна:

ktpass -princ HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL -mapuser squid@mydomain.local -crypto RC4-HMAC-NT -pass Secretpassw0rd -ptype KRB5_NT_PRINCIPAL -out proxy.keytab

Важно указать «принципалом» именно hostname линукс сервера (в данном примере — proxy) потому что, в свойствах браузеров FireFox или IE нужно указать proxy.mydomain.local а не IP. Если необходимо указывать другое имя, а не то, что отдает дебиан по hostname -a, его нужно указать в конфиге сквида в параметре visible_hostname.

Копируем созданный файл proxy.keytab на прокси сервер в файл /etc/krb5.keytab он нам ещё понадобиться.

Читайте также:  Как пользоваться crystaldiskinfo. программа для мониторинга жестких дисков.

Настройка DNS

Переходим к настройкам линукса в современных дистрибутивах /etc/resolv.conf генерится автоматически и есть разные варианты настройки поэтому нужно смотреть инструкцию на свой дистрибутив но в конечном итоге должно получиться примерно так:

domain MYDOMAIN.LOCAL search MYDOMAIN.LOCAL nameserver 192.168.0.8 nameserver 192.168.0.9

Проверяем что контроллер домена доступен:

nslookup serverdc.mydomain.local ping serverdc.mydomain.local

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

Kerberos не будет проходить аутентификацию, если время между клиентом, прокси сервером и контроллером домена будет отличатся более чем на 3 минуты с учётом часовых поясов.

Если что то не работает в первую очередь нужно проверить что время везде одинаковое и часовые пояса правильные.

Чтобы время всегда было правильным ставим демона (службу) который будет синхронизировать время с контроллером домена

apt-get install ntp

Добавим в /etc/ntp.conf с кем нужно синхронизироваться:

# Specify one or more NTP servers. server serverdc.mydomain.local server serverdc2.mydomain.local

Остановим ненадолго демона

/etc/init.d/ntp stop

Проверим время и заодно синхронизируем часы

ntpdate serverdc

Запускаем демона теперь он сам будет следить за временем

/etc/init.d/ntp start

Настройка kerberos

Поставим утилиты и библиотеки необходимые для работы kerberos:

apt-get install krb5-user krb5-config libkrb53

Теперь нужно привести файл настроек /etc/krb5.conf к виду

[appdefaults] pam = { debug = false alt_auth_map = %s@MYDOMAIN.LOCAL force_alt_auth = true ticket_lifetime = 24h renew_lifetime = 24h forwardable = true krb4_convert = false } [libdefaults] default_realm = MYDOMAIN.LOCAL ticket_lifetieme = 24h dns_lookup_realm = false dns_lookup_kdc = false kdc_timesync = 1 ccache_type = 4 forwardable = yes rdns = no default_keytab_name = /etc/krb5.keytab default_tgs_enctypes = des-cbc-crc rc4-hmac des-cbc-md5 default_tkt_enctypes = des-cbc-crc rc4-hmac des-cbc-md5 permitted_enctypes = des-cbc-crc rc4-hmac des-cbc-md5 clock_skew = 300 [realms] MYDOMAIN.LOCAL = { kdc = serverdc.mydomain.local:88 kdc = serverdc2.mydomain.local:88 admin_server = serverdc.mydomain.local:749 default_domain = MYDOMAIN.LOCAL } [domain_realm] .mydomain.local = MYDOMAIN.LOCAL mydomain.local = MYDOMAIN.LOCAL [logging] default = FILE:/var/log/krb5lib.log kdc = FILE:/var/log/krb5kdc.log kdc = SYSLOG:INFO AEMON admin_server = FILE:/var/log/kadmin.log

Проверим правильность настройки kerberos

kinit usertest

usettest это может быть любой пользователь их AD если после ввода пароля не было никаких сообщений значит все хорошо можно двигаться дальше, если есть ошибки стоит ещё раз внимательно перепроверить файл /etc/krb5.conf.

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

kinit -V -k -t /etc/krb5.keytab HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL

Должно быть сообщение об успешной авторизации. Если наблюдаются ошибки то здесь они могут быть самыми не очевидными например не поддерживается алгоритм шифрования однако лечится генерацией кейтаба с исправленным hostname.

Короче нужно ещё раз внимательно проверить что кейтаб был сгенерирован с правильными параметрами с полным доменным именем прокси сервера. Ещё помнится как то долго бился пока не заменил везде hostname на более короткий.

Также нужно убедиться что в DNS сделана правильная A запись для прокси сервера.

Установка SQUID

Теперь перейдем к установке squid

apt-get install squid3 libpam-krb5

Скажем squid создать кэш и перезапустим чтобы проверить что он работает.

squid3 -z /etc/init.d/squid3 restart

Cоздаем файл /etc/pam.d/squid в который пишем:

auth required pam_krb5.so session required pam_krb5.so account required pam_krb5.so password required pam_krb5.so

Теперь нужно дописать в начало файла (после второй строки) /etc/init.d/squid3

KBR5_KTNAME=/etc/krb5.keytab export KRB5_KTNAME

И назначим права на кейтаб:

chown proxy:proxy /etc/krb5.keytab chmod 664 /etc/krb5.keytab

Переходим к редактированию конфига /etc/squid3/squid.conf

acl manager proto cache_object acl localhost src 127.0.0.1/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager include /etc/squid3/auth.conf http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all http_port 3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|?) 0 0% 0 refresh_pattern . 0 20% 4320

Конфиг на самом деле дефолтный кроме строки номер 18 где опцией unclude подключается файлик с дополнительными настройками.

Создаем файлик include /etc/squid3/auth.conf в котором пишем самое главное:

#Используем специальный helper для прозрачной аутентификации через kerberoos #auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL auth_param negotiate children 20 auth_param negotiate keep_alive on #Используем kerberos через систему pam для базовой авторизации с запросом пароля auth_param basic program /usr/lib/squid3/basic_pam_auth -n squid auth_param basic children 10 auth_param basic credentialsttl 2 hours auth_param basic realm MYDOMAIN.LOCAL #Необходимо для поиска групп в AD #external_acl_type ldap_check ttl=1200 children=15 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b «dc=mydomain,dc=local» -f «(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=mydomain,dc=local))» -D «squid@mydomain.local» -w «MegaPass123» -K -d 192.168.0.8 external_acl_type ldap_check ttl=1200 children=15 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b «dc=mydomain,dc=local» -f «(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=mydomain,dc=local))» -D «squid@mydomain.local» -w «MegaPass123» -K 192.168.0.8 #Описание групп доступа из AD acl all_it external ldap_check IT acl all_student external ldap_check Students acl all_inet external ldap_check inet #Описываем пользователей которые невходят в другие группы acl auth proxy_auth admin@MYDOMAIN.LOCAL acl auth proxy_auth sasha@MYDOMAIN.LOCAL #Назначаем разрешения кому можно ходить в интернет http_access allow all_student http_access allow all_inet http_access allow all_it http_access allow auth

Строчки 2 и 13 отличаются от 3 и 14 только параметром -d который можно использовать чтобы получить более подробную информацию о процессе авторизации в логах для обычной работы он ненужен.

Перезапускаем squid

/etc/init.d/squid3 restart

проверим что в логах нет ошибок

tail -n 50 /var/log/squid3/access.log

Если все впорядке то осталось настроить браузер на клиенте.

Настройка браузера

Для прозрачной авторизации нужен Internet Explorer 7 версии и выше т.к. на более ранних версиях протокол kerberos не поддерживается. В настройках нужно указывать обязательно полное имя прокси сервера proxy.mydomain.local и порт 3128.

Краткая инструкция по настройки прокси есть в отдельной статье тут.

На этом всё, комментарии, исправления и дополнения приветствуются.

Источник: http://www.zonepc.ru/avtorizaciya-squid-v-active-directory-cherez-kerberos/

Настраиваем proxy-сервер SQUID c авторизацией по LDAP (AD Windows) и web-интерфейсом для администриования SAMS

Настраиваем связку SQUID SAMS+REJIK с аунтентификацией по NTLM.

Так как есть ДОМЕН под управление Win 2003 Server, и нужна авторизация пользователя под своей учетной записью и так же вести логи и предоставлять информацию начальству в случаи надобности.

Первая часть, рассмотрим как ввести наш сервер в домен.

Авторизация пользователей будет по NTLM.

Для всего нам понадобится apache, php, mysql, сам squid, sams, samba.

Все это нам предстоит установить, или обновить.

Для начало ставим скопом apache, php, mysql:

$ aptitude install apache2 apache2-doc apache2-utils ssl-cert mysql-server libmysqlclient15-dev libapache2-mod-php5 php5 php5-common php5-dev php5-mcrypt php5-imagick php5-mysql

далее …

Для того, чтобы пользователи могли проходить NTLM аутентификацию, необходимо настроить авторизация через Active Directory, и здесь вы будем использовать samba, kerberos, winbind, pam. Настраиваем и введем наш сервер в домен:

1. На всякий случай смотрим что б у нас host ’е было прописано полное имя машины:

$ nano /etc/hosts

2. Устанавливаем и настраиваем Kerberos

$ aptitude install krb5-doc krb5-user krb5-config

в конце процесса установки, установщик спросит у наc два параметра:

на оба запроса вводим наш адрес домен-контроллера(DC)

Далее правим /etc/krb5.conf и приводим его к такому виду (EXAMPLE.COM — наш master.ns.domain ):

$ nano /etc/krb5.conf

Так же можно добавить несколько записий kdc,если это необходимо, так вторым kdc вполне может быть вторичный контроллер домена Active Directory например kdc = ad1.example.com и тд.

Проверяем, берем пользывателя из AD:

$ kinit admin@EXAMPLE.COM
Password for admin@EXAMPLE.COM: ***** $ klist

3. Устанавливаем и настраиваем SAMBA

$ aptitude install winbind samba

Теперь настраиваем winbind, для этого правим файл /etc/samba/smb.conf.

$ nano /etc/samba/smb.conf

Проверяем конфигурацию SAMBA:

$ testparm

Далее правим файл nsswitch.conf

$ nano /etc/nsswitch.conf

Поcле редактирования /etc/samba/smb.conf, не забываем реcтарт samba+winbind

$ /etc/init.d/winbind stop && /etc/init.d/samba restart && /etc/init.d/winbind start

Теперь заведем наш сервер в домен:

$ net ads join -U administrator

или

net ads join -U USER%PASSWD

Теперь для проверки работоспособности winbind проведем ряд тестов.

$ wbinfo -p
Ping to winbindd succeeded $ wbinfo -t
checking the trust secret via RPC calls succeeded Проверить, видит ли Samba группы,пользователей домена можно так: $ wbinfo -u

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

группы:

$ wbinfo -g

Так же можно проверить авторизоваться в домене:

$ wbinfo -a user%password plaintext password authentication succeeded

challenge/response password authentication succeeded

Проверим утилитой id доменного пользователя:

$ id USER

Во второй части поговорим как поставить собственно SQUID SAMS и прикрутить к нему редиректор REJIK

Еще записи по теме

Источник: http://www.itword.net/page/proxy-server-squid-ldap-ad-windows-sams

Squid с авторизацией в AD

#cat /usr/local/etc/squid/squid.conf

# squid conf

# порт где слушаем

http_port 3128

# список слов, которые будучи обнаруженными в URL вызывают обработку без кэширования

hierarchy_stoplist cgi-bin ?

# список ACL которые вызывают несовпадение с кэшем, и, запрос с ответом кэшироваться не будут

acl QUERY urlpath_regex cgi-bin ?

# собственно — правило что не кэшируем

no_cache deny QUERY

# сколько отдаём ему памяти (реально пожрёт втрое больше)

cache_mem 1024 MB

# Директория для кэша, числа — размер кэша в Mb,

# число директорий первого уровня, число директорий второго уровня в каждой директории #первого.

cache_dir ufs /usr/local/squid/cache 1024 16 256

# лог доступа — первый параметр путь, второй — формат форматы описаны в дефолтовом #файле.

access_log /var/log/squid/access.log squid

# лог активности менеджера хранилища. Показывает, какие объекты были #сохранениы/удалены из кэша и как долго.Мне он не нужен, а места занимает прилично.

cache_store_log none

# файл hosts, проверяемый при запуске. Из него берётся доменное имя и добавляется к #неполным адресам (которые не содержат ни одной точки в имени)

hosts_file /etc/hosts

# домен добавляемый к неполным именам

append_domain .mydomain.local

# авторизация

# нативная авторизация ослика

auth_param ntlm program /usr/local/bin/ntlm_auth —helper-protocol=squid-2.5-ntlmssp

# число детишек для авторизации — сколько процессов запускать

auth_param ntlm children 30

# базовая авторизация для тех, кто не может нативную (я, например, т.к. сижу из под #FreeBSD, да и многие программы — например, родной ICQ клиент от AOL)

auth_param basic program /usr/local/bin/ntlm_auth —helper-protocol=squid-2.5-basic

# Число процессов для базовой аворизации — значительно меньше чем для основной, т.к. #таких юзеров/программ немного

auth_param basic children 4

# Заголовок окна выводимяй при запросе авторизации

auth_param basic realm Squid proxy-caching web server

# время жизни авторизации — сколько кэшировать данные (для базовой авторизации)

auth_param basic credentialsttl 2 hours

# внешняя ACL для разруливания по группам

external_acl_type nt_group %LOGIN /usr/local/libexec/squid/wbinfo_group.pl

# пользователи у которых просто интернет — с ограничениями

acl inet_users external nt_group inet_users

# пользователи у которых есть тока аська

acl inet_icq external nt_group inet_icq

# пользователи с полными парвами на доступ в инет

acl inet_full external nt_group inet_full

# люди с доступом к серверу аналитики

acl inet_analit external nt_group inet_analit

# пользователи с ограниченным доступом в инет — тока определённый набор ресурсов и всё.

acl inet_restrict external nt_group inet_restrict

# Пользователи которым разрешён метод CONNECT

acl inet_connect external nt_group inet_connect

# ACL авторизации на проксе

acl MYDOMAIN proxy_auth REQUIRED

# Описываем порты на которые разрешено лазить

acl SSL_ports port 443 563

acl SSL_for_client_banks port 910 8443 4500

Читайте также:  Диск загружен на 100%. диск с используется на 100%. компьютер зависает из-за диска

# порты на которе можно ходить юзерам

acl safe_ports port 80 # http

acl safe_ports port 21 # ftp

acl safe_ports port 443 # ssl

acl ICQ_ports port 5190 # ICQ

# надо ли? 1025-65535

acl CONNECT method CONNECT

# Описываем все сети все IP

acl all src 0.0.0.0/0.0.0.0

# описываем локалхост

acl localhost src 127.0.0.1/255.255.255.255

# acl до сайтов которые разрешены всем

acl mydomain_site dstdomain «/usr/local/etc/squid/db/allow_all.txt»

# запрещённые в URL выражения (для всего УРЛа)

acl bad_url url_regex «/usr/local/etc/squid/db/deny_url.txt»

# запрещённые в URL выражения (для самого урла, без домена)

#acl bad_url_2 urlpath_regex «/usr/local/etc/squid/db/deny_url_2.txt»

# запрещённые доменные имена

acl deny_domains dstdomain «/usr/local/etc/squid/db/deny_domains.txt»

# acl для клиент-банков и прочих кому надо напрямую ходить

acl client_banks dst «/usr/local/etc/squid/db/clinet_banks.txt»

# сети в которые ходить не надо (ICQ и прочия)

acl bad_networks dst «/usr/local/etc/squid/db/bad_networks.txt»

# те кто ходят без авторизации

acl not_autorized src «/usr/local/etc/squid/db/not_autorized.txt»

# список сайтов для тех у кого их определённый набор

acl domains_for_restrict dstdomain «/usr/local/etc/squid/db/domains_for_restrict.txt»

### настройки доступа ####

# выпускаем на неавторизуемые сайты

http_access allow client_banks

# выпускаем тех кто не авторизуется в принципе т.к. они не в домене и т.п.

http_access allow not_autorized

# Разрешаем всем доступ на сайт конторы

# Этим же правилом срубаются все неавторизованные

http_access allow LOCAL mydomain_site

# Разрешаем доступ ко всему группе 'inet_full'

http_access allow inet_full all

# Зарубаем запрещённые куски url

http_access deny bad_url

# Разрешаем асечный порт тем у кого есть аська

http_access allow inet_icq ICQ_ports

# зарубаем запрещённые сети

http_access deny bad_networks

# зарубаем запрещённые домены

http_access deny deny_domains

# Зарубаем коннект кроме как к SSL (надо ли группе отдельной?)

http_access deny CONNECT !SSL_ports

# зарубаем все порты проме safe_ports

http_access deny !safe_ports

# разрешаем инет обычным пользователям

http_access allow inet_users

# разрешаем инет ограниченным пользователям на разрешённые сайты

http_access allow inet_restrict domains_for_restrict

# зарубаем всё

http_access deny all

Источник: http://unix-way.ru/index.php/poleznyashki-freebsd/17-squid-s-avtorizatsiej-v-ad

SQUID с авторизацией в AD

Встала передо мной задача установить и настроить прокси сервер с авторизацией пользователей в Windows Active Directory (AD). Задача довольно распространенная информации по этой теме столько, что все и не перечитать. Поэтому все опишу довольно кратко для себя, в качестве шаблона.

SAMBA

Первым делом ставлю samba сервер. Оттуда нужен, в принципе, только winbind, но samba в хозяйстве пригодится.
# cd /usr/ports/net/samba36 && make install clean После установки samba пишу конфигурационный файл для kerberos.

В AD используется система билетов, которые выдаются доверяемым хостам, включенным в домен. Для реализации этого механизма и правлю /etc/krb5.conf:

[libdefaults] default_realm = DOMAIN.LC [realms] DOMAIN.LC = { kdc = DOMAIN.LC admin_server = DOMAIN.LC } [domain_realm] .domain.lc = DOMAIN.LC [logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log

Говорю, что для проверки пользователей и паролей надо использовать winbind. Добавляю в /etc/nsswitch.conf

group: files winbind passwd: files winbind

Теперь правлю smb.conf

[global] # workgroup = NT-Domain-Name or Workgroup-Name, eg: MIDEARTH workgroup = DOMAIN.LC # server string is the equivalent of the NT Description field server string = # Security mode. Defines in which mode Samba will operate. Possible # values are share, user, server, domain and ads. Most people will want # user level security. See the Samba-HOWTO-Collection for details. security = ADS # This option is important for security. It allows you to restrict # connections to machines which are on your local network. The # following example restricts access to two C class networks and # the «loopback» interface. For more examples of the syntax see # the smb.conf man page hosts allow = 10.73. 127. # If you want to automatically load your printer list rather # than setting them up individually then you′ll need this load printers = no # this tells Samba to use a separate log file for each machine # that connects log file = /var/log/samba/log.%m # Put a capping on the size of the log files (in Kb). max log size = 50 # Use password server option only with security = server # The argument list may include: # password server = My_PDC_Name [My_BDC_Name] [My_Next_BDC_Name] # or to auto-locate the domain controller/s # password server = * ; password server = password server = DC.DOMAIN.LC passdb backend = tdbsam # Use the realm option only with security = ads # Specifies the Active Directory realm the host is part of realm = DOMAIN.LC # Configure Samba to use multiple interfaces # If you have multiple network interfaces then you must list them # here. See the man page for details. ; interfaces = 192.168.12.2/24 192.168.13.2/24 # Browser Control Options: # set local master to no if you don′t want Samba to become a master # browser on your network. Otherwise the normal election rules apply ; local master = no # OS Level determines the precedence of this server in master browser # elections. The default value should be reasonable ; os level = 33 # Domain Master specifies Samba to be the Domain Master Browser. This # allows Samba to collate browse lists between subnets. Don′t use this # if you already have a Windows NT domain controller doing this job ; domain master = yes domain master = no # Preferred Master causes Samba to force a local browser election on startup # and gives it a slightly higher chance of winning the election ; preferred master = yes preffered master = no # Enable this if you want Samba to be a domain logon server for # Windows95 workstations. ; domain logons = yes domain logons = no # WINS Support — Tells the NMBD component of Samba to enable its WINS Server ; wins support = yes wins support = no display charset = koi8-r unix charset = koi8-r dos charset = 866 # DNS Proxy — tells Samba whether or not to try to resolve NetBIOS names # via DNS nslookups. The default is NO. dns proxy = no idmap uid = 10000-20000 idmap gid = 10000-20000 winbind use default domain = yes ;[homes] ; comment = Home Directories ; browseable = no ; writable = yes ; BONUS [all] comment = path = /shares/all read list = «@DOMAINПользователи домена» write list = «@DOMAINПользователи домена» admin users = «@DOMAINАдминистраторы домена» read only = no map acl inherit = yes map archive = no map read only = no create mask = 0660 directory mask = 0770 force unknown acl user = yes delete readonly = yes

Для получения тикета кербероса выполняю:
# kinit egoad где egoad — пользователь в домене. Теперь ввожу машину в домен:

# net join -U egoad

при этом egoad должен иметь права для ввода машин в домен (обычно администраторы домена). Проверяю, получает ли winbind информацию о пользователях домена:

# id egoad

uid=10000(egoad) gid=10004(пользователи домена) groups=10004(пользователи домена)

Создаю директорию для шар и задаю ей права:
# mkdir /shares && mkdir /shares/all && chown -R egoad:»Администраторы домена» /shares Прописываю самбу в rc.conf и стартую ее:

# echo 'samba_enable=»YES»' >> /etc/rc.conf
# /usr/local/etc/rc.d/samba start

Для тонкой настройки придется идти на samba.org или что нибудь близкое по наполнению =)

SQUID

Теперь перехожу непосредственно к Squid:
# cd /usr/ports && make search name=squid3 Port: squid-3.1.15_1 Path: /usr/ports/www/squid31 Info: HTTP Caching Proxy Maint: *protected email* B-deps: perl-5.12.4_2 R-deps: perl-5.12.4_2

WWW: http://www.squid-cache.org/

Обязательно:

# chown root:squid /var/db/samba/winbindd_privileged

Теперь конфиг /usr/local/etc/squid/squid.conf:auth_param ntlm program /usr/local/bin/ntlm_auth —helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 5 auth_param ntlm keep_alive on authenticate_cache_garbage_interval 15 minute authenticate_ttl 5 minute auth_param basic program /usr/local/bin/ntlm_auth —helper-protocol=squid-2.5-basic auth_param basic children 5 auth_param basic realm Squid Proxy-Server auth_param basic credentialsttl 20 minute auth_param basic casesensitive off #acl USERS proxy_auth REQUIRED external_acl_type nt_group %LOGIN /usr/local/libexec/squid/wbinfo_group.pl # # Recommended minimum configuration: # acl manager proto cache_object acl localhost src 127.0.0.1/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # __ USERS ACL __/ acl inet_all external nt_group OIT # # Recommended minimum Access Permission configuration: # # Only allow cachemgr access from localhost http_access allow manager localhost http_access deny manager # Deny requests to certain unsafe ports http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on «localhost» is a local user http_access deny to_localhost # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed #http_access allow localnet http_access allow localhost # __ ACCESS TO INET __/ http_access allow inet_all # And finally deny all other access to this proxy http_access deny all # Squid normally listens to port 3128 http_port 3128 # Uncomment and adjust the following to add a disk cache directory. #cache_dir ufs /var/squid/cache 100 16 256 # Leave coredumps in the first cache dir coredump_dir /var/squid/cache # Add any of your own refresh_pattern entries above these. refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|?) 0 0% 0 refresh_pattern . 0 20% 4320

Из всего описанного выше хочу выделить

auth_param ntlm program /usr/local/bin/ntlm_auth —helper-protocol=squid- 2.5-ntlmssp auth_param ntlm children 5 auth_param ntlm keep_alive on authenticate_cache_garbage_interval 15 minute authenticate_ttl 5 minute auth_param basic program /usr/local/bin/ntlm_auth —helper-protocol=squid-2.5-basic auth_param basic children 5 auth_param basic realm Squid Proxy-Server auth_param basic credentialsttl 20 minute auth_param basic casesensitive off

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

external_acl_type nt_group %LOGIN /usr/local/libexec/squid/wbinfo_group.pl

Скрипт проверяет группу пользователя в AD.
Далее AD группу OIT обзываю inet_all

acl inet_all external nt_group OIT

Прописываю доступ для inet_all

Источник: http://jnotes.ru/squid-autorization-in-ad.html

Kerberos авторизация в SQUID на базе LDAP групп Active Directory

#image.jpgПриветствую, гости и читатели моего блога о Linux. Продолжаем расширять возможности squid. На данный момент попытаемся воплотить авторизацию доменных учеток Active Directory на базе их членства в группах.

В статье будет задействовано новая для меня разработка, в какой я пока не очень соображаю — LDAP. Поэтому о ней пока будет поведано «вскользь». Для того, чтобы у вас заработала данная схема, необходимо ознакомиться со статьями:

  • Прокси-сервер SQUID, вводный пост
  • Аутентификация и авторизация юзеров squid
  • squid, настройка ограничений скорости (delay pools)

Без данных статей и понимания принципов работы squid — никак #image.jpg

Что такое LDAP в Active Directory (Введение)

Т.к. LDAP пока для меня — это малая затаенна. Расскажу, что знаю… Итак, LDAP — это некий каталог (дословно — lightweight directory access protocol, в переводе — облегчённый протокол доступа к каталогам), который хранит в себе различную информацию в древовидной форме и имеет структуру, на нашем примере (на примере домена AD.LOCAL):  #image.jpg

Читайте также:  Defraggler как пользоваться. программа для дефрагментации жесткого диска.

Давайте разберем что к чему… В голове структуры — имя домена (AD.LOCAL), «в руководстве» у домена — отделы (т.н. организационные единицы), у каждого отдела могут быть в руководстве другие отделы.

Не считая того, в хоть какой отдел (в том числе и в корневой контейнер — домен) могут входить некие элементы — группы, пользователи, принтеры и др.

, которые «в себе» могут хранить некоторые функции —  атрибуты объекта (например, у пользователя — пароль, имя, адрес почты и др.).

У каждой записи в LDAP, будь то объект или контейнер с объектами внутри имеется уникальное для всего каталога LDAP имя (т.н.  англ. Distinguished Name (DN) — Отличительное имя).

Это даже не имя, а путь, характеризующий полный путь к этом этой записи во всей иерархии. Уникальный путь может смотреться (на примере группы squid), следующим образом: «cn=squid, ou=groups, ou=UNIXs,  dc=ad, dc=local».

Уникальное имя состоит из 1-го или нескольких относительных отличительных имен (RDN — англ. Relative Distinguished Name), разделённых запятой.

Относительное уникальное имя имеет вид ИмяАтрибута=значение (например cn=squid ).

На одном уровне каталога не может существовать 2-ух записей с похожими относительными уникальными именами (при всем этом, в Active Directory имеются некоторые дополнительные ограничения, например, не может быть пользователя с похожим именованием во всем дереве).

Давайте разберем приведенный путь. Данный путь стОит читать с конца.

Он начинается с описания домена, в каком расположен каталог и обозначается как dc=ad, dc=local, здесь — имя dc (оно же Domain Component – компонент доменного имени) задает имя домена, другими словами если бы у нас был домен, например subdomain.ad.local, то данный кусок отличительного имени смотрелся бы как   dc=subdomain, dc=ad, dc=local.

 Дальше описывается структура иерархия контейнеров отделов (они же OU, они же Organization Unit — организационная единица или подразделение), которые представляет собой  ou=groups, ou=UNIXs. Это стоит читать так же с конца, другими словами в текущем домене есть некий контейнер UNIXs, в каком есть подконтейнер groups.

Если бы подходящий нам объект находился в отделе, например, Склады, то текущий кусок DN (Distinguished Name) смотрелся бы следующим образом:  ou=Склады, ou=groups.

Далее мы видим в DN описание определенной записи (в данном случае — запись — это группа squid).

Кусок, DN пути, описывающий группу представляет собой строку cn=squid, где CNCommon Name — общее (относительное) имя (Пользователь, контакт, группа или другой объект, который обычно не имеет дочерних объектов).

Думаю, что общую структуру объяснил понятно. Этого понимания, думаю, будет достаточно для реализации Kerberos LDAP авторизации на базе группы Active Directory.

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

Настройку squid на Kerberos аутентификацию необходимо сделать, согласно статьи Negotiate — метод аутентификации в squid. После функции Kerberos аутентификации у нас начинает работать некий прокси-сервер squid, который аутентифицирует доменных юзеров. Представим, что он имеет некий конфиг:

Источник: http://hpunix.org/howto/kerberos-avtorizacija-v-squid-na-baze-ldap-grupp.html

Squid active directory authentication

В этой статье будет описан принцип настройки аутентификации пользователей на proxy сервере squid. Иными словами, перед тем как получить доступ в интернет, пользователь обязан предоставить свой логин и пароль, который squid будет искать в базе active directory. Для поиска будут задействованы следующие схемы проверки подлинности: Basic, NTLM и Negotiate.

  • Basic — самая простая схема аутентификации. Пользователь открывает браузер и ему предлагается ввести свой логин и пароль. Информация передается в открытом виде.
  • NTLM — схема, использующая одноименный протокол аутентификации разработанный Microsoft. В случае с NTLM информация шифруется. Так же доменному пользователю не нужно вводить логин и пароль при каждом открытии браузера. Используются данные, указанные при входе в систему.
  • Negotiate — данная схема в зависимости от доступности выбирает протокол сетевой аутентификации Kerberos или проверку подлинности NTLM. Kerberos является более совершенный по сравнению с NTLM. Так же как в NTLM, при Kerberos аутентификации используются данные, указанные при входе в систему.

Установка squid будет производиться на Ubuntu Server 16.04.1 LTS. Версия squid 3.5.12.

Базовая настройка

После установки системы изменим имя сервера на proxy

# hostnamectl set-hostname proxy

Укажем полное имя сервера в файле hosts

# nano /etc/hosts 127.0.0.1 localhost 127.0.1.1 proxy.4skill.loc proxy . . .

Настроим сетевое подключение

# nano /etc/network/interfaces . . . # The primary network interface auto ens32 iface ens32 inet static address 192.168.1.23 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.21 192.168.1.22 dns-search 4skill.loc

В dns-nameservers нужно указать IP адреса доменных DNS серверов. В dns-search название своего домена. Более подробно о настройке сети можно прочитать здесь.

Перезагрузим систему

# reboot

Обновим индексы пакетов и систему

# apt update # apt upgrade

Более подробно об обновлении Ubuntu Server можно прочитать здесь.

Для синхронизации времени с контроллерами домена установим пакет ntp

# apt install ntp

В /etc/ntp.conf нужно закоментировать все строки начинающиеся со слова pool и добавить информацию о контроллерах домена

# nano /etc/ntp.conf . . . # Specify one or more NTP servers. # Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board # on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for # more information. #pool 0.ubuntu.pool.ntp.org iburst #pool 1.ubuntu.pool.ntp.org iburst #pool 2.ubuntu.pool.ntp.org iburst #pool 3.ubuntu.pool.ntp.org iburst # Use Ubuntu's ntp server as a fallback. #pool ntp.ubuntu.com # Domain Controllers server dc1.4skill.loc server dc2.4skill.loc . . .

Перезапустим ntp сервис и проверим статус синхронизации времени

# service ntp restart # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== dc1.4skill.loc 82.199.107.209 3 u 3 64 1 0.467 8.206 0.000 dc2.4skill.loc 192.168.1.21 5 u 1 64 1 0.916 256.769 0.000

Установим proxy сервер squid

# apt install squid

Создадим копию конфигурационного файла squid. Из оригинального файла удалим комментарии и пробелы

# cp /etc/squid/squid.conf /etc/squid/squid.conf.orig # grep -v «^#» /etc/squid/squid.conf.orig | grep -v «^$»> /etc/squid/squid.conf

Настройка basic и ntlm схем

Для ввода сервера в домен потребуется пакет samba. Так же в состав samba входят хелперы, которые будут использованы для basic и ntlm схем аутентификации в squid. Вместе с samba нужно установить пакет winbind. Он нужен для использования доменных групп и пользователей на linux сервере.

# apt install samba winbind

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

# service nmbd stop && service smbd stop # update-rc.d -f nmbd remove && update-rc.d -f smbd remove

Отредактируем конфигурационный файл samba

# nano /etc/samba/smb.conf [global] security = ADS workgroup = 4SKILL realm = 4SKILL.LOC # Default idmap config for local BUILTIN accounts and groups idmap config * : backend = tdb idmap config * : range = 3000-7999 # idmap config for the 4SKILL domain idmap config 4SKILL : backend = rid idmap config 4SKILL : range = 10000-999999 winbind use default domain = Yes

4SKILL нужно поменять на свой домен.

Проверим конфигурационный файл samba на наличие ошибок

# testparm Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER

Чтобы убрать предупреждение

rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)

Выполним команду

# ulimit -n 16384

И добавим в /etc/security/limits.conf следующие строки

# nano /etc/security/limits.conf . . . * — nofile 16384 root — nofile 16384 . . .

Введем proxy сервер в домен

# net ads join -U Administrator osName='Ubuntu Server GNU/Linux' osVer='16.04 LTS' Enter Administrator's password: Using short domain name — 4SKILL Joined 'PROXY' to dns domain '4skill.loc'

Перезапустим winbind и проверим базовый функционал

# service winbind restart # wbinfo -t checking the trust secret for domain 4SKILL via RPC calls succeeded

Проверим аутентификацию пользователей через winbind

# wbinfo -a 4skill\administrator Enter 4skilladministrator's password: plaintext password authentication succeeded Enter 4skilladministrator's password: challenge/response password authentication succeeded

Для нормального функционирования ntlm аутентификации, пользователь, от имени которого работает squid, должен входить в группу winbindd_priv

# gpasswd -a proxy winbindd_priv Adding user proxy to group winbindd_priv

В Ubuntu и Debian каталог winbindd_privileged создается в двух местах

# ls -la /var/lib/samba/winbindd_privileged итого 8 drwxr-x— 2 root root 4096 янв 19 14:45 . drwxr-xr-x 6 root root 4096 янв 19 14:45 .. srwxrwxrwx 1 root root 0 янв 19 14:45 pipe root@proxy:~# ls -la /var/run/samba/winbindd_privileged итого 0 drwxr-x— 2 root winbindd_priv 40 янв 19 14:36 . drwxr-xr-x 9 root root 480 янв 19 14:48 ..

Группу /var/lib/samba/winbindd_privileged нужно изменить по аналогии с /var/run/samba/winbindd_privileged на winbindd_priv

# chgrp -R winbindd_priv /var/lib/samba/winbindd_privileged root@proxy:~# ls -la /var/lib/samba/winbindd_privileged итого 8 drwxr-x— 2 root winbindd_priv 4096 янв 19 14:45 . drwxr-xr-x 6 root root 4096 янв 19 14:45 .. srwxrwxrwx 1 root winbindd_priv 0 янв 19 14:45 pipe

Протестируем basic аутентификацию.

# /usr/bin/ntlm_auth —helper-protocol=squid-2.5-basic 4skilladministrator Pa$$w0rd OK

Ntlm аутентификацию протестировать из командой строки невозможно.

Добавим в /etc/squid/squid.conf поддержку basic и ntlm схем аутентификации, а так же сопутствующий ACL

# nano /etc/squid/squid.conf auth_param ntlm program /usr/bin/ntlm_auth —helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 100 startup=10 idle=5 auth_param ntlm keep_alive off auth_param basic program /usr/bin/ntlm_auth —helper-protocol=squid-2.5-basic auth_param basic children 10 startup=1 idle=1 auth_param basic realm 4SKILL.LOC auth_param basic credentialsttl 1 hours . . . acl auth proxy_auth REQUIRED . . . http_access allow localhost http_access allow auth http_access deny all . . .

Перезапустим squid

# squid -k reconfigure

На клиентском компьютере заходим в «Пуск»->»Панель управления»->»Свойства браузера»->вкладка «Подключения»->кнопка «Настройка сети». Ставим галочку «Использовать прокси сервер…» и указываем «Адрес:proxy.4skill.loc Порт:3128«, нажимаем «Ок»

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

Настройка negotiate схемы

Для аутентификации proxy сервера на контроллере домена и последующей идентификации пользователей, необходимо создать файл keytab.

Этот файл содержит в себе Kerberos Principal (хост, пользователь и домен) и ключи шифрования (определяются из пароля Kerberos).

Перед созданием keytab файла, в домене необходимо создать пользователя для proxy сервера. Для этого откроем на контроллере домена powershell и выполним команду

PS C:> New-ADUser -Name squid -AccountPassword (ConvertTo-SecureString -AsPlainText 'Pa$$w0rd' -Force) -PasswordNeverExpires $true -Enabled $true -Description «Системный пользователь для работы squid»

Создадим keytab файл. Для этого на контроллере домена откроем от имени администратора CMD и выполнить команду

C:>ktpass -princ HTTP/proxy.4skill.loc@4SKILL.LOC -mapuser 4SKILLsquid -pass Pa$$w0rd -ptype KRB5_NT_PRINCIPAL -out C:squid.keytab Targeting domain controller: DC1.4skill.loc Using legacy password setting method Successfully mapped HTTP/proxy.4skill.loc to squid. Key created. Output keytab to C:squid.keytab: Keytab version: 0x502 keysize 67 HTTP/proxy.4skill.loc@4SKILL.LOC ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x92937945b518814341de3f726500d4ff)

Для передачи keytab файла на proxy сервер, нужно скачать утилиту pscp, положить её в корень диска C. Открыть CMD и выполнить команду

C:>pscp.exe squid.keytab username@proxy.4skill.loc: Store key in cache? (y/n) y username@proxy.4skill.loc's password: squid.keytab | 0 kB | 0.1 kB/s | ETA: 00:00:00 | 100%

username — пользователь, под которым настраивается proxy сервер.

На proxy сервере переместим keytab файл в каталог /etc/squid/ и выставим права

# mv ~/squid.keytab /etc/squid/ # chown proxy:proxy /etc/squid/squid.keytab # chmod 400 /etc/squid/squid.keytab

Укажем squid где искать keytab файл

# nano /etc/default/squid KRB5_KTNAME=/etc/squid/squid.keytab export KRB5_KTNAME

Для поддержки Kerberos установим следующий пакет

# apt install krb5-user

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

# nano /etc/krb5.conf [libdefaults] default_realm = 4SKILL.LOC dns_lookup_realm = false dns_lookup_kdc = true default_keytab_name = /etc/squid/squid.keytab

В default_realm нужно указать название своего домена.

Попробуем получить билет Kerberos для proxy сервера

Источник: https://4skill.ru/squid-active-directory-authentication/

Ссылка на основную публикацию