Ключевые слова:squid, auth, win, (найти похожие документы)
From: Рашид Ачилов
Newsgroups: email
Date: Mon, 22 Nov 2004 14:31:37 +0000 (UTC)
Subject: Авторизация Windows-пользователей в SQUID на основе их доменных аккаунтов
--------------------------------------------------------------------
Статья опубликована в журнале "Системный администратор", ╧10, 2004г.
http://www.samag.ru/
Вы можете подписаться на журнал в любом почтовом отделении связи.
Подписной индекс 81655 по каталогу "Роспечать",
87836 по каталогу "Пресса России".
--------------------------------------------------------------------
Настройка squid для использования авторизации из домена Windows 2000
Рашид Ачилов
Постановка задачи
Предположим, имеется компьютерная сеть на базе домена Windows NT или
2000, выходящая в Интернет исключительно через прокси-сервер,
расположенный на компьютере под управлением операционной системы
FreeBSD. Рано или поздно возникает необходимость контролировать доступ
пользователей прокси-сервера к различным объектам. Первое, что приходит
в голову в таких случаях - разделение доступа по IP-адресам компьютеров.
Этот способ достаточно просто реализуется с помощью несложного набора
ACL в конфигурационном файле squid.conf, но он обладает одним весьма
существенным недостатком - невозможно без привлечения дополнительных
ресурсов однозначно сказать, какой пользователь в данный момент имел
доступ к данному ресурсу.
Более удобным для администратора является способ, когда каждый
пользователь идентифицируется и получает доступ к прокси только при
наличии действующей регистрационной записи в домене Windows (и возможно,
только при вхождении в определенную группу домена). Варианты настроек
прокси-сервера, обеспечивающие получение регистрационного имени
пользователя, запросившего данный ресурс, и будут рассмотрены в данной
статье. (Оставим пока в стороне вопрос о том, что делать с этой
информацией - расчет статистики загрузки канала и отображения ее - это
тема для отдельной статьи).
Для моделирования ситуации использовалась следующая конфигурация:
- Домен на базе Windows 2000 Server.
- Прокси-сервер Squid 2.5-STABLE6 на базе FreeBSD 4.10-STABLE.
- Samba 2.2.11 и Samba 3.0.6.
Все программы собирались с помощью портов, в Makefile которых при
необходимости вносились изменения. Данные изменения не затрагивали
каталоги для размещения файлов порта.
Все команды в данной статье запускаются от имени пользователя root. Если
для выполнения команды достаточно привилегий рядового пользователя, это
оговаривается заранее.
Squid 2.5 и Samba 2.2.x
Первый рассматриваемый вариант - предоставление доступа к прокси-серверу
при условии наличия действующей учетной записи в домене Windows с
использованием пакета Samba 2.2.x. Версия Samba здесь имеет
принципиальное значение, поскольку с различными версиями пакета samba
необходимо использовать различные варианты внешних аутентификаторов для
squid.
Для проверки имени и пароля пользователя, переданных Squid, мы будем
использовать аутентификаторы wb_ntlmauth и wb_auth, которые собираются
вместе со Squid, если задать их сборку. Для задания сборки данных
аутентификаторов следует добавить "winbind" в строки
--enable-basic-auth-helpers="список"
--enable-ntlm-auth-helpers="список"
в строке CONFIGURE_ARGS порта squid.
В последней на данный момент версии порта (1.138 от 21.08.2004) эти
параметры заданы по умолчанию. Если имеются исходные тексты Samba, то
можно указать их расположение параметром
--with-samba-sources=<полный путь>,
например:
--with-samba-sources=/usr/ports/net/samba/work/samba-2.2.11
иначе Squid будет использовать часть исходных текстов Samba,
распространяемых вместе с ним. Если сборка выполняется не с помощью
портов, а самостоятельно (что крайне не рекомендуется делать), то
следует добавить к строке запуска configure эти параметры:
./configure --enable-auth="basic ntlm"
--enable-basic-auth-helpers="winbind"
--enable-ntlm-auth-helpers="winbind" ... <другие параметры порта, если необходимы>
После сборки и установки порта в каталоге /usr/local/libexec должны
появиться файлы wb_ntlmauth и wb_auth.
Аутентификатор для проверки имени и пароля, переданного от Squid,
обращается к демону winbindd, который должен быть запущен на данном
компьютере. Для обеспечения работоспособности данной схемы Samba, в
состав которой входит winbindd, должна быть собрана со следующими
параметрами:
make WITH_WINBIND=yes WITH_WINBIND_AUTH_CHALLENGE=yes
Если сборка самбы выполняется не через порты, а самостоятельно (что не
рекомендуется делать), то к строке запуска configure следует добавить
следующие параметры:
./configure - with-winbind - with-winbind-auth-challenge ... <другие параметры порта, если надо>
Данная строка задает только сборку Samba безотносительно наличия на
компьютере Squid. Если Samba уже была установлена и собиралась без
указанных параметров, ее необходимо пересобрать.
По окончании сборки и установки порта в каталоге /usr/ local/sbin должна
появиться программа winbindd, а в каталоге /usr/local/bin - wbinfo,
которая служит для "общения" с winbindd и получения от него информации.
После запуска самбы следует проверить работоспособность winbindd
следующим образом:
granch:[Shelton] 101>wbinfo-p
Ding to winbindd succeeded on fd 3
granch:[Shelton] 104>wbinfo-t
checking the trust secret via RPC calls succeeded
Первая команда проверяет, работает ли winbindd. Вторая - что учетная
запись компьютера, на котором запущен winbindd, добавлена в домен и
имеет доступ к базе данных домена. Для выполнения данной команды
достаточно прав пользователя, имеющего доступ к каталогу /var/db/samba/
winbindd_privileged. Если вывод программ отличается от приведенного,
следует обратиться к документации по samba для выяснения причины, почему
winbindd неработоспособен, устранить эти причины и повторять
тестирование до тех пор, пока не будет получен успешный результат.
Наиболее общими причинами являются:
- winbindd не запущен (несмотря на всю тривиальность данной причины);
- компьютер не включен в домен Windows, который указан в параметре
workgroup конфигурационного файла Samba (не выполнялась команда
smbpasswd -j MYDOMAIN для samba 2.x или net rpc join <type> -w MYDOMAIN
для samba 3.x).
Наконец вся предварительная работа выполнена, можно переходить к
настройке Squid.
В файле squid.conf после тега auth_param (для версии 2.5.STABLE6 это
строка 1000) идет длинный-длинный комментарий к данному параметру. Там
расписаны все параметры для всех схем авторизации, а ниже всего этого
описания (а оно достаточно объемное - почти полторы сотни строк) идут
строки с параметрами программ аутентификации, отмеченные символом "#" в
первой позиции, распознаваемым как признак комментария. В данных строках
не вписана только собственно программа. Сделано это намеренно, для того
чтобы человек, который возьмется настраивать эти параметры, понимал, что
он делает.
Для того, чтобы наша схема работала, убираем символ "#" из первой
позиции и изменяем следующие строки файла squid.conf:
auth_param ntlm program /usr/local/libexec/wb_ntlmauth
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param basic program /usr/local/libexec/wb_auth auth_param basic children 5
auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours
после чего необходимо будет перезапустить прокси-сервер.
Что мы сделали:
первые четыре строки описывают хелпер аутентификации wb_ntlmauth,
который предназначен для работы с браузером Microsoft Internet Explorer,
а также с другими браузерами, распознающими конструкции вида
MYDOMAIN\myusername (еще к браузерам такого типа относятся
Mozilla/Firefox);
остальные строки описывают хелпер аутентификации wb_auth, который
предназначен для проверки имени и пароля, передаваемого со стандартного
ввода с помощью winbindd. Это позволяет использовать любые браузеры -
как графические, так и нет (lynx, например).
Обращаю внимание на следующие моменты: Строки в конфигурационном файле
должны стоять в том же порядке, что и в примере, приведенном выше. По
умолчанию дело обстоит именно так. Обьясняется это одним странным
свойством браузера Microsoft Internet Explorer - он способен
использовать только первый описанный хелпер. Если первым описать хелпер
wb_auth, Explorer доступ к прокси-серверу получить не сможет.
Необходим будет полный перезапуск через останов сервера и его
последующий старт. Команды squid -k reconfigure недостаточно, поскольку
при изменении параметров аутентификации squid выгружает и загружает
хелперы аутентификации самостоятельно.
Кроме того, необходимо изменить правила получения доступа к
прокси-серверу таким образом, чтобы доступ предоставлялся только в
случае, если пользователь ввел имя и пароль действительной записи в
домене Windows.
Для этого в файл squid.conf следует добавить следующие строки:
acl NTLMauth http_access
proxy_auth allow
REQUIRED NTLMauth
Первая строка создает правило, согласно которому:
Доступом к прокси-серверу управляет внешняя программа (программы),
описанная в секции auth_param (см. выше описание данного параметра).
Если какая-либо из программ завершается с ошибкой, отсутствует или дает
отрицательный ответ, то вызывается следующая по списку, пока не будут
просмотрены все присутствующие в файле squid.conf строки auth_param.
Для доступа к прокси-серверу необходим положительный ответ от
программы-аутентификатора (хелпера), иначе доступ предоставлен не будет.
Завершение с ошибкой, отсутствие или отрицательный ответ всех хелперов
считаются отрицательным результатом и являются основанием для отказа в
доступе.
Вторая строка разрешает доступ к прокси только в том случае, если
проверка правила NTLMauth, описанного в первой строке, завершилась
успешно.
Проверяем.
Запустив любой браузер, кроме Internet Explorer, пытаемся посетить
какой-нибудь сайт. Получаем запрос на ввод имени и пароля. Вводим (для
того чтобы не вводить его постоянно в Mozilla/Konqueror, например, есть
режим хранения паролей, при котором во все последующие разы достаточно
нажать "ОК"). Получаем доступ к сайту. Смотрим файл регистрационного
журнала access.log прокси-сервера и видим в конце строки, там где всегда
было пусто, введенное нами имя пользователя.
Запускаем Internet Explorer. Пароль вводить не надо -Internet Explorer
обладает "неестественным" интеллектом и передаст его сам. Получаем
доступ к сайту. Смотрим файл регистрационного журнала access.log
прокси-сервера и видим...
Здесь мы сталкиваемся с двумя вполне безобидными, но способными поначалу
озадачить особенностями Internet Explorer - во-первых, автоматическая
передача регистрационного имени и пароля пользователя происходит только
на третий запрос бразуера, после того как он дважды получает в ответ:
TCP_DENIED/407, а во-вторых, регистрационное имя передается в форме
MYDOMAIN\myusemame, что потребует потом его дальнейшей обработки, потому
что регистрационное имя, передаваемое прочими браузерами, не содержит
Windows-домена.
Squid 2.5 и Samba 3.x
Несколько усовершенствуем нашу систему. Все бы в ней ничего, но есть как
минимум один момент, который может потребовать доработок. Он связан с
тем, что Samba Team официально прекращает поддержку ветки 2.2.x с 1
октября 2004 г. для того, чтобы сосредоточить все усилия на ветке 3.x и
перспективной 4.x. Это означает то, что обнаруженные ошибки исправляться
не будут, вне зависимости от их степени опасности. Поэтому мы
заблаговременно отказываемся в нашей системе от Samba 2.2.11 и переходим
на Samba 3.x.
Samba 3.x - это новый продукт Samba team, который содержит огромное
количество изменений (и примерно та кое же количество ошибок) по
сравнению с Samba 2.2.x. Squid еще не умеет работать с winbindd-демоном
от Samba 3.x, поэтому Samba Team поставляет собственную версию хелпера
аутентификации для использования его в Squid -ntlm_auth. Поэтому при
сборке Squid безразлично, что будет задано в качестве параметров
--enable-basic-auth-helpers и --enable-ntlm-auth-helpers. Для сборки
Samba как обычно следует указать:
make WITH_WINBIND=yes
при сборке через порты либо:
./configure --with-winbind ... <прочие параметры, если надо>
После сборки порта в каталоге /usr/local/bin должен появиться файл
ntlm_auth. Для него существует руководство (мануал) в отличие от тех
хелперов, что поставляются вместе со Squid, можете посмотреть, набрав
man ntlm_auth.
Как обычно, сначала убеждаемся, что winbindd запущен и Samba
сконфигурирована нормально, запустив wbinfo -p и wbinfo -t (пример
вывода программ и рекомендации, что делать, если вывод не совпадает,
приведен выше).
Можно переходить к изменению конфигурационного файла 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 max_challenge_reuses 0 auth_param ntlm
max_challenge_lifetime 2 minutes
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-caching web server auth_param basic redentialsttl 2 hours
Более подробную информацию о параметрах хелпера htlm_auth можно получить
из команды man ntlm_auth.
Как обычно, следите за тем, чтобы ntlm_auth в /usr/local/ bin был из
сборки Samba, потому что Squid тоже собирает свой собственный хелпер
ntlm_auth (-enable-ntlm-auth-helpers="SMB"). Но хелпер Squid не умеет
работать с winbindd, входящим в комплект Samba 3.x. И конечно, хелпер,
обслуживающий запросы Internet Explorer, должен располагаться перед
хелпером, принимающем пароль со стандартного ввода.
Отличительной (и приятной) особенностью работы данного хелпера является
то, что при общении с Internet Explorer имя пользователя передается в
лог без доменной части (myusername вместо MYDOMAIN\myusername при
взаимодействии с хелперами, входящими в комплект Squid).
Стоит отметить еще одну особенность данного хелпера - для нормальной
работы ему необходим доступ к pipe winbindd, который по умолчанию
располагается в /var/db/ samba/winbindd_privileged. Собственно pipe
имеет права 0777, но каталог, в котором он находится, имеет права 0750.
Для решения этой проблемы достаточно изменить группу пользователей
каталога winbindd_privileged на squid:
chown root:squid /var/db/samba/winbindd_privileged
Squid 2.5, Samba и наличие пользователей в определенной группе
Модифицируем нашу систему дальше. Сделаем так, чтобы пользователь мог
получить доступ к прокси-серверу, только если его учетная запись
находится в группе My Proxy. Для решения этой проблемы можно
использовать как стандартные аутентификаторы прокси-сервера (ntlm_auth и
wbinfo_group), так и аутентификатор ntlm_auth из комплекта сборки Samba.
Рассмотрим каждый вариант.
Использование аутентификаторов из комплекта прокси-сервера
Для того чтобы использовать аутентификаторы прокси-сервера вместе с
Samba (версия не имеет значения), необходимо использовать другие
программы-хелперы.
Для использования хелперов из комплекта прокси-сервера задача аутентификации
разбивается на две части -используется хелпер ntlm_auth и внешняя
программа wbinfo_group.pl, представляющая из себя скрипт на языке Perl.
Перестраиваем конфигурацию аутентификаторов следующим образом:
auth_param ntlm program /usr/local/libexec/ntlm_auth
MY_DOMAIN\\dconeMY_DOMAIN\\dctwo auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes
auth_param basic program /usr/local/libexec/wb_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
Здесь dcone и dctwo - соответственно первый и второй контроллеры домена
(имеются в виду NetBIOS-имена). Следует заметить, что здесь мы меняем
только конфигурацию для браузеров, которые умеют работать с
конструкциями MY_DOMAIN\myname и не меняем конфигурацию для прочих
браузеров. Кроме того, в секцию external_acl_type мы добавляем
дополнительную внешнюю программу wbinfo_ group.pl (для установки данной
программы следует указать:
--with-external-acl-helpers="wbinfo group"
в строке запуска configure при сборке прокси-сервера, последняя версия
Makefile в портах установит его по умолчанию) таким образом:
external acl type ntgroup concurrency=5%LOGIN
/usr/local/libexec/wbinfo_group.pi
Что мы сделали: задали использование внешней программы-аутентификатора,
с именем ntgroup (будет использоваться при задании ACL), пять
одновременно работающих копий в памяти, передаваться ей будет
регистрационное имя, в ответ программа должна вернуть ОК или ERR, в
зависимости от проверяемого условия.
Кроме того, изменяем условие предоставления доступа к прокси-серверу на
следующее:
acl NTDCgroup external ntgroup Internet
acl NTLMauth proxy_auth REQUIRED
http_access allow NTLMauth NTDCgroup
С условием NTLMauth мы уже знакомы - оно задает представление доступа
только в случае успешного возврата от хелперов аутентификации. Условие
NTDCgroup задает вызов внешней программы, описанной в условии ntgroup,
при этом в качестве параметра внешней программе передается имя группы,
вхождение в которую должно быть проверено. В данном примере это группа
Internet. Доступ к прокси будет предоставлен только в случае
одновременного выполнения обоих условий.
Достоинством данного метода является независимость его от версии Samba -
wb_ntlmauth и wbinfo_group работают путем передачи команд демону
winbindd - можно спокойно перейти с версии Samba 2.x на версию 3.x и не
заметить момент перехода.
Использование аутентификаторов из комплекта Samba (только Samba 3.x)
Поскольку хелперы прокси-сервера не умеют работать с winbindd демоном из
сборки Samba 3.x, рекомендуется отказаться от их применения и
использовать хелпер ntlm_auth из сборки прокси-сервера (не путать с
одноименным хелпером из сборки Samba! Хелпер прокси-сервера обычно лежит
в /usr/local/libexec, а хелпер Samba - в /usr/local/bin). Кроме того,
использование wbinfo_group.pl имеет один отрицательный момент - это
скрипт, он написан на языке Perl, следовательно, в оперативной памяти
постоянно находится некоторое количество копий процесса perl,
интерпретирующего скрипт.
Отказ от wbinfo_group.pl позволит сократить объем требуемой памяти.
Использование аутентификаторов из комплекта Samba значительно проще: не
нужно никаких внешних программ, не нужно никаких дополнительных правил -
сам хелпер ntlm_auth имеет параметр -require-membership-of="Group".
Поэтому возвращаем наше правило, регулирующее доступ к прокси-серверу, к
виду, описанному в разделе "Samba 2.5 и Samba 2.2.x".
http_access allow NTLMauth
и заменяем хелперы из поставки squid на хелпер ntlm_auth из поставки
samba следующим образом:
auth_param ntlm program /usr/local/bin/ntlm_auth
--helper-protocol=squid-2.5-ntlmssp \
--require-membership-of="MYDOMAIN+My Proxy"
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param basic program /usr/local/bin/ntlm_auth
--helper-protocol=squid-2.5-basic \ --require-membership-of="MYDOMAIN+MyProxy"
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
Здесь "My Proxy" - группа, присутствие в которой дает право пользоваться
прокси-сервером. На что следует обратить внимание - в значении параметра
-require-membership-of задана запись "MYDOMAIN+My Proxy". В этой записи
"My Proxy" - название группы, а знак "+" - это значение параметра
"winbind separator" из конфигурационного файла Samba smb.conf. В
сервере, на котором проводилось тестирование, параметр задан следующим
образом:
winbind separator = +
Если у вас используется другой символ, его следует указывать вместо
знака "+" (в противном случае хелпер не сможет определить принадлежность
к группе и пользователь не получит доступа к прокси в конечном итоге).
Следует иметь в виду, что данное значение параметра winbind separator не
является значением по умолчанию для самбы. По умолчанию значением
является "\" (обратная косая черта). Но использование этого символа в
командах, передаваемых в shell, как правило, чревато необходимостью
"защищать" его от того, чтобы shell не воспринял его как служебный,
поэтому был выбран другой символ. Хотя, например, man smb.conf не
рекомендует использовать именно "+" чтобы избежать возможных проблем с
NIS.
Если какой-либо из приведенных способов не работает
Отнюдь не факт, что любой описанный здесь метод заработает с первого
раза. Мне приходилось немало проверять, перепроверять и тестировать
конфигурационные файлы, прежде чем начинал работать какой-либо из
методов, хотя в конечном итоге работали все методы. Если какой-либо
браузер (Mozilla, например, но не Internet Explorer) запрашивает пароль
и не реагирует как положено на правильный, следует:
- Убедиться, что пароль введен правильно.
- Посмотреть лог cache.log в каталоге логов прокси-сервера - хелперы
выводят сообщения об ошибках туда.
- Проверить правильность написания путей в правилах задания хелперов.
- Проверить наличие самих хелперов по указанным путям и достаточность прав
на запуск хелперов из-под пользователя, от имени которого работает
прокси-сервер (обычно это squid из группы squid).
- Если хелперы запускаются, следует обратить внимание на моменты их
запуска - если ntlm_auth, например, не может установить связь с
контроллером домена, он сообщит об этом.
- Если используются хелперы на базе winbindd, следует проверить
работоспособность winbindd-демона (команды приводились выше).
- Если задействован хелпер ntlm_auth из поставки Samba -его можно
запустить в режиме отладки с консоли, приказав выводить максимально
подробную отладочную информацию. В случае успешного запуска следует
ввести через пробел имя и пароль пользователя, как показано ниже. Для
выполнения данной команды достаточно прав пользователя, имеющего доступ
к каталогу /var/db/samba/winbindd_privileged
> ntlm_auth --helper-protocol=squid-2.5-basic
--require-membership-of="MYDOMAIN+My Proxy" -d10 -I /tmp [2004/08/29
23:15:22, 5] lib/debug.c:debug_dump_status(367)
INFO: Current debug levels:
all: True/10
tdb: False/0
printdrivers: False/0
lanman: False/0
smb: False/0
rpc_parse: False/0
rpc srv: False/0
rpc_cli: False/0 passdb: False/0 sam: False/0 auth: False/0 winbind:
False/0 vfs: False/0 idmap: False/0 quota: False/0 acls: False/0
В ответ на запрос программы вводим имя пользователя testuser, пароль 123456.
[2004/08/29 23:16:21, 10] utils/ntlm_auth.c:manage_squid_request(1621)
Got 'testuser 123456' from squid (length: 15).
[2004/08/29 23:16:21, 3] utils/ntlm_auth.c:check_plaintext_auth(292)
NT_STATUS_OK: Success (0x0) OK
Всегда используйте для тестирования только подобных "пользователей",
потому что пароль виден на консоли, а также может остаться в файлах
.history, .bash_history или .mc/history!
Проверить права доступа на каталог /var/db/samba/winbindd_privileged,
если используется хелпер ntlm_auth из поставки Samba. При недостаточных
правах хелпер может выдавать в файл регистрационного журнала cache.log
сообщения, из которых совершенно невозможно понять, чего ему не хватает
для нормальной работы. При большом количестве запросов следует
пропорционально увеличить количество загружаемых хелперов (параметр
auth_param <method> children). При недостаточном количестве хелперов
запросы на аутентификацию ставятся в очередь и при переполнении очереди
прокси может аварийно завершить работу. Также следует обеспечить
постоянную доступность контроллера домена, потому что при плохой связи с
контроллером домена запросы на аутентификацию опять же ставятся в
очередь, и прокси может аварийно завершить работу при большом количестве
хелперов, ожидающих ответа от контроллера домена.
Дополнительные замечания
О безопасности передаваемых данных
Эксперименты показали, что при использовании всех хелперов, кроме
ntlm_auth из комплекта Samba 3.x и wb_ ntlmauth из комплекта squid,
пароль, передаваемый на проверку контроллеру домена, передается в
открытом виде, и лицо, имеющее возможность перехвата сетевого трафика с
данного компьютера, сможет узнать пароли. Программы ntlm_auth из
комплекта Samba 3.x и wb_ntlmauth из комплекта squid используют для
работы с контроллером домена протокол NTLM SSP, и пароль не передается
по сети в открытом виде даже при указании
--helper-protocol=squid-2.5-basic (этот параметр определяет не протокол
работы хелпера с контроллером домена, а протокол работы хелпера со
сквидом).
О преобразовании логинов из формата MYDOMAIM\myusername
Хелпер wb_ntlmauth записывает в лог полученный от пользователя логин в
виде MYDOMAIN\myusername, в то время как хелпер wb_auth записывает его в
формате myusername.
Для того чтобы использовать полученные данные в какой-либо программе
расчета статистики, необходимо унифицировать данные. Я делаю это
удалением домена и приведением всех логинов к формату myusername. Для
этого мной была разработана пара скриптов на языках shell и awk, которые
делают следующее:
Удаляют из лога строки TCP_DENIED/407, которые генерируются браузером
Internet Explorer.
Удаляют доменную часть имени пользователя, если оно представлено в
формате MYDOMAIN\myusername.
Если DNS-имя компьютера или его IP-адрес совпадает с DNS-именем или
IP-адресом, указанным в файле доверенных адресов, то в поле имени
пользователя вписывается имя, указанное в данном файле. (Если
используется как авторизация по регистрационному имени, так и
авторизация по IP-адресу, то для обработки статистики некоторым
IP-адресам жестко сопоставляется определенное имя.) Формат файла
доверенных адресов очень прост: по одной записи на строке DNS-имя или
IP-адрес компьютера и через пробел - имя пользователя, которое будет
подставляться. Например:
192.168.1.1 alice
192.168.1.2 bob
Ниже приведен основной скрипт. Вариант, демонстрируемый в данной статье,
тестовый, практической ценности не имеет и приведен только для
иллюстрации того, как обрабатывать данные файла регистрационного
журнала.
#!/bin/sh
# This is a part of SquidCount package version 1.11.4
# Daily squid proxy statistic maintenance
# Written by CityCat 25.10.2001. Copyright Granch Ltd. (C)
# This is a public software, distributed with a BSD license.
# $Id: squidcount,v 1.11.4.6 2004/07/21 12:53:02 shelton Exp $
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
trustlist="/usr/local/etc/sarg2/sargtrusted"
inlog="/var/log/squid/access.log"
# Check on presence trusted hosts list
if [ -e $trustlist ]; then
hosts=`awk '{if ($1 == "#") nextline; else print $1}' < $trustlist`
tusers=`awk '{if ($1 == "#") nextline/ else print $2}'< $trustlist`
else
logger -i -p daemon.err -t sqcount Trust list empty, will skip prepare1st stage... hosts=""
tusers=""
fi
# When trusted host list is presented, replace according
# by them...
if [ ${#hosts} -ne 0 ]; then
awk -f /usr/local/sbin/awksquid -v hosts="$hosts" -v tusers="$tusers" < $inlog > tmp/tmpaccess.log
else
cp $inlog /tmp/tmpaccess.log
fi
Далее приведен скрипт чтения файла регистрационного журнала,
реализованный на языке awk. Это рабочий скрипт, который я использую для
расчета статистики загрузки канала.
#!/usr/bin/awk -f
#This is a part of SquidCount package version 1.11.4 Squid log
# preparation to count #statistic Developed by Rashid N. Achilov.
# Copyright Granch Ltd. (C) Thisi is a public #software, distributed with
# BSD license. Externals: hosts = <list of hosts with #trusted users>
tusers = <list of trusted user logins, correspoding hosts)
# When $8 is "-" and $2 == one of trusted hosts, instead of "-" set strusted login,
# correspond this host
# When $4 is "TCP_DENIED/407" skip this line (and f*ck MS IE!)
# $Id: awksquid,v 1.11.4.2 2003/08/06 03:28:54 shelton Exp $
BEGIN {
split(hosts,harray)
split(tusers,tuarray)
if ($4 == "TCP_DENIED/407")
next
subind = index($8,"\\")
if (subind != 0) {
subname = substr($8,subind + 1) printf("%s %6s %s %s %s %s %s %s %s %s\n", J
$1,$2,$3,$4,$5,$6,$7,subname,$9,$10) next }
for (i = l;harray[i] != "";i++) {
if ($3 == harray[i]) {
if ($8 == "-") { printf("%s %6s %s %s %s %s %s %s %s %s\n", J $1,$2,$3,$4,$5,$6,$7,tuarray[i],$9,$10) break
if (harray[i] == "") print $0
Заключение
В данной статье были рассмотрены несколько способов авторизации
пользователя домена Windows на прокси-сервере squid с использованием
контроллера домена Windows. Выбор конкретного способа зависит только от
используемой версии Samba и не зависит от типа контроллера домена
Windows (схема с авторизацией через Samba 2.x и хел-перы Squid работала
достаточно долгое время в домене Windows NT, потом совершенно незаметно
была перенесена в домен Windows 2000). Samba 3.x мне кажется наиболее
перспективным решением с наиболее простым вариантом конфигурации.
Пара комментариев. Я использую
эти схемы уже год. Но под Linux. Сейчас стоит
samba 3.0.7
squid-2.5-stable-5
Хелперы были оба. В данный момент перешел на хелпер из samba - он во многом более адекватный.
1. Что касается прав доступа до winbind_privileged
Я только не помню кто, но при задаче прав 0777, этот кто-то (вроде winbind) не запускается и ругается на права. Благо у меня XFS. Я просто добавил ACL для доступа пользователя SQUID.
2. Эта схема к сожалению не работает локально. То-есть авторизация работает, а вот проверка пользователя в группе не работает. Но связано это с тем, что winbind не хочет локально выдавать информацию о группах. Приходится группы отдельно проверять через squid_unix_group. Я ее немного правил как раз для того, чтобы пользователи передавались без доменной части.
а не может быть 2 связанно с локальностью/глобальностью группы, которую ты завел в домене? проверка (хелпером сквида) проходит нормально только в глобальных группах.
>>Надо поменять группу на root:squid(с root:root) на /var/cache/samba/winbindd_privileged и всё будет работать
>>
>
>
>а есди у меня нет такой группы!?
>и Squid STABLE10? что тогда?
Должна быть группа nobody. Ее и указывай, ибо как правило под этим юзером Кальмар и стартует.
хорошая статья! наконец то появлся материал, обобщающий инфу по авторизации через групы! которого,кстати, почему то нет на радном сайте сквида. только вроде в форумах (жаль, что она не вышла неделю назад :)
Приятно, что статью опубликовали, не зря сканировал и правил. Надеюсь, что автор меня за это не засудит. (Не смог я сним связаться)
Лично мне помогла именно эта статья (правда осталась одна проблема). Все остальное, что нашел в Сети, не слишком-то помогло (может изложено не совсем нормальным языком :)
PS читайте журнал "Системный Администратор", это статья из октябрьского номера.
при использовании самбы 2.2 и сквида 2.5 все работает со всеми браузерами...
статья до работы с группами повторяет фак http://www.squid-cache.org/Doc/FAQ/FAQ-23.html#ss23.2, проверь по нему на всякий случай...
хелпер лежит, где указанно?
Что-то не получается настроить докачку FlashGet как для http так для ftp. Подскажите что в докачке надо прописать, какой тип прокси и надо ли вписывать доменное имя пользователя и пароль?
FlashGet не поддерживает NTLM аутентификацию.
от запроса пароля спасло переустановка прав на winbindd_privileged, а задание группы squid будет работать ведь если сквид запускается от имени пользователя этой группы.
samba.sh:
chmod 750 /usr/local/samba/var/locks/winbindd_privileged
"запуск самбы"
chmod 755 /usr/local/samba/var/locks/winbindd_privileged
В конфиге squid.conf:
auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmss --require-membership-of="DOMAIN+User"
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param basic program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-bassic --require-membership-of="DOMAIN+User"
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
Пробую провести проверку хелпера, как описано в статье выдает сообщение об ошибке:
[2005/01/26 12:51:54, 10] utils/ntlm_auth.c:manage_squid_request(1609)
Got 'test' from squid (length: 4).
[2005/01/26 12:51:54, 2] utils/ntlm_auth.c:manage_squid_basic_request(718)
Password not found. Denying access
Прикольно, конечно samba-3.0.11, squid-2.5.9, FreeBSD 5.3-STABLE. Если писать
auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmss
Все работает.
А Вот если
auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmss --require-membership-of="DOMAIN+User"
Фиг вам и wblog такая ошибка валится:
[2005/03/17 15:11:09, 3] nsswitch/winbindd_misc.c:winbindd_interface_version(261)
[14851]: request interface version
[2005/03/17 15:11:09, 3] nsswitch/winbindd_misc.c:winbindd_priv_pipe_dir(297)
[14851]: request location of privileged pipe
[2005/03/17 15:11:09, 3] nsswitch/winbindd_misc.c:winbindd_info(248)
[14851]: request misc info
[2005/03/17 15:11:09, 5] nsswitch/winbindd.c:winbind_client_read(477)
read failed on sock 19, pid 14851: EOF
[2005/03/17 15:11:09, 5] nsswitch/winbindd.c:winbind_client_read(477)
read failed on sock 20, pid 14851: EOF
wbinfo все находит, ntlm_auth руками авторизируется нормально. Протокол в самбе битый? Али сквид плохо рулит?
такой вопрос немного не хватает гибкости,
обычно надо в нет пускать всех, а например какой-то отдел не пустить (группу) можно конечно блокировать по одному занеся 20 юзеров в конфиг-файл сквида (или внешний файл не важно )
можно добавить 1000 пользователей в группу прокси юзерс, а 20 не добавить, тоже мне вариант, а если у вас два домена???, абзац.
а можно просто добавить строку
acl badgroup MYDOMAIN/my_group
http_access deny badgroup
вот такая функциональностьесть????
вот этого решения хотелось бы :(
мож кто прикрутил?
>такой вопрос немного не хватает гибкости,
>обычно надо в нет пускать всех, а например какой-то отдел не пустить
>(группу) можно конечно блокировать по одному занеся 20 юзеров в конфиг-файл
>сквида (или внешний файл не важно )
>можно добавить 1000 пользователей в группу прокси юзерс, а 20 не добавить,
>тоже мне вариант, а если у вас два домена???, абзац.
>
>а можно просто добавить строку
>acl badgroup MYDOMAIN/my_group
>http_access deny badgroup
>вот такая функциональностьесть????
>вот этого решения хотелось бы :(
>мож кто прикрутил?
sams.irc.perm.ru
Правда я с бубдном до сих пор скачу :) но вещь интересная
Сделал почти всё как во всевозможных мануалах и на данный момент имею следущий результат: при запуске squid Parsing Config File:Unknown authentication scheme 'ntlm'. Шо ето значить? По поводу прав на /var/db/samba/winbindd_privileged- нету у меня группы squid, меняю владельца на nobody- перестаёт запускаться winbindd. Вот такая вот печальная история
>Сделал почти всё как во всевозможных мануалах и на данный момент имею
>следущий результат: при запуске squid Parsing Config File:Unknown authentication scheme 'ntlm'.
>Шо ето значить? По поводу прав на /var/db/samba/winbindd_privileged- нету у
>меня группы squid, меняю владельца на nobody- перестаёт запускаться winbindd. Вот
>такая вот печальная история
Скорей всего у тебя squid собран без ntlm.
Выполни ./configure --help | less и прочти. Там все написано. Если что не понятно - пиши. Когда сам делал - все по шагам написал - могу помочь.
Есть такая команда - find :)
find / | grep "winbindd_privileged" - самый простой способ.
Если у тебя FreeBSD - то этот каталог живет где-то тут: /usr/local/samba/var/lock/winbindd_privileged - пишу по памяти, но точно в каталоге Samba.
Пиши. На себе убедился, что работает, хотя по началу полно было ошибок.
Хорошая статейка , тока вот у меня вопрос тут нарисовался на горизонте , есть домен и есть под домены , пробую через helper по группе авторизовывать , --mebership-of и т.д все работает . все отлично но получается что я не могу использовать другие группы , но зато работает авторизация через домен и через его поддомены , то бишь mos.comp.ru и copm.ru . А если есть группы , как быть , раньше использовался wbinfo-group.pl , была выборка по группам , но в этом случаи отваливалась авторизация в поддомене .Так как же объединит авторизацию в домене и поддомене с авторизации еще и по группам ??