28 марта 2024, 22:43

Цитата дня:

Единственный способ установить границы возможного - это выйти за них в невозможное.  Закон Кларка


SQUID + Kerberos - проблема с доступом.

Автор DeepPurple, 27 августа 2018, 17:40

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Вниз

DeepPurple

Добрый день!
Пытаюсь настроить squid и столкнулся с проблемой отсутствия доступа у пользователей при использовании более одной  внешней группы.
Мой конфиг в данный момент:
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -d -s HTTP/proxy01.domain.ru
acl localnet src 192.168.12.0/24
acl localnet src 192.168.14.0/24
acl auth proxy_auth REQUIRED
external_acl_type squidtest ttl=300 negative_ttl=60 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g squidtest -D DOMAIN.RU
acl squidtest external squidtest
external_acl_type standart ttl=300 negative_ttl=60 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g standart -D DOMAIN.RU
acl standart external standart
http_access deny !auth
http_access allow squidtest
http_access allow standart
http_access deny all
http_port 3128
access_log daemon:/var/log/squid/access.log squid
logfile_rotate 31
debug_options ALL,1 33,2 28,9


Сократил его до минимума пытаясь локализировать проблему, как в местных темах советовали ранее для начала сократил секцию http_access до:
http_access deny !auth
http_access allow localnet
http_access deny all


Все работает, у пользователей локальной сети доступ в интернет есть.
Пробую:
http_access deny !auth
http_access allow squidtest
http_access deny all

У тех кто состоит в группе squidtest в AD так же доступ есть у остальных нет.
А вот когда я добавляю второе разрешение (да и вообще любые правила касающиеся других групп):
http_access deny !auth
http_access allow squidtest
http_access allow standart
http_access deny all

