LINUX.ORG.RU
ФорумAdmin

SQUID kerberos and failback LDAP auth

 


1

1

Всем привет!

Имею конфигу:

# egrep -v '^(#|$)' /etc/squid3/squid.conf 
auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth
auth_param negotiate children 10
auth_param negotiate keep_alive on
auth_param basic program /usr/lib/squid3/basic_ldap_auth -R -b "CN=Users,DC=xxxx,DC=ru" -f sAMAccountName=%s -h xxx -D "CN=reader,CN=Users,DC=xxx,DC=ru" -w xxx
auth_param basic children 5
auth_param basic realm Weclome!
auth_param basic credentialsttl 2 hours
acl auth proxy_auth REQUIRED
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 deny !auth
http_access allow auth
http_access deny all
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny all
http_port 3128
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 (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern .		0	20%	4320

При таком конифге, Linux работает адекватно (firefox)! Если нет kerberos билета, предлагает BASIC AUTH - c ldap. Всё ок. Windows клиенты - не важно, firefox, IE: если нет kerberos билета, выкидывают окно аутотентификации BASIC AUTH - c ldap, при вводе пароля, окно снова вылетает (и так до бесконечности). При том в логе squid такое:

TCP_DENIED/407 4702 GET http://www.google.ru/url? - HIER_NONE/- text/html

Удалось нагуглить, что Windows посылает похоже не только Kerberos, LDAP, но и NTLM запрос. От чего squid сходит с ума... http://serverfault.com/questions/544858/http-proxy-authentication-kerberos-fa... - очень походит на правду.

Что собственно делать в таком случае? Потыкал палочкой: /usr/lib/squid3/ntlm_fake_auth - но это не то, что нужно насколько я понимаю.

Как быть?

# squid3 -v
Squid Cache: Version 3.3.8
Ubuntu
configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security'
★★★★★

Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от blind_oracle

Ну я упоминал про самбу тут раньше (в этом треде). В общем рано я обрадовался... - Chrome тоже не проглатывает аутотентификацию. Но способен выбрать аутотентификатор при неправильном их порядке.

Мы пока мест смотрим на самбу, чтобы не покупать серверные винды. Нам по сути от неё нужен SSO (потому как Microsoft отказалась хранить basic пароли в своём password storage начиная с Vista (не очень правда понятно зачем тогда вообще он нужен?)). В целом всё что нам нужно вроде как работает (а именно: делегирование тикетов, SSO на нужные нам сервисы)... Но есть нюансы, есть... В частности как раз вот этот, и нюанс с автообновлением билетов. - Билеты не продлеваются в linux (автоматом имею ввиду). В Windows вроде как получше с продлением, но тоже на мой взгляд есть странности. Вот думаю, не уж-то может co squid быть такой косяк косячный из-за криворукой samba.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от DALDON

Конкретно, эта проблема со squid она в общем то не страшная. Это третьестепенный сервис. И насколько я понял, все те приложения, которые хотят ходить в Интернет, минуя настройки винды - могут авторизоваться. Ну и вообще, в целом давать Интернет только по тикетам - не самая ужасная проблема. Да и в linux вроде как работает squid по паролю. Надо попробовать правда копнуть поточнее.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

Мы пока мест смотрим на самбу, чтобы не покупать серверные винды.

Странная экономия, учитывая что купить пару копий win server standard для контроллеров будет стоить вроде тысяч 40-50 - и никакого гемора с самбой.

потому как Microsoft отказалась хранить basic пароли в своём password storage начиная с Vista (не очень правда понятно зачем тогда вообще он нужен?

Не понял о чем ты - об обратимом шифровании чтоль? Чтобы пароли можно было прочитать из лдапа? Вроде там можно галку поставить «хранить в обратимом виде», но не пробовал. Я пароли храню в отдельной бд куда они заносятся автоматом после создания юзеров.

Вот думаю, не уж-то может co squid быть такой косяк косячный из-за криворукой samba.

Ну, я других отличий вроде не вижу от своей схемы, так что дедуктивным методов приходим к выводу... :) Я бы на твоем месте поднял мини-лабу в виртуалках из контроллера домена на винде и прокси для проверки.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Странная экономия, учитывая что купить пару копий win server standard для контроллеров будет стоить вроде тысяч 40-50 - и никакого гемора с самбой.

Две версии Windows Server 2012 R2 Std - 60 тысяч.

Лицензии клиентского доступа на наш парк (Windows CAL license): 138 тысяч.

Железо где всё это крутить (облака не рассматриваю, так-как это всё же AD, а оно в облаках как-то не очень): пусть даже по 30к на тазики- 60 тысяч. Ну или виртуализация, что также не отменяет расходов.

Итого: 60+138+60 = 258 тысяч.

Шеф сказал: давай попробуем samba. Мы сейчас вообще без домена живём, и в целом успешно живём. У нас крайне большой круг задач, хоть и мало народу. Так что всё равно очень много чего приходится делать руками. Так же у нас очень много легаси ПО и сервисов.

Не понял о чем ты - об обратимом шифровании чтоль?

Нет, нет... Что ты. Я смотри об чём: когда у тебя где-либо вылетает окно с BASIC AUTH - там есть птичка - сохранить пароль. Так вот по факту эта птичка не работает начиная с WinVista. - Нам это нужно при доступе по sharepoint. Так вот они там отключили хранение пароля. И таким образом, если у тебя нету kerberos, при каждом открытии документа через протокол sharepoint у тебя будет вылезать окно - введи логин+пароль.

Ну, я других отличий вроде не вижу от своей схемы, так что дедуктивным методов приходим к выводу... :) Я бы на твоем месте поднял мини-лабу в виртуалках из контроллера домена на винде и прокси для проверки.

