LINUX.ORG.RU

Squid: проблема с кириллицей (аутентификация на основе групп AD)

 , , , ,


0

1

Добрый день, товарищи. Может, у кого была такая проблема: аутентификация в squid работает только для латиницы и цифр. Не хочу нагружать лишней информацией, я вроде бы вычленил проблему, но пока не пришло в голову, как это реализовать)

Реализовано всё на Centos 8.3, плюс-минус по такой инструкции: https://www.dmosk.ru/miniinstruktions.php?mini=squid-ad#groups

На контроллере сгенерирован keytab, на сервере настроен Керберос 5, Самба 4.12.3, Виндинд и Сквид 4.4. Wbinfo всё отображает корректно.

Но в access.log Сквида можно увидеть примерно такие строчки:

1618289967.445 7 192.168.21.115 TCP_DENIED/403 6873 CONNECT http://www.google.com:443 %d0%af%d1%85%d0%b8%d0%bd%d0%b0 %d0%9d %d0%90@DOMEN.LOCAL HIER_NONE/- text/html

То есть, хелпер выдаёт имя пользователя не в той кодировке. Насколько я понял, это как-то связано с параметром %LOGIN в auth_param.

Конфиг squid:

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -s HTTP/proxy.domen.local@DOMEN.LOCAL
auth_param negotiate children 20
auth_param negotiate keep_alive on

auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5 -ntlmssp --domain=DOMEN
auth_param ntlm children 10
auth_param ntlm keep_alive off

external_acl_type inet_sisadmin ttl=300 negative_ttl=60  %LOGIN  /usr/lib64/squid/ext_kerberos_ldap_group_acl -g inet_sisadmin@DOMEN.LOCAL

acl localnet src 0.0.0.1-0.255.255.255	# RFC 1122 «this» network (LAN)
acl localnet src 10.0.0.0/8		# RFC 1918 local private network (LAN)
acl localnet src 100.64.0.0/10		# RFC 6598 shared address space (CGN)
acl localnet src 169.254.0.0/16 	# RFC 3927 link-local (directly plugged) machines
acl localnet src 172.16.0.0/12		# RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16		# RFC 1918 local private network (LAN)
acl localnet src 192.168.20.0/22
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
acl inet_sisadmin external inet_sisadmin

http_access allow inet_sisadmin
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
http_port 3129 intercept

coredump_dir /var/spool/squid
cache_dir ufs /var/spool/squid 4096 32 256

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
access_log /var/log/squid/access.log squid

Я уже понял, как можно преобразовать в нужный мне формат эту ерунду, что-то типа:

echo -ne $(echo -n "$1" | sed -E "s/%/\\\\x/g") 

Но пока никак не могу применить это к параметру %LOGIN, который, похоже, жёстко забит...

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

На данный момент всё прекрасно работает на Debian 7.4... Но хотелось бы обновиться.

Заранее спасибо, извините, если что не так с форматированием текста, это моя первая тема на этом форуме

запусти

echo <username> | /usr/lib64/squid/ext_kerberos_ldap_group_acl -d -i -a -g inet_sisadmin@DOMEN.LOCAL
и посмотри что оно скажет.

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

Премного извиняюсь, ввёл в заблуждение... Похоже, что кириллицей всё нормально. Дело в пробелах. Не заметил, у нас почти все учётки в формате «Иванов И И»... Конечно, там с кодировкой тоже проблема, но ведь работает... А вот вывод команды учётки с пробелами:

echo 'Яхина Н А@domen.local' | /usr/lib64/squid/ext_kerberos_ldap_group_acl -d -i -a -g inet_sisadmin@DOMEN.LOCAL 
:

