Squid Proxy could not activate tls connection

dresd1989
Завсегдатай
Сообщения: 25
Зарегистрирован: 15 янв 2016 11:49

Squid Proxy could not activate tls connection

Сообщение dresd1989 » 15 янв 2016 12:13

Добрый день!
Настраивал прозрачный прокси по аналогии http://blog.it-kb.ru/2014/06/26/forward ... /#comments

Все работает как нужно, но только с не авторизованными пользователями.
Не проходит этап ext_ldap_group_acl
На сопоставление пользователь\группа.
Выдает ERR. Если добавить ключ -d то увидим что не возможно создать TLS сессию с сервером AD(текст ошибки в заглавии).
Схема леса и домен 2008 R2.
Я как понимаю что версионность TLS не совпадает и нескуьюрное соединение доменные контроллеры не разрешают.
Это можно решить либо отключить безопасность на серверах, либо допилить squid+ubuntu 14.04
Кто какие варианты по допиливанию предложит?
Заранее спасибо!

Аватара пользователя
Алексей Максимов
Администратор сайта
Сообщения: 413
Зарегистрирован: 14 сен 2012 06:50
Откуда: г.Сыктывкар
Контактная информация:

Re: Squid Proxy could not activate tls connection

Сообщение Алексей Максимов » 15 янв 2016 12:18

Что-то я не пойму о чём идет речь. Прозрачный прокси и ext_ldap_group_acl, насколько я понимаю, вещи несовместимые. Прозрачный прокси не подразумевает авторизации, а хелпер ext_ldap_group_acl используется для схем LDAP-авторизации.

dresd1989
Завсегдатай
Сообщения: 25
Зарегистрирован: 15 янв 2016 11:49

Re: Squid Proxy could not activate tls connection

Сообщение dresd1989 » 15 янв 2016 12:26

Алексей Максимов писал(а):Что-то я не пойму о чём идет речь. Прозрачный прокси и ext_ldap_group_acl, насколько я понимаю, вещи несовместимые. Прозрачный прокси не подразумевает авторизации, а хелпер ext_ldap_group_acl используется для схем LDAP-авторизации.
Маленько не правильно сформулировал, проксик то не прозрачный как раз таки. Он с прозрачной авторизацией для пользователей.
И на стадии авторизации он не может согласовать TLS сессию.

Аватара пользователя
Алексей Максимов
Администратор сайта
Сообщения: 413
Зарегистрирован: 14 сен 2012 06:50
Откуда: г.Сыктывкар
Контактная информация:

Re: Squid Proxy could not activate tls connection

Сообщение Алексей Максимов » 15 янв 2016 12:38

Попробуйте поиграть с параметрами хелпера. Все параметры узнать можно командой:

Код: Выделить всё

/usr/lib/squid3/ext_ldap_group_acl -h
Например можно попробовать понизить версию LDAP (-v 2), правда не предполагаю, какой будет результат.
Также можно попробовать другие хелперы, например ext_kerberos_ldap_group_acl, он вроде как более секьюрным будет.

dresd1989
Завсегдатай
Сообщения: 25
Зарегистрирован: 15 янв 2016 11:49

Re: Squid Proxy could not activate tls connection

Сообщение dresd1989 » 18 янв 2016 06:55

Алексей Максимов писал(а):Попробуйте поиграть с параметрами хелпера. Все параметры узнать можно командой:

Код: Выделить всё

/usr/lib/squid3/ext_ldap_group_acl -h
Например можно попробовать понизить версию LDAP (-v 2), правда не предполагаю, какой будет результат.
Также можно попробовать другие хелперы, например ext_kerberos_ldap_group_acl, он вроде как более секьюрным будет.
В общем изменение параметров хелпера ext_ldap_group_acl не помогло, не создается TLS сессия.
После чего была прочитана куча мануала по хелперам.
Решил использовать хелпер ext_kerberos_ldap_group_acl, он действительно более секьюрный чем ext_ldap_group_acl.
Но суть в чем его просто напросто не оказалось в сборке squid 3.3.8. для Ubuntu. Для Debian он есть.
Поэтому дабы не пересобирать пакет самому, нашел на просторах интернета его легко из сборки Debian. После чего все завелось. То есть могу проверить наличие пользователя в группе. Логика работы хелпера отличается поэтому проверить то я могу, но как это добавить в squid.conf чтобы корректно проверял и выдавал доступ пока не допер.
Кто-нибудь работал с данным хелпером и группами? есть примеры конфига?