Да, ты прав. Просто я удивлён вот чему: формально, я могу сделать сервер kerberos, не только на samba. Могу его сделать на: Windows/samba/MIT kerberos server/389 Directory Server (хоть это тот же MIT но всё же). И т.п. Исходя из моего представления: SQUID вообще не должен ходить на kerberos сервер. Он при запуске (ну и видимо когда истекает срок жизни билета), по keytab авторизуется на kerberos сервере. Затем он ожидает билетов от клиентов. Клиент ему предъявил билет - билет валидный. - Всё, он пропустил. Тут я правда не до конца всё же понял, на счёт сессионых ключей kerberos. Но tcpdump на SQUID не показывает никакой активности в сторону samba, когда люди ходят по Интернету.

Более того: формально, мне домен тоже не нужен. Можно поставить на Windows HOME - клиент MIT Kerberos, получить билет, положить его в хранилище MSLSA: , и иметь SSO. Другое дело, что для конечного пользователя это не очень удобно, и есть там моменты с продлением билета. Но всё же. Удобнее конечно залогиниться в ОС, и сразу иметь SSO. Но формально - и такая схема работает.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Итого: 60+138+60 = 258 тысяч.

Да, про клиентские лицензии я подзабыл, давно это добро не покупал.

Насчёт серверов - у меня лично всё давно и прочно виртуализовано, физических серверов почти нет. Так что пару виртуалок поднять обычно не проблема :)

У нас крайне большой круг задач, хоть и мало народу.

Такая же фигня, поэтому я стараюсь везде где можно всё автоматизировать, и виндовое АД в этом плане очень сильно помогает. Плюс стопицот скриптов) Руками почти ничего не делается, в итоге. Щас вот на VDI перейдём и будет вообще лафа :)

Я смотри об чём: когда у тебя где-либо вылетает окно с BASIC AUTH - там есть птичка - сохранить пароль. Так вот по факту эта птичка не работает начиная с WinVista. - Нам это нужно при доступе по sharepoint.

А, это. А почему у вас нет сквозной авторизации в домене? Потому что домена по-сути нет? :) Так сделайте его и проблема сама уйдёт. У меня даже апач юзеров на странице создания тикетов авторизует керберосом абсолютно прозрачно (всё точно также как в сквиде), юзер вводит пароль только при входе в винду.

Но tcpdump на SQUID не показывает никакой активности в сторону samba, когда люди ходят по Интернету.

Так и есть. Это принцип кербероса - служба никогда напрямую не обращается к авторизационному серверу. Когда клиент хочет получить доступ к службе HTTP/squid.domain.ru, то сервер авторизации после проверки прав клиента генерирует ему тикет с сессионным ключом, который зашифрован ключом службы, т.е. тем, который в кейтабе. Поэтому если сквид смог расшифровать своим кейтабом твой запрос (там симметричная криптография, ключ на шифровку и дешифровку один и тот же), то он автоматически считает тебя авторизовавшимся.

Он при запуске (ну и видимо когда истекает срок жизни билета), по keytab авторизуется на kerberos сервере.

Хуже того, он там вообще не авторизуется :)

# klist -l
Principal name                 Cache name
--------------                 ----------

Можно получить тикет службы, но на авторизацию это никак не влияет:
# kinit -k -t /etc/squid/keytabs/squid.domain.ru.keytab HTTP/squid.domain.ru@DOMAIN.RU

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/squid.domain.ru@DOMAIN.RU

Valid starting    Expires           Service principal
24/08/2014 23:19  25/08/2014 09:19  krbtgt/DOMAIN.RU@DOMAIN.RU
        renew until 25/08/2014 09:19

Ну а резюмируя про домены - я так считаю, что раз у тебя клиенты виндовые, то домен нужен виндовый. Самба таки отстает прилично от паровоза мелкомягких и гемора с ней прилично. А виндовый дц просто работает и хрен бы ему будет. Если б клиенты были линух или макось какой, то можно что-то другое городить, а так - непонятно, ну пусть 200 тыщ на это, для почти любой конторы это небольшие деньги. А тем, для кого большие есть Windows Essentials (<=25 юзеров).

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Насчёт серверов - у меня лично всё давно и прочно виртуализовано, физических серверов почти нет. Так что пару виртуалок поднять обычно не проблема :)

У нас нету соответствующей инфраструктуры. :(

Такая же фигня, поэтому я стараюсь везде где можно всё автоматизировать, и виндовое АД в этом плане очень сильно помогает. Плюс стопицот скриптов) Руками почти ничего не делается, в итоге. Щас вот на VDI перейдём и будет вообще лафа :)

У нас недавно праздник был, мы убрали последнюю WinNT. Теперь убираем Win2k. VDI это хорошо. Но есть там много моментов. Кладя все яйца в одну корзину встаёт ряд вопросов: начиная от профессиональности системного администратора, до увеличения пропускной способности сети. VDI это можно сказать домен для железяк. Всё это ОЧЕНЬ круто, но у нас VDI на все места не сгодится. К сожалению полностью гомогенную инфраструктуру не получится сделать. И бизнес не совсем понимает: зачем нам VDI, когда и так всё работает... - К слову, нам VDI насчитали на 12 млн. руб.

А, это. А почему у вас нет сквозной авторизации в домене? Потому что домена по-сути нет? :) Так сделайте его и проблема сама уйдёт.

