Authpf - Help 0

HunterNomad
Нужно каждому юзВЕРю дать доступ через OpenBSD доступ в инет без лишнего выпендрежа, но по авторизации (собственно с этой целью и был выбран вариант +pf).

Мне почему-то видится, что выбран как раз-таки гемморойный способ.

Для случая FreeBSD задача достаточно тривиально решается посредством SQUID + OpenLDAP.

Не думаю, что на OpenBSD будет сложнее.

Для 10 пользователей (и случая ТОЛЬКО доступа в Internet) можно обойтись и без LDAP’а. Но если авторизацию (с централизованным хранением информации о пароле) делать для нескольких сервисов, то даже для 2-х пользователей имеет смысл LDAP.

HunterNomad
ПОМОГИТЕ!!! Киньте ссылку где бы доступно (для тупых) был описан шаг за шагом. И вконце все ОК (в смысле все проверено и будет работать).

Чем детальнее инструкция — тем больше трудоёмкость её написания.

Выше вероятность ошибки и неприличная скорость устаревания.

+ слишком часть — неудобочитаемость при наличии знаний (и собственного мнения не тождественного с мнением автора инструкции).

Посему рекомендую приобрести (он того стоит) и прочитать Эви Немет (сотоварищи) «Unix. Руководство системного администратора».

Для случая SQUID 2.6.19 и OpenLDAP задача решается следующим образом:

В /usr/local/etc/squid/squid.conf пишется

auth_param basic program /usr/local/libexec/squid/squid_ldap_auth -v 3 -b "ou=Users,dc=mydomain,dc=ru" -D "uid=squid,ou=Services,dc=mydomain,dc=ru" -W /usr/local/etc/squid/passwd 127.0.0.1
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
...
acl ldap_users proxy_auth REQUIRED
...
http_access allow ldap_users

SQUID (как и Apache) использует для авторизации соответствующее поле в заголовке пакета. Согласно стандарту допускается указание только одного заголовка, содержащего авторизационные данные. Следовательно через SQUID с авторизацией доступ к ресурсам использующим HTTP-авторизацию типа Basic невозможен. При этом данные для авторизации передаются в незашифрованном виде!

Доступ к FTP-ресурсам с авторизацией возможен только на чтение (SQUID всё равно не обеспечивает возможности полноценной работы с FTP) возможен через браузер при указании логина/пароля в адресной строке.

Для случая списка пользователей в файле — почти аналогично: Read the Fuck.

Anarchist
SQUID (как и Apache) использует для авторизации соответствующее поле в заголовке пакета. Согласно стандарту допускается указание только одного заголовка, содержащего авторизационные данные. Следовательно через SQUID с авторизацией доступ к ресурсам использующим HTTP-авторизацию типа Basic невозможен.

Это — полный бред. О том, что помимо Authorization: существует еще Proxy-Authorization:, Вы просто не знаете.

sendmoreinfo
Это — полный бред. О том, что помимо Authorization: существует еще Proxy-Authorization:, Вы просто не знаете.

Традиционный бред бздишника.

Я бы просил ограничить его рамками ресурса opennet.ru. Здесь нам такой радости не нужно.

Искать цитату в FAQ на http://wiki.squid-cache.org мне лень (там говорится не только про заголовок типа Proxy-Authentication request).

Поэтому просто задам вопрос: Вы когда-нибудь пробовали обратиться через squid с авторизацией (схема Basic) к Апачевскому виртуальному хосту, тоже требующему авторизации (тоже по схеме Basic)?

Попробуйте. Узнаете много интересного. :)

Ничего интересного, все работает, как задумано — в request header клиент посылает Authorization и Proxy-Authorization, и получает желаемый документ с хоста.

Учите матчасть!

sendmoreinfo
Ничего интересного, все работает, как задумано — в request header клиент посылает Authorization и Proxy-Authorization, и получает желаемый документ с хоста.

Знания теории удовлетворительные.

Вот только далеко не всегда теория совпадает с практикой.

По косвенным признакам — утверждение носит чисто теоретический характер.

sendmoreinfo
Учите матчасть!

Подобными заявлениями opennet.ru полнится.

Поэтому предлагаю вместо громких фраз привести конфиг сквида, информацию об используемом браузере, версию Apache и цитату из конфига описывающую авторизацию.

Где же пример из практики, опровергающий теорию?

sendmoreinfo
Где же пример из практики, опровергающий теорию?

Так… Сквид с авторизацией знаем только в теории. Ясненько.

Базовая часть squid.conf — практически дистрибутивная.

В части авторизации:

auth_param basic program /usr/local/libexec/squid/squid_ldap_auth -v 3 -b "ou=Users,dc=mydomain,dc=ru" -D "uid=squid,ou=Services,dc=mydomain,dc=ru" -W /usr/local/etc/squid/passwd 127.0.0.1
...
acl ldap_users proxy_auth REQUIRED
...
http_access allow ldap_users
http_access deny all

В httpd.conf доступ к каталогу виртуального хоста описан следующим образом

           AuthName "Password Required"
           AuthType Basic
           AuthBasicProvider ldap
           AuthLDAPURL "ldap://auth.mydomain.ru:389/ou=Users,dc=mydomain,dc=ru"
           AuthzLDAPAuthoritative off
           AuthLDAPBindDN uid=apache,ou=Services,dc=mydomain,dc=ru
           AuthLDAPBindPassword some_password
           Require ldap-attribute uid=user1 uid=user2 uid=user3 uid=user4
           Options Indexes FollowSymLinks
           AllowOverride None
    
           Order deny,allow
           Deny from all
           Allow from .mydomain.ru
    </Directory>

Мимо прокси — работает замечательно.

Через SQUID — 403 Forbidden

Воспроизвести проблему с такими исходными данными невозможно, это раз. Покажите request headers, которые получает сервер от клиента с и без прокси, это два.

sendmoreinfo
Воспроизвести проблему с такими исходными данными невозможно, это раз.

Покажите request headers, которые получает сервер от клиента с и без прокси, это два.

:)))

Не указал очевидного: используется основная по версии портов FreeBSD ветка SQUID’а (ну совершенно неочевидный момент).

Сквид никогда не настраивали, сквида с авторизацией (или web-серверов, требующих авторизацию в Apache) не видели. Суть проблемы знакома хорошо если условно. Понятно.

Вы невменяемы. Прощайте.

sendmoreinfo
Вы невменяемы. Прощайте.

Клиент поставит себе поразительно точный диагноз.

Ну и подтвердил отсутствие навыков/понимания конфигурирования SQUID.

Различные типы заголовков авторизации корректно отрабатываются если

#  TAG: always_direct
#               always_direct allow FTP
#  TAG: never_direct
#Required by authentification in Web
never_direct allow all

Если же

acl MYDOMAIN dstdomain .mydomain.ru
#  TAG: always_direct
#               always_direct allow FTP
always_direct allow MYDOMAIN
#  TAG: never_direct
#Required by authentification in Web
never_direct allow all

ресурс требующий авторизации прописать в тэге «always_direct», то SQUID отрабатывает как я описал выше.

ЗЫ: Столь «компетентным» (и самовлюблённым) бздунишкам должно сидеть на опеннете и не вякать.