Аватара пользователя
Алексей Максимов
Администратор сайта
Сообщения: 413
Зарегистрирован: 14 сен 2012 06:50
Откуда: г.Сыктывкар
Контактная информация:

Re: Squid Proxy could not activate tls connection

Сообщение Алексей Максимов » 18 янв 2016 07:04

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

dresd1989
Завсегдатай
Сообщения: 25
Зарегистрирован: 15 янв 2016 11:49

Re: Squid Proxy could not activate tls connection

Сообщение dresd1989 » 18 янв 2016 10:16

Алексей Максимов писал(а):Да там наверняка ничего сложного быть не должно. Покажите то, какой командой проверяете хелпер и то какие у хелпера есть ключи.
ВОт проверка на пользователя в группе.
sudo /usr/lib/squid3/ext_kerberos_ldap_group_acl -d -a -i -g TEST-Internet-Standart@TEST.LOCAL -D TEST.LOCAL
Вот запрос параметров хелепера!
Usage:
squid_kerb_ldap [-d] [-i] -g group list [-D domain] [-N netbios domain map] [-s] [-u ldap user] [-p ldap user password] [-l ldap url] [-b ldap bind path] [-a] [-m max depth] [-h]
-d full debug
-i informational messages
-g group list
-t group list (only group name hex UTF-8 format)
-T group list (all in hex UTF-8 format - except seperator @)
-D default domain
-N netbios to dns domain map
-S ldap server to dns domain map
-u ldap user
-p ldap user password
-l ldap url
-b ldap bind path
-s use SSL encryption with Kerberos authentication
-a allow SSL without cert verification
-m maximal depth for recursive searches
-h help
The ldap url, ldap user and ldap user password details are only used if the kerberised
access fails(e.g. unknown domain) or if the username does not contain a domain part
and no default domain is provided.
If the ldap url starts with ldaps:// it is either start_tls or simple SSL
The group list can be:
group - In this case group can be used for all keberised and non kerberised ldap servers
group@ - In this case group can be used for all keberised ldap servers
group@domain - In this case group can be used for ldap servers of domain domain
group1@domain1:group2@domain2:group3@:group4 - A list is build with a colon as seperator
Group membership is determined with AD servers through the users memberof attribute which
is followed to the top (e.g. if the group is a member of a group)
Group membership is determined with non AD servers through the users memberuid (assuming
PosixGroup) or primary group membership (assuming PosixAccount)
The ldap server list can be:
server - In this case server can be used for all Kerberos domains
server@ - In this case server can be used for all Kerberos domains
server@domain - In this case server can be used for Kerberos domain domain
server1a@domain1:server1b@domain1:server2@domain2:server3@:server4 - A list is build with a colon as seperator
Последний раз редактировалось dresd1989 18 янв 2016 10:22, всего редактировалось 1 раз.

dresd1989
Завсегдатай
Сообщения: 25
Зарегистрирован: 15 янв 2016 11:49

Re: Squid Proxy could not activate tls connection

Сообщение dresd1989 » 18 янв 2016 10:22

Внес в конфиг squid следующие строки:
external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g TEST-Internet-Standart@TEST.LOCAL -D TEST.LOCAL
external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g TEST-Internet-Restricted@TEST.LOCAL -D TEST.LOCAL
external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g TEST-Internet-Full-Anon@TEST.LOCAL -D TEST.LOCAL
external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g TEST-Internet-Full-Auth@TEST.LOCAL -D TEST.LOCAL
external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g TEST-Internet-Blocked@TEST.LOCAL -D TEST.LOCAL
Не получилось! Пока что.