Ну да... Но тут возникает ряд моментов, начиная с того, что часть Windows HOME версий. Есть часть ноутбуков, есть удалёнщики со своим хомячковым оборудованием...

Это принцип кербероса - служба никогда напрямую не обращается к авторизационному серверу. Когда клиент хочет получить доступ к службе HTTP/squid.domain.ru, то сервер авторизации после проверки прав клиента генерирует ему тикет с сессионным ключом, который зашифрован ключом службы, т.е. тем, который в кейтабе. Поэтому если сквид смог расшифровать своим кейтабом твой запрос (там симметричная криптография, ключ на шифровку и дешифровку один и тот же), то он автоматически считает тебя авторизовавшимся.

Спасибо за более подробное пояснение, в целом я так себе всё это и представлял.

Хуже того, он там вообще не авторизуется :)

Вооот. Это я как раз и отметил. И по сему не до конца понимаю роль keytab на сервере squid.

Можно получить тикет службы, но на авторизацию это никак не влияет:

Да, это я тоже подметил.

Ну а резюмируя про домены - я так считаю, что раз у тебя клиенты виндовые, то домен нужен виндовый.

В целом согласен. У меня 90 процентов это Win клиенты. Другое дело, что они несколько разных версий все и разных поколений... HOME/PRO. 2000/Vista/7/XP.

А тем, для кого большие есть Windows Essentials (<=25 юзеров).

Ага, в курсе про эту штуку. Не дорогая совсем.

В общем резюмируя наш разговор: я так и не понимаю, почему SQUID может себя так странно вести... Или не SQUID а его клиенты... Вот в чём дело. Что может такого делать косячного samba, что вот ТАК ВОТ это сбоит..? Прям не понимаю.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

И по сему не до конца понимаю роль keytab на сервере squid.

Ну дык как раз для дешифровки сессионного ключа, который клиент передает. Если он дешифровался - клиент авторизован, все довольны.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Спасибо! Понял. Пока мест поковыряю это добро ещё малость. :) Может чего и выйдет ещё толкового.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Слушай, у меня пока мест нету времени на поднятие виндового DC, мне вот чего подумалось то...

Если у меня нет kerberos тикета, то squid вообще должен не обращать внимания ни на что и сувать мне BASIC AUTH... - И уж тем более не должен обращать внимания на ДЦ. Так-как я хочу BASIC AUTH. То есть домен не при делах. Однако, остаётся один момент: keytab. Быть может, squid его читает, и там что-то не так сгенерированно... - Вот в это я охотно поверую, ибо по сути только keytab меня и связывает с доменом. Больше то ничего. Я ведь прихожу без kerberos...

Пожалуйста, покажи мне:

root@gateway:~# klist -kt /etc/squid3/squid.keytab 
Keytab name: FILE:/etc/squid3/squid.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 01.01.1970 03:00:00 HTTP/proxy.company.ru@COMPANY.RU

Есть мнение, что я олух просто, и не правильно подготовил keytab. В частности, меня смущает kvno 1 (кстати, я до конца так и не понял, на что влияет этот kvno, это вроде как формат/версия билета?).

Keytab генерировал так (Win 2008 SP2):

ktpass /princ HTTP/proxy.company.ru@COMPANY.RU /mapuser squid@COMPANY.RU /pass xxxxxxxxxx /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL -out c:\squid.keytab
DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

Если у меня нет kerberos тикета, то squid вообще должен не обращать внимания ни на что и сувать мне BASIC AUTH... -

Нет, не так. Алгоритм авторизации следующий:

1. Твой браузер отправляет проксе запрос GET что-то там

2. Прокся настроена на авторизацию методами BASIC и NEGOTIATE и отвечает на запрос ответом «407 Proxy authentication required», где в заголовке перечислены методы авторизации, которые прокси умеет

3. Браузер выбирает подходящий ему метод (по RFC - самый надежный, см. посты раньше о баге в IE, который ломился в первый попавшийся) и отправляет GET запрос еще раз, но уже с заголовком с авторизационными данными (тикетом кербероса с сессионным ключом и т.п.)

Пожалуйста, покажи мне:

Всё аналогично:

Keytab name: FILE:/etc/squid/keytabs/squid.domain.ru.keytab
KVNO Timestamp        Principal
---- ---------------- ---------------------------------------------------------
   1 01/01/1970 03:00 HTTP/squid.domain.ru@DOMAIN.RU
Кейтаб это таблица (что ясно из названия) и в ней может быть несколько ключей, так что KVNO это просто индекс ключа в файле.

Keytab генерировал так (Win 2008 SP2):

А зачем яго в винде генерить, если у тебя домен на самбе?.. Генерируй через mskutil

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

mskutil - то ещё поделие... Я так понимаю проект не развивается. Ему правда может и развиваться особо некуда, но я так поглядел на него, и покамест не стал связываться. Его поставить - то ещё дело... Я ставил. Генерил ключи, но мне что-то не понравилось... А вот чего: не понравилось: kvno оно там ставило странные, и TimeStamp реальный. - Почему кстати он от 1970 года? :)

Так... Ну ты описал процедуру аутотентификации ровно так, как я себе её представлял. Раз ключи у нас с тобой одинаковые, то может быть krb5.conf отличается..? Зачем кстати хэлперу kerberos нужен krb5.conf, если его уже keytab накормили..?

SQUID kerberos and failback LDAP auth (комментарий) - сейчас погляжу внимательнее на твой пост, и твой krb5.conf. Они у нас отличаются. Ну это единственное в таком случае, что ещё может связывать SQUID и samba домен. Не очень понимаю зачем нужен правда этот файл в случае keytab.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

