Аутентификация пользователей в 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 следующие параметры:
|
1 2 |
MAKE_KERBEROS5 = yes ENABLE_SUID_K5SU = yes |
После этого необходимо пересобрать мир (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 в моем случае это:
|
1 2 3 4 5 6 7 |
[libdefaults] default_realm = PIVA.NET [realms] PIVA.NET = { kdc = lab002.piva.net admin_server = lab002.piva.net } |
Все остальные опции можно оставлять по умолчанию.
Попробуем соединиться с сервером Kerberos.
|
1 2 |
[root@lab003 ~] kinit -p Administrator@piva.net Administrator@PIVA.NET's Password: |
и вводим пароль, система должна выдать
|
1 |
kinit: NOTICE: ticket renewable lifetime is 1 week |
проверим соединение, в моем случае это выглядит так:
|
1 2 3 |
[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/
Необходимые опции
[X] ADS With Active Directory support
[X] WINBIND With WinBIND support
Далее необходимо настроить smb.conf
Отличное руководство по этому процессу [6].
Замечание: на четвертой версии FreeBSD при использовании Kerberos
клиента версии 0.6.3 программа wbinfo не могла проверить наличие
доверительного аккаунта в домене(wbinfo -t). Проблема решилась
использованием security level domain вместо ads.
Приведу опции, которые добавлял я:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
workgroup = piva server string = lab003 netbios name = lab003 realm = piva.net security = ads password server = lab002.piva.net encrypt passwords = yes winbind separator = + winbind use default domain = yes winbind uid = 10000-20000 winbind gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = /home/winnt/%D/%U template shell = /usr/local/bin/bash |
Как и советует автор [1], добавим необходимы нам имена в файл
/usr/local/etc/lmhosts
|
1 2 3 |
10.10.10.1 lab001.piva.net 10.10.10.2 lab002.piva.net 10.10.10.3 lab003.piva.net |
Входим в домен:
|
1 2 |
net ads join -U Administrator%password Joined 'LAB003' to realm 'PIVA.NET' |
3. winbindd
Следующим шагом у нас запуск winbindd.
Я запускал с ключиком -d10, в debug режиме.
Проверить работоспособность winbind можно командой wbinfo
Необходимо удостовериться, что winbind нормально работает и может
получать списки пользователей и групп с сервера.
|
1 2 |
[root@lab003 ~] wbinfo -t checking the trust secret via RPC calls succeeded |
Это означает что доверительный аккаунт компьютера создан.
Посмотрим на список пользователей.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[root@lab003 ~] wbinfo -u (для просмотра пользователей) administrator guest support_388945a0 lab002$ krbtgt iusr_lab002 iwam_lab002 lab001$ iwam_lab001 iusr_lab001 lab003$ pablo lab005$ |
Как видно, аккаунт для нашего компьютера уже создался (lab003$) и
взаимодействие налажено.
Попробуем аутентифицироваться в домене:
|
1 2 3 |
[root@lab003 ~] wbinfo -a administrator%password plaintext password authentication succeeded challenge/response password authentication succeeded |
На этом настройку winbind можно считать законченной.
4. squid
Устанавливаем /usr/ports/www/squid
Насколько видно из Makefile helper для winbind включен по умолчанию.
Т.е. ничего особенного конфигурировать не нужно.
После установки при запущенном winbindd необходимо проверить работу
helper’а
Для этого запускаем
|
1 |
/usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic |
Вводим piva+administrator password
Если получен ответ OK значит все отлично. Иначе необходимо смотреть логи
winbindd
Настраиваем собственно сам squid. Отличное руководство по это делу [3]
В данном случае были добавлены следующие стороки:
|
1 2 3 4 5 6 7 8 9 |
auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 10 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 10 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours |
Данная конфигурация описывает два 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:
|
1 2 |
[root@lab004 ~] wbinfo -n inetusers S-1-5-21-1828638205-4279006917-513177360-1121 Domain Group (2) |
После этого необходимо изменить конфигурационный файл squid указав в
местах описания хелперов необходимо директиву.
|
1 2 3 |
auth_param ntlm program /usr/local/bin/ntlm_auth \ --require-membership-of=S-1-5-21-1828638205-4279006917-513177360-1121 \ --helper-protocol=squid-2.5-ntlmssp |
Теперь пользователи которые не входят в группу inetusers не смогут выйти
в Internet.