В этой части мы рассмотрим ряд подготовительных манипуляций по созданию доменных групп безопасности, которые будут использоваться для ограничения доступа к Интернет, а также созданию вспомогательных файлов, ссылки на которые будут включены в основной конфигурационный файл Squid 3.3.8. Затем отредактируем основной конфигурационный файл Squid и проверим работу нашего прокси-сервера с новыми настройками.
Создаём доменные группы доступа
Ранее по условиям нашей задачи было определено, что для разграничения доступа пользователей к Интернет мы будем использовать группы безопасности в домене Active Directory (AD). Создадим несколько таких групп:
- KOM-Internet-Blocked - Пользователи которым запрещён любой доступ в Интернет. Проверка членства в этой группе в Squid будет проверяться в первую очередь. Поэтому, даже если получиться так, что пользователь по ошибке включён в какие-то другие группы доступа, в доступен к Интернет такому пользователю всё равно будет отказано.
- KOM-Internet-Restricted - Пользователи Интернет с доступом к ограниченному списку сайтов. В большинстве случаев есть ряд пользователей, которым для выполнения служебных обязанностей требуется доступ к определённым Интернет-ресурсам, а к любым другим внешним ресурсам доступ нужно ограничить.
- KOM-Internet-Standard - Пользователи Интернет с доступом к любым сайтам за исключением списка блокированных сайтов (настройка такого списка будет выполнена в отдельном файле). В эту группу входит основная масса пользователей.
- KOM-Internet-Full-Auth - Пользователи Интернет с доступом ко всем сайтам без исключений. В такую группу может входить например руководство компании, которое хочет ограничить доступ к некоторым Интернет-ресурсам своим подчинённым, а само при этом желает иметь полный доступ без ограничений.
- KOM-Internet-Full-Anon - Пользователи Интернет с доступом ко всем сайтам без исключений. Отличие этой группы от предыдущей заключается в том, что доступ в Интернет для членов этой группы не будет записываться в лог и поэтому не будет фигурировать в отчетности использования ресурсов Интернет. То есть данная группа предназначена для возможных сценариев требования анонимности некоторых пользователей.
Как видим, группы перечислены в порядке расширения прав доступа. И именно в таком порядке мы будем обрабатывать эти группы в конфигурационном файле Squid.
KOM-Internet-All-Users – Это ещё одна служебная группа, которую мы создадим. Она будет включать в себя все вышеперечисленные группы. Эта группа потребуется нам в дальнейшем для настройки отчетности использования ресурсов Интернет.
Наполним созданные группы доменными пользователями. Помимо прямого членства пользователей в эти группы можно включать другие доменные группы доступа, так как членство в группах будет выполняться с учетом возможной вложенности.
Настраиваем вспомогательные файлы параметров
Настраиваемая нами в Squid система аутентификации пользователей будет иметь три типа: Negotiate, NTLM, Basic. Первый тип будет представлять собой согласование с клиентом, где Kerberos будет использоваться как приоритетный протокол аутентификации а NTLM как альтернативный. Второй тип будет аутентифицировать клиентов, которые имеют явное желание использовать протокол NTLM. Третий тип рассматривается как исключительный (в силу его небезопасности) и нужен лишь для поддержки приложений, которые умеют работать только с Basic аутентификацией. Минимальные подготовительные процедуры для обеспечения функциональности Kerberos и NTLM мы рассмотрели в прошлой части. Если же говорить о Basic аутентификации, то здесь нам потребуется дополнительно создать в домене отдельную учетную запись пользователя, от имени которого будет выполняться подключение к AD, как к LDAP-каталогу для выполнения Basic-аутентификации а также авторизации (проверке членства в доменных группах). Лучше всего, чтобы это была отдельная учетная запись пользователя с минимальным набором прав в домене, однако в нашем примере для упрощения будет использоваться та же учетная запись, которая ранее нами была создана для поддержки Kerberos-аутентификации (s-KOM-SquidKerb).
Создадим отдельный файл conf_param_ldappass.txt в котором будет храниться пароль этой учетной записи для дальнейшего использования на него ссылок из конфигурационного файла Squid.
sudo sh -c "echo 'PasSw0rd' > /etc/squid3/conf_param_ldappass.txt" sudo chmod o-r /etc/squid3/conf_param_ldappass.txt sudo chgrp proxy /etc/squid3/conf_param_ldappass.txt ls -la /etc/squid3/conf_param_ldappass.txt -rw-r----- 1 root proxy 17 Jun 5 19:19 /etc/squid3/conf_param_ldappass.txt
***
Далее создадим дополнительные конфигурационные файлы в которых будут записаны ранее созданные нами доменные группы безопасности. Разумеется этого можно и не делать и напрямую в дальнейшем включить названия групп в основной конфигурационный файл Squid, однако подход с модульностью параметров (когда данные параметров подключаются из дополнительных внешних файлов) в некоторых случаях может быть удобен и полезен.
sudo sh -c "echo 'KOM-Internet-Blocked' > /etc/squid3/conf_param_groups_blocked.txt" sudo sh -c "echo 'KOM-Internet-Restricted' > /etc/squid3/conf_param_groups_restricted.txt" sudo sh -c "echo 'KOM-Internet-Standard' > /etc/squid3/conf_param_groups_standard.txt" sudo sh -c "echo 'KOM-Internet-Full-Auth' > /etc/squid3/conf_param_groups_full_auth.txt" sudo sh -c "echo 'KOM-Internet-Full-Anon' > /etc/squid3/conf_param_groups_full_anon.txt"
***
Создаём дополнительные конфигурационные файлы для хранения разных списков сайтов.
sudo touch /etc/squid3/conf_param_sites_allowed.txt sudo touch /etc/squid3/conf_param_sites_blocked.txt sudo touch /etc/squid3/conf_param_sites_priority.txt
Файл conf_param_sites_priority.txt будет содержать перечень сайтов к которым нужно предоставить всем без исключения пользователям организации без аутентификации и авторизации на прокси. То есть доступ к этим Интернет-сайтам будет разрешён для пользователей, даже если они не включены ни в одну из доменных групп доступа. К таким сайтам может относиться например внешний Интернет-сайт компании. Или например есть на компьютерах пользователей такое приложение как Microsoft Office 2013, которое может вести себя неадекватно при использовании требующего аутентификацию прокси-сервера отличного от Microsoft ISA/TMG. В частности при открытии приложений типа Word 2013 или Excel 2013 пользователь может получать многократные запросы авторизации, так как эти приложения пытаются получить доступ к внешним веб-узлам Microsoft, при этом сами эти приложения ни в какую не хотят представлять прокси серверу данные для аутентификации пользователя (проверено на дампе сетевого трафика). Поэтому для того, чтобы не ущемлять функциональность Microsoft Office, было решено включить используемые им URL в файл conf_param_sites_priority.txt. Пример такого файла:
### How to add domains to this file # # 1. Use only the domain name EXCLUDING the protocol prefix, i.e. # don't put "http://" at the start. # # 2. Do not append a directory to the domain name, i.e. don't put # /index.php/path/blah.html at the end of the name. # # 3. Prefix each entry with a single dot ".", this ensures a match of # example.com and www.example.com. # # 4. If you need to match different top level domains like .com, # .net, .com.au for sites that have multiple top level domains to # the same website then add a seperate entry for each e.g. # .example.com # .example.com.au # ### # # Corp.sites # .www.holding.com # # Learning sites # .cdo.academlp.ru .tests24.ru # # Microsoft Office sites # .officeimg.vo.msecnd.net .office.microsoft.com .office15client.microsoft.com .officeapps.live.com #
Файл conf_param_sites_allowed.txt будет содержать перечень сайтов, к которым нужно предоставить доступ ограниченной категории пользователей, прошедшим аутентификацию и авторизацию на прокси. Пользователи которым разрешается доступ только к этому списку сайтов должны быть включены в доменную группу доступа KOM-Internet-Restricted. Ко всем другим сайтам Интернет доступ для данной категории пользователей будет запрещён. Примером из жизни могут стать пользователи которым нужно дать доступ к определённым Интернет-сайтам компаний партнёров по бизнесу, а к Интернету в целом доступ должен быть заблокирован. Пример такого файла (без закомментированных строк в шапке файла по аналогии с предыдущим примером):
.app1.partner1.ru .arm.sub.partner2.ru
Файл conf_param_sites_blocked.txt будет содержать перечень сайтов, доступ к которым необходимо запретить всем пользователям Интернет (не относиться к пользователям включённым в группы KOM-Internet-Full-*). Примером таких сайтов могут быть сайты, содержимое которых по мнению руководства может отрицательно влиять на трудовую дисциплину сотрудников компании, типа социальных сетей, развлекательных сайтов и т.п.. Другим кандидатом в попадание в такой список могут стать сайты, доступ к которым необходимо ограничить согласно писем Роскомнадзора. Пример такого файла:
.fourthreich.com .nssukr.com
***
Отдельно обозначим создание двух дополнительных конфигурационных файлов для обеспечения доступа определённых компьютеров сети к определённым сайтам со службой Windows Update
sudo touch /etc/squid3/conf_param_sites_wsus.txt sudo touch /etc/squid3/conf_param_computers_wsus.txt
Создание таких файлов обусловлено тем, что используемый в нашей ситуации сервер System Center 2012 R2 Configuration Manager (SCCM) занимающийся автоматической загрузкой обновлений из Интернет-службы Microsoft Windows Update не умеет аутентифицироваться на прокси и поэтому ему нужно организовать прямой доступ к соответствующим веб-ресурсам.
Файл conf_param_sites_wsus.txt будет содержать список сайтов Microsoft к которым соответствующим компьютерам локальной сети нужно организовать прямой доступ. Пример такого файла:
# .download.windowsupdate.com #
Файл conf_param_computers_wsus.txt соответственно будет содержать список IP-адресов серверов SCCM. Пример такого файла:
# # KOM-AD01-SCCM01 10.160.250.100 #
Настаиваем основной конфигурационный файл squid.conf
Перед тем как начать редактирование основного конфигурационного файла /etc/squid3/squid.conf хорошим тоном будет создать его резервную копию, чтобы на всякий случай иметь под рукой возможность восстановления конфигурации по умолчанию, после чего можно со спокойной душой открыть исходный файл на редактирование:
sudo cp /etc/squid3/squid.conf /etc/squid3/squid.conf.default sudo nano -Y sh /etc/squid3/squid.conf
Далее мы рассмотрим пример конфигурационного файла, разбив его содержимое на основные логические секции и предварительно в трёх словах описав ту или иную часть настроек.
Аутентификация и авторизация пользователей в Squid выполняется вспомогательными программами, так называемыми хелперами. В первой части конфигурации выполняется описание вызовов этих хелперов с передачей им необходимых параметров и в порядке их приоритетности. Как ранее уже было отмечено, в нашем примере будет использоваться три схемы аутентификации. Сначала идёт описание приоритетного метода аутентификации – Согласование выбора Kerberos или NTLM. Затем если клиент по какой-то причине не может использовать аутентификацию Kerberos и при этом готов работать с NTLM – выполняется обработка настроек NTLM. Ну и в последнюю очередь описывается работа метода Basic.
Для процедур согласования будет использоваться специальный хелпер negotiate_wrapper_auth доступный в составе Squid3. Этот отвечает за вызов аутентификации Kerberos с помощью хелпера negotiate_kerberos_auth (из состава Squid) либо аутентификации NTLM c помощью хелпера ntlm_auth (из состава Samba). При этом в качестве важных параметров Kerberos-хелпера указывается SPN служебной учетной записи, для которой ранее мы генерировали keytab-файл.
Для процедуры Basic-аутентификации будет использоваться хелпер basic_ldap_auth из состава Squid3.
Возможные значения параметров auth_param для разных методов аутентификации довольно подробно расписаны в комментариях конфигурационного файла squid.conf. Возможные значения ключей хелперов расположенных по умолчанию в каталоге /usr/lib/squid3/, как правило, можно узнать при самостоятельном вызове этих хелперов к ключами –h или –-help.
# SQUID 3.3.8 Configuration # ----------------------------------------------------------------------------- # # OPTIONS FOR AUTHENTICATION # ----------------------------------------------------------------------------- # # Negotiate Kerberos and NTLM authentication auth_param negotiate program /usr/lib/squid3/negotiate_wrapper_auth --ntlm /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --kerberos /usr/lib/squid3/negotiate_kerberos_auth -r -s HTTP/kom-ad01-squid.holding.com@HOLDING.COM auth_param negotiate children 200 startup=50 idle=10 auth_param negotiate keep_alive off # Only NTLM authentication auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 100 startup=20 idle=5 auth_param ntlm keep_alive off # Basic authentication via ldap for clients not authenticated via kerberos/ntlm auth_param basic program /usr/lib/squid3/basic_ldap_auth -v 3 -P -R -b "dc=holding,dc=com" -D s-KOM-SquidKerb@holding.com -W /etc/squid3/conf_param_ldappass.txt -f sAMAccountName=%s -h kom-ad01-dc01.holding.com kom-ad01-dc02.holding.com auth_param basic children 20 auth_param basic realm "KOM-AD01-GW10 SQUID Proxy Server Basic authentication!" auth_param basic credentialsttl 2 hours
Далее идёт секция описания списков контроля доступа (ACL). Сначала опишем основной ACL внешнего типа, который будет вызывать хелпер LDAP-авторизации ext_ldap_group_acl (из состава Squid3), который в свою очередь фактически будет выполнять проверку членства уже аутентифицированного на прокси пользователя в доменных группах группах безопасности, чтобы понять какой этому пользователю в дальнейшем нужно предоставить доступ. Обратите внимание на то, что в LDAP-фильтре используемом для поиска к атрибуту memberOf добавлен ключ :1.2.840.113556.1.4.1941:, который объясняет LDAP-серверу (контроллеру домена AD), что поиск членства в группах нужно выполнять с учётом вложенности групп.
# ACCESS CONTROLS # ----------------------------------------------------------------------------- # # LDAP authorization external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_ldap_group_acl -v 3 -P -R -K -b "dc=holding,dc=com" -D s-KOM-SquidKerb@holding.com -W /etc/squid3/conf_param_ldappass.txt -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,OU=Security Groups,OU=KOM,DC=holding,DC=com))" -h kom-ad01-dc01.holding.com kom-ad01-dc02.holding.com #
Далее идёт секция описания всех основных ACL, которые по сути являются переменными содержащими некие значения, которыми в дальнейшем будут оперировать правила доступа.
Первый ACL нужен для объявления в дальнейшем в некоторых правилах обязательного требования аутентификации пользователя.
Следующие пять ACL нужны для вызова описанного ранее внешнего ACL для проверки членства в той или иной доменной группе описанной в подключаемых файлах.
Следующие три ACL описывают разные списки сайтов из соответствующих подключаемых файлов. Следующие два ACL потребуются нам в дальнейшем для описания правил для Windows Update.
Затем идёт ряд ALC используемых в конфигурации по умолчанию, важным из которых для нас является ALC описывающий диапазон локальной сети, клиенты из которого будут иметь возможность подключаться к нашему прокси серверу. ACL описывающие разрешённые для проксирования порты вполне можно принять в предлагаемом по умолчанию составе.
acl auth proxy_auth REQUIRED acl BlockedAccess external memberof "/etc/squid3/conf_param_groups_blocked.txt" acl RestrictedAccess external memberof "/etc/squid3/conf_param_groups_restricted.txt" acl StandardAccess external memberof "/etc/squid3/conf_param_groups_standard.txt" acl FullAccess external memberof "/etc/squid3/conf_param_groups_full_auth.txt" acl AnonymousAccess external memberof "/etc/squid3/conf_param_groups_full_anon.txt"
acl allowedsites dstdomain "/etc/squid3/conf_param_sites_allowed.txt" acl blockedsites dstdomain "/etc/squid3/conf_param_sites_blocked.txt" acl prioritysites dstdomain "/etc/squid3/conf_param_sites_priority.txt" # acl LocalWUServers src "/etc/squid3/conf_param_computers_wsus.txt" acl GlobalWUSites dstdomain "/etc/squid3/conf_param_sites_wsus.txt" # # # Squid default ACLs # ACLs all, manager, localhost, and to_localhost are predefined. # acl manager proto cache_object # acl localhost src 127.0.0.1/32 ::1 # acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 acl localnet src 10.0.0.0/8 # RFC1918 possible internal network #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network #acl localnet src 192.168.0.0/16 # RFC1918 possible internal network #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. Очередность расположения правил играет важную роль и поэтому правила расположены в такой последовательности, которая позволит задействовать все созданные нами ACL в соответствии с их предназначением. Самым последним правилом запрещается любой доступ в Интернет, то есть действует принцип, при котором всё, что явно не разрешено ранее идущими правилами – запрещено.
# # Deny requests to certain unsafe ports http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports # Аllow cachemgr access from localhost and localnet http_access allow localhost manager http_access allow localnet manager http_access deny manager # Allow direct access to Windows Update http_access allow GlobalWUSites LocalWUServers # Allow unrestricted access to prioritysites http_access allow prioritysites localnet # Enforce authentication, order of rules is important for authorization levels http_access deny !auth # Prevent access to basic auth prompt for BlockedAccess users http_access deny BlockedAccess all http_access allow allowedsites localnet http_access deny RestrictedAccess all http_access allow AnonymousAccess auth localnet http_access allow FullAccess auth localnet http_access deny blockedsites http_access allow StandardAccess auth localnet # And finally deny all other access to this proxy http_access deny all #
Далее идёт не менее важная секция описывающая то, на каких сетевых интерфейсах Squid будет принимать подключения. Ограничим возможность подключения рамками локальной сети, чтобы наш прокси сервер не отвечал на запросы из Интернет.
# NETWORK OPTIONS # ----------------------------------------------------------------------------- # http_port 10.160.0.2:3128 http_port 127.0.0.1:3128 #
Увеличение значения параметра forward_max_tries может оказаться полезно в ситуациях, когда на запрос прокси на разрешение имени какого-либо Интернет-ресурса возвращено большое количество внешних IP адресов, часть из которых не отвечает на запросы.
# OPTIONS WHICH AFFECT THE NEIGHBOR SELECTION ALGORITHM # ----------------------------------------------------------------------------- # hierarchy_stoplist cgi-bin ? forward_max_tries 25 #
Далее идут параметры кэширования веб-контента. Кэш Squid делится на оперативный кэш в ОЗУ и дисковый кэш. Если нужна высокая скорость работы кэша при большом количестве ОЗУ на сервере, то можно отказаться от использования дискового кэша вообще. Если же объём ОЗУ не велик, то при необходимости можно значительно увеличить общий объем кэша перенеся его бОльшую массу да диск. В нашем случае именно так и сделано, то есть используется гибридная конфигурация кэширования с 2GB кэша в ОЗУ и 7GB кэша на отдельном диске, который мы приготовили в одной из предыдущих частей нашего описания.
# MEMORY CACHE OPTIONS # ----------------------------------------------------------------------------- # cache_mem 2048 MB maximum_object_size_in_memory 2048 KB memory_replacement_policy heap GDSF # DISK CACHE OPTIONS # --------------------------------------------------------------------------- # cache_replacement_policy heap LFUDA cache_dir ufs /mnt/squid-cache/ 7000 16 256 maximum_object_size 32768 KB #
Далее идут параметры логирования (напомню, что пользователи из ACL AnonymousAccess не логируются) и траблшутинга. Затем идёт конфигурация по умолчанию для тюнинга кэширования и ряд других параметров. Отдельное внимание стоит обратить на то, что весьма желательно с помощью параметра cachemgr_passwd ограничить паролем доступ к менеджеру кэша Squid, который доступен через URL http://kom-ad01-squid.holding.com:3128/squid-internal-mgr/menu из локальной сети согласно настроенного нами ранее правила “http_access allow localnet manager”. Если этого не сделать то все желающие из локальной сети как минимум смогут получить доступ к информации о паролях пользователей используемых в схемах Basic-аутентификации.
# LOGFILE OPTIONS # ----------------------------------------------------------------------------- # # don't log AnonymousAccess access_log daemon:/var/log/squid3/access.log squid !AnonymousAccess # OPTIONS FOR TROUBLESHOOTING # ----------------------------------------------------------------------------- # cache_log /var/log/squid3/cache.log coredump_dir /var/spool/squid3 # OPTIONS FOR TUNING THE CACHE # ----------------------------------------------------------------------------- # refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880 refresh_pattern . 0 20% 4320 # ADMINISTRATIVE PARAMETERS # ----------------------------------------------------------------------------- # cache_mgr DST-SQUID-Admins@holding.com httpd_suppress_version_string on visible_hostname KREVEDKO-01 # ERROR PAGE OPTIONS # ----------------------------------------------------------------------------- # error_directory /usr/share/squid3/errors/ru error_default_language ru # DNS OPTIONS # ----------------------------------------------------------------------------- # dns_v4_first on # MISCELLANEOUS # ----------------------------------------------------------------------------- # forwarded_for delete cachemgr_passwd StrOnG_PaZsZw0rD all # #
Разумеется приведённый пример конфигурационного файла squid.conf не отражает всего множества доступных параметров, позволяющих гибко тюнинговать функции Squid, а лишь является примером рабочей базовой конфигурации.
После того как мы закончили с редактированием конфигурационного файла, выполним его проверку на наличие синтаксических ошибок:
sudo squid3 -k parse
Если парсер не обнаружил никаких явных ошибок, то можем применить новую конфигурацию Squid:
sudo squid3 -k reconfigure
***
После этого можно приступать к проверке настроенных нами правил доступа на клиентских компьютерах локальной сети. Корректность работы схем аутентификации желательно проверить на разных браузерах.
В случае проблем в реальном режиме времени смотрим логи:
sudo tail -f /var/log/squid3/cache.log
sudo tail -f /var/log/squid3/access.log
***
На данном этапе можно считать, что наш прокси-сервер функционирует и способен обслуживать клиентов локальной сети. В следующей части мы рассмотрим пример авто-настройки браузеров на клиентских компьютерах сети с помощью механизмов Proxy Auto Configuration (WPAD) на базе веб-сервера Apache2.
***
Предыдущие части цикла заметок:
Часть 1. Установка ОС на ВМ Hyper-V Gen2
Часть 2. Настройка диска для кэша Squid
Часть 3. Конфигурация DNS , NTP и установка Squid
Часть 4. Конфигурация Kerberos и NTLM
Следующие части цикла заметок:
Часть 6. Настройка Proxy Auto Configuration (WPAD)
Часть 7. Кастомизация страниц ошибок
Часть 8. Конфигурация SqStat
Часть 9. Конфигурация LightSquid
Часть 10. Отключаем IPv6
RSS - Записи
т.к. сам занимаюсь подобной проблемой под freebsd 10.0 в виртуалке, то есть вопросы:
1.Почему выбор пал именно на убунту?
2. не увидел настроек файрвола. под 10-й настраивал файрвол, пришлось открывать порты определенные на контролеры домена - тут не вижу файрвола. порты открыты?
3. nat не используется? вот например включить нат для опреденных серверов выглядить как бы логично.
1. Ответ на этот вопрос изложен в самом начале первой части цикла заметок.
2. Специальных настроек фаервола не делал, так как с точки зрения локальной сети всё заработало без дополнительных манипуляций. С точки зрения доступа к серверу из Интернет - если Вы внимательно просмотрите конфигурацию служб и приложений сервера с самого начала цикла заметок, то сможете обратить внимание на то, что все открываемые TCP-прослушиватели настраиваются на работу исключительно на LAN-интерфейсе.
Проверить то какие порты и на каких интерфейсах в Ubuntu Server прослушиваются в системе можно например с помошью команды:
sudo ss -lnptu | sort
Для бОльшего успокоения можно дополнительно прощупать доступность открытых портов сервера из Интернет с помощью таких онлайн-сервисов как например TestIP - Portscan (выбрать полный тест).
3. Сценарий при котором потребуется какая-то отдельная настройка NAT не предполагается на сервере, который изначально позиционируется как выделенный прокси-сервер, ибо, как Вы можете заметить, описание цикла заметок называется не "Настройка роутера на Linux..." а несколько иначе.
Список проксируемых портов в описанной конфигурации достаточно большой и я пока не могу представить ситуацию, в которой нельзя было бы выпустить тот или иной компьютер локальной сети к ресурсам Интернет через Squid.
1. Да, не досмотрел преимущества убунту в виртуальной среде :-)
2.то что программа слушает только внутренню сеть как бы +, но без файрвола ставить прокси сервак в инет я бы побоялся. ошибки в по есть во всех ос. лучше все таки подумать 10 раз прежде.
3.хе! криво написаный банк клиент требует исключительно нат. или например программа для для подбора климатического оборудования с автообновлением и авторизацией через интернет. при наличии файрволклиента на клиентской машине эта проблема решается. а вот тут даже не знаю как и решить. настроек прокси нету, программа ломится напрямую в инет по ip
А за цикл статей спасибо!
по п.2 согласен. Постараюсь дополнить соответствующей информацией первую часть описания.
Доброго дня! Огромное спасибо за интересные статьи!
Хотелось бы узнать:
1) Как при такой схеме происходит авторизация в программах типа skype, qip, magent, teamviewer, ammyy и им подобных? Через basic с указанием в настройках каждой программы?
2) Тестировали работу нестандартных браузеров? IE, Firefox, Google Chome - должны будут работать без проблем. А вот всякие Яндекс-браузеры, Маилру-интернеты, Амиги и прочие активно втюхиваемые пользователям поделки?
3) Как в случае таких схем авторизации поступаете с терминальными серверами? Блокируете доступ с их ip-адресов перед разрешением пользователям:
http_access deny IpOfTerminalServer
http_access allow Users
так?
1. Где как. Всё зависит от возможностей ПО. Из перечисленного списка был свидетелем проверки успешной работы QIP Infium с использованием NTLM аутентификации. Там где Kerberos или NTLM недоступны используется Basic.
2. По тестам браузеров могу сказать следующее. Адекватней всего с разными схемами аутентификации ведут себя Mozilla Firefox и IE. Chrome и Opera в той или иной ситуации дуркуют. Весь прочий сброд нужно убирать с компьютеров пользователей административными методами, чтобы потом не ломать себе пальцы.
3. Никак. На ферме терминальных серверов пользовательское окружение полноценное, то есть в том числе работает и Интернет, и я не вижу веских причин для того, чтобы его ограничивать.
Обратная ссылка: Базовая настройка брандмауэра Ubuntu Server 14.04 LTS с помощью iptables | Блог IT-KB /
Здравствуйте Алексей!
Прошу помочь, решил настроить прокси-сервер согласно вашей инструкции, выполнил все до 5 части включительно, но к сожалению прокси не раздает интернет.
https://cloud.mail.ru/public/8074a0c78e0d/ie-error.png
прилагаю лог файлов cache, access и squid_conf
https://cloud.mail.ru/public/a1fb6cadd3e0/cache_log-access_log-squid_conf.txt
Где моя ошибка?
Что я делаю не так?
Вероятно проблема в авторизации (проверка членства в доменных группах). Повышайте уровень логирования в squid.conf (в вербозном логе cache.conf возможно станет более очевиден корень проблемы)
external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_ldap_group_acl -v 3 -P -R -K -b "dc=holding,dc=com" -D s-KOM-SquidKerb@holding.com -W /etc/squid3/conf_param_ldappass.txt -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,OU=Security Groups,OU=KOM,DC=holding,DC=com))" -h kom-ad01-dc01.holding.com kom-ad01-dc02.holding.com
может sAMAccountName=%u а не %v ?
Алексей, Доброго времени суток!
У меня проблема похожая на проблему Kamrad Verdana, как вы и писали, похоже что проблема в проверке членства в доменных группах. Собственно вопрос можете ли Вы подробнее расписать что означает конструкция external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_ldap_group_acl -v 3 -P -R -K -b "dc=holding,dc=com" -D s-KOM-SquidKerb@holding.com -W /etc/squid3/conf_param_ldappass.txt -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,OU=Security Groups,OU=KOM,DC=holding,DC=com))" -h kom-ad01-dc01.holding.com kom-ad01-dc02.holding.com. Особенно ее часть OU=Security Groups,OU=KOM,DC=holding,DC=com, т.к. у меня не совсем такие OU в домене. Или другой вопрос можно поподробней как повысить уровень логирования в squid.conf.
external_acl_type - параметр определяющий ACL данные которого формируются путём вызова внешней программы-хелпера.
memberof - придуманное нами название ACL.
далее идут параметры ACL (все их возможные значения и описание есть в дефолтном squid.conf)ttl=3600 > время жизни кэша полученных значений в секундах
ipv4 > форсированное использование протокола IPv4
%LOGIN > сюда передаётся логин текущего пользователя для которого выполняется авторизация
далее идёт путь к самой внешней программе-хелперу > /usr/lib/squid3/ext_ldap_group_acl
вызвав хэлпер в командной строке без параметров вы сможете узнать список всех доступных для хелпера параметров и их краткое описание.
Достаточно просто нагуглить и онлайн справыку по ключам хэлпера, например
http://manpages.ubuntu.com/manpages/saucy/man8/ext_ldap_group_acl.8.html
В нашем случае используются следующие ключи:
-v 3 > Используем версию LDAPv3
-P > Используем постоянные подключения к LDAP-каталогу
-R > Где-то находил информацию о полезности ключа (сейчас сходу не найду)
-K > Отрезаем доменную часть от имени пользователя
-b «dc=holding,dc=com» > LDAP-корень с которого начинаем поиск
-D s-KOM-SquidKerb@holding.com > Учетная запись от имени которой подключаемся к LDAP-каталогу
-W /etc/squid3/conf_param_ldappass.txt > Пароль учетной записи (мы храним его во внешнем файле)
-f «(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,OU=Security Groups,OU=KOM,DC=holding,DC=com))» > LDAP-фильтр используемый для поиска.
то есть здесь мы выполняем поиск в LDAP-каталоге всех объектов типа person, с именем пользователя %v, и у которых при этом атрибут memberOf содержит внутри себя путь cn=%g,OU=Security Groups,OU=KOM,DC=holding,DC=com
где переменная %g - имя доменной группы (берется из соответсвующих подключаемых в нашем примере файлов описывающих доменные группы доступа)
OU=Security Groups,OU=KOM,DC=holding,DC=com в нашем примере это контейнер где лежат группы доступа, про которые идёт в заметке речь.
-h kom-ad01-dc01.holding.com kom-ad01-dc02.holding.com > Здесь мы перечисляем 2 котнтроллера домена в качестве источника LDAP-каталога.
Проверить отдельно работу хелпера можно вызвав его напрямую из командной строки со всеми параметрами, заменив значения %v и %g накакие-то реальные данные
По поводу логирования. Здесь всё зависит от того, какой именно лог мы хотим сделать более подробным.
Посмотрите описание параметра debug_options в дефолтном squid.conf
Помимо этого можно включить расширенное логирование для какого-то конкретного хэлпера, они как правило все имеют соответствующие ключи запуска.
Алексей, спасибо большое за развернутый ответ!
Похоже нашел в чем у меня проблема. Начать следует с того, что контроллер домена у меня организован не на винде, а на Ubuntu Server + Samba4 (Имитирует работу домена Windows Server 2003) и, похоже, что Samba не все функции имитирует. Например, в моем случае в конструкции, которая была выше подробно разобрана, моим контроллером домена не обрабатывается ключ :1.2.840.113556.1.4.1941:, который нужен для определения членства в группе с учетом вложенности групп. Т.е. если убрать этот ключ и добавить пользователя в нужную группу, то все работает, а с вложенными группами пока не получается. Может есть идеи куда копать в данном случае?
Указанный цифровой ключ это фича Microsoft-реализации LDAP в AD и разумеется в других LDAP-каталогах она работать не будет. Как я понимаю, сам по себе хелпер ext_ldap_group_acl вложенность групп не обрабатывает, поэтому в Вашем конкретном случае нужно либо использовать структуру простых групп без вложенности (что проще всего организовать), либо искать замену указанного хелпера на какой-то другой, способный обрабатывать вложенность групп.
создаю одну греппу в АД к примеру internet_www добавляю туда пользователя, далее пишу:
sudo sh -c "internet_www' > /etc/squid3/internet"
потом даю этой группе полный доступ в интернет, следующим образом:
http_access allow internet_www
меня ни куда не пускает, такое ощущение что не чекаются группы в АД. подскажите куда копать?
Портянки с логами публиковаться в ветке комментариев не будут.
Пишите все свои вопросы в этот раздел http://forum.it-kb.ru/viewforum.php?f=52
Там можно более подробно с логами, скриншотами и т.п.
При этом просьба разделять вопросы по отдельным топикам, а не валить всё в одну кучу.
Добрый день! Спасибо вам огромное за ваш бесценный труд! Возникла проблема при попытке проверить авторизацию по доменный группам (В роли AD старенький WinServer2003)
/usr/lib/squid3/ext_ldap_group_acl -v 3 -P -R -K -b "dc=mydomen,dc=ru" -D gate@mydomen.ru -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%u,OU=SQUID3,DC=mydomen,DC=ru))" -h pdc.mydomen.ru
%u поставил, т.к. увидел в описании хелпера
-f filter (REQUIRED) group search filter pattern. %u = user,
%v = group
ext_ldap_group_acl: WARNING: LDAP search error 'Operations error'
ERR
Пробовал оставить как у вас, рез-т тот же
В чем может быть проблема?
Спасибо
Посмотрите тему http://forum.it-kb.ru/viewtopic.php?f=52&t=70
Там описан пример тестирования хелпера ext_ldap_group_acl.
Если не будет получаться, то можете открыть в разделе http://forum.it-kb.ru/viewforum.php?f=52 отдельную тему и там можно будет попробовать разобрать ситуацию.
При проверке выдает ошибку:
# sudo /usr/lib/squid3/ext_ldap_group_acl -d -v 3 -P -R -K -b "ou=MC_Users,dc=mc,dc=local" -D s-MC-SquidKerb@mc.local -W /etc/squid3/conf_param_ldappass.txt -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,OU=MC_Users,OU=Access Group,OU=ProxyGroups,DC=mc,DC=local))" -h dc.mc.local
User Internet-Standart
ext_ldap_group_acl.cc(587): pid=1751 :Connected OK
ext_ldap_group_acl.cc(726): pid=1751 :group filter '(&(objectclass=person)(sAMAccountName=User)(memberOf:1.2.840.113556.1.4.1941:=cn=Internet-Standart,OU=MC_Users,OU=Access Group,OU=ProxyGroups,DC=mc,DC=local))', searchbase 'ou=MC_Users,dc=mc,dc=local'
ERR
Так же в логах доступа в реальном времени выдает,что доступ закрыт.
1409831114.874 0 10.0.49.102 TCP_DENIED/403 4354 GET http://player.rutv.ru/iframe/datalive/id/21/sid/r24 User HIER_NONE/- text/html
1409831119.785 3 10.0.49.102 TCP_DENIED/403 4390 CONNECT mail.google.com:443 User HIER_NONE/- text/html
1409831119.869 2 10.0.49.102 TCP_DENIED/403 4390 CONNECT plus.google.com:443 User HIER_NONE/- text/html
Что можно проверить? Все сделано по Руководству.
Попробуйте вместо -b «ou=MC_Users,dc=mc,dc=local» использовать -b «dc=mc,dc=local»
Перекинул группы доступа в корень Контролера домена и все заработало. Почему так?
Добрый день, делаю настройку squid по вашему циклу статей, но вот возникла проблема, squid не стартует, в логах вижу вот такую ошибку:
2014/09/18 09:33:50 kid1| WARNING: negotiateauthenticator #Hlpr0 exited
2014/09/18 09:33:50 kid1| Too few negotiateauthenticator processes are running (need 10/200)
2014/09/18 09:33:50 kid1| Closing HTTP port 192.168.1.65:3128
2014/09/18 09:33:50 kid1| Closing HTTP port 127.0.0.1:3128
2014/09/18 09:33:50 kid1| storeDirWriteCleanLogs: Starting...
2014/09/18 09:33:50 kid1| Finished. Wrote 0 entries.
2014/09/18 09:33:50 kid1| Took 0.00 seconds ( 0.00 entries/sec).
FATAL: The negotiateauthenticator helpers are crashing too rapidly, need help!
Не могу понять где косяук.
Возможно проблема в работе хелпера negotiate (/usr/lib/squid3/negotiate_wrapper_auth). Попробуйте запустить хелпер сам по себе отдельно (посмотрите какие у него есть ключи запуска дополнительные). Включайте в squid режим расширенного логирования и отлавливайте проблему.
Да спасибо, разобрался, но вот авторизацию не проходит, браузер просит пароль, хотя по логике не должен, но и вводя пароль он не проходит, получаю ошибку:
HTTP/1.1 407 Proxy Authentication Required
Server: squid
Mime-Version: 1.0
Date: Fri, 19 Sep 2014 14:41:02 GMT
Content-Type: text/html
Content-Length: 4084
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
Proxy-Authenticate: Negotiate
Proxy-Authenticate: NTLM
Proxy-Authenticate: Basic realm=""SQUID Proxy Server Basic authentication!""
X-Cache: MISS from KREVEDKO
X-Cache-Lookup: NONE from KREVEDKO:3128
Via: 1.1 KREVEDKO (squid)
Connection: close
Права я все выдал на каталог где кеш, более полный лог тут:
http://hastebin.com/zukokefoka.coffee
Спасибо.
Авторизация выполняется после аутентификации. Если Вы считаете, что фаза аутентификации успешно выполнена, а проблема возникает именно в авторизации, то нужно смотреть по какой причине не работает хелпер ext_ldap_group_acl, и соответственно тестировать его. То, как это сделать, уже обсуждалось. http://forum.it-kb.ru/viewtopic.php?f=52&t=70
хелпер ext_ldap_group_acl работает
[root@ProxySrv squid]# /usr/lib/squid/ext_ldap_group_acl -v 3 -P -R -K -b "dc=kvm,dc=loc" -D ldapreader@zgs.loc -W /etc/squid/conf_param_ldappass.txt -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,OU=ProxyGroup,OU=Groups,DC=kvm,DC=loc))" -h dc01.kvm.loc
s.chistiakov Internet-Standard
OK
Добрый день!
Алексей, огромное спасибо за подробное описание процесса настройки SQUID3,
Руководствовался на примере вашего описания, возникла дополнительная задача, ограничить мультимедиа-контент с использованием группы безопасности домена - "KOM-Internet-Multimedia", которую я дополнительно создал для поставленной цели. Пытаюсь настроить с помощью "mime" типов перечисленных в /usr/share/squid3/mime.conf... Запретить то я запретил - всем, прописав:
acl mimeblock rep_mime_type -i ^video
acl mimeblock rep_mime_type -i ^audio
----------------------------------------------------
http_reply_access deny mimeblock
Моя задача запретить для группы "KOM-Internet-Standard", а в случае потребности использования мультимедиа-контента для какого либо пользователя, разрешить, добавив его в группу "KOM-Internet-Multimedia".
Как на Вашем примере, разрешить мультимедиа-контент для пользователей которые входят в "KOM-Internet-Multimedia" но уже ограниченных ранее, пользователей группой "KOM-Internet-Standard"?
P.S. Я в этом деле новичок, недавно начал осваивать азы Linux+SQUID... За ранее благодарен за помощь...
День добрый.
Настроил всё согласно мануала и всё было прекрасно.
Авторизация и группы и интернет.
сменил внешний ИП, и на тебе.
2014/10/16 09:31:46 kid1| No cache_dir stores are configured.
Интернет есть , всех согласно групп пускает но нет логов lightsquid.
Куда делась директория для кеша ?
Всё что нужно lightsquid это access-логи. И к "No cache_dir " это не имеет отношения. А что ы Вас и куда делось я сказать не могу.
Здравствуйте. Возникла проблема. Настраивал с первой по пятую часть по Вашей инструкции. Но все равно не работает - Squid разрешает доступ только к Priority Sites. Покомемнтировав строки в конфигурации Squid, выяснил, что не работают строки, где доступ разрешается через auth (например, http_access allow StandardAccess auth localnet).
Проверил на опечатки и соответствие мануалу описание хелперов, все нормально. В точности, как у Вас, за исключением, конечно, имени домена.
kinit срабатывает без ошибок.
iptables на виртуальке ubuntu server дает всем ACCEPT, из правил только одно - NAT для контроллеров домена, т.к. они ходят в интернет просто через шлюз.
Домен на WinServer 2012 R2, два контроллера dc1.domain.local и dc2.domain.local.
Подскажите, пожалуйста, в какую сторону копать?
Оказалось, я сам ступил. У меня была немного другая структура OU, в которой находятся группы доступа к интернету. Плюс у LDAP авторизации для получения списка групп ttl в 3600 секунд.
Подправил external_acl_type memberof, перезагрузил виртуальную машину ubuntu, кэш сбросился и все заработало.
Алексей, добрый день.
Использовал вашу статью как основу для настройки Squid + AD(Server 2012 R2) + Kerberos.
авторизация настроена только по kerberos.
Все работает, логи пишутся - но одна проблема - сайты открываются ну уж очень медленно.
Перед открытием браузер долго думает и потом медленно подгружает содержимое сайта. Если отключить авторизацию по kerberos - все грузиться в момент.
Можете подсказать - в чем может быть проблема?
Часть конфига squid.conf:
auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -s HTTP/gw.dmz.local@DMZ.LOCAL
auth_param negotiate children 10
auth_param negotiate keep_alive off
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow auth
http_access allow localhost manager
http_access deny manager
http_access deny !auth
http_access allow localhost
Проблема может быть в чём угодно, начиная с некорректной работы DNS в AD, заканчивая некорректной настройкой Kerberos на стороне Linux-сервера.
Добрый день )
С недавних пор начал подтупливать инет в браузерах пользователей, которые ходят через прокси. Открыл cache.log и увидел неприятные строчки:
2014/11/07 17:10:00| WARNING: Negotiate Authentication waiting for helper reply!
2014/11/07 17:10:00| WARNING: Negotiate Authentication waiting for helper reply!
ext_ldap_group_acl: WARNING: LDAP search error 'Can't contact LDAP server'
ext_ldap_group_acl: WARNING: LDAP search error 'Can't contact LDAP server'
ext_ldap_group_acl: WARNING: LDAP search error 'Can't contact LDAP server'
2014/11/07 17:20:46| WARNING: Negotiate Authentication waiting for helper reply!
2014/11/07 17:20:46| WARNING: Negotiate Authentication waiting for helper reply!
2014/11/07 17:25:44| WARNING: Negotiate Authentication waiting for helper reply!
Очевидно, что пропадает связь с DC каким-то, но не очень понятно каким (DC1 или DC2), и не получается у меня выявить момент пропажи коннекта. Пытаюсь тупо мучать хелпер ext_ldap_group_acl, запуская его из консоли и подсовывая логины пользователей и группы, но хелпер отлично справляется со своей задачей и пишет то "ОК", то "ERR" в ответ, ни разу не написав про "Cant contact LDAP Server". Посоветуйте, как бы мне отловить проблемку, чтобы её героически решить :) Заранее спасибо :) ЗЫ: Я же правильно предполагаю, что ворнинги - это следствие пропаж коннекта (или плохого коннекта) с LDAP серверами?
Для kerberos аунтификации все же использовать конкретное имя в SPN не очень хорошая идея и лучше (ИМХО) использовать squid_kerb_auth -s GSS_C_NO_NAME
Взято отсюда:
http://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory
В чём же "нехорошесть"? И чем GSS_C_NO_NAME лучше, чем использование выделенной учетной записи? Объясните. Я этого не знаю.
Спасибо за статьи!
Подскажите, пожалуйста, новичку в линуксах:
1. в cache.log есть строчки
helperOpenServers: Starting 0/20 'basic_ldap_auth' processes
helperOpenServers: No 'basic_ldap_auth' processes needed
Это нормально? Авторизация доменных пользователей на доменных машинах ("прозрачно") и через окно логин-пароль идёт.
2. после добавления "up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.160.0.1" (см ч.1)
не смог подключиться к машине через Putty. Убрал строчку - подключился. Что это?
1. Да, это нормально. В указанной выше конфигурации хелпер basic-аутентификации может быть запущен squid-ом до 20 экземпляров, но при старте не запускается ни одного. Первый экземпляр хелпера будет автоматически запущен сразу, как только в нём возникнет потребность.
2. Если хотите, то можно попробовать разобрать этот вопрос в форуме.
Извиняюсь, при переводе на свою сеть наврал в маске... Ещё раз спасибо за инструкцию. С нуля знаний и умений в ubuntu и squid собрал работающую систему. Это что-то!
Пожалуйста. В качестве благодарностей принимается щёлканье по баннерам :)
Алексей, подскажите как быть, если подразделения на русском языке? Возможности сменить название нет, т.к. права делегированы только на наше подразделение.
Я пока не услышал проблемы. Обозначьте более конкретно.
/usr/lib/squid3/ext_ldap_group_acl -d -v 3 -P -R -K -b "dc=oaoreu,dc=ru" -D 202SQUID@oaoreu.ru -W /etc/squid3/conf_param_ldappass.txt -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,OU=202 Новосибирский,OU=Филиалы,DC=oaoreu,DC=ru))" -h 202-dc-01.oaoreu.ru
shavrinsv 202-INTERNET-FULL
ext_ldap_group_acl.cc(587): pid=6921 :Connected OK
ext_ldap_group_acl.cc(726): pid=6921 :group filter '(&(objectclass=person)(sAMAccountName=ыshavrinsv)(memberOf:1.2.840.113556.1.4.1941:=cn=202-INTERNET-FULL,OU=202 Новосибирский,OU=Филиалы,DC=oaoreu,DC=ru))', searchbase 'dc=oaoreu,dc=ru'
ERR
Если перемещаю группы в "Users" то ответ получаю "ОК"
Прошу прощения, была опечатка, два часа жизни потратил на это)
Так всё-таки работает с кириллицей или нет?
Да, с кириллицей работает отлично, был удивлен. Но теперь независимо от того в какой группе находится пользователь, он не может зайти ни на одну страницу "доступ запрещен", cache.log вижу такую строчку: "helperOpenServers: No 'basic_ldap_auth' processes needed." В access.log вижу свою учетку:" 0 10.22.1.120 TCP_DENIED/403 4493 GET http://bash.im/abyssbest shavrinsv HIER_NONE/- text/html". Авторизация, вроде проходит, а в чем тогда может быть загвоздка?
Строка "No ‘basic_ldap_auth’ processes needed" в Вашей проблеме отношения скорее всего не имеет. Эта запись уже ранее объяснялась в комментариях. Насколько я понимаю, пользователя попросту не пускают к кэшу. Возможно где-то в squid.conf ошибка, возможно и какие-то другие проблемы. В любом случае разбирать это надо не здесь. Для этого есть форум.
Опять же, все проблемы от невнимательности, неправильно написал подразделение в конфиге... Еще одна проблема была связана с тем, что не дал права доступа на файлы с группами для squid
А никто так и не может дать какой-нить коммент по поводу моего поста выше? (( Про "WARNING: Negotiate Authentication waiting for helper reply!"? Заранее спасибо )
На этот вопрос у меня пока ответа нет. Наблюдаю аналогичное явление и у себя на разных серверах. Но на работоспособность прокси, как вижу, это никак ощутимо не влияет.
Здравствуйте.
Строка http_access allow allowedsites localnet разрешает доступ к доменам (/etc/squid3/conf_param_sites_allowed.txt) всей локальной сети (acl localnet src 10.0.0.0/8).
Как доменной группе разрешить доступ только к ограниченному списку сайтов, а не всей сети?
p.s. только учусь
Сделал так:
acl allowedsites url_regex "/etc/squid3/conf_param_sites_allowed.txt"
http_access allow RestrictedAccess allowedsites
#http_access deny RestrictedAccess all
вроде работает )
Здравствуйте! Прокси пропускает только на сайты из группы (allowedsites) все остальные как бы не работают помогите. проверял авторизацию все нормально((
Все спасибо разобрался сам. Не правильно указал
acl localnet src 10.0.0.0/8)))
настроено как написано, но вот только ошибка при реконфиге
ext_ldap_group_acl: ERROR: Can not read secret file /etc/squid3/ldappass.conf
ext_ldap_group_acl: ERROR: Can not read secret file /etc/squid3/ldappass.conf
ext_ldap_group_acl: ERROR: Can not read secret file /etc/squid3/ldappass.conf
ext_ldap_group_acl: ERROR: Can not read secret file /etc/squid3/ldappass.conf
ext_ldap_group_acl: ERROR: Can not read secret file /etc/squid3/ldappass.conf
как следствие не авторизуется ((( пароль там указан верный от учетной записи.
вот что в логах по авторизации
ERROR: Negotiate Authentication validating user. Error returned 'BH NT_STATUS_UNSUCCESSFUL NT_STATUS_UNSUCCESSFUL'
в чем проблема? где не так ? едиснтвенно конечно что было не так при настройке так это формирование файла keytab не совпали первые 3 строчки из PowerShell
Могу предположить, что squid не имеет доступа к файлу ldappass.conf
права для этого файла выставил так как было описано...
или как то по другому что-то нужно сделать?
Доброе время суток.
Подскажите пожалуйста. не работает авторизация
Negotiate Kerberos and NTLM authentication и Only NTLM authentication
пишет
ERROR: Negotiate Authentication validating user. Error returned 'BH NT_STATUS_UNSUCCESSFUL NT_STATUS_UNSUCCESSFUL'
# Basic authentication работает только
Добрый день!
Настраивал всё по статье, однако не получается получить доступ в интернет
Ошибка из cache.log
ext_ldap_group_acl: WARNING: LDAP search error 'Invalid DN syntax'
Группы доступа созданы в OU: GB\User-Groups\InternetAccess
squid3.conf
# LDAP authorization
external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_ldap_group_acl -v 3 -P -R -K -b "dc=gb.dc=ksgbank,dc=com,dc=ua" -D squidkrb@gb.ksgbank.com.ua -W /etc/squid3/conf_param_ldappass.txt -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,OU=Security Groups,OU=GB,OU=User-Groups,OU=InternetAccess,DC=gb,DC=ksgbank,DC=com,DC=ua))" -h pdc.gb.ksgbank.com.ua
Подскажите в чём ошибка?
Может строку надо в обратном порядке указывать?
OU=GB,OU=User-Groups,OU=InternetAccess
Пишите вопросы по своей настройке сюда http://forum.it-kb.ru/viewforum.php?f=52
Добрый день.
объясните пожалуйста, что это за группа proxy.
>>sudo chgrp proxy /etc/squid3/conf_param_ldappass.txt
Почитайте в дефолтном squid.conf описание параметров cache_effective_group и cache_effective_user
Первое. Благодарность автору. Второе и последнее. Как сбросить авторизацию? Как выйти и зайти под другим пользователем. Я не побывал лиш перезагрузить комп. Перезагрузка squid не помогает! Значит хранится где то локально. кеш браузера (chrom) чистил но все бестолку. в лога видно что авторизация работает. Как ее теперь прибить? Вот так блин, первый раз такое - настроишь, а как сломать хрен его знает. Может все по тому что уже вечер и я устал. Посему прошу помощи на столь тупой вопрос.
Дополняю значение ключа -R, сам наи...ся по самое нехочу. это рекурсия, т.е. когда без него и пользователь и группа должны находится в одном OU.
Огромный спасибо автору!
Каждые несколько секунд в cache.log стала (после более месяца работы) появляться строка "ERROR: Negotiate Authentication validating user. Error returned 'BH gss_accept_sec_context() failed: An unsupported mechanism was requested." На многих (не всех!) доменных машинах часто запрашивается логин/пароль. Если окошко просто закрыть - интернет есть. Начинается утром, заканчивается вечером. Достаточно случайным образом. Где причина, где следствие, никак не пойму. Встречал совет забить на ошибку, но - логи пухнут, клиенты греются...
Забыл добавить. Как могут меняться настройки Squid для малых/средних/больших сетей? У меня, например, может быть до 600 одновременно работающих клиентов.
подскажите, данный конфиг подойдет для авторизации пользователей с другого домена, котоырй находится в доверитильных отношениях?
добавил пользователей другого домена в группу KOM-Internet-Full-Auth
1432017033.382 0 192.168.100.103 TCP_DENIED/403 4061 GET http://www.intms.ru/css/tmsengine.css DOMAINUSER HIER_NONE/- text/html
1432017033.382 0 192.168.100.103 TCP_DENIED/403 4034 GET http://www.intms.ru/js/tmsengine.js DOMAINUSER HIER_NONE/- text/html
1432017033.441 0 192.168.100.103 TCP_DENIED/403 4038 GET http://www.google-analytics.com/ga.js DOMAINUSER HIER_NONE/- text/html
1432017033.514 0 192.168.100.103 TCP_DENIED/403 4232 GET http://counter.yadro.ru/hit? DOMAINUSER HIER_NONE/- text/html
1432017037.247 0 192.168.100.103 TCP_DENIED/403 3996 GET http://yamdex.net/? DOMAINUSER HIER_NONE/- text/html
1432017038.152 0 192.168.100.103 TCP_DENIED/403 4037 GET http://ya.ru/ DOMAINUSER HIER_NONE/- text/html
1432017038.208 6 192.168.100.103 TCP_DENIED/403 4526 CONNECT upload.wikimedia.org:443 DOMAINUSER HIER_NONE/- text/html
1432017038.271 0 192.168.100.103 TCP_DENIED/403 4023 GET http://ya.ru/favicon.ico DOMAINUSERHIER_NONE/- text/html
еще вопрос
в созданные нами группы можно добавлять группы? или только пользователей?
Насчет доверительных отношений сказать не могу. Это скорее вопрос NTLM/Kerberos, чем Squid. Думаю что, как минимум нужно будет расширять информацией о доверенном домене конфиги krb5.conf и smb.conf. Относительно вложенности групп в статье написано.
а можно сатью про httpaccess и httpass, всем бы было интересно
Про htaccess есть хороший материал здесь: https://beget.ru/articles/htaccess. А что подразумевается под httpass мне представить сложно, но по крайней мере ничего приличного в голову не приходит.
а случаем по emix такой же ман для убунту?
EXIM*
Коллеги, вопрос по поводу conf_param_sites_blocked.txt, да безусловно вещь нужная в принципе при наличии такого текстового файла можно создать свой блок лист не малых размеров путем подставления из существующих скидгардовсих блек листов. Но вот хотелось бы чтоб в случае блока у пользователя происходила пересылка на какой-нибудь сайт или страницу с информацией о блокировке, а не белая картинка что сайт недоступен, как сделать так чтоб редиректилось на сайт в случае блока без использования программ редиректа, такое вообще возможно? Быстрым гуглом не нашол.
Для этого уже нужно использовать редиректоры, например rejik
Да реджик стоит, быстрый клевый и все нравится, но думаю пробывать сквидгвард, в реджике не нравится только одно, плохая работа с HTTPS, а именно при попытке зайти например на facebook.com браузер формирует запрос по протоколу HTTPS, а редирект идет на HTTP в связи с этим картинка не рисуется, браузер просто игонрит это событие, на форумах реджика стоит упоминание что в урл надо ставить код ошибки для редиректа например 302:http://kuda.idem.net/block.html но походу это работает для старых версий сквида. Поскольку сквид 3.4 и выше формирует несколько другой вид лога, что критично для реджика. Просто надеяфлся что катко можно по группе из выше указанного решения сделать какойто редиректор встроенными средствами сквида. :).
В общем редирект на HTTPS не возможен ввиду секюрности протокола. Из редиректоров остановился на squidGuard он качественно работает с LDAP и можно создать группы с пользователями и описать правила доступа не внося изменения в конфиг сквида на правила аутентификации. Иными словами, сквид авторизовал дальше правила сквидгарда определяют наличие этого пользователя в группе и с его allow deny листами.
Коллеги есть еще вопрос, в данной статье рассмотрен вариант блокировки ftp поверх сквида. Можно ли как-то в самом сквиде разрешить доступ к фтп только выбранной группе например той которая KOM-Internet-Full-Auth а все остальные в блок? Причем средствами SQUID а не редиректорв.
можно ли в blocked_sites добавить ip ?
по логике вещей нет. для этого используется команда dst. Но если ты вставишь туда ip и протестишь - ничего страшного не произойдет. Во всяком случае машина точно останется стоять на месте.
т.е можно по идее сделать разделить ?:
acl blockedip dst "blocked_ip.txt"
acl blockedsite dstdomain "blocked_sites.txt"
...
http_access deny blocked_ip
http_access deny blocked_sites
Вместо ext_ldap_group_acl, который гоняет по сети учетные данные открытым текстом, лучше использовать ext_kerberos_ldap_group_acl, который к тому-же проще в применении. Ну и необходимость использовать на прокси NTLM и, тем более, Basic-аутентификацию вызывает глубокие сомнения.
Отличная статья, автору большое спасибо! У меня такая проблема, пользователи из группы Internet-Standard получает полный доступ в инет, за исключением списка сайтов которые перечислены в файле conf_param_sites_blocked.txt. А должны получать доступ только к списку сайтов из файла conf_param_sites_allowed.txt. Ни как не могу понять, с чем это связано? И в cache.log периодически вываливается такое сообщения: ext_ldap_group_acl: WARNING: LDAP search error 'Can't contact LDAP server'
подскажите куда капать?
А можно ли сделать дополнительно вариант авторизации по MAC или IP? По схеме если адрес клиента присутствует в списке у него логин пароль не запрашивается, если отсутствует, то авторизация идет через керберос и тд.
По IP можно точно. Создайте acl со ссылкой на внешний файл где будут перечислены разрешённые без авторизации IP, а затем вставьте разрешающее правило до строки
http_access deny !auth
Подскажите, не знаю, после чего, в логах стала появляться запись вида "...sAMAccountName=DOMAIN\5cUser...", в результате чего авторизация ни у кого не проходит.
5с - очень смахивает на экранирование или что-то вроде того, почему это появилось ?
У меня выдает такую ошибку:
2015/10/09 11:59:46| FATAL ERROR: auth_param negotiate program /usr/lib/squid3/negotiate_wrapper_auth: (2) No such file or directory
Понятно, что не хватает файла. Вопрос почему его нет и где взять?
Обратная ссылка: Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 9. Конфигурация LightSquid | Блог IT-KB /
Обратная ссылка: Ограничение скорости Интернет для разных категорий пользователей на прокси-сервере Squid (Delay pools) | Блог IT-KB /
Добрый день! Появилась необходимость вернуться к Линукс, ваши статьи помогли в настройке Squid, работает проверка по пользователю в AD, работает управление через группы, но не могу заставить работать в режиме basic через Kerberos. Хелпер basic_ldap_auth работает в консоли, а вот браузеры и другой софт не может пройти проверку, постоянно выскакивает окно запроса логина и пароля, в логах 407.
squid.conf: http://pastebin.com/5XVAatrg
Буду признателен за помощь.
"basic через Kerberos" это как? Это два разных вида аутентификации.
а разве удостоверение пользователя в ldap не требует keypass? если нет, то я значит не так понял работу basic. в любом случае это не важно, важнее результат.
Вы писали про хелпер basic_ldap_auth, а он к Kerberos отношения не имеет. basic и есть basic. учётные данные передаются в открытом виде.
Добрый день! Столкнулся с аналогичной проблемой. Постоянно вылезает окно авторизации в браузере. Ввод любых учетных данных не помогает. В access.log пишет TCP_DENIED/407.
Все аутентификации проходят, (через kinit -k и через wbinfo -a) отношения с доменом доверительные. прокся по доменному имени пинается с других машин... пошла 3 неделя, а прогресса нет. В кэш логе было только запись про не стартующий basic_ldap_auth, но в коментариях выше вы говорите, что проблема не в этом... уже руки опускаются. Если нужны записи из access или cache логов, скажите
тоже все же хочу получить ответ по проблеме.
Уважаемые, я в комментариях неоднократно писал, что для того, чтобы разобраться с проблемой, нужно со всех сторон изучать конкретно взятый случай. Для этого нужны расширенные логи, разные проверочные запуски бинарников в режиме дебага и т.п. Ветка комментов - это не место для разбора подобных полётов. Пользуйтесь форумом, предварительно просмотрев там старые ветки (часто проблемы однотипны).
однотипные проблемы имеют решения на множестве ресурсов. пока решение не найдено ни на одном, а "разные проверочные запуски бинарников в режиме дебага и т.п." скорее танцы с бубном а не решение. На простые вопросы - простые ответы, либо работает из коробки, либо не работает потому что.... а дебаги и бинарники это уже извращение.
Добрый день, Алексей.
Очень хорошая и познавательная статья.
Имеется вопрос: как дополнить конфиг сквида так чтобы авторизация шла по доменной учетке как у вас, а те кто не в домене - автоматически попадали в одну из групп доступа, например KOM-Internet-Blocked - для гостей с личными устройствами и для смартфонов?
Те, кто не в домене, по определению не могут попасть в доменную группу доступа. Если хотите разобрать конкретную ситуацию создайте отельную тему в нашем форуме http://forum.it-kb.ru/viewforum.php?f=52
Алексей, я имел в виду не группу, а права как у этой группы. Можно сделать это с вашим конфигом?
Скажите если пользователь включен в группу "Restricted" и в файле "conf_param_sites_priority.txt" перечень сайтов которым нужно предоставлять доступ без исключения, пример сайты Microsoft и какой-нибудь сайт компании. Он должен будет пользователям из группы "Restricted", открывать сайты из файла "conf_param_sites_priority.txt"? У меня не открывает... Я что-то не так сделал или непонял?
conf_param_sites_allowed.txt . В заметке про это написано.
Понял. Извиняюсь!Тогда другой вопрос как в файл "conf_param_sites_allowed.txt" записать сайт который состоит из ip адреса.
К примеру:
.192.168.1.22/account "и.т.д".
Из группы restricted не открывает, а из группы standard работает.
Может синтаксис не такой?
Алексей, выражаю Вам великую благодарность за большую работу. По существу руководства возникло два вопроса: 1) с чем связана необходимость использования группы Blocked, если пользователи, которые не состоят ни в одной группе доступа и так не попадут в интернет? 2) если у хелпера стоит ttl, скажем в 1 минуту, насколько от этого возрастает нагрузка на КД и насколько адекватным будет такое значение, если требуется оперативность в управлении доступом?
1. Чтобы дать доступ только к определенным сайтам, а к остальным закрыть.
Пользователи акцесс-листа BlockedAccess смогут попасть на сайты перечисленные в prioritysites но никуда более.
Дополнительной функцией такой категории является то, что даже если какого-либо пользователя после отключения от Интернет (например внесение в группу KOM-Internet-Blocked по заявке службы безопасности) снова (например по ошибке администратора) включили в какую-то из групп предоставляющих доступ, то доступ всё равно работать не будет, так как правило доступа с акцесс-листом BlockedAccess обрабатывается раньше остальных, то есть имеет приоритет. То есть, фактически, данная группа доступа несёт дополнительную контрольную функцию и позволяет явно отделить пользователей, которые когда-либо полностью отключались от Интернет по инициативе руководства или СБ.
А по поводу значений TTL дать какой-то универсальный рецепт сложно. Такие значения нужно подбирать на практике под себя. Но указывать 60 секунд это уже всё-таки наверно через чур. Неужели вы с такой интенсивностью меняете членство групп доступа в домене.
Спасибо, стало ясно. И еще вопрос, почему решили не использовать хелпер ext_kerberos_ldap_group_acl, который, насколько мне известно тоже поддерживает вложенные группы и данные передает в зашифрованном виде.
А никто и не утверждал, что описанной мной здесь решение закрывает все вопросы и является единственно верным. Хотите использовать какие-то другие хелперы, - пожалуйста используйте.
Подскажите пожалуйста, как мне настроить доступ так, чтобы для некоторых пользователей, которые состоят в группе «KOM-Internet-Standard» (в которой запрещены социальные сети и другие сайты), можно было разрешить доступ к сайту vk.com и ok.ru добавив пользователя например в группу «KOM-Internet-Social», но чтобы доступ оставался закрытым на те сайты, которые перечислены в группе «KOM-Internet-Standard» ?
Логика простая. Создать отдельный акцесс-лист и разрешить его до того, где идёт описание того, что явно запрещено акцесс-листу StandardAccess (http_access deny blockedsites). Фактически тут нужно делать упор на правильный порядок конструкций http_access.
А можете пожалуйста привести пример?
Попробуйте так:
Спасибо огромное что подсказали, я настройку делал по аналогичной статье:
http://ploha.ru/stati/mnogofunkcionalnyi-ofisnyi-server-na-linux-1/ustanovka-i-nastroika-proksi-servera-squid-3-s-domennoi-autentifikaciei-razgranicheniem-dostupa-k-resursam-po-gruppam-filtraciei-i-pr
Сделал по аналогии, но не работает, как нужно. Запутался, прошу помощи профессионалов. Спасибо.
Настроил по Вашей статье все отлично работает, но тут недавно обновился Chrome до 47 версии и.....тут началось он ну никак не хочет авторизоваться по kerberos, но это пол беды по ntlm работают только https, никто не сталкивался? в логах даже если ALL включить всего одна строчка по поводу авторизации : ERROR: Negotiate Authentication validating user. Error returned 'BH gss_accept_sec_context() failed: An unsupported mechanism was requested.
Это известный баг 47 версии. http://forum.it-kb.ru/viewtopic.php?f=52&t=176
Приветствую, благодарствую за труды. Пара вопросов, если можно:
1. external_acl_type memberof с параметром ttl=3600 подвешивал инет минут на 20 примерно каждый час, убрал ttl и всё ок. С чем может быть связано?
2. Если ходить через IE 11, то на некоторых сайтах (например mail.ru) выскакивает "revocation information for the security certificate for this site is not available".
Что самое интересное: на этом же компе отключил проксю, зашёл на мыло.ру - предупреждения, нет. тут же включил проксю обратно, зашёл на мыло.ру и вуаля - предупреждение исчезло. Магия какая-то...
Сталкивались с таким поведением? если да, то побеждается ли это средствами сквида или можно просто в IE отключить проверку и не париться?
1.http://www.squid-cache.org/Doc/config/external_acl_type/ ttl - время жизни кэша хелпера. 3600 секунд, т.е. 1 час -значение по умолчанию, то есть, насколько я понимаю, указывать ttl=3600 или убирать этот параметр вообще - действия равнозначные. Так что проблему ищите в чём-то другом.
2. Это проблема IE, так как именно он инициирует (в соответствии со своими настройками) проверку отзыва сертификатов. Регулируйте эту ситуацию настройками IE.
Добрый день! Спасибо за подробное руководство, всё удалось завести, но осталось пара вопросов.
В cache.log периодически сыпется сообщение
2016/01/29 09:54:32 kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: gss_accept_sec_context() failed: An unsupported mechanism was requested. Unknown error; }}
При этом тестируем группой около 10 человек. Керберос 2-3 из них, остальные в браузерах (разные браузеры). Не могу отловить от кого и почему вызывается такая ошибка, забивающая порой лог и делает его нечитаемым для отлова других ошибок :(
Не подскажите как можно задебажить ошибку и/или отключить её? По факту всё работает...
Второй вопрос с логированием в access.log - можно ли включить логирование самого факта подключения на HTTPS, а не постфактум видеть сообщения типа
1454043756.722 61042 10.10.10.12 TCP_MISS/200 343 CONNECT tiles.services.mozilla.com:443 testuser HIER_DIRECT/54.148.98.19 -
Спасибо!
Все сделал по инструкции, но не работает доступ по группам. Проверил работу хелпера ext_ldap_group_acl отдельно, всегда выдает ERR. Группы созданы и существуют, пользователи в них есть. Но я не нашел в аттрибута memberOf в AD LDAP, как такое может быть?
Пишите в форум Прокси-сервер Squid, если есть желание разобраться.
Подробно опишите каким образом Вы искали атрибут memberOf.
Спасибо, что откликнулись, но уже разобрался. У меня почему-то memberOf содержит cn=proxy,cn=Users,dc=test,dc=local вместо cn=proxy,ou=Users,dc=test,dc=local.
Кстати, memberOf это виртуальный атрибут получается?
Статья актуальна на текущий момент. Только что все настроил на ubuntu 16.04. Спасибо автору за труд. Возникло одно затруднение, ответ нашел в комментариях.
Доброго дня! Могли бы Вы подсказать где почитать про Squid for Windows и авторизацию Kerberos? Просто есть свободные лицензии и машины Windows и хотелось бы прямо на них запустить в AD прокси.
Не подскажу. Squid ставить на Windows я бы не стал даже если бы этих лицензий было вагон. И да, тут как раз и описан пример Squid с интеграцией в AD.
добрый день, еще раз скажу что статья актуальна и отлично написана, автору огромное спасибо (по каким там банерам пощелкать, чтобы отблагодарить?)
есть вопрос: у меня почему-то пускает в инет только пользователей группы FULL. у остальных запрашивает логин\пароль и все равно не пускает.
до этого была проблема
2018/01/10 10:23:40 kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. Key table file '/etc/squid3/PROXY.keytab' not found; }}
решил путем создания линка на папку со сквидом /etc/squid/
теперь вот такое сообщения в логах
2018/01/10 10:24:51 kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. Cannot find key for HTTP/r19proxy.main.russianpost.ru@MAIN.RUSSIANPOST.RU kvno 4 in keytab; }}
это в access.log такое.
подскажите куда копнуть,
Здравствуйте, Александр. В Вашем комментарии содержится информация о причине ошибки - пользователь обращается к прокси по имени, которого нет в keytab-файле.
Алексей, проверил, действительно, по ip все нормально.
Подскажите в чем причина? DNS, keytab или еще что-то?
Здравствуйте! Помогите, пожалуйста: не хочет работать авторизация ext_ldap_group_acl
https://forum.it-kb.ru/viewtopic.php?f=52&t=70 - видела эту тему, у меня точь такая ситуация, как у этого человека, только CN с OU не путаю, но почему-то вот получаю вот такое при попытке удостовериться, что скуид точно распознает, в какой группе юзер
ext_ldap_group_acl: WARNING: could not bind to binddn 'Invalid credentials'
Здравствуйте, Татьяна. Создайте тему на форуме, более подробно описав свою конфигурацию.
https://forum.it-kb.ru/viewtopic.php?f=52&t=372
Тему создала)
И еще вопросик: sudo wbinfo -a KOM\\s-KOM-SquidKerb с паролем из /etc/squid3/conf_param_ldappass.txt должен нормально отработать? ну... т.е. этот юзер должен авторизоваться корректно? У меня он просто не может авторизоваться, типо, пароль неверный. Возможно, изза этого и ошибка could not bind to binddn 'Invalid credentials' и появляется?
Здравствуйте, подскажите в какую сторону смотреть:
1. Если на клиентах указываю ip адрес прокси - все отлично
2. Если указываю FQDN или короткое proxy2 то в cache.log так вот ошибка:
2020/01/22 19:45:03| ERROR: Negotiate Authentication validating user. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. No key table entry found for HTTP/proxy2.classic.ru@CLASSIC.ru'
Здравствуйте, Лев. У Вас не работает Kerberos аутентификация. Нет нужных записей в keytab-файле, либо squid не имеет доступа к keytab-файлу
появилась новая проблема....
после перезагрузки прокси-сервера минут 10 все работает как надо. Потом в cache log появляются повторяющиеся ошибки:
ERROR: Negotiate Authentication validating user. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. ''
Предполагаю что после "Minor code may provide more information" должна быть уточняющая информация , но ее нет.....
Добавлю - опытным путем установил что NTLM и Basic авторизации успешно работают.
Здравствуйте, подскажите пожалуйста, пытаюсь блокировать сайты согласно blacklist, все работает, но до переконфигурации squid. После реконф-ии правило блокировки http_access deny blacklist становится ниже правила htpp_access allow Sams2Template, и естественно все перестает работать. ACL блокировки разместил в самом начале, выше только acl sams2.nsca proxy_auth REQUIRED. Помогите студенту пожалуйста.
Добрый день!
Помогите пожалуйста уже который раз мучаюсь со SQUID. Все настроил, но авторизация через AD не проходит при проверке логов вижу одну и ту же ошибку
2022/05/05 10:08:34 kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. Permission denied; }}
Помогите разобраться в чем может быть проблема!
Здравствуйте, Ярослав.
Почитайте обсуждения в этом разделе https://forum.it-kb.ru/viewforum.php?f=52
Там обсуждалось то, как дебажить проблемы аутентификации.
Добрый день! возникла проблема при ограничении скорости, доступ в интернет идет, пользователей подхватывает из групп AD. Помогите пожалуйста в чем может быть поблема, в логах та же ошибка была. Текст ошибки прикладываю.
WARNING: fullaccess ACL is used in context without an ALE state. Assuming mismatch.
current master transaction: master5
Настаиваем основной конфигурационный файл squid.conf
Думаю, настоялся - можно пить )
Добрый день!
Заметил странность что пользователи не состоящие ни в одной из перечисленных групп в AD все равно имеют доступ в сеть интернет за исключением сайтов указанных в conf_param_sites_blocked.txt