В общем содрал твой keytab - не помогло. :( Остаётся... Зимовать. Или понять зачем нужен таки krb5.conf при наличии keytab.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

mskutil - то ещё поделие... Я так понимаю проект не развивается. Ему правда может и развиваться особо некуда, но я так поглядел на него

Ну оно 13 года обновилось последний раз, нормуль. Может дошло до идеала, да :)

Зачем кстати хэлперу kerberos нужен krb5.conf, если его уже keytab накормили..?

Может разве что для описания имеющихся реалмов\доменов и ограничения типов шифрования ключей, мол принимать только aes, остальное в баню. А для basic/pam авторизации еще как нужен. У меня через него же еще и сокс прокси авторизуется.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Может разве что для описания имеющихся реалмов\доменов и ограничения типов шифрования ключей, мол принимать только aes, остальное в баню.

Ну блин, если ты прав, то как может влиять samba на процесс выбора способа аутотентификации... Искренне не понимаю! Прям уже есть желание накатить squid постарше куда-нибудь, запихать ему в глотку keytab и попробовать.

А для basic/pam авторизации еще как нужен. У меня через него же еще и сокс прокси авторизуется.

Ну для модуля PAM - всё понятно, тут нет вопросов, очевидно оно нужно чтобы он за тебя получал билеты.

Кстати, какой у тебя сокс? Ты его через kerberos не научил? :( Чего через него гоняешь?

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

Сокс данте, гоняю через него скайп и еще чёто вроде, не помню уже. Скайп вроде не умеет через керберос, хотя могу ошибаться, разбираться лень.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Вот тоже хочу dante. Руками прописываешь его в скайпе? Кстати, а что будет у тебя если пользователь пропишет себе вместо http proxy в браузере, твой SOCKS, увидит мультики минуя SQUID или ты как то это предусмотрел? Почему кстати не рискнул прописывать SQUID в skype? Там всё совсем плохо с оверхедом в виде HTTP?

Как учитываешь трафик на dante?

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Да, руками эникеи прописывают пока, но вроде там групповые политики на это есть, хотя логин-пасс пока всё равно надо руками.

В браузере юзеры ничего прописывать не имеют права, им политиками там всё заблокировано нафиг :) Ну и скайп стоит только у узкого круга ограниченных людей, так что люлей раздать, если что вдруг, будет нетрудно.

Сквид почему нет, уже не помню - толи он не работал толком, толи только чаты работали, а голосовые звонки - нет, давно это было. Можно будет попробовать ради интереса еще разок, авось запашет.

Траффик я не учитываю, у нас канал гигабит анлим, как-то пофиг в общем. Но, в принципе, можно по логам данте смотреть, а встроенного механизма там вроде особо нет.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Всё так, всё так барин.

В браузере юзеры ничего прописывать не имеют права

Так portable firefox таскаютЪ... Или ты настолько суров, что сумел запретить запуск всех exe кроме доверенных?

Если дойдут руки, сегодня сделаю apt-get install squid на ubuntu 12.04. Благо машинка есть уже под рукой. Посмотрю на старый squid.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

Так portable firefox таскаютЪ... Или ты настолько суров, что сумел запретить запуск всех exe кроме доверенных?

Уже почти до этого дошли - софт только из program files, куда доступа на запись у юзверей нет. USB уже у всех заблокирован на запись, только чтение разрешено. Параноя она такая :)

blind_oracle ★★★★★
()
Ответ на: комментарий от DALDON

То же самое с W2012 в качестве КД

Настраиваю прокси, хочу, чтобы браузер не спрашивал у пользователя, кто он такой, а чтобы брал данные,
введенные пользователем при входе в систему. Пришел к тому, что требуется аутентикация по керберос.
Делаю на OpenSUSE 12,3 присоединенной к домену ALG.LAN; Прокси - squid 3.2.11 ; хост alg-gw7
контроллер домена сделан на W2012

Для хоста на контроллере домена создал кейтаб-файл.
Создавал так:

ktpass /princ HTTP/alg-gw7.alg.lan@ALG.LAN /mapuser alg-gw7$@alg.lan /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass пароль /out путь 

Созданный файл проверяю на Проксе:

kinit -V -k -a HTTP/alg-gw7.alg.lan 
Using default cache: /tmp/krb5cc_0 
Using principal: HTTP/alg-gw7.alg.lan@ALG.LAN 
Authenticated to Kerberos v5 

klist 
Ticket cache: FILE:/tmp/krb5cc_0 
Default principal: HTTP/alg-gw7.alg.lan@ALG.LAN 

Valid starting     Expires            Service principal 
09/05/14 10:01:26  09/05/14 20:01:36  krbtgt/ALG.LAN@ALG.LAN 
        renew until 09/06/14 10:01:26 

Конфиг сквида в части, которая касается пользователей, прошедших аутентикацию или авторизацию

auth_param basic program /usr/sbin/basic_ldap_auth -d -b "dc=alg,dc=lan" -R -D wwwrun@alg.lan -W /etc/squid/pass -f "sAMAccountName=%s" -h alg-dc1.alg.lan
auth_param negotiate program /usr/sbin/negotiate_kerberos_auth -i -d -r -s HTTP/alg-gw7.alg.lan@ALG.LAN
acl allowinett proxy_auth REQUIRED
external_acl_type ldapgroup %LOGIN /usr/sbin/ext_ldap_group_acl -d -R -b "dc=alg,dc=lan" -f "(&(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%a,OU=Internet-Access,OU=ANYWHERE,dc=alg,dc=lan))" -D wwwrun@alg.lan -W /etc/squid/pass alg-dc1.alg.lan
acl inet_access_0 external ldapgroup IA-ALG-IT
acl inet_access_1 external ldapgroup IA-ALG-Acc
http_access allow allowinett
http_access allow inet_access_0
http_access allow inet_access_1
http_access deny !allowinett