Аватара пользователя
Алексей Максимов
Администратор сайта
Сообщения: 413
Зарегистрирован: 14 сен 2012 06:50
Откуда: г.Сыктывкар
Контактная информация:

Re: Squid Proxy could not activate tls connection

Сообщение Алексей Максимов » 18 янв 2016 12:08

Покажите вывод, который получается после ввода указанной вами команды:

Код: Выделить всё

sudo /usr/lib/squid3/ext_kerberos_ldap_group_acl -d -a -i -g TEST-Internet-Standart@TEST.LOCAL -D TEST.LOCAL
Ещё меня смущает то, что показанный вами набор параметров начинается с значения "squid_kerb_ldap". Вы точно показали ключи хелпера ext_kerberos_ldap_group_acl ?

dresd1989
Завсегдатай
Сообщения: 25
Зарегистрирован: 15 янв 2016 11:49

Re: Squid Proxy could not activate tls connection

Сообщение dresd1989 » 18 янв 2016 12:22

Алексей Максимов писал(а):Покажите вывод, который получается после ввода указанной вами команды:

Код: Выделить всё

sudo /usr/lib/squid3/ext_kerberos_ldap_group_acl -d -a -i -g TEST-Internet-Standart@TEST.LOCAL -D TEST.LOCAL
Ещё меня смущает то, что показанный вами набор параметров начинается с значения "squid_kerb_ldap". Вы точно показали ключи хелпера ext_kerberos_ldap_group_acl ?
Выводи предоставил точно ext_kerberos_ldap_group_acl !
Вот вывод команды который Вы запросили.
sudo /usr/lib/squid3/ext_kerberos_ldap_group_acl -d -a -i -g TEST-Internet-Standart@TEST.LOCAL -D TEST.LOCAL
[sudo] password for user:
kerberos_ldap_group.cc(275): pid=1763 :2016/01/18 15:17:39| kerberos_ldap_group: INFO: Starting version 1.3.1sq
support_group.cc(374): pid=1763 :2016/01/18 15:17:39| kerberos_ldap_group: INFO: Group list TEST-Internet-Standart@TEST.LOCAL
support_group.cc(439): pid=1763 :2016/01/18 15:17:39| kerberos_ldap_group: INFO: Group TEST-Internet-Standart Domain TEST.LOCAL
support_netbios.cc(75): pid=1763 :2016/01/18 15:17:39| kerberos_ldap_group: DEBUG: Netbios list NULL
support_netbios.cc(79): pid=1763 :2016/01/18 15:17:39| kerberos_ldap_group: DEBUG: No netbios names defined.
support_lserver.cc(74): pid=1763 :2016/01/18 15:17:39| kerberos_ldap_group: DEBUG: ldap server list NULL
support_lserver.cc(78): pid=1763 :2016/01/18 15:17:39| kerberos_ldap_group: DEBUG: No ldap servers defined.
student TEST-Internet-Standart
kerberos_ldap_group.cc(367): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: INFO: Got User: student%09TEST-Internet-Standart set default domain: TEST.LOCAL
kerberos_ldap_group.cc(372): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: INFO: Got User: student%09TEST-Internet-Standart Domain: TEST.LOCAL
support_member.cc(55): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: User domain loop: group@domain TEST-Internet-Standart@TEST.LOCAL
support_member.cc(57): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Found group@domain TEST-Internet-Standart@TEST.LOCAL
support_ldap.cc(801): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Setup Kerberos credential cache
support_krb5.cc(90): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Get default keytab file name
support_krb5.cc(96): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Got default keytab file name /etc/squid3/PROXY.keytab
support_krb5.cc(110): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Get principal name from keytab /etc/squid3/PROXY.keytab
support_krb5.cc(121): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Keytab entry has realm name: TEST.LOCAL
support_krb5.cc(133): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Found principal name: HTTP/srv-prx-01.TEST.local@TEST.LOCAL
support_krb5.cc(174): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Set credential cache to MEMORY:squid_ldap_1763
support_krb5.cc(269): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Got principal name HTTP/srv-prx-01.TEST.local@TEST.LOCAL
support_krb5.cc(312): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Stored credentials
support_ldap.cc(830): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Initialise ldap connection
support_ldap.cc(836): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Canonicalise ldap server name for domain TEST.LOCAL
support_resolv.cc(373): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.TEST.LOCAL record to dc02.TEST.local
support_resolv.cc(373): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.TEST.LOCAL record to dc04.TEST.local
support_resolv.cc(373): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.TEST.LOCAL record to dc03.TEST.local
support_resolv.cc(373): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.TEST.LOCAL record to dc01.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 1 of TEST.LOCAL to dc03.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 2 of TEST.LOCAL to dc03.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 3 of TEST.LOCAL to dc03.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 4 of TEST.LOCAL to dc01.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 5 of TEST.LOCAL to dc01.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 6 of TEST.LOCAL to dc01.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 7 of TEST.LOCAL to dc02.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 8 of TEST.LOCAL to dc02.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 9 of TEST.LOCAL to dc02.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 10 of TEST.LOCAL to dc04.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 11 of TEST.LOCAL to dc04.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 12 of TEST.LOCAL to dc04.TEST.local
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 13 of TEST.LOCAL to 192.168.48.2
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 14 of TEST.LOCAL to 192.168.48.2
support_resolv.cc(201): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Resolved address 15 of TEST.LOCAL to 192.168.48.2
support_resolv.cc(401): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Adding TEST.LOCAL to list
support_resolv.cc(437): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Sorted ldap server names for domain TEST.LOCAL:
support_resolv.cc(439): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Host: dc04.TEST.local Port: 389 Priority: 0 Weight: 100
support_resolv.cc(439): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Host: dc03.TEST.local Port: 389 Priority: 0 Weight: 100
support_resolv.cc(439): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Host: dc01.TEST.local Port: 389 Priority: 0 Weight: 100
support_resolv.cc(439): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Host: dc02.TEST.local Port: 389 Priority: 0 Weight: 100
support_resolv.cc(439): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Host: 192.168.48.2 Port: -1 Priority: -1 Weight: -1
support_resolv.cc(439): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Host: TEST.LOCAL Port: -1 Priority: -2 Weight: -2
support_ldap.cc(845): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Setting up connection to ldap server dc04.TEST.local:389
support_ldap.cc(856): pid=1763 :2016/01/18 15:17:54| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
support_sasl.cc(268): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
support_ldap.cc(860): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact LDAP server
support_ldap.cc(845): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Setting up connection to ldap server dc03.TEST.local:389
support_ldap.cc(856): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
support_ldap.cc(870): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Successfully initialised connection to ldap server dc03.TEST.local:389
support_ldap.cc(299): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Search ldap server with bind path "" and filter: (objectclass=*)
support_ldap.cc(569): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Search ldap entries for attribute : schemaNamingContext
support_ldap.cc(615): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: 1 ldap entry found with attribute : schemaNamingContext
support_ldap.cc(308): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Search ldap server with bind path CN=Schema,CN=Configuration,DC=TEST,DC=local and filter: (ldapdisplayname=samaccountname)
support_ldap.cc(311): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Found 1 ldap entry
support_ldap.cc(316): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Determined ldap server as an Active Directory server
support_ldap.cc(978): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Search ldap server with bind path dc=TEST,dc=LOCAL and filter : (samaccountname=student TEST-Internet-Standart)
support_ldap.cc(991): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Found 0 ldap entries
support_member.cc(68): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: INFO: User student TEST-Internet-Standart is not member of group@domain TEST-Internet-Standart@TEST.LOCAL
support_member.cc(83): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Default domain loop: group@domain TEST-Internet-Standart@TEST.LOCAL
support_member.cc(111): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: Default group loop: group@domain TEST-Internet-Standart@TEST.LOCAL
ERR
kerberos_ldap_group.cc(407): pid=1763 :2016/01/18 15:17:55| kerberos_ldap_group: DEBUG: ERR

Ответить

Вернуться в «Прокси-сервер Squid»