аутентификация пользователей в squid через доменные аккаунты
задача
Необходимо аутентифицировать пользователей в squid на основе доменных аккаунтов. Не всегда подходит классическая схема учета трафика по IP- адресам. Кроме того, стояла задача защищать подключение к 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.
настройка клиента Kerberos
В FreeBSD существует две реализации Kerberos - производства MIT и HEIMDAL, но соединиться с сервером Kerberos, используемым в Windows 2003, у меня получилось только в случае использования Kerberos-клиента производства HEIMDAL. Более того, работает только версия старше 0.6. В пятой ветке FreeBSD в базовой системе идет Kerberos производства HEIMDAL версии 0.6.1, поэтому для его использования необходимо добавить в файл /etc/make.conf следующие параметры:
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. В моем случае это:
[libdefaults]
default_realm = PIVA.NET
[realms]
PIVA.NET = {
kdc = lab002.piva.net
admin_server = lab002.piva.net
}
Все остальные опции можно оставлять по умолчанию. Попробуем соединиться с сервером 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
Отлично, соединение есть.
samba
Устанавливаем /usr/ports/net/samba3/. Необходимые опции:
[X] ADS With Active Directory support
[X] WINBIND With WinBIND support
Далее необходимо настроить smb.conf. Отличное руководство по этому процессу вы найдете в HOWTO.
Замечание: на четвертой версии FreeBSD при использовании Kerberos-клиента версии 0.6.3 программа wbinfo не могла проверить наличие доверительного аккаунта в домене(wbinfo -t). Проблема решилась использованием security level domain вместо ads.
Приведу опции, которые добавлял я:
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
Добавим необходимые нам имена в файл /usr/local/etc/lmhosts:
10.10.10.1 lab001.piva.net
10.10.10.2 lab002.piva.net
10.10.10.3 lab003.piva.net
Входим в домен:
net ads join -U Administrator%password
Joined 'LAB003' to realm 'PIVA.NET'
winbindd
Следующим шагом у нас будет запуск winbindd. Я запускал с ключиком -d10, в debug-режиме.
Проверить работоспособность winbind можно командой wbinfo.
Необходимо удостовериться, что winbind нормально работает и может получать списки пользователей и групп с сервера.
[root@lab003 ~] wbinfo -t
checking the trust secret via RPC calls succeeded
Это означает, что доверительный аккаунт компьютера создан.
Посмотрим на список пользователей.
[root@lab003 ~] wbinfo -u (для просмотра пользователей)
administrator
guest
support_388945a0
lab002$
krbtgt
iusr_lab002
iwam_lab002
lab001$
iwam_lab001
iusr_lab001
lab003$
pablo
lab005$
Как видно, аккаунт для нашего компьютера уже создался (lab003$) и взаимодействие налажено. Попробуем аутентифицироваться в домене:
[root@lab003 ~] wbinfo -a administrator%password
plaintext password authentication succeeded
challenge/response password authentication succeeded
На этом настройку winbind можно считать законченной.
squid
Устанавливаем /usr/ports/www/squid. Насколько видно из Makefile, helper для winbind включен по умолчанию. То есть ничего особенного конфигурировать не нужно.
После установки при запущенном winbindd необходимо проверить работу helper'а
Для этого запускаем:
/usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic
Вводим piva+administrator password.
Если получен ответ OK, значит все отлично. Иначе необходимо смотреть логи winbindd.
Настраиваем, собственно, сам squid. За помощью в этом вопросе обратитесь к документации.
В данном случае были добавлены следующие стороки:
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.
После этого можно приступать к полноценному тестированию из веб-браузера.
как это выглядит
В случае, если пользователь не входит в домен, ему выдается окно, в котором предлагается ввести имя пользователя, пароль и домен. Клиенты, вошедшие в домен и использующие IE, аутентифицируются прозрачно. Клиенты, вошедшие в домен и использующие иные браузеры, аутентифицируются по протоколу basic.
Каждый раз при запуске вводят имя и пароль.
Самая главная проблема - невозможность аутентифицировать пользователей с русскими именами.
дополнительный функционал
Есть возможность управлять доступом в Internet из Windows. Для этого можно воспользоваться параметром --require-membership-of= ntlm_auth. Как видно из названия, при аутентификации helper будет требовать наличие пользователя в определенной группе. В моем случае указание там названия группы проблемы не решило. Пришлось указывать универсальный идентификатор группы в домене (SID). Узнать его можно с помощью уже знакомой программы wbinfo.
Например, если необходимо узнать SID группы inetusers:
[root@lab004 ~] wbinfo -n inetusers
S-1-5-21-1828638205-4279006917-513177360-1121 Domain Group (2)
После этого необходимо изменить конфигурационный файл squid, указав в местах описания хелперов необходимую директиву.
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.
Михаил Володько
Необходимо аутентифицировать пользователей в squid на основе доменных аккаунтов. Не всегда подходит классическая схема учета трафика по IP- адресам. Кроме того, стояла задача защищать подключение к 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.
настройка клиента Kerberos
В FreeBSD существует две реализации Kerberos - производства MIT и HEIMDAL, но соединиться с сервером Kerberos, используемым в Windows 2003, у меня получилось только в случае использования Kerberos-клиента производства HEIMDAL. Более того, работает только версия старше 0.6. В пятой ветке FreeBSD в базовой системе идет Kerberos производства HEIMDAL версии 0.6.1, поэтому для его использования необходимо добавить в файл /etc/make.conf следующие параметры:
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. В моем случае это:
[libdefaults]
default_realm = PIVA.NET
[realms]
PIVA.NET = {
kdc = lab002.piva.net
admin_server = lab002.piva.net
}
Все остальные опции можно оставлять по умолчанию. Попробуем соединиться с сервером 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
Отлично, соединение есть.
samba
Устанавливаем /usr/ports/net/samba3/. Необходимые опции:
[X] ADS With Active Directory support
[X] WINBIND With WinBIND support
Далее необходимо настроить smb.conf. Отличное руководство по этому процессу вы найдете в HOWTO.
Замечание: на четвертой версии FreeBSD при использовании Kerberos-клиента версии 0.6.3 программа wbinfo не могла проверить наличие доверительного аккаунта в домене(wbinfo -t). Проблема решилась использованием security level domain вместо ads.
Приведу опции, которые добавлял я:
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
Добавим необходимые нам имена в файл /usr/local/etc/lmhosts:
10.10.10.1 lab001.piva.net
10.10.10.2 lab002.piva.net
10.10.10.3 lab003.piva.net
Входим в домен:
net ads join -U Administrator%password
Joined 'LAB003' to realm 'PIVA.NET'
winbindd
Следующим шагом у нас будет запуск winbindd. Я запускал с ключиком -d10, в debug-режиме.
Проверить работоспособность winbind можно командой wbinfo.
Необходимо удостовериться, что winbind нормально работает и может получать списки пользователей и групп с сервера.
[root@lab003 ~] wbinfo -t
checking the trust secret via RPC calls succeeded
Это означает, что доверительный аккаунт компьютера создан.
Посмотрим на список пользователей.
[root@lab003 ~] wbinfo -u (для просмотра пользователей)
administrator
guest
support_388945a0
lab002$
krbtgt
iusr_lab002
iwam_lab002
lab001$
iwam_lab001
iusr_lab001
lab003$
pablo
lab005$
Как видно, аккаунт для нашего компьютера уже создался (lab003$) и взаимодействие налажено. Попробуем аутентифицироваться в домене:
[root@lab003 ~] wbinfo -a administrator%password
plaintext password authentication succeeded
challenge/response password authentication succeeded
На этом настройку winbind можно считать законченной.
squid
Устанавливаем /usr/ports/www/squid. Насколько видно из Makefile, helper для winbind включен по умолчанию. То есть ничего особенного конфигурировать не нужно.
После установки при запущенном winbindd необходимо проверить работу helper'а
Для этого запускаем:
/usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic
Вводим piva+administrator password.
Если получен ответ OK, значит все отлично. Иначе необходимо смотреть логи winbindd.
Настраиваем, собственно, сам squid. За помощью в этом вопросе обратитесь к документации.
В данном случае были добавлены следующие стороки:
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.
После этого можно приступать к полноценному тестированию из веб-браузера.
как это выглядит
В случае, если пользователь не входит в домен, ему выдается окно, в котором предлагается ввести имя пользователя, пароль и домен. Клиенты, вошедшие в домен и использующие IE, аутентифицируются прозрачно. Клиенты, вошедшие в домен и использующие иные браузеры, аутентифицируются по протоколу basic.
Каждый раз при запуске вводят имя и пароль.
Самая главная проблема - невозможность аутентифицировать пользователей с русскими именами.
дополнительный функционал
Есть возможность управлять доступом в Internet из Windows. Для этого можно воспользоваться параметром --require-membership-of= ntlm_auth. Как видно из названия, при аутентификации helper будет требовать наличие пользователя в определенной группе. В моем случае указание там названия группы проблемы не решило. Пришлось указывать универсальный идентификатор группы в домене (SID). Узнать его можно с помощью уже знакомой программы wbinfo.
Например, если необходимо узнать SID группы inetusers:
[root@lab004 ~] wbinfo -n inetusers
S-1-5-21-1828638205-4279006917-513177360-1121 Domain Group (2)
После этого необходимо изменить конфигурационный файл squid, указав в местах описания хелперов необходимую директиву.
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.
Михаил Володько
Сетевые решения. Статья была опубликована в номере 07 за 2007 год в рубрике sysadmin
