9 июн. 2015 г.

Squid + Samba4 AD Kerberos Authorization

В продолжение предыдущей заметки пара слов об авторизации доменных пользователей в Squid посредством того же Kerberos. Вообще все должно быть легко, ибо все уже украдено до нас есть готовый хелпер в комплекте /usr/lib/squid3/ext_kerberos_ldap_group_acl (по крайней мере, в Debian), который умеет ходить в AD, авторизовываться текущим keytab-ом, получать необходимые тикеты и понимать, находится ли поданная ему на вход учетная запись пользователя в заданной группе. Для тестовых целей, как и ранее, запускаем прямо из консоли:
/usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM
Для дебага можно добавить опции -i или -d. Опция -h покажет встроенный хелп. 
Нормальная работа хелпера выглядит так:
root@gw0:~# /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM
inettest01@example.com
OK
inettest02@example.com
ERR 
Соответственно, пользователь inettest01 является членом группы FastInet в домене EXAMPLE.COM, а пользователь inettest02 - нет.
Если ERR имеем всегда, а -d показывает ошибки вида:
kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Unknown authentication method
то, возможно, не хватает модулей gssapi к библиотеке libsasl2, через которую реализуется подключение хелпера к домену по LDAP: libsasl2-modules-gssapi-mit. После установки этого пакета у меня такая ошибка более не появлялась:
kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
kerberos_ldap_group: DEBUG: Successfully initialised connection to ldap server dc0.example.com:389
В самом Squid конструкция описывается следующим образом:
external_acl_type fastgroup_krb children=10 cache=10 grace=15 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g FastInet@EXAMPLE.COM
acl fastinet external fastgroup_krb
http_access allow fastinet
Запись external_acl_type должна быть записана в одну строку. Переменная %LOGIN передает учетную запись пользователя от negotiate хелпера (см. предыдущую заметку). Конечно, групп может быть несколько, и количество определений external_acl_type не ограничивается.
Вроде бы все просто, однако на работе хелпера я сидел не один день. Судя по дебагу вида:
support_ldap.cc(856): pid=1593 :2015/06/09 15:50:55| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
support_sasl.cc(268): pid=1593 :2015/06/09 15:50:55| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error
support_ldap.cc(860): pid=1593 :2015/06/09 15:50:55| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error
хелпер не мог соединиться с контроллером домена по ldap и запросить требуемые данные. Причем keytab-файл заведомо использовался, имена разрешались и вообще до момента означенной ошибки все логи были хорошими.
В разборках сильно помогла заметка пользователя Timp, который указал отсутствующие на PTR-записи контроллеров домена в своей очень похожей ситуации. Беда в том, что nslookup на gw0 корректно разрешался в обе стороны для dc0.
По прошествии времени я снова вернулся к этой заметке и решил последовать примеру товарища - вооружиться tcpdump-ом. И каково же было моё удивление, когда я обнаружил ответа dc0 с содержимым NXDOMAIN! И да, появлялись они в моменты работы хелпера. И дважды да, предваряли эти сообщения запросы PTR для адреса контроллера домена!!!
Точки над i расставил dig (вывод я порезал):
root@gw0:~# dig -x 192.168.0.241
;; QUESTION SECTION:
;241.0.168.192.in-addr.arpa.   IN      PTR
Секции ANSWER нет! То есть, действительно, обратной записи для контроллера домена в DNS нет. Идем в соответствующую оснастку (или samba-tool в консоли dc0, что ближе) и добавляем недостающий пойнтер. Смотрим:
root@gw0:~# dig -x 192.168.0.241
;; QUESTION SECTION:
;241.0.168.192.in-addr.arpa.   IN      PTR
;; ANSWER SECTION:
241.0.168.192.in-addr.arpa. 3600 IN    PTR     dc0.example.com.
После этих действий хелпер начал работать.