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

Слушай, у меня пока мест нету времени на поднятие виндового 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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.