То есть LDAP читаю пользователем wwwrun, созданном в AD с паролем, прописанным в файл pass
Если закомментировать negotiate, то basic прекрасно работает, спрашивает аккаунт, определяет группу и соответственно дает или не дает доступ к инет
Если раскомментровать negotiate то... спрашивает аккаунт, в зависимости от браузера два раза хром или шесть раз осел, но хоть убей в инет не пускает,а логе (заранее простите, не смог понять как сделать спойлер) cache.log в это время вот что...

negotiate_kerberos_auth.cc(316): pid=8984 :2014/09/05 11:19:25| negotiate_kerberos_auth: DEBUG: Got 'YR YIIG4gYGKwYBBQUCoIIG1jCCB......eOLg8fJZlJGLk=' from squid (length: 2359).
negotiate_kerberos_auth.cc(379): pid=8984 :2014/09/05 11:19:25| negotiate_kerberos_auth: DEBUG: Decode 'YIIG4gYGKwYBBQUCoIIG1jCCB.......eOLg8fJZlJGLk=' (decoded length:1766).                                                   negotiate_kerberos_auth.cc(199): pid=8984 :2014/09/05 11:19:25| negotiate_kerberos_auth: ERROR: gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information.                                    
2014/09/05 11:19:25| negotiate_kerberos_auth: INFO: User not authenticated                                                   
2014/09/05 11:19:25.677 kid1| helper.cc(969) helperStatefulHandleRead: helperStatefulHandleRead: 98 bytes from negotiateauthenticator 
#1
2014/09/05 11:19:25.677 kid1| helper.cc(993) helperStatefulHandleRead: helperStatefulHandleRead: end of reply found                                                                                                              
2014/09/05 11:19:25.677 kid1| UserRequest.cc(122) releaseAuthServer: releasing Negotiate auth server '0x7f33b15d41f8'
2014/09/05 11:19:25.677 kid1| helper.cc(463) helperStatefulReleaseServer: srv-0 flags.reserved = 1
2014/09/05 11:19:25.677 kid1| helper.cc(1202) StatefulGetFirstAvailable: StatefulGetFirstAvailable: Running servers 2
2014/09/05 11:19:25.677 kid1| helper.cc(1222) StatefulGetFirstAvailable: StatefulGetFirstAvailable: returning srv-0
2014/09/05 11:19:25.677 kid1| ERROR: Negotiate Authentication validating user. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. '
2014/09/05 11:19:25.677 kid1| UserRequest.cc(97) valid: Validated. Auth::UserRequest '0x7f33b12e4fc0'.
2014/09/05 11:19:25.677 kid1| UserRequest.cc(97) valid: Validated. Auth::UserRequest '0x7f33b12e4fc0'.
2014/09/05 11:19:25.677 kid1| UserRequest.cc(97) valid: Validated. Auth::UserRequest '0x7f33b12e4fc0'.
2014/09/05 11:19:25.677 kid1| UserRequest.cc(97) valid: Validated. Auth::UserRequest '0x7f33b12e4fc0'.
2014/09/05 11:19:25.677 kid1| client_side_request.cc(768) clientAccessCheckDone: The request CONNECT alt1-safebrowsing.google.com:443 is 3, because it matched 'allowinett'
2014/09/05 11:19:25.677 kid1| client_side_request.cc(781) clientAccessCheckDone: Access Denied: alt1-safebrowsing.google.com:443
2014/09/05 11:19:25.677 kid1| client_side_request.cc(782) clientAccessCheckDone: AclMatchedName = allowinett
2014/09/05 11:19:25.677 kid1| helper.cc(1202) StatefulGetFirstAvailable: StatefulGetFirstAvailable: Running servers 2
2014/09/05 11:19:25.677 kid1| helper.cc(1222) StatefulGetFirstAvailable: StatefulGetFirstAvailable: returning srv-0
2014/09/05 11:19:25.677 kid1| client_side_request.cc(138) ~ClientRequestContext: 0x7f33b1600008 ClientRequestContext destructed
2014/09/05 11:19:25.679 kid1| UserRequest.cc(126) releaseAuthServer: No Negotiate auth server to release.
2014/09/05 11:19:25.679 kid1| UserRequest.cc(126) releaseAuthServer: No Negotiate auth server to release.
2014/09/05 11:19:25.679 kid1| UserRequest.cc(125) ~UserRequest: freeing request 0x7f33b12e4fc0
2014/09/05 11:19:25.679 kid1| User.cc(14) ~User: doing nothing to clear Negotiate scheme data for '0x7f33b15d3f70'
2014/09/05 11:19:25.679 kid1| User.cc(154) ~User: Freeing auth_user '0x7f33b15d3f70'.
Логи такие, потому что уже голову сломал, не могу понять, включил сообщения отладки
Есть жуткое подозрение, что кейтаб-файл как-то неправильно создан, в сети еще есть описания,
что можно примапить к учетке пользователя, кто-нибудь может подсказать какая разница?

savranskiy73
()
Ответ на: То же самое с W2012 в качестве КД от savranskiy73

