Squid3 на сервере FreeBSD 10.0 и доменные пользователи. Часть 2
 |
Прошло совсем немного времени после моего написания статьи про настройку кеширующего сервера squid3 на компьютере под управлением FreeBSD 10.0 совместно с доменными пользователями, как реалии работы вынудили меня искать несколько иной путь авторизации пользователей на сквиде… |
Дело в том, что при ldap-аутентификации на squid доменный пользователь вынужден постоянно вводить свой логин и пароль в случаях, если сам squid был перезагружен, или пользователь закрыл и снова открыл окно браузера. В случае с Firefox и даже Internet Explorer все не так критично, т.к. браузер запоминает эту пару для аутентификации, и пользователю необходимо просто нажать на кнопочку подтверждения OK. А вот в случае Opera, Chrome и сделанного на его основе Yandex-браузера, логин и пароль каждый раз приходится полностью вводить заново… Согласитесь, это вызывает раздражение у пользователей. Вот тут-то мне и пришлось задуматься, как сделать авторизацию доменных пользователей “тихой”, таким образом, чтобы проверяемые credentials брались из их текущей сессии в windows. В этом мне помогла аутентификация с помощью kerberos.
В squid3 существует поддержка negotiate аутентификации с помощью kerberos. Для этого необходимо при установке squid отметить опцию AUTH_KERB, как показано на рисунке выбора опций ниже. Так же, мной осталась отмечена возможность аутентификации по ldap (опция AUTH_LDAP), для определения принадлежности пользователей к той или иной группе, существующей в AD.
Итак, начнем. На момент написания статьи имеем следующее:
# uname -a
FreeBSD squid.domain.ru 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Wed Mar 5 13:09:19 MSK 2014
root@squid.domain.ru:/usr/obj/usr/src/sys/MYKERNEL amd64
# cd /usr/ports/www/squid
# less distinfo
SHA256 (squid3.4/squid-3.4.9.tar.xz) = 0a0f13bc745437e78df14c31828d9324979b1f2f940b9ce8c9d5bbb7d5fcaa7c
SIZE (squid3.4/squid-3.4.9.tar.xz) = 2160416
Произведем установку squid:
# portsnap fetch update # cd /usr/ports/www/squid # make config
Отметьте необходимые опции:
И произведите собственно установку:
# make install clean
Все необходимые хелперы для аутентификации вы обнаружите по пути:
# ls -Al /usr/local/libexec/squid/ total 1156 -r-xr-xr-x 1 root wheel 4150 13 ноя 16:30 basic_db_auth -r-xr-xr-x 1 root wheel 10401 13 ноя 16:30 basic_fake_auth -r-xr-xr-x 1 root wheel 16277 13 ноя 16:30 basic_getpwnam_auth -r-xr-xr-x 1 root wheel 36937 13 ноя 16:30 basic_ldap_auth -r-xr-xr-x 1 root wheel 81439 13 ноя 16:30 basic_msnt_auth -r-xr-xr-x 1 root wheel 3960 13 ноя 16:30 basic_msnt_multi_domain_auth -r-xr-xr-x 1 root wheel 43101 13 ноя 16:30 basic_ncsa_auth -r-xr-xr-x 1 root wheel 24979 13 ноя 16:30 basic_pam_auth -r-xr-xr-x 1 root wheel 1466 13 ноя 16:30 basic_pop3_auth -r-xr-xr-x 1 root wheel 38266 13 ноя 16:30 basic_radius_auth -r-xr-xr-x 1 root wheel 9348 23 окт 14:59 basic_smb_auth -r-xr-xr-x 1 root wheel 2229 23 окт 14:59 basic_smb_auth.sh -r-xr-xr-x 1 root wheel 285751 13 ноя 16:30 cachemgr.cgi -r-xr-xr-x 1 root wheel 43193 13 ноя 16:30 digest_file_auth -r-xr-xr-x 1 root wheel 97041 13 ноя 16:30 diskd -r-xr-xr-x 1 root wheel 25082 13 ноя 16:30 ext_file_userip_acl -r-xr-xr-x 1 root wheel 38879 13 ноя 16:30 ext_ldap_group_acl -r-xr-xr-x 1 root wheel 22421 13 ноя 16:30 ext_time_quota_acl -r-xr-xr-x 1 root wheel 19906 13 ноя 16:30 ext_unix_group_acl -r-xr-xr-x 1 root wheel 5005 23 окт 14:59 ext_wbinfo_group_acl -r-xr-xr-x 1 root wheel 5505 13 ноя 16:30 helper-mux.pl -r-xr-xr-x 1 root wheel 14828 13 ноя 16:30 log_file_daemon -r-xr-xr-x 1 root wheel 60388 13 ноя 16:30 negotiate_kerberos_auth -r-xr-xr-x 1 root wheel 24960 13 ноя 16:30 negotiate_kerberos_auth_test -r-xr-xr-x 1 root wheel 26841 13 ноя 16:30 negotiate_wrapper_auth -r-xr-xr-x 1 root wheel 34843 13 ноя 16:30 ntlm_fake_auth -r-xr-xr-x 1 root wheel 119401 13 ноя 16:30 ntlm_smb_lm_auth -r-xr-xr-x 1 root wheel 2428 13 ноя 16:30 storeid_file_rewrite -r-xr-xr-x 1 root wheel 8014 13 ноя 16:30 unlinkd -r-xr-xr-x 1 root wheel 10473 13 ноя 16:30 url_fake_rewrite -r-xr-xr-x 1 root wheel 2251 13 ноя 16:30 url_fake_rewrite.sh
Теперь необходимо провести некоторые важные подготовительные работы.
Примем, наш домен – domain.ru (уровень домена и леса – Windows Server 2003, хотя в моей сети и присутствует вторичный dc под управлением Windows Server 2008 R2). Сервер FreeBSD 10.0, на котором мы конфигурируем squid – squid.domain.ru, имеющий ip — 192.168.0.3. Имя пользователя в нашем домене, от имени которого будут проверяться credentials доменных юзеров – squid с паролем squid. Версия heimdal (включен в FreeBSD по умолчанию) – свободной реализации Kerberos 5, имеющей совместимость с MIT krb5 и обратную совместимость с krb4:
# kinit --version kinit (Heimdal 1.5.2) Copyright 1995-2011 Kungliga Tekniska Hц╤gskolan Send bug-reports to heimdal-bugs@h5l.org
Хотя все описанное далее справедливо и для версии Heimdal 1.1.0 на FreeBSD 8.4, что лично мной проверено.
192.168.0.2 и 192.168.0.21 — IP адреса двух домен-контроллеров (dc.domain.ru и dc2.domain.ru), на обоих запущены сервисы DNS.
Обязательно приведите сетевые настройки своего сервера FreeBSD к виду:
файл /etc/resolv.conf:
# less /etc/resolv.conf domain domain.ru search domain.ru nameserver 192.168.0.2 nameserver 192.168.0.21
файл /etc/hosts:
# less /etc/hosts 127.0.0.1 localhost.domain.ru localhost 192.168.0.3 squid.domain.ru squid 192.168.0.3 squid.domain.ru.
Проверьте вывод команды hostname:
# hostname squid.domain.ru
Если вывод вас не устроит, внесите в /etc/rc.conf следующую строку:
# less /etc/rc.conf | grep hostname hostname="squid.domain.ru"
DNS вашего домена должен иметь прямую — A и обратную — PTR записи, описывающие ваш сервер FreeBSD, на котором вы настраиваете squid (проверяем запросом к одному из dns-серверов):
# host squid 192.168.0.2 Using domain server: Name: 192.168.0.2 Address: 192.168.0.2#53 Aliases: squid.domain.ru has address 192.168.0.3 # host 192.168.0.3 192.168.0.2 Using domain server: Name: 192.168.0.2 Address: 192.168.0.2#53 Aliases: 3.0.168.192.in-addr.arpa domain name pointer squid.domain.ru.
Думаю, что излишне, но все же: ваш домен должен иметь синхронизацию с единым сервером времени – и dc, и сервер FreeBSD, и клиентские компьютеры пользователей.
Последнее допущение: на вашем сервере FreeBSD нет других работающих сервисов, использующих kerberos.
Приведем настройку файла /etc/krb5.conf к следующему виду (источник — wiki.squid-cache.org):
# less /etc/krb5.conf
[libdefaults]
default_realm = DOMAIN.RU
dns_lookup_kdc = no
dns_lookup_realm = no
ticket_lifetime = 24h
default_keytab_name = /usr/local/etc/squid/squid.keytab
default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
[realms]
DOMAIN.RU = {
kdc = 192.168.0.2
kdc = 192.168.0.21
admin_server = 192.168.0.2
default_domain = domain.ru
}
[domain_realm]
.domain.ru = DOMAIN.RU
domain.ru = DOMAIN.RU
Где /usr/local/etc/squid/squid.keytab – кейтаб для сервера FreeBSD, где мы настраиваем squid, для осуществления проверки credentials пользователей на нашем dc. Сам кейтаб мы сформируем на одном из наших домен-контроллеров, чтобы не использовать ничего лишнего с сервера FreeBSD. Я получил кейтаб на сервере Windows Server 2003 R2 при помощи команды ktpass, входящей в состав Support Tools со второго установочного диска.
Идем на dc, запускаем cmd.exe и вводим волшебные символы в одну строку:
C:\>ktpass -princ HTTP/squid.domain.ru@DOMAIN.RU -mapuser squid -crypto RC4-HMAC-NT -pass "squid" -ptype KRB5_NT_PRINCIPAL -out C:\squid.keytab
— где:
- -princ — имя сервиса и принципала;
- -mapuser — аккаунт принципала;
- -crypto — используемый алгоритм шифрования;
- -pass — пароль к аккаунту принципала;
- -ptype — тип запроса от принципала;
- -out — файл для вывода кейтаба.
Справку по данной команде вы получите по ktpass -?. Обратите внимание на синтаксис в данной команде. Мне пришлось много экспериментировать, прежде чем удалось сделать работоспособный кейтаб. Он был получен именно с данными ключами.
Вывод работы команды ktpass для получения кейтаба:
C:\>ktpass -princ HTTP/squid.domain.ru@DOMAIN.RU -mapuser squid -crypto RC4-HMAC-NT -pass "squid" -ptype KRB5_NT_PRINCIPAL -out C:\squid.keytab Targeting domain controller: dc.domain.ru Using legacy password setting method Successfully mapped HTTP/squid.domain.ru to squid. Key created. Output keytab to C:\squid.keytab: Keytab version: 0x502 keysize 69 HTTP/squid.domain.ru@DOMAIN.RU ptype 1 (KRB5_NT_PRINCIPAL) vno 24 etype 0x17 (RC4-HMAC) keylength 16 (0x8996736ca369980aeaa1ca641c8a2d6a)
Обратите внимание, имя пользователя squid для входа в домен поменяется на:
Теперь переместите (рекомендуется сделать это “секурно”) полученный кейтаб с домен-контроллера на ваш сервер FreeBSD и положите в каталог /usr/local/etc/squid, или в место, которое вы указали в вашем /etc/krb5.conf. Учтите одно, если вы не обозначили файл кейтаба, как это сделал я, будет приниматься во внимание кейтаб по умолчанию, который должен иметь имя и располагаться: /etc/krb5.keytab.
Просмотреть содержимое вашего файла кейтаб вы можете командой:
# ktutil -k /usr/local/etc/squid/squid.keytab list /usr/local/etc/squid/squid.keytab: Vno Type Principal Aliases 24 arcfour-hmac-md5 HTTP/squid.domain.ru@DOMAIN.RU
Теперь вы можете попробовать получить билетик инициализации от вашего домена. Делается это командой:
# kinit -k -t /usr/local/etc/squid/squid.keytab HTTP/squid.domain.ru
Если на этом этапе у вас ничего не получилось (выдает какие-либо ошибки), в дальнейшем у вас ничего не выйдет. Проверено… :(
Просмотреть содержимое билетика вы можете командой:
# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: HTTP/squid.domain.ru@DOMAIN.RU
Issued Expires Principal
Nov 10 03:12:04 2014 Nov 10 13:12:04 2014 krbtgt/DOMAIN.RU@DOMAIN.RU
Так как данный билетик нам больше не пригодится, уничтожьте его командой kdestroy и проверьте:
# kdestroy # klist klist: No ticket file: /tmp/krb5cc_0
Наконец, нам необходимо указать squid’у, где он должен брать кейтаб. Это очень важная опция для запуска! Поместите в ваш /etc/rc.conf следующие строки:
# less /etc/rc.conf | grep squid squid_enable="YES" squid_krb5_ktname="/usr/local/etc/squid/squid.keytab"
— где squid_krb5_ktname – файл, указанный вами в вашем /etc/krb5.conf, куда вы положили полученный с домен-контроллера кейтаб.
Теперь перейдем непосредственно к конфигурированию squid. Учтите, что negotiate авторизация должна идти самой первой, перд basic (если вы таковую будете использовать, как я). Здесь приведен необходимый минимум в части касающейся:
# nano -w /usr/local/etc/squid/squid.conf
#прописываем аутентификатор
auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -d -r -s HTTP/squid.domain.ru@DOMAIN.RU
auth_param negotiate children 10 startup=5 idle=1
auth_param negotiate keep_alive on
#задаем acl SQUID для которой требуется аутентификация
acl SQUID proxy_auth REQUIRED
#разрешаем полный доступ в интернет прользователям, прошедшим аутентификацию
http_access allow SQUID
#запрещаем всем остальным доступ к кэшу
http_access deny all
#указываем порт для работы squid
http_port squid.domain.ru:3128
#видимое имя хоста
visible_hostname squid.domain.ru
#расположение файла hosts
hosts_file /etc/hosts
Разберем аутентификатор:
- -d — включает полный дебаг (без него при отладке очень сложно понять, что к чему);
- -r — в логах access.log убирает от авторизовавшегося пользователя его REALM (@DOMAIN.RU);
- -s — имя сервиса принципала.
В остальном настройка аналогична тому, как она была произведена в прошлой статье: Настройка кеширующего сервера squid3 на компьютере под управлением FreeBSD 10.0 совместно с доменными пользователями.
Теперь наконец-то можно произвести запуск squid и осуществить мониторинг его работы:
# /usr/local/etc/rc.d/squid start # tail -f /var/squid/logs/access.log # tail -f /var/squid/logs/cache.log
Напоследок приведу свой полный рабочий файл конфигурации кеширующего сервера squid (все кавычки – прямые "):
# less /usr/local/etc/squid/squid.conf | grep -v “^#” auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -r -s HTTP/squid.domain.ru@DOMAIN.RU auth_param negotiate children 10 startup=5 idle=1 auth_param negotiate keep_alive on auth_param basic program /usr/local/libexec/squid/basic_ldap_auth -R -D squid@domain.ru \ -W /usr/local/etc/squid/scrt -b “DC=domain,DC=ru” \ -f “sAMAccountName=%s” -h 192.168.0.2 auth_param basic children 10 startup=5 idle=1 auth_param basic realm Welcome! Please, enter your password auth_param basic credentialsttl 12 hours auth_param basic casesensitive off acl localnet src 192.168.0.0/24 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 443 # https acl Safe_ports port 1025-65535 # unregistered ports http_access deny !Safe_ports acl CONNECT method CONNECT http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access deny to_localhost http_access allow localhost acl QUERY urlpath_regex cgi-bin \? cache deny QUERY acl SQUID proxy_auth REQUIRED external_acl_type ldap_users ttl=1200 %LOGIN /usr/local/libexec/squid/ext_ldap_group_acl \ -R -b “DC=domain,DC=ru” -f “(&(sAMAccountName=%v) (memberOf=cn=%a,OU=Squid,DC=domain,DC=ru))” \ -D squid@domain.ru -W /usr/local/etc/squid/scrt -h 192.168.0.2 acl squid.denyall external ldap_users squid.denyall http_access deny all squid.denyall acl squid.exclusive external ldap_users squid.exclusive http_access allow all squid.exclusive http_access allow SQUID http_access deny all http_port squid.domain.ru:3128 cache_dir ufs /var/squid/cache/squid 100 16 256 coredump_dir /var/squid/cache/squid access_log stdio:/var/squid/logs/access.log squid cache_log /var/squid/logs/cache.log cache_store_log none 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 visible_hostname squid.domain.ru error_default_language ru error_directory /usr/local/etc/squid/errors/ru error_log_languages on hosts_file /etc/hosts forwarded_for off
Basic аутентификация используется мной для доступа к интернету через squid пользователей с компьютеров не входящих в домен. На таких компьютерах необходимо ввести логин и пароль какого-нибудь доменного пользователя.
Одно важное замечание: в настройках браузера в качестве прокси-сервера теперь необходимо указывать не его ip, а FQDN (Fully Qualified Domain Name — «полностью определённое имя домена»). Т.е. не 192.168.0.3, а squid.domain.ru. Чтобы осуществить данную настройку через AD, сделайте так:
Откройте оснастку Group Policy Management, выберите необходимую Group Policy Objects (в моем случае – test), Edit -> Конфигурация пользователя -> Конфигурация Windows -> Настройка Internet Explorer -> Подключение и внесите свои настройки (squid.domain.ru, порт 3128):
Вот теперь – все!
P.S. у вас могут возникнуть трудности с доступом к интернету при kerberos аутентификации с компьютеров под управлением Windows XP. Да, таковых в моей сети пока еще тоже предостаточно. Дело в том, что даже при наличии в сети NTP-сервера для синхронизации времени всех устройств, она (синхронизация) не выполняется в должной мере на Windows XP. Microsoft благополучно прекратила поддержку этой операционной системы, поэтому обновление timezone для нее не было выпущено после последнего закона о переходе на “зимнее время” в России. Чтобы исправить сие недоразумение, вам необходимо вручную переставить временную зону. Например для MSK выставить в свойствах даты и времени зону для Калининграда (GMT+03:00):
После выставления временной зоны таким образом и синхронизации времени с вашим ntp сервером в сети, squid будет авторизовывать пользователей с такого компьютера под управлением Windows XP.
______
небольшое дополнение: если вы не желаете хранить пароль для доменного пользователя, от имени которого проверяется наличие пользователя или группы вашего домена, во внешнем файле (в моём примере – файл /usr/local/etc/squid/scrt), вы можете обозначить этот пароль непосредственно в файле настройки squid при объявлении хелперов с помощью опции -w. соответствующие строки конфигурационного файла из моего примера будут иметь вид:
...
auth_param basic program /usr/local/libexec/squid/basic_ldap_auth -R -D squid@domain.ru \
-w password -b "DC=domain,DC=ru" \
-f "sAMAccountName=%s" -h 192.168.0.2
...
external_acl_type ldap_users ttl=1200 %LOGIN /usr/local/libexec/squid/ext_ldap_group_acl \
-R -b "DC=domain,DC=ru" -f "(&(sAMAccountName=%v) (memberOf=cn=%a,OU=Squid,DC=domain,DC=ru))" \
-D squid@domain.ru -w password -h 192.168.0.2
...
Все это прекрасно, если у вас в сети нет ноутбуков, которые командировочные :) Тогда сотруднику вместо логина и пароля, придется каждый раз убирать галочку в IE с принудительного Proxy.
Привет!
У меня при аналогичном конфиге, при подключении с машины, не находящейся в домене возникает следующая ошибка:
ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
lif, я не нашел, каким образом победить данную ошибку. но ведь валидация проходит нормально и пользователь все равно получает доступ в интернет сквозь таким образом настроенный squid. таких ошибок за сутки у меня несколько тысяч в логе… :(
если найдёте решение, убирающее данную ошибку – поделитесь…
Колосально!!!!!
Коллега вы проделали большую работу и сэкономили мне кучу времени, спасибо за хороший мануал. У меня как раз появилась задача перейти с kerio control на squid, пока на тестовом стенде из виртуалок все поднимал, настройку аутентификации через kerberos делал по вашей статье, все завелось с полоборота. К статье я бы добавил только, что предварительно требуется создание пользователя в домене, перед созданием файла keytab, а то меня это здорово в ступор поначалу ввело (пробовал keytab без пользователя создать, контроллер сильно ругался), ниже увидел скрин свойств пользователя, и смекнул что его следует предварительно создать.