Как победить периодический Access Denid у squida?

Question

[Николай Савельев]

Настраиваю squid с kerberos аутентификацией. Все компьютеры в домене freeipa. Согласно документации сделал нужный keytab.

auth_param negotiate program /usr/lib64/squid/squid_kerb_auth -d -s HTTP/squid01.example.com

Аутентификация проходит, все прекрасно.
Дальше мне нужно разграничить доступ в интеренет.

external_acl_type ipa_inet_full ttl=300 negative_ttl=60 ipv4 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -a -d -g inet_full@ -D example.com

И тут начинаются танцы с бубном. По большей части хелпер правильно определяет принадлежность пользователя к группе, но периодически выдает ERR и тогда на минуту доступ пропадает. Затем снова работает.
Поскольку в логах в этот момент видим отлуп аутентифицированному пользователю, то дело в хелпере.
Как побороть?

Comments

[Николай Савельев]

В общем, нашел причину. В сети 3 сервера freeipa, именно с них и берутся данные пользователей.
Хелпер ext_kerberos_ldap_group_acl делает запрос к одному из серверов (dns autodiscovery) запрос групп, в которых есть пользователь (memberuid=user). В полученном списке ищет нужную группу. Так вот...
Один из серверов на такие запросы всегда выдает пустой список. Остальные нормально ищут группы. Изюминка в том, что два других сервера были получены репликацией первого. В чем дело - пока буду разбираться.

Answer 1

[Николай Савельев]

В общем, решил вопрос. Дело было вовсе не в хелпере, а в кривой настройке freeipa. Там есть какой-то режим compat, непонятно для чего нужный. Так вот... При миграции на freeipa c openldap у меня openfire не захотел оттуда пользователей тягать - якобы они задваиваются (что верно, так как пользователи во freeipa хранятся в двух ветках -

cn=users,cn=accounts,cn=domain,cn=lan и cn=users,cn=compat,cn=domain,cn=lan

). Я на одном сервере этот режим отключил. Почему-то хелперы стали на этом сервере только по GID пользователя проверять принадлежность, а все остальные группы игнорировали, хотя ldapsearch работал нормально. Там где режим включен все ОК. Составлять нормальный ldap фильтр для openfire я не стал - лень. Просто указал:

/lib64/squid/ext_kerberos_ldap_group_acl -a -g inet_full@ -D fs.lan -S "dc.fs.lan dc2.fs.lan dc4.fs.lan"

Как я понимаю, получая ERR на первом сервере, хелпер лезет дальше по списку. Остальные 2 правильно отрабатывают, значит все нормально. Может позже заставлю openfire с ipa-compat-manage enable работать.

Answer 2

[bugs bunny]

auth_param negotiate children - возможно не хватает. Или с потоком запросов не справляется AD.

Comments

[Николай Савельев]

children ставил до 100, пока тестирую - пользователей меньше 10.
Вы, наверное, не заметили, но АД у меня нет. Все клиенты на linux, kerberos на freeipa.

[bugs bunny]

Да момент упустил. Мысль была в том, что сервер (kerberos) не справляется с количеством запросов, т.к проблема длиться минуту и не очень большое количество пользователей, на количество экземпляров хелпера.

[Николай Савельев]

А разве минута не отсюда - negative_ttl=60?
Я тестировал хелпер вручную, та же самая ситуация. Периодически получаю ERR и соответсвенно отлуп.
Думаю все же в хелпере дело.

[bugs bunny]

Это настройки кеша
ttl=n TTL in seconds for cached results (defaults to 3600 for 1 hour)
negative_ttl=n TTL for cached negative lookups (default same as ttl)