kerberos_ldap_group.cc(311): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: INFO: Starting version 1.4.0sq
support_group.cc(382): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: INFO: Group list inet_sisadmin@DOMEN.LOCAL
support_group.cc(447): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: INFO: Group inet_sisadmin  Domain DOMEN.LOCAL
support_netbios.cc(83): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: DEBUG: Netbios list NULL
support_netbios.cc(87): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: DEBUG: No netbios names defined.
support_lserver.cc(82): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: DEBUG: ldap server list NULL
support_lserver.cc(86): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: DEBUG: No ldap servers defined.
kerberos_ldap_group.cc(435): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: INFO: Got User: %D0%AF%D1%85%D0%B8%D0%BD%D0%B0 Domain: NULL
support_member.cc(119): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: DEBUG: Default group loop: group@domain inet_sisadmin@DOMEN.LOCAL
ERR
kerberos_ldap_group.cc(474): pid=233656 :2021/04/14 09:25:35| kerberos_ldap_group: DEBUG: ERR
BH fgets NULL

Пока обдумываю новые вводные...

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

Разве это как-то повлияет? Пока курю мануалы и пытаюсь сделать что-то методом тыка - не выходит. Для учётки без пробелов вывод команды

echo salnikov@domen.local | /usr/lib64/squid/ext_kerberos_ldap_group_acl -d -i -a -g inet_sisadmin@DOMEN.LOCAL
выглядит так:

 
kerberos_ldap_group.cc(311): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: INFO: Starting version 1.4.0sq
support_group.cc(382): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: INFO: Group list inet_sisadmin@DOMEN.LOCAL
support_group.cc(447): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: INFO: Group inet_sisadmin  Domain DOMEN.LOCAL
support_netbios.cc(83): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Netbios list NULL
support_netbios.cc(87): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: No netbios names defined.
support_lserver.cc(82): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: ldap server list NULL
support_lserver.cc(86): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: No ldap servers defined.
kerberos_ldap_group.cc(435): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: INFO: Got User: salnikov Domain: DOMEN.LOCAL
support_member.cc(63): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: User domain loop: group@domain inet_sisadmin@DOMEN.LOCAL
support_member.cc(65): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Found group@domain inet_sisadmin@DOMEN.LOCAL
support_ldap.cc(1007): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Setup Kerberos credential cache
support_krb5.cc(131): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Set credential cache to MEMORY:squid_ldap_DOMEN.LOCAL_3760
support_krb5.cc(78): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: No default principal found in ccache : No credentials cache found
support_krb5.cc(263): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Get default keytab file name
support_krb5.cc(269): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Got default keytab file name /etc/squid/proxy.keytab
support_krb5.cc(283): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Get principal name from keytab /etc/squid/proxy.keytab
support_krb5.cc(294): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Keytab entry has realm name: DOMEN.LOCAL
support_krb5.cc(306): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Found principal name: HTTP/proxy.domen.local@DOMEN.LOCAL
support_krb5.cc(326): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Got principal name HTTP/proxy.domen.local@DOMEN.LOCAL
support_krb5.cc(390): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Stored credentials
support_ldap.cc(1048): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Initialise ldap connection
support_ldap.cc(1057): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Canonicalise ldap server name for domain DOMEN.LOCAL
support_resolv.cc(379): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.DOMEN.LOCAL record to AD2.domen.local
support_resolv.cc(379): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.DOMEN.LOCAL record to ad02.domen.local
support_resolv.cc(379): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.DOMEN.LOCAL record to ad1.domen.local
support_resolv.cc(379): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.DOMEN.LOCAL record to ad2.domen.local
support_resolv.cc(207): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Resolved address 1 of DOMEN.LOCAL to AD1.domen.local
....... ещё 8 подобных строчек.....
support_resolv.cc(407): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Adding DOMEN.LOCAL to list
support_resolv.cc(443): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Sorted ldap server names for domain DOMEN.LOCAL:
support_resolv.cc(445): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Host: ad02.domen.local Port: 389 Priority: 0 Weight: 100
support_resolv.cc(445): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Host: ad1.domen.local Port: 389 Priority: 0 Weight: 100
support_resolv.cc(445): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Host: AD2.domen.local Port: 389 Priority: 0 Weight: 100
support_resolv.cc(445): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Host: DOMEN.LOCAL Port: -1 Priority: -2 Weight: -2
support_ldap.cc(1068): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Setting up connection to ldap server ad02.domen.local:389
support_ldap.cc(1081): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
support_ldap.cc(1100): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Successfully initialised connection to ldap server ad02.domen.local:389
support_ldap.cc(316): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Search ldap server with bind path "" and filter: (objectclass=*)
support_ldap.cc(665): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Search ldap entries for attribute : schemaNamingContext
support_ldap.cc(719): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: 1 ldap entry found with attribute : schemaNamingContext
support_ldap.cc(327): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Search ldap server with bind path CN=Schema,CN=Configuration,DC=domen,DC=local and filter: (ldapdisplayname=samaccountnam                      e)
support_ldap.cc(332): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Found 1 ldap entry
support_ldap.cc(341): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Determined ldap server as an Active Directory server
support_ldap.cc(1232): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Search ldap server with bind path dc=DOMEN,dc=LOCAL and filter : (samaccountname=salnikov)
support_ldap.cc(1247): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Found 1 ldap entry
support_ldap.cc(665): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Search ldap entries for attribute : memberof
support_ldap.cc(719): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: 27 ldap entries found with attribute : memberof
support_ldap.cc(1275): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Entry 1 "Archive" in hex UTF-8 is 41726368697665
support_ldap.cc(1291): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Entry 1 "Archive" does not match group name "inet_sisadmin"
..... Длинный список групп пользователя.....
support_ldap.cc(1588): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: Unbind ldap server
support_member.cc(69): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: INFO: User salnikov is member of group@domain inet_sisadmin@DOMEN.LOCAL
OK
kerberos_ldap_group.cc(471): pid=3760 :2021/04/14 15:30:55| kerberos_ldap_group: DEBUG: OK
BH fgets NULL

