Введение
В данной статье рассматривается довольно сложная тема как подружить прокси сервер squid с Active Directory (AD) используя kerberos.
Почему был выбран kerberos — это один из самых безопасных сетевых протоколов аутентификации который используется в AD и можно использовать в linux системах.
Сразу предупреждаю новичкам следует начать с чего-нибудь попроще т. к. kerberos очень привередлив к настройкам, а причины ошибок kerberos зачастую весьма туманны. Особое внимание нужно уделять регистру написания доменов. Ещё в разных версиях squid любят переименовывать параметры и названия хелперов. И как обычно одна неправильная точка, запятая, или имя компьютера может изрядно попортить вам нервы так что будьте внимательны и аккуратны.
Итак что у нас есть:
1. Контроллеры домена на windows 2008 R2 или 2012 R2 — serverdc (192.168.0.8), serverdc2 (192.168.0.9) которые управляют доменном mydomain.local
2. Прокси сервер на debian (ubuntu server) — proxy (192.168.0.6)
Начнём с настройки прокси сервера.
3. Клиенты windows XP и/или windows 7,8,10
Обращаю особое внимание что на всех серверах ip адреса должны быть статическими на клиентах можно использовать и динамические.
Настройки контроллера домена
Предполагается что контроллер домена уже настроен и все клиенты в него заведены. Нам нужно добавить A запись на DNS сервере:
proxy узел(A) 192.168.0.6
Проверим запись:
nslookup proxy.mydomain.local
Теперь нужно создать тикет (кейтаб) для пользователя, от имени которого будет проверяться валидность пользователя интернета.
В АД создаем пользователя например squid с вечным паролем и не блокируемым.
Генерим сам кейтаб для этого используем утилитку ktpass на контроллере доменна:
ktpass -princ HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL -mapuser squid@mydomain.local -crypto RC4-HMAC-NT -pass Secretpassw0rd -ptype KRB5_NT_PRINCIPAL -out proxy.keytab
Важно указать «принципалом» именно hostname линукс сервера (в данном примере — proxy) потому что, в свойствах браузеров FireFox или IE нужно указать proxy.mydomain.local а не IP. Если необходимо указывать другое имя, а не то, что отдает дебиан по hostname -a, его нужно указать в конфиге сквида в параметре visible_hostname.
Копируем созданный файл proxy.keytab на прокси сервер в файл /etc/krb5.keytab он нам ещё понадобиться.
Настройка DNS
Переходим к настройкам линукса в современных дистрибутивах /etc/resolv.conf генерится автоматически и есть разные варианты настройки поэтому нужно смотреть инструкцию на свой дистрибутив но в конечном итоге должно получиться примерно так:
domain MYDOMAIN.LOCAL search MYDOMAIN.LOCAL nameserver 192.168.0.8 nameserver 192.168.0.9
Проверяем что контроллер домена доступен:
nslookup serverdc.mydomain.local ping serverdc.mydomain.local
Настройка точного времени
Kerberos не будет проходить аутентификацию, если время между клиентом, прокси сервером и контроллером домена будет отличатся более чем на 3 минуты с учётом часовых поясов. Если что то не работает в первую очередь нужно проверить что время везде одинаковое и часовые пояса правильные.
Чтобы время всегда было правильным ставим демона (службу) который будет синхронизировать время с контроллером домена
apt-get install ntp
Добавим в /etc/ntp.conf с кем нужно синхронизироваться:
# Specify one or more NTP servers. server serverdc.mydomain.local server serverdc2.mydomain.local
Остановим ненадолго демона
/etc/init.d/ntp stop
Проверим время и заодно синхронизируем часы
ntpdate serverdc
Запускаем демона теперь он сам будет следить за временем
/etc/init.d/ntp start
Настройка kerberos
Поставим утилиты и библиотеки необходимые для работы kerberos:
apt-get install krb5-user krb5-config libkrb53
Теперь нужно привести файл настроек /etc/krb5.conf к виду
[appdefaults]
pam = {
debug = false
alt_auth_map = %s@MYDOMAIN.LOCAL
force_alt_auth = true
ticket_lifetime = 24h
renew_lifetime = 24h
forwardable = true
krb4_convert = false
}
[libdefaults]
default_realm = MYDOMAIN.LOCAL
ticket_lifetieme = 24h
dns_lookup_realm = false
dns_lookup_kdc = false
kdc_timesync = 1
ccache_type = 4
forwardable = yes
rdns = no
default_keytab_name = /etc/krb5.keytab
default_tgs_enctypes = des-cbc-crc rc4-hmac des-cbc-md5
default_tkt_enctypes = des-cbc-crc rc4-hmac des-cbc-md5
permitted_enctypes = des-cbc-crc rc4-hmac des-cbc-md5
clock_skew = 300
[realms]
MYDOMAIN.LOCAL = {
kdc = serverdc.mydomain.local:88
kdc = serverdc2.mydomain.local:88
admin_server = serverdc.mydomain.local:749
default_domain = MYDOMAIN.LOCAL
}
[domain_realm]
.mydomain.local = MYDOMAIN.LOCAL
mydomain.local = MYDOMAIN.LOCAL
[logging]
default = FILE:/var/log/krb5lib.log
kdc = FILE:/var/log/krb5kdc.log
kdc = SYSLOG:INFO AEMON
admin_server = FILE:/var/log/kadmin.log
Проверим правильность настройки kerberos
kinit usertest
usettest это может быть любой пользователь их AD если после ввода пароля не было никаких сообщений значит все хорошо можно двигаться дальше, если есть ошибки стоит ещё раз внимательно перепроверить файл /etc/krb5.conf.
Теперь проверим кейтаб который мы сделали ранее на контроллере домена:
kinit -V -k -t /etc/krb5.keytab HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL
Должно быть сообщение об успешной авторизации. Если наблюдаются ошибки то здесь они могут быть самыми не очевидными например не поддерживается алгоритм шифрования однако лечится генерацией кейтаба с исправленным hostname. Короче нужно ещё раз внимательно проверить что кейтаб был сгенерирован с правильными параметрами с полным доменным именем прокси сервера. Ещё помнится как то долго бился пока не заменил везде hostname на более короткий. Также нужно убедиться что в DNS сделана правильная A запись для прокси сервера.
Установка SQUID
Теперь перейдем к установке squid
apt-get install squid3 libpam-krb5
Скажем squid создать кэш и перезапустим чтобы проверить что он работает.
squid3 -z /etc/init.d/squid3 restart
Cоздаем файл /etc/pam.d/squid в который пишем:
auth required pam_krb5.so session required pam_krb5.so account required pam_krb5.so password required pam_krb5.so
Теперь нужно дописать в начало файла (после второй строки) /etc/init.d/squid3
KBR5_KTNAME=/etc/krb5.keytab export KRB5_KTNAME
И назначим права на кейтаб:
chown proxy:proxy /etc/krb5.keytab chmod 664 /etc/krb5.keytab
Переходим к редактированию конфига /etc/squid3/squid.conf
acl manager proto cache_object acl localhost src 127.0.0.1/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager include /etc/squid3/auth.conf http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all http_port 3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 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
Конфиг на самом деле дефолтный кроме строки номер 18 где опцией unclude подключается файлик с дополнительными настройками.
Создаем файлик include /etc/squid3/auth.conf в котором пишем самое главное:
#Используем специальный helper для прозрачной аутентификации через kerberoos #auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL auth_param negotiate children 20 auth_param negotiate keep_alive on #Используем kerberos через систему pam для базовой авторизации с запросом пароля auth_param basic program /usr/lib/squid3/basic_pam_auth -n squid auth_param basic children 10 auth_param basic credentialsttl 2 hours auth_param basic realm MYDOMAIN.LOCAL #Необходимо для поиска групп в AD #external_acl_type ldap_check ttl=1200 children=15 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "dc=mydomain,dc=local" -f "(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=mydomain,dc=local))" -D "squid@mydomain.local" -w "MegaPass123" -K -d 192.168.0.8 external_acl_type ldap_check ttl=1200 children=15 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "dc=mydomain,dc=local" -f "(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=mydomain,dc=local))" -D "squid@mydomain.local" -w "MegaPass123" -K 192.168.0.8 #Описание групп доступа из AD acl all_it external ldap_check IT acl all_student external ldap_check Students acl all_inet external ldap_check inet #Описываем пользователей которые невходят в другие группы acl auth proxy_auth admin@MYDOMAIN.LOCAL acl auth proxy_auth sasha@MYDOMAIN.LOCAL #Назначаем разрешения кому можно ходить в интернет http_access allow all_student http_access allow all_inet http_access allow all_it http_access allow auth
Строчки 2 и 13 отличаются от 3 и 14 только параметром -d который можно использовать чтобы получить более подробную информацию о процессе авторизации в логах для обычной работы он ненужен.
Перезапускаем squid
/etc/init.d/squid3 restart
проверим что в логах нет ошибок
tail -n 50 /var/log/squid3/access.log
Если все впорядке то осталось настроить браузер на клиенте.
Настройка браузера
Для прозрачной авторизации нужен Internet Explorer 7 версии и выше т.к. на более ранних версиях протокол kerberos не поддерживается. В настройках нужно указывать обязательно полное имя прокси сервера proxy.mydomain.local и порт 3128.
Краткая инструкция по настройки прокси есть в отдельной статье тут.
На этом всё, комментарии, исправления и дополнения приветствуются.
Спасибо за подробный материал. Есть вопрос: Не проходит авторизация пользователя. В отладке сквид пишет, что достукивается до контроллера АД и проводит поиск в группах, а пользователю всё равно запрещено выходить в интернеты. Куда копать?
Поиск в группах проходит через обычный windows запрос ntlm и тут проблемы могут быть только в не правильно написаным фильтре по группе.
Проблемы в основном бывают в самой авторицации пользователя тут нужно смотреть прошел ли пользователь авторизацию и если нет то какие ошибки выдает.
Если с авторизацией все впорядке то нужно проверить что перед разрешающими правилами:
http_access allow auth
нету запрешающих правил типа:
http_access deny all
Ну и всякие мелочи тоже нужно проверить типа что пользователи входят в указаную группу, время везде одинаковое и регистр имени домена везде соблюден — керберос любит придераться к таким мелочам.
Здравствуйте, отличная статья, думаю нужно знать некоторые полезные команды при настройке squid:
после редактирования конфига обязательно используйте вот эту команду: squid -k parse, она проверит файл на наличие синтаксических ошибок. Для того, чтобы squid применил внесенные в конфиг изменения без перезапуска самого «себя»)), т.е просто перечитал свой конфиг и применил изменения, делаем так:
squid -k reconfigure.
Я кстати написал о том, как я настраивал squid на работы с AD вот ссылка http://www.artcom-ufa.ru/posts/2012/07/28/nastroika-squid
Спасибо за полезный коммент. Надо будет написать статейку о базовых вещах в сквиде, а то для новичков керберос очень страшный зверь.
И в вашей статье там тоже есть парочка полезных моментов.
y menia problema smagli vi pamoch
kinit: Client not found in Kerberos database while getting initial credentials
Если напрямую читать то «Указанного пользователя не существует в домене». Возможно просто неправильно указали параметры для kinit или проблемы с кейтабом например нет прав на чтение.
kinit: Client not found in Kerberos database while getting initial credentials
«В настройках нужно указывать обязательно полное имя прокси сервера proxy.mydomain.local и порт 3128.»
Не заморачивался с настройкой клиентов — указал в iptables заворачивать запросы с 80 и 8080 портов на 3128
Порт можно в настройках поменять но в празрачном режиме браузеры вообще не передают запросы на авторизацию на проксе. А керберос ещё придерается если вместо dns имени указать ip или имя незарегистрированое в кейтабе. Так что настройки прокси всеравно нужно указавать руками, в груповых политиках или файликом автонастройки типа wpad.dat
Отличная статья! Мне помогло, спасибо огромное. Единственное дополнение, при создании keytab указал метод шифрования ALL. После этого авторизация заработала в домене на базе WS2008r2. Вопрос, кто-нибудь пробовал настроить авторизацию для пользователей из других доменов. Есть такая структура, мой домен ad1.firma.com, есть филиалы с доменами fil1.ad1.firma.com fil2.ad1.firma.com и есть филиалы с доменом ad2.firma.com. Авторизацию из доменов fil1.ad1.firma.com fil2.ad1.firma.com пользователи проходят, но доступ в интернет не получают, squid пишет «Доступ запрещен». В группу в моем домене я добавил пользователей из доменов fil1.ad1.firma.com и fil2.ad1.firma.com, но судя по всему не удается прочитать список пользователей из доменов fil1.ad1.firma.com и fil2.ad1.firma.com. Пользователи из доменов ad2.firma.com не проходят авторизацию. Как можно настроить авторизацию в squid по такой структуре?
Спасибо за статью.
Не могли бы вы сказать для чего указываете два типа авторизации:
«#Используем специальный helper для прозрачной авторизации через kerberoos» и «#Используем kerberos через систему pam для стандартной авторизации с запросом пароля».
Это чтобы те, кто не авторизован в домене, могли использовать прокси, если их пользователь описан вне группы? Если да, то получается, что если мне нужна только прозрачная авторизация, я могу не описывать pam?
Все правильно сначала прокси пытается договорится с браузером о прозрачной авторизации, и если не получается то обрабатывает по правилам pam. Однако прозрачная авторизация работает только с современными браузерми при условии что компьютер в домене. При этом большинство программ не умеет ничего кроме базовой авторизации нам например нужно пускать skype, 1с и др. вот для них и сделана авторизация в домене через прослойку pam.
Либо Вы не понимаете разницы между аутентификацией и авторизацией, либо я не понимаю где тут настраивается и как работает авторизация через kerberos (В этом случае очень прошу подсказать, т.к. не могу решить проблему)
Да действительно есть ошибки с терминологией, статью обновил. Авторизацией в данном случае занимается squid, а kerberos протокол аутентификации.
Привет ребят я ламер) ток пробую себя в юнексе помогите вот с чем как правильно описать или где взять уту строку
external_acl_type ldap_check ttl=1200 children=15 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b «dc=mydomain,dc=local» -f «(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=mydomain,dc=local))» -D «squid@mydomain.local» -w «MegaPass123» -K 192.168.0.8
вот то что я сделал и получил но проверку не могу пройти где то ошибка
http://s020.radikal.ru/i708/1603/9a/5988d743b77d.png
http://i053.radikal.ru/1603/57/5bea72f0563a.png
http://s019.radikal.ru/i642/1603/37/d5796337ee58.png
кейтаб проверен связь есть проверки проходит
Ошибка в этом squid_ldap_group теперь его зовут ext_ldap_group_acl
Ещё одна ошибка, пока не могу выяснить в чём запинка WARNING: external_acl_type option children=N has been deprecated in favor of children-max=N and children-startup=N
Да этот хелпер переименовали и синтаксис параметров немного изменился вместо children=15 теперь два параметра children-startup=5 и children-max=15 хотя если их не ставить то будут использоваться числа по умолчанию.
Убрал эти 2 параметра ttl=1200 children=15
Относятся к кешу походу мне не нужен кеш
осталось немного на этот раз не знаю что ковырять вот теперь ребят ХЕЛП
http://s018.radikal.ru/i524/1603/c8/5ec28e7471c3.png
squid.conf
#acl manager proto cache_object
cache deny all
#acl localhost src 127.0.0.1/32 ::1
#acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
# Добавляем описание нашей подсети:
acl localnet src 192.168.15.0/24
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
include /etc/squid3/auth.conf
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
# Этой строчкой разрешаем использование squid из локальной сети:
http_access allow localhost
http_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
error_directory /usr/share/squid3/errors/Russian-1251
coredump_dir /var/spool/squid3
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
auth.conf
#Используем специальный helper для прозрачной аутентификации через kerberoos
#auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s proxy@UNLIS.LOCAL
auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -s proxy@UNLIS.LOCAL
auth_param negotiate children 20
auth_param negotiate keep_alive on
#Используем kerberos через систему pam для базовой авторизации с запросом пароля
#auth_param basic program /usr/lib/squid3/pam_auth -n squid
auth_param basic program /usr/lib/squid3/basic_pam_auth -n squid
auth_param basic children 10
auth_param basic credentialsttl 2 hours
auth_param basic realm UNLIS.LOCAL
#Необходимо для поиска групп в AD
#external_acl_type ldap_check ttl=1200 children=15 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b «dc=mydomain,dc=local» -f «(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUs$
external_acl_type ldap_check %LOGIN /usr/lib/squid3/ext_ldap_group_acl -R -b «dc=unlis,dc=local» -f «(&(objectclass=users)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=unlis,dc=local))»$
#Описание групп доступа из AD
acl all_it external ldap_check IT
acl all_student external ldap_check Students
acl all_inet external ldap_check inet
#Описываем пользователей которые невходят в другие группы
acl auth proxy_auth Administrator@UNLIS.LOCAL
#Назначаем разрешения кому можно ходить в интернет
http_access allow all_student
http_access allow all_inet
http_access allow all_it
http_access allow auth
Проверь ldap фильтр в частности memberof=cn=%a,ou=Groups,ou=MainUsers,dc=unlis,dc=local указывает где в AD хранятся группы доступа, переменная %a подставляется из acl к примеру для:
acl all_it external ldap_check IT
в AD должна быть группа cn=IT,ou=Groups,ou=MainUsers,dc=unlis,dc=local
Запутался у меня unlis.local-UNIXs-groups и там группы Inet, IT, Students.
Вот моя строка из конфига значения %a %v должны в автомате подставиться или я что то путаю? на фоне приведённой строки моего домена и подразделения не могли бы написать.
(&(objectclass=users)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=unlis,dc=local))
Спасибо!
Да %a %v эти переменные squid подставляет
%a — имя группы
%v — логин пользователя
Оргюниты (ou) в обратном порядке пишутся:
(&(objectclass=users)(sAMAccountName=%v)(memberof=cn=%a,ou=groups,ou=UNIXs,dc=unlis,dc=local))
А вообще стоит почитать как формируются ldap фильтры в AD еще пригодится в том же виндовом powershell
Пишет что мне доступ запрещён страничка сквида.
Перебрал по группам что бы пользователь входил в групп, и бестолку запрет и всё! Что смотреть?
Смотри в каком порядке в конфиге идут http_access.
Сквид обрабатывает правила доступа по порядку до первого совпадения и последним обычно ставят запрет всего
http_access deny all
и если есть правила после этой строчки то они игнорируются.
Спасибо!
Привет подскажите когда пользователь входит в группу разрешено инет есть если пользователя переместить в группу где нет инета то у пользователя он всё равно есть да же если и пере зайти в винду, но если же перезапустить squid то инет пропадает что соответствует значению группе. Такое чувство что где то или сквид хранит эти данные как это убрать? Сквид не прозрачный без кеша.
Да так и должно быть squid запоминает результаты предыдущего запроса пользователя. В данном случае директива external_acl_type хранит запрос столько сколько указано в параметре ttl, если ttl не указан то по умолчанию он равен 3600 сек. (1 час). Делается это в целях оптимизации работы прокси сервера, но помните что если поставить слишком маленькое значение ttl это может привести к высокой нагрузке на сервер при большом количестве одновременных клиентов. Поэтому правильнее не менять группы слишком часто.
Спасибо! Дочитался и уже понял! Сори за глупые вопросы только учусь 🙂
Добрый день!
Можно поподробнее рассказать о работе skype, icq и прочего подобного добра через squid c kerberos-аутентификацией? Долгое время использовали только ntlm и basic аутентификации. Вот начитался про безопасность kerberos и решил настроить.
На всякий случай перечислю версии ПО, вдруг кому-то помочь смогу, потому что пока разбирался испытал на себе все возможные ошибки). Итак: контроллеры домена — Windows Server 2008 R2, прокси-он же шлюз — CentOS 7.2.15.11, Squid 3.3.8.
В общем-то, до определённого этапа всё получилось — авторизация на основе групп AD, белые/черные списки сайтов. Единственный момент — не работает ничего, кроме браузера). Через браузер идут (смотрю access.log) прекрасные/желанные TCP_MISS 200, с указанием пользователя ivanov@DOMAIN.LOCAL, а из этих приложений (пусть будет Skype) запросы CONNECT на адреса скайповских серверов (443 порт) получают 407 и никакого пользователя в строке нет. То есть, скайп либо «пытается и не может» (значит, проблема в конфиге squid), либо «не умеет» аутентифицировать свои запросы по kerberos. Вот этого не могу понять.
Если явно разрешить метод CONNECT на 443 порт, то подключается на ура, но в таком случае, правило работает и для неавторизованных в домене пользователей. При этом по NTLM всё работает — и приложения посылают авторизованные запросы и доступом в Сеть через браузер можно рулить как угодно(чего тебе еще надо!?). Буду очень благодарен за информацию по вопросу.
Да к сожалению Negotiate(kerberos) и ntlm поддерживается далеко не всеми программами поэтому для них приходится использовать basic аутентификацию. При этом как вы правильно заметили такие программы сначала пытаются пройти с неправильной аутентификацией и получают 407 ошибку. Но вместе с ошибкой обратно squid отправляет программе список поддерживаемых протоколов аутентификации и программа должна повторить попытку с новым протоколом у меня вторым идет basic протокол и большинство нормальных программ заходит со второй попытки.
При этом skype ещё важно правильно настроить. Во первых нужно обязательно убрать голочку skype wifi потом в настройках соединения прописать https прокси, логин пишется через собаку например ivanov@domain.local. Входящий порт ставим любой skype его все равно не сможет использовать если прокся за NAT и поставить галочку использовать дополнительные порты 80 и 443. Скайп при первой авторизации может долго запускаться до 2 минут перебирая настройки, а второй вход уже быстрый.
Но не все программы нормальные. Вот например Opera 12 на старом движке вообще ничего не помогало, Negotiate она неумела, а до basic похоже не доходила. Многие программы вообще не умеют работать через проксю особенно этим грешат почтовые программы и вебинары. Ещё у коллеги на макбуке после обновления skype на более новую версию вообще напрочь перестал воспринимать свои настройки прокси хотя это давно было не знаю может это уже починили. Firefox, internet explorer, chome без проблем работают с Negotiate(kerberos). Но было забавно что web инсталятор chrome не принимал аутентификацию и обновиться можно было только через standalone установщик. В общем с прокси серверами есть очень много тонкостей и проблем поэтому приходится сильно постараться чтобы обеспечить очередную «совтинку» интернетом.
Нда, дело в том, что по ntlm(а это именно он — я проверил, отключив все остальные программы) скайп и иже с ним работают сейчас работали при мне года 4, пережив все обновления. И абсолютно никаких настроек соединения мы не указываем. Да это и не очень удобно — многие сотрудники уезжают по командировкам с рабочими ноутами, им с головой хватает отключения прокси в браузере). При этом (ntlm) скайп посылает строго авторизованные запросы, все взаимодействие его со своими серверами записывается в статистку sarg’ем (так любимым руководством). Если добавлять еще kerberos в конфиг сквида, придется разбираться и допиливать еще и сардж этот самый. Как минимум по ntlm в логи пишется только имя пользователя, а по керберос имя@домен. Ну и т.д. Так вот я и думаю, а так ли он нужен этот самый керберос.
Из-за чего вообще я туда полез? Старый шлюз верой и правдой, отслужив 24/7 9 лет начал медленно ложиться. Поставили новый, ну и соответственно версии многих программ обновились. В т.ч и сквид начал чудить — выкидывать окна авторизации там, где их раньше не было. В ситуации, когда юзеру запрещен любой доступ в инет, кроме сайтов из белого списка. Поскольку, если исследовать исходный код страницы сайта — то в большинстве случаев, там будут ссылки на другие ресурсы(вставки лент соцсетей и т.д), которых в белом списке, естественно, нет. И на каждый такой сайт браузер выкидывал окно авторизации, нажимая на отмену (бывает и 20 раз) переходишь на разрешенный сайт.
На одном из форумов подсказали, что не отрабатывает нормально SSO(единая точка входа), реализована эта штука в kerberos — делай его. Самое главное, что пока ковырялся разобрался и с вылетающим окном. Не сказать, что глубоко понял проблему, но понял, что вместо нужной мне «403 Forbidden» при попытке перехода на сайт, подпадающий под команду deny, я получаю «407 — Proxy Authentication Required». В документации по сквиду (не знаю, можно тут ссылки постить?) нашел такую запись:
For example, this normal configuration will cause a login re-challenge until working details are presented:
http_access deny mustLogin
This «all hack» will present a plain access denied page without challenging for different credentials:
http_access deny mustLogin all
добавив к запрещающему правилу all — затыкаем его наглухо.
На несколько таких моментов нарвался, но всё расписывать, конечно, смысла нет. Жаль, что нельзя сослаться на какую бы то ни был документацию по программе — написали бы ясно «скайп поддерживает то-то и то-то, работает с тем-то и с тем-то, а сюда не лезьте даже». А то так получается бродишь как ежик в тумане.
Спасибо за ответ, в любом случае. Наверное, буду отказываться пока от kerberos.
Basic исторически появился одним из первых. Ntlm это первая реализация sso реализованная микрософттом. Kerberos одна из последних реализаций sso для микрософта. А последней можно считать OAuth. Поэтому вполне естественно что старые протоколы поддерживаются большинством, а самые новые почти никем.
И да скайп под маком про который я говорил вообще перестал делать любые запросы к прокси серверу хотя он был прописан у него в настройках что интересно это произошло через несколько месяцев после покупки скайпа микрософтом. Ну да это все мелочи продукты apple и microsoft вообще как показывает практика не очень дружат друг с другом.
А вот то что skype работает без настроек прокси это не совсем правда где то ведь прописан порт прокси например 3128 иначе он будет ломится в обход прокси напрямую на 80 и 443 порты. Наверняка где то в сетке есть либо файлик wpad.dat либо прокся прозрачная. Но насколько я знаю с transparent squid вообще не работает никакая аутендификации.
Если окошко с аутентификацией вылезает но редко то у вас скорее всего не хватает свободных хелперов ntlm чтобы запрос обработать. Причины могут быть разные например стало очень много сотрудников которые работают с интернетом одновременно, а хелперов мало и они не успевают отработать. Но если навешать много черно-белых списков то может сильно возрасти нагрузка на сервер и уже все начнет притормаживать включая хелперы ntlm. Я вот например никак не могу squidGuard побороть чтобы он процессор не сьедал но там дикие многомегабайтные списки которые сам сквид все равно не переварит и загнется. В общем через Squid Cache Manager посмотрите статистику использования хелперов ntlm.
Ну прокси прописан в браузере (IE), а в скайпе по дефолту в настройках соединения стоит «Автом. обнаружение прокси-сервера» и чекбокс «для доп. входящих соединений использовать 80 и 443». Но туда даже не заглядываем. Ставишь — и работает сразу. Видимо, хорошо и правильно берёт из браузера. Сценариев автоматической настройки прокси нет. С прозрачным прокси авторизация не работает — точно. Спасибо за иноформацию.
Спасибо за статью, очень помогла!
Не получается в Centos 7 сделать basic:
# /usr/lib64/squid/basic_pam_auth -n squid -t 300 -o
при вводе имени пользователя и пароля выдает ERR, в логе:
localhost basic_pam_auth: pam_krb5[7775]: called to authenticate ‘username’, configured realm ‘MY.DOMAIN.ORG’
localhost basic_pam_auth: pam_krb5[7775]: error resolving user name ‘username’ to uid/gid pair
Если ввести имя пользователя и пароль, который использовался при генерации keytab’а, то:
# /usr/lib64/squid/basic_pam_auth -n squid -t 300 -o
squid supersecretpass
OK.
При этом:
# kinit username не выдает ошибок. Ну и доменные машины работают по SSO, нужно реализовать работу доменных пользователей на маках и личных машинах, телефонах. Подскажете, куда копать?
Попробуйте в файле /etc/krb5.conf в секции pam аутентификации изменить шаблон для параметра:
alt_auth_map = %s@DOMAIN.ORG
А вообще при использовании доменных учеток желательно всегда явно указывать домен например username@domain.org это решает половину проблем с аутентификацией. Если комп не в домене то IE и другие программы микрософта пытаются использовать имя текущего компьютера вместо домена, что обычно приводит к ошибке. На личных машинках так же всегда нужно следить чтобы время совпадало с тем что на серверах. На телефонах проблема в том что настройки прокси не всегда просто найти и зачастую работают они только с браузером. Ну и напоследок нужно ещё учитывать что есть программы которые принципиально не умеют ходить через проксю но это отдельная история.
Да, всегда явно указываю домен.
Изменил шаблон, добавил имя домена. Все равно squid не пропускает, выкидывает окно авторизации вновь и вновь, только теперь в логе:
kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
Хммм… Видимо беда браузеров. Запустил на машине IE, единожды введя учетные данные получил доступ в интернет. А как же другие браузеры научить работать с этой схемой?
Да есть такая проблема не все браузеры умеют использовать kerberos, выхода два либо использовать нормальные браузеры (IE, firefox, chrome offline installer) либо настраивать древний ntlm вместо kerberos. А вот к примеру skype с недавних пор вообще через прокси перестал работать и это не лечится.
А в том и дело, что только IE заработал, Firefox и Chrome не хотят.
Странно ошибка
ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
Обычно бывает если указать неполное или неправильное FQDN имя прокси сервера в настройке браузера.
Да, видимо я уже запутался. В общем, наблюдаю сейчас картину. Авторизация доменных машин по auth_param negotiate работает исправно, даже группы правильно берет. А вот при попытке выйти в сеть с недоменной машины выходит окно запроса логина и пароля, при вводе в cache.log:
ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
а по systemctl status squid вижу:
proxy (basic_pam_auth)[30623]: pam_krb5[30623]: error resolving user name ‘%username%’ to uid/gid pair
попробовал скормить логин и пасс
/usr/lib64/squid/basic_pam_auth -n squid
в любом варианте ввода ERR. Есть у хелпера дебаг вообще? Как понять, что не так?
Этот хелпер не имеет ключей для дебага, можно настроить дебаг через конфиги самого pam, но я без этого обходился.
А так все правильно нужно добиться чтобы хелпер
/usr/lib64/squid/basic_pam_auth -n squid
Выдавал ответ OK
В данном случае для pam используются два файла
/etc/pam.d/squid — какие библиотеки и настройки использовать для аутентификации.
/etc/krb5.conf — здесь нужно внимательно проверить параметры из секции pam
При правильной настройке хелпер может принимает логины двух видов:
username
username@domain.ru
Логины в формате domain\username неправильно обрабатываются поэтому их можно даже не пытаться набирать.
Если на сервере хелпер заработает тогда можно смотреть на клиентах.
Я совсем ничего не понимаю. В общем, видимо какая-то особенность не MS браузеров. Если выходить в сеть через IE, то после запроса логина и пароля система получает kerberos ticket и и IE и сторонние браузеры успешно работают. Если не получать kerberos ticket и выйти, к примеру, через chrome, то авторизация не проходит (точнее проходит единожды после рестарта squid, и сохраняется на время сессии (до закрытия браузера)). Помогает auth_param negotiate keep_alive off — тогда все браузеры успешно проходят авторизацию. Но все же тикет получает ТОЛЬКО IE (Edge не проверял), соответственно браузеры просят авторизацию каждый раз после закрытия. Полагаю, что за это отвечает опция auth_param basic credentialsttl 2 hours, не отрабатывает, видимо.
Ах да, /usr/lib64/squid/basic_pam_auth -n squid по прежнему выдает ERR, но в браузере пользователя можно вводить и как username@domain.ru и как domain\username )))) а вот просто username не проходит. В общем, у меня все наоборот. Centos7, Srv2012, Squid 3.5.
Все браузеры работают по разному. Обычные браузеры в целях безопасности запрашивают kerberos ticket только для доменов из белого доверенного списка. В домене компьютеры запрашивают тикеты как минимум при входе в компьютер и там все прозрачно. Но если очень надо не доменные компьютеры помучать, то как настроить белый список SPNEGO посмотреть можно здесь:
http://www.microhowto.info/howto/configure_firefox_to_authenticate_using_spnego_and_kerberos.html
https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM
В целом kerberos ticket действует только в приделах сессии и когда браузер закрывается то закрывается и сессия, чтобы получить новый тикет нужно повторно проходить аутентификацию. Из простого можно сохранить пароль, чтобы его не набирать каждый раз, но нажимать кнопку OK все равно придется.
И ещё параметры auth_param negotiate в данном случае относятся только к kerberos аутентификации. Все параметры auth_param basic относятся только к базовой не шифрованной аутентификации открытым текстом, нужно это только тем программам которые не умеют более сложные алгоритмы аутентификации.