Опять таки у squidtest есть доступ а у группы standart нет :(

При этоv в cache.log в конце пишется такое:
negotiate_kerberos_auth.cc(778): pid=9933 :2018/08/27 17:16:22| negotiate_kerberos_auth: DEBUG: Groups group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxAQIAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxUVgAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxh0AAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxakAAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sx1jAAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sx1zAAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxQUAAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxgD8AAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sx1UoAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxckAAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxQEAAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxQ04AAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxEDAAAA== group=AQUAAAAAAAUVAAAAYNLpG7cy3G2eX3sxYxwAAA== group=AQUAAAAAAAUVAAAAlRR/hp1TrTwKXZP2WQgAAA== group=AQUAAAAAAAUVAAAAJFXGYc++Cnt+njHbqQoAAA== group=AQUAAAAAAAUVAAAATlq5okHzGq5cq7YIXwgAAA== group=AQUAAAAAAAUVAAAAPM9wUWV2zn6zKbjXcwQAAA== group=AQUAAAAAAAUVAAAAKpW+OUrP3EiufSXQpA0AAA== group=AQUAAAAAAAUVAAAAkbIMlwyja+uOLbtosQYAAA== group=AQUAAAAAAAUVAAAAdlH79S3cW6TsgD78VwQAAA== group=AQUAAAAAAAUVAAAAlRR/hp1TrTwKXZP2qyUAAA== group=AQUAAAAAAAUVAAAAKpW+OUrP3EiufSXQWAQAAA== group=AQUAAAAAAAUVAAAAcMIUF2B8UPYn0NHVewQAAA== group=AQUAAAAAAAUVAAAAMFMXprb9marcHp2HbAQAAA== group=AQUAAAAAAAUVAAAAKpW+OUrP3EiufSXQqg0AAA== group=AQUAAAAAAAUVAAAAp86zlMfr9Dl18tJlSwgAAA== group=AQUAAAAAAAUVAAAAlRR/hp1TrTwKXZP2qCUAAA== group=AQEAAAAAABIBAAAA
2018/08/27 17:16:22.184 kid1| 28,8| Acl.cc(355) aclCacheMatchFlush: aclCacheMatchFlush called for cache 0x55be7eb17e98
2018/08/27 17:16:22.184 kid1| 28,5| InnerNode.cc(94) resumeMatchingAt: checking http_access at 0
2018/08/27 17:16:22.184 kid1| 28,5| Checklist.cc(400) bannedAction: Action 'DENIED/0is not banned
2018/08/27 17:16:22.184 kid1| 28,5| InnerNode.cc(94) resumeMatchingAt: checking http_access#1 at 0
2018/08/27 17:16:22.184 kid1| 28,5| InnerNode.cc(94) resumeMatchingAt: checking !auth at 0
2018/08/27 17:16:22.184 kid1| 28,5| Acl.cc(138) matches: checking auth
2018/08/27 17:16:22.184 kid1| 28,4| Acl.cc(333) cacheMatchAcl: ACL::cacheMatchAcl: cache hit on acl 'auth' (0x55be7e755f00)
2018/08/27 17:16:22.184 kid1| 28,3| Acl.cc(158) matches: checked: auth = 1
2018/08/27 17:16:22.184 kid1| 28,3| InnerNode.cc(97) resumeMatchingAt: checked: !auth = 0
2018/08/27 17:16:22.184 kid1| 28,3| InnerNode.cc(97) resumeMatchingAt: checked: http_access#1 = 0
2018/08/27 17:16:22.184 kid1| 28,5| Checklist.cc(400) bannedAction: Action 'ALLOWED/0is not banned
2018/08/27 17:16:22.184 kid1| 28,5| Acl.cc(138) matches: checking http_access#2
2018/08/27 17:16:22.184 kid1| 28,5| Acl.cc(138) matches: checking squidtest
2018/08/27 17:16:22.184 kid1| 28,9| Acl.cc(99) FindByName: ACL::FindByName 'squidtest'
2018/08/27 17:16:22.184 kid1| 28,3| Acl.cc(158) matches: checked: squidtest = -1 async
2018/08/27 17:16:22.184 kid1| 28,3| Acl.cc(158) matches: checked: http_access#2 = -1 async
2018/08/27 17:16:22.184 kid1| 28,3| InnerNode.cc(97) resumeMatchingAt: checked: http_access = -1 async
negotiate_kerberos_auth.cc(783): pid=9933 :2018/08/27 17:16:22| negotiate_kerberos_auth: DEBUG: AF oYGyMIGvoAMKAQChCwYJKoZIgvcSAQICooGaBIGXYIGUBgkqhkiG9xIBAgICAG+BhDCBgaADAgEFoQMCAQ+idTBzoAMCAReibARqCY5bUgPi1ylhWGubvyaku48fJdWXWBdUqVEGcnGwqUcaQ4R/Vy0Gas1icgLyvWdbKgfCBuuRy3KRdvOTnP/5oB1LSsBQY3oDdMWFySd3WIO6STXf5ZBPLXAK7+A8eYpFRBfvjboVkEcHzQ== test-VRN@DOMAIN.RU

Как я понимаю после проверки на принадлежность группе squidtest он почему то не идет на следующую проверку, в access.log в результате получаем
1535380202.767      1 192.168.14.202 TCP_DENIED/407 4707 GET http://ya.ru/ - HIER_NONE/- text/html
 
а у пользователя вечно загружающаяся страничка без каких либо ошибок

Подскажите пожалуйста в чем может быть косяк и что еще можно попробовать?

STALKER_SLX

Для начала укажите, пожалуйста, точную версию Вашей ОС и непосредственно номер резила прокси (это очень сильно сузит круг проблем и облегчит решение Вашей задачи)!
Т.к. Ubuntu18.04 на сегодняшний день совсем ещё сырая и полна разного рода "сюрпризов", да и не все "кальмары" работают корректно.

Уваров А.С.

1. Запустите хелпер отдельно и проверьте соответствие пользователей группам.
2. Включите опцию отладки:

debug_options ALL,1 33,2

после чего будет видно какие именно правила где сработали, а какие нет и почему.

DeepPurple

#3
29 августа 2018, 13:12 Последнее редактирование: 29 августа 2018, 13:15 от DeepPurple
ОС - Ubuntu Ubuntu 16.04.5 LTS
Squid - Version 3.5.12

Запустил хелпер с ключем -d, и увидел что он "зацикливается" на одной из групп и никак не может двинуться дальше (во вложении), что с ним может быть не так?

Причем группа rdesktop есть у пользователя, а группы Rdesktop нет, зато rdesktop является членом группы Rdesktop. Возможно он пытается проверить вложенные группы и ему что-то мешает? Это можно как-то отключить, то есть чтобы проверка делалась только по группам которые непосредственно есть у пользователя? Либо как-то убрать из объектов проверки эту группу?

Уваров А.С.

Такой опции у хелпера нет, а вот вы что-то явно накрутили с группами. Если я правильно понял то Rdesktop и rdesktop - это вложенные группы? Тогда я не удивлен...

Справка по хелперу:  http://manpages.ubuntu.com/manpages/xenial/man8/negotiate_kerberos_auth.8.html

DeepPurple

Хех, да это вложенные группы. Их трогать я к сожалению не могу, будем думать...

А не подскажете ответ на такой вопрос, в описании версии squid есть такой пункт
Changes to acl in Squid-3.5: New type at_step to match the current SSL-Bump processing step. Never matches and should not be used outside of ssl_bump.

У меня версия сквида 3.5.12, но при использовании этого типа пишет "Invalid acl type 'at_step'"  В чем может быть проблема? Может надо отдельно этот тип включить или как-то обновить?

Уваров А.С.

Для этого squid должен быть собран с поддержкой этой опции, также нужно наличие определенных версий библиотек. В новых дистрибутивах работать должно, в старых поддержки этих опций нет и не будет.

Вверх