Я уже думаю, может попробовать squid версии ниже...

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

т.е. ext_kerberos_ldap_group_acl в принципе работает.

А с кирилическими именам работает?

Есть разница между squid 3 и 4 по протоколам взаимодействия с внешними acl.

Для внешних acl параметр protocol=2.5 изменяет правила экранирования параметров.

Непонятно в каком виде ext_kerberos_ldap_group_acl расчитывает получать параметры.

У сквида есть диагностические сообщения для разных разделов (doc/debug-sections.txt). Секция 82 про внешние acl. Включи, посмотри что он посылает в ext_kerberos_ldap_group_acl и что приходит в ответ.

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

У нас тоже самое с логинами пользователей, правда нет пробелов, но от этого не легче, ввиду того что у нас файлы потом отправляются в graylog, предварительно их обрабатывае через скрипт https://sgww.livejournal.com/7984.html. Косталь, но нам хватает, хотя конечно же хотелось бы рабочий вариант чтобы сразц все было красиво. У вас нет прогресса?

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

Спасибо, буду ковыряться. Включил, но ничего интересного не увидел… Да, с кириллицей и без пробелов работает. Проблема именно в пробелах. Сейчас взял тайм-аут, надо освежить голову)

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

Пока нет. Ясно, что надо как-то экранировать пробелы, скорей всего ext_kerberos_ldap_group_acl получает только фамилию пользователя. Буду ковыряться конкретно в нём. Обязательно напишу, как что-то сдвинется

anton1823
() автор топика

Если заменить пробелы на \%20 - всё проходит. Команда

echo Яхина\%20Н\%20А@vvrz.local | /usr/lib64/squid/ext_kerberos_ldap_group_acl -d -i -a -g inet_sisadmin@VVRZ.LOCAL
обрабатывается корректно. Дело за малым - как-то присобачить костыль к отправляемому аргументу %LOGIN

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