Аутентификация пользователей в squid через доменные аккаунты Windows

Задача.

Необходимо аутентифицировать пользователей в squid на основе доменных
аккаунтов. Не всегда подходит классическая схема учета трафика по IP
адресам примеры случаев когда подобная ситуация не устраивает достаточно
полно описаны в [1]. Кроме того, стояла задача защищать подключение к
Internet в большой сети от приносимых ноутбуков.

Инструменты.

1. OC FreeBSD использовались версии 4.11-RELEASE и 5.3-RELEASE-p5
2. Windows 2003 - контроллер домена.
3. samba-3.0.11
4. squid-2.5.8


Сеть и топология.

Домен - piva.net
Контроллер домена - lab002.piva.net
Рабочие станции соответственно - labxxx.piva.net
Машина на которой установлен squid - lab003.piva.net

Практическое руководство.

1. Настройка клиента Kerberos

В FreeBSD существует две реализации Kerberos производства MIT и HEIMDAL,
соединиться с сервером Kerberos используемым в Windows 2003 у меня
получилось только в случае использования Kerberos клиента производства
HEIMDAL. Более того, он работает, только если версия старше 0.6. В пятой
ветке FreeBSD в базовой системе идет Kerberos производства HEIMDAL
версии 0.6.1, поэтому для его использования необходимо добавить в файл
/etc/make.conf следующие параметры:



После этого необходимо пересобрать мир (make buildworld && make
installworld). Как это делается, я описывать не буду, обратитесь к
руководствам по этой теме.

В базовой системе четвертой версии FreeBSD идет клиент Kerberos
производства HEIMDAL однако довольно старой версии 0.5.1. Для
использования сервера Kerberos производства HEIMDAL версии 0.6.х в
четвертой версии FreeBSD необходимо установить порт
/usr/ports/security/heimdal.

Важное замечание - DNS сервер, прописанный в /etc/resolv.conf ДОЛЖЕН
ЗНАТЬ о зоне используемой для построения Windows домена (наиболее
удобный путь настроить его как вторичный DNS сервер). Клиент Kerberos
будет искать записи типа SRV _kerberos._udp.

Настраиваем клиента Kerberos. В файл /etc/krb5.conf необходимо добавить
информацию о сервере Kerberos в моем случае это:


Все остальные опции можно оставлять по умолчанию.
Попробуем соединиться с сервером Kerberos.

[root@lab003 ~] kinit -p Administrator@piva.net
Administrator@PIVA.NET's Password:


и вводим пароль, система должна выдать

kinit: NOTICE: ticket renewable lifetime is 1 week


проверим соединение, в моем случае это выглядит так:

[root@lab003 ~] klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: administrator@PIVA.NET

Issued Expires Principal
Feb 22 17:10:40 Feb 23 03:10:38 krbtgt/PIVA.NET@PIVA.NET


Отлично, соединение есть.


2. Samba

Устанавливаем /usr/ports/net/samba3/
Необходимые опции



Далее необходимо настроить smb.conf
Отличное руководство по этому процессу [6].

Замечание: на четвертой версии FreeBSD при использовании Kerberos
клиента версии 0.6.3 программа wbinfo не могла проверить наличие
доверительного аккаунта в домене(wbinfo -t). Проблема решилась
использованием security level domain вместо ads.

Приведу опции, которые добавлял я:



Как и советует автор [1], добавим необходимы нам имена в файл
/usr/local/etc/lmhosts



Входим в домен:



3. winbindd

Следующим шагом у нас запуск winbindd.
Я запускал с ключиком -d10, в debug режиме.

Проверить работоспособность winbind можно командой wbinfo

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




Это означает что доверительный аккаунт компьютера создан.

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




Как видно, аккаунт для нашего компьютера уже создался (lab003$) и
взаимодействие налажено.

Попробуем аутентифицироваться в домене:




На этом настройку winbind можно считать законченной.

4. squid

Устанавливаем /usr/ports/www/squid

Насколько видно из Makefile helper для winbind включен по умолчанию.
Т.е. ничего особенного конфигурировать не нужно.

После установки при запущенном winbindd необходимо проверить работу
helper'а

Для этого запускаем




Вводим piva+administrator password

Если получен ответ OK значит все отлично. Иначе необходимо смотреть логи
winbindd

Настраиваем собственно сам squid. Отличное руководство по это делу [3]

В данном случае были добавлены следующие стороки:



Данная конфигурация описывает два helper'a один дня IE (ntlmssp)
другой для всех остальных пользователей (mozilla, opera, etc).

Необходимо отметить что для нормальной работы из броузера у пользователя
под который работает squid должно хватать прав для обращения к сокету на
котором слушает winbindd. Согласно man ntlm_auth это winbindd_privileged
в $LOCKDIR. В моем случае сокет находиться в
/var/db/samba/winbindd_privileged. Для решения проблемы я изменил группу
владельца этой директории на squid.

После этого можно приступать к полноценному тестированию из веб броузера.


5. Как это выглядит

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

Самая главная проблема - невозможность аутентифицировать пользователей с
русскими именами.


6. Дополнительный функционал

Дополнительно можно использовать возможность управлять доступом в
Internet из Windows. Для этого можно воспользоваться параметром
--require-membership-of= ntlm_auth. Как видно из названия при
аутентификации helper будет требовать наличие пользователя в
определенной группе. В моем случае указание там названия группы проблемы
не решило. Пришлось указывать универсальный идентификатор группы в
домене (SID). Узнать его можно с помощью уже знакомой программы wbinfo.
Например, если необходимо узнать SID группы inetusers:




После этого необходимо изменить конфигурационный файл squid указав в
местах описания хелперов необходиму директиву.




Теперь пользователи которые не входят в группу inetusers не смогут выйти
в Internet.