Я мапил на учётку пользователя, так-как у меня squid не в домене.

А поменяй ка местами:

auth_param basic program ... auth_param negotiate program ...

То есть так: auth_param negotiate program ... auth_param basic program ...

После этого скорее всего у тебя заработает kerberos. Но вот вполне может быть такое, что отвалится BASIC.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

Значит, я логично поступил при изготовлении кейтаба...

В таком положении, как сейчас, basic тоже не работает, если после negotiate то тоже не работает basic...

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

savranskiy73
()
Ответ на: комментарий от savranskiy73

Ага. Примерно аналогичная фигня и у меня...

Вот что можешь попробовать: http://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory - ходят слухи, что нужно NTLM обязательно настраивать. - У меня впрочем не получилось ничего. Ну я так понимаю, чтобы использовать NTLM в домене нужно уже обязательно быть. Я собственно в домен зашёл. Но толку нет. :(

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Это может показаться странным, но не могу понять, какой хелпер в моей системе за это отвечает...
Есть в системе ntlm_fake_auth и ntlm_smb_lm_auth, basic_msnt_auth и basic_msnt_multi_domain_auth
Не могу понять, как их проверить, манов на них в системе нет, два последних ругаются чуть ли не матом, что надо указать DC
Первый не ругается, но понять какие ему данные дать не могу, и что он мне должен отвечать непонятно..

savranskiy73
()
Ответ на: комментарий от DALDON

А вот просто единственный negotiate_kerberos_auth разве не может работать, без всяких других?
Чтобы, например, основную толпу, которые просто каким-то образом проникли в систему, пропускать в инет, ну тоже какой-то усредненный
А вот уже потом, если пользователь принадлежит группе ИТ или вообще ТОП, то тогда ему можно больше..

savranskiy73
()
Ответ на: комментарий от DALDON

Эту статью тоже видел, кстати, как и в других есть указание создать переменную KRB5_KTNAME и экспортировать ее
Так вот, у меня в SUSE есть каталог /etc/default и в нем лежат файлы, но ни в одном из них export не применяется
Может здесь и ошибка, что сам сквид не понимает, где кейтабфайл? Может это в SUSE не так делается?

savranskiy73
()
Ответ на: комментарий от DALDON

Kerberos работает, корректно отрабатывает kinit. С хоста самого прокси получает билет на любого пользователя, если угадал пароль. )
Если пароль не угадал - kinit ругается, что, мол провалено получение креденшлов.

kinit wwwrun
Password for wwwrun@ALG.LAN: правильный
klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: wwwrun@ALG.LAN

Valid starting     Expires            Service principal
09/06/14 18:57:09  09/07/14 04:57:28  krbtgt/ALG.LAN@ALG.LAN
        renew until 09/07/14 18:57:09
kdestroy
kinit wwwrun
Password for wwwrun@ALG.LAN: неправильный 
kinit: Preauthentication failed while getting initial credentials
Я выше выкладывал получение билета без запроса пароля с кейтаб-ключом. Причем путь к ключу я не указываю, он понимает как-бы сам...
Я правильно понимаю, при изготовлении кейтаб-ключа на учетную запись компьютера в AD устанавливается пароль,
и созданный утилитой ключ содержит: компьютер такой-то, пароль такой-то, адрес такой-то, и т.д., а аутентикатор просто читает билет и сверяет с запросом?
Я в данный момент в конфиге поменял-таки местами, как советовали, не работает, однако...
В логе вот...
2014/09/06 19:30:04 kid1| Starting new negotiateauthenticator helpers...
2014/09/06 19:30:04 kid1| helperOpenServers: Starting 1/5 'negotiate_kerberos_auth' processes
negotiate_kerberos_auth.cc(271): pid=840 :2014/09/06 19:30:04| negotiate_kerberos_auth: INFO: Starting version 3.0.4sq
negotiate_kerberos_auth.cc(316): pid=840 :2014/09/06 19:30:04| negotiate_kerberos_auth: DEBUG: Got 'здесь длиинный ключ' from squid (length: 2359).
negotiate_kerberos_auth.cc(379): pid=840 :2014/09/06 19:30:04| negotiate_kerberos_auth: DEBUG: Decode 'здесь длиинный ключ' (decoded length: 1766).
negotiate_kerberos_auth.cc(199): pid=840 :2014/09/06 19:30:04| negotiate_kerberos_auth: ERROR: gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. 
2014/09/06 19:30:04 kid1| ERROR: Negotiate Authentication validating user. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. '
2014/09/06 19:30:04| negotiate_kerberos_auth: INFO: User not authenticated
в соседней теме парень пишет, что тупил squidGuard, он у меня тоже установлен, но я его не трогал вообще... и следов присутствия нет и логов его нет и процесса такого нет

savranskiy73
()
Ответ на: комментарий от DALDON

Вот последняя редакция моего конфига:

# Squid 3.2.11
# debug_options ALL,1 84,9 85,5 82,3 29,6
auth_param negotiate program /usr/sbin/negotiate_kerberos_auth -i -d -r -s HTTP/alg-gw7.alg.lan@ALG.LAN
auth_param negotiate children 5
auth_param negotiate keep_alive on
auth_param basic program /usr/sbin/basic_ldap_auth -d -b "dc=alg,dc=lan" -R -D wwwrun@alg.lan -W /etc/squid/pass -f "sAMAccountName=%s" -h alg-dc1.alg.lan
auth_param basic children 10
acl allowinett proxy_auth REQUIRED
external_acl_type ldapgroup %LOGIN /usr/sbin/ext_ldap_group_acl -d -R -b "dc=alg,dc=lan" -f "(&(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%a,OU=Internet-Access,OU=ANYWHERE,dc=alg,dc=lan))" -D wwwrun@alg.lan -W /etc/squid/pass alg-dc1.alg.lan

# Эти строки были по умолчанию в конфиге
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
# acl localnet src 172.16.0.0/12        # RFC1918 possible internal network
# acl localnet src 192.168.0.0/16       # RFC1918 possible internal network
# acl localnet src fc00::/7       # RFC 4193 local private network range
# acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
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 localhost manager
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
#http_access deny to_localhost
# Этот кусок конфига я почти не трогал, все по умолчанию 

# А вот здесь я не уверен, что все правильно сделал
acl inet_access_0 external ldapgroup IA-ALG-IT
acl inet_access_1 external ldapgroup IA-ALG-Acc
http_access allow allowinett
http_access allow inet_access_0
http_access allow inet_access_1
http_access deny !allowinett

# http_access allow localnet
# http_access allow localhost
http_access deny all
http_port 10.0.20.1:3128
cache_mem 1024 MB
cache_dir aufs /var/cache/squid 2048 32 256
coredump_dir /var/cache/squid
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
По моим расчетам это должно было работать так: Клиенты имеют возможность аутентикации сначала по керберос потом авторизации по basic
Правило allowinet дальше пропускает тех, у кого с auth все в порядке. Далее «пробиваются» в AD данные на пользователя...
Дальше кусок конфига, так было по умолчанию, я не торгал.
А вот правила inet_access_0 и inet_access_1 может неправильно сделал?
Изначально я хотел, чтобы из тех, кто аутентицировался или авторизовался на проксе получал доступ,
если он принадлежит или IT или Acc группам, остальным нельзя.
Eсли закомментировать negotiate аутентикацию тогда пользователя, угадавшего пароль и входящего в эти группы - пропускает
Если раскомментировать - то запрашивает логин\пароль бесконечно, пароль хоть какой вводи.. Я проверял, раз 20 вводил...Думал, мало ли....

savranskiy73
()
Ответ на: комментарий от DALDON

И, тогда уж еще вопрос к гуру:
Как проверить работу negotiate_kerberos_auth - Squid kerberos based authentication helper. Version 3.0.4sq?
Не могу понять, какие ему данные надо и что он мне ответить должен, ибо не добился ни разу от него ответа.
Вот я так запускал:

negotiate_kerberos_auth -d -i -s HTTP/alg-gw7.alg.lan@ALG.LAN

negotiate_kerberos_auth.cc(271): pid=2430 :2014/09/06 22:02:27| negotiate_kerberos_auth: INFO: Starting version 3.0.4sq
tester%Alg12345
negotiate_kerberos_auth.cc(316): pid=2430 :2014/09/06 22:02:58| negotiate_kerberos_auth: DEBUG: Got 'tester%Alg12345' from squid (length: 15).
negotiate_kerberos_auth.cc(363): pid=2430 :2014/09/06 22:02:58| negotiate_kerberos_auth: ERROR: Invalid request [tester%Alg12345]
BH Invalid request
^C
И на все один ответ. Хоть что ему вводи... Как я ни извращался, так и не понял, как с ним разговаривать.

В манах тоже долдонят, что надо в стартовый скрипт внести строку, но без конкретных указаний, наверное, это элементарно...

KRB5_KTNAME=/etc/squid/HTTP.keytab export KRB5_KTNAME

У себя в системе нашел /etc/default, но файла squid там не было. Создал, внес строку, в ней указал путь к своему кейтабу.
Перезагружался. Понимания не добавило. Пытался в скрипт /etc/init.d/squid вставить такую строку, тоже где-то читал на форумах.
Научите, кто знает..

savranskiy73
()
Ответ на: комментарий от savranskiy73

Стоп... Стоп. Стоп.... Всё слишком сложно. Ты мне кажется запутался чуть более чем полностью. Куда спешишь? У тебя стоит сейчас задача номер1: это сделать прозрачную аутотентификацию в kerberos. Вот ты сперва реши её, а потом уже иди дальше. Для аутотентификации по kerberos тебе достаточно весьма простого конфига squid: описать просто аутотентификатор, и задать одно правило для http_access и один acl. Всё. Уже всё должно заработать. Иди от простого к сложному. Ты навключал кучу дебага, и сам же не понимаешь о чём у тебя в логах ругань идёт. Но насколько я могу понять твои логи - у тебя в kerberos присутствует очень серьёзная ошибка. И скорее всего у тебя не подгружается keytab. Так же я не очень понимаю, почему ты keytab создавал на компьютер, а не на пользователя? - Везде создают на пользователя... Я не знаю какая точно в этом разница, и чем принципиально отличаются объекты в kerberos - пользователь, компьютер... Но я бы всё же сделал как делают все. HTTP/alg-gw7.alg.lan@ALG.LAN - это у тебя о чём? У тебя имеется А запись на хост: alg-gw7.alg.lan ? И PTR на него же? PTR должна быть единственной. В браузере должен быть прописан fqdn. - В общем на ubuntu я поднял squid c kerberos вообще не напрягась можно сказать. Тут главное не суетиться. :)

К примеру, я поднял kerberos на squid буквально с первого запуска. В ubuntu мне потребовалось править /etc/init/squid (не путать с /etc/init.d , может конечно /etc/init это фишка upstart, не вникал...) или как-то так. То есть в последней ubuntu насколько я понял /etc/default для squid не отрабатывает. По сему я там прописал просто экспорт keytab файла. Сейчас мне лениво лезть на сервер за конфигами. Выходной же... :) Но в общем суть я думаю тебе понятна.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от savranskiy73

И на все один ответ. Хоть что ему вводи... Как я ни извращался, так и не понял, как с ним разговаривать.

Я не гуру... Был бы гуру, сам тут не спрашивал бы. :) Но в целом, у меня есть ощущение, что данный хелпер не ожидает никакого простого текста с клавиатуры. А ожидает полноценный билет. Следовательно - тем способом, что ты его хочешь дебажить - может и не возможно это делать.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

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

Так и есть, это же negotiate авторизация, а не basic, которую можно проверить тупым логин-пароль.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Угу. Я как-то help глянул по этому хэлперу (простите за тавтологию), кроме опций дебага ничего не нашёл.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

Привет, ты решил эту задачу?

У себя столкнулся с точно таким же поведением(вечно выскакивающее окно авторизации на машинах не входящих в домен), решил установлением директивы keep-alive в состояние off, т.е. строки авторизации выглядят так:

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/proxy.domain.local@DOMAIN.LOCAL
auth_param negotiate children 20
auth_param negotiate keep_alive off

auth_param basic program /usr/lib/squid3/basic_pam_auth -n squid
auth_param basic children 10
auth_param basic realm ProxyAuthentication

После этого на WIN машине, не входящей в домен, вводим в выскакивающее basic окно логин-пароль и попадаем в интернет.
P.S. домен у меня тоже на samba4
P.S.S. В IE и chrome логин нужно вводить в формате DOMAIN.LOCAL\username, в firefox достаточно указать username.

menzoberronzan
()
Последнее исправление: menzoberronzan (всего исправлений: 3)
Ответ на: комментарий от menzoberronzan

ТВОЮ-жеж ты мать!!! Проблему я не решил, и уже отчаился... Пока ты вот не написал... Спасибо тебе, что не поленился! А я что-то даже и не подумал, что всё так просто.

Значится так, у меня сейчас настройки такие:

auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -r
auth_param negotiate children  99 startup=20 idle=20
auth_param negotiate keep_alive off


auth_param basic program /usr/lib/squid3/basic_pam_auth -n squid -t 300 -o
auth_param basic children 5 startup=5 idle=1
auth_param basic credentialsttl 10800 seconds

blind_oracle Имя пользователя можно вводить и в формате: user@domain.local.

Вопрос, как бы избавиться от: «@domain.local» или «DOMAIN.LOCAL\» в имени пользователя? При basic AUTH?

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от DALDON

Интересно, сейчас посмотрел - в логах ни слова о basic_pam_auth.
Закомментировал строчки с basic авторизацией, перезапустил squid и поведение на машине не-в-домене сохранилось. Т.е. выскочило окошко, ввел логин DOMAIN.LOCAL\username и получил доступ в интернет. Получается, что окошко авторизации выводит negotiate_kerberos_auth, до basic_pam_auth дело даже не доходит.

menzoberronzan
()
Последнее исправление: menzoberronzan (всего исправлений: 1)
Ответ на: комментарий от menzoberronzan

Ааа... Похоже на правду. А причина такому поведению скорее всего является:

auth_param negotiate keep_alive off

По идее, чтобы перескочило на следующий хэлпер, оно должно быть on. Но на практике - мне это не помогало.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Вопрос, как бы избавиться от: «@domain.local» или «DOMAIN.LOCAL\» в имени пользователя? При basic AUTH?

Проще пареной репы:

# cat /etc/pam.d/squid 
auth sufficient pam_krb5.so alt_auth_map=%s@DOMAIN.LOCAL
account required pam_krb5.so

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Ага, это то у меня вестимо есть. :) Я ж забыл, что и сам выяснил, но тов. menzoberronzan - напомнил. Что дело то до BASIC и вовсе не доходит... Так что мой basic хэлпер вообще не используется...

DALDON ★★★★★
() автор топика
8 апреля 2015 г.
Ответ на: комментарий от blind_oracle

Вчера стали неожиданно днём сыпаться ошибки в браузерах: Прокси сервер отказывается принимать соединения... Страницы открывались через раз... Часть css, js не загружалась.

Первое что пришло в голову - увеличить кол-во kerberos хелперов. - Стал увеличивать, особо не помогало. Увеличил в три раза - помогло. Оказалось ужасное.

Стал выяснять по логам, и по коннектам, чего происходит, вычислил top ip адресов, которые ломятся в squid:

netstat -nat |grep :3128 | grep -v 0.0.0.0:3128 | grep -v 127.0.0.1:3128 | awk '{print $5}' | awk -F\: '{print $1}' | sort |uniq -c

Потом посмотрел в отчёты и ужаснулся... : http://pix.toile-libre.org/upload/original/1428481614.png у одного из пользователей, windows решила так обновиться (про WSUS знаю)... При этом создав 43,000 запросов на squid, от чего всем kerberos хелперам стало плохо.

Ну я так... Малоли тебе интересно будет. :)

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Нифига себе... винда, я смотрю, всё ещё может удивить весёлыми глюками)))

У меня хоть и WSUS, но с ним тоже весело - когда всякие удалённые офисы начинают дружно качать обновления с него через 5-10Мбит каналы. А апдейты нынче (с офисом вместе) бывают по 1.5Гбайт за раз... После этого начинает глючить ip-телефония даже несмотря на шейпинг и прочий QoS :)

blind_oracle ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.