proNovell

Собственно и не комментарий, а вопрос к знатокам. А что, серьёзные сложности использовать LDAP через SSL? А то у меня есть мысль повозиться в этом направлении. Неужто бесполезно?

Константин,

я полагаю, что вряд ли проблемы возникнут в этом месте. Скорее всего, что настроить можно - и без особых затруднений. Но, как я писал на этом форуме уже дважды, есть ещё одна проблема - а именно, передача пароля от рабочей станции (т.е. браузера) до прокси-сервера (т.е. Squid-а). При использовании схемы аутентификации Basic в каждом запросе к прокси-серверу передаётся в нешифрованном виде пара "логин/пароль", которую легко перехватить. Смысл при этом шифровать SSL-ем канал "Squid <-> NDS"?

А между SQUID и рабочей станцией какие еще могут быть типы авторизации?

Только не авторизации, а аутентификации.

Из известных мне - Digest и NTLM. У каждого свои достоинства и свои недостатки. Ещё возможные варианты - не полагаться на заголовки HTTP, а использовать сторонние механизмы. Я таковых знаю два: демон IDENTD (стандартная вещь в *NIX-ах, есть версии под Windows) и Novell-овский (точнее, Entrust-овский) клиент Single Sign-On (SSO) от Border Manager-а. Но с ними тоже свои проблемы, по крайней мере устраивающего меня законченного решения пока не получается.

С INETD почти всё хорошо: Squid штатно умеет к нему обращаться, легко настроить, но проблема в том, что на Виндовых машинах его элементарно можно подделать. Сам протокол INETD не предусматривает защиты, и для грамотного программиста написать аналог INETD, выдающий Сквиду вместо своего имени пользователя всё, что угодно - дело пары минут.

С SSO же проблема в том, что он умеет работать лишь в сочетании с каким-то NLM-ом на сервере, а как его состыковать с работающим на *NIX-е Squid-ом - неясно. Похоже, что надо писать для этого дополнительный NLM, грузить его на каком-то из серверов NetWare, да вдобавок патчить Squid, чтобы он аутентификацию делал через этот бутерброд.

А можно про IDENTD поподробнее?
Кстати http://forge.novell.com/modules/xfmod/p ... ?sso-squid - может чего и сделают

IDENTD - Ident Daemon, протокол Ident - "дубовейший" до безобразия, описан в RFC1413 в 1993 году. В двух словах: клиент (в данном случае им будет Сквид) спрашивает сервер (IdentD, запущенный на раб. станции и слушающий порт TCP 113) : "Это кто там на твоём компьютере открыл соединение с порта YYYY на мой порт XXXX?" А IdentD ему и отвечает: "Это сэр Vasya_Pupkin, эсквайр" Всё.

Версию IdentD под Windows NT/2000 я брал отсюда (почему-то в данный момент недоступно), хотя есть и другая версия (под Windows 9x) вот здесь.

За ссылочку про SSO-Squid - спасибо, посмотрю!

Посмотрел я на http://forge.novell.com/modules/xfmod/project/?sso-squid. Впечатление удручающее. Кроме сообщения о том, что "Registered: 2004-05-13 15:13" и пары предложений с грамматическими ошибками ("Aim is to realize a SingelSignOn ...") больше ничего нет. Т.е. вообще ничего.

Понятное дело - не актуально. Просто ждут, когда народ ломанется что-то писать для этого, а все ждут.

А ssh подымать для связи клиент - сквид сильно накладно?

Г-да. SQUID - это только ЧАСТЬ доступа, который может иметь Пользователь.
Все эти разговоры идут не только из-за разграничения доступа, а и для ПОЛУЧЕНИЯ ПОЛНОЙ СТАТИСТИКИ.
Поэтому стоит свои взоры обратить на:
1. Win станция ------------SERVER Интернет
Между ними подымаете VPN
На SERVER pptp+freeradius
2. Получате однозначную связку:
USER ---- IP
3. Строите Файервол (iptables), SQUID, NEWS исходя из того, что IP , четко определяет ИМЕННО ПОЛЬЗОВАТЕЛЯ (благодаря радиус).
4. При этом RADIUS Вам позволит иметь информацию:
- кто именно
- когда была сессия (начало..конец)
- сколько байт принял/передал

При этом от станции к серверу ВСЕ (и пароль и данные) будет идти в криптованом виде.


Минус этого решения:
0. Список USER/PAssword/IP хранится отдельным списком на Linux
1. Надо отдельно в каждом месте (iptables, squid, news..) прописывать правила для этого IP <=> Пользователя
2. Мне, пока, не удалось заставить Радиус лезть по LDAP за проверкой на Имя/пароль в другое место.

Плюсы:
0. Четко и однозначно по каждому известно сколько БАЙТ и когда...
2. Права пользователя на сервисы ИНЕТ Не привязаны к станции

Если все равно подымать VPN, то может через ssh? Там вроде можно заставить смотреть в LDAP.

Потому-что
1. КЛиент VPN уже входит в поставку W98...XP
2. в линуксе есть PPTP и он связывается с РАДИУСОМ.
РАДИУС ВЕДЕТ НУЖНЫT ЛОГ И ДАЕТ КОНКРЕТНОМУ ИМЕНИ IP.
3. Этот клиент VPN имеет опцию шифорвания пароля и данных.
Настроив соответсвующим бразом PPTP на сервере все будет и так шифроваться при передаче.

А вот сконцигурировать FREERADIUS , что-бы он лез к LDAP за аутентификацией.. у меня пока никак.. Говорят, что можно.
Если есть у Вас силы и время - попробуйте

Прошу прощения, но я у себя на 2000-ке не нашел клиента VPN. Куда смотреть то надо?

Багинский Константин писал(а):Прошу прощения, но я у себя на 2000-ке не нашел клиента VPN. Куда смотреть то надо?

Он еще в 98 был
Control Panel->Network Connections->New Connections Wizard

W200Proof
Start | Programs | Accessories | Communications | Network and Dial-up Connections

Далее в нем выбираете
NetWork Connection Wizard

В нем есть:
Connect to a privet network through the Internet
(Create a Virtual Privet Network (VPN) connection or `tunnel` through the Internet.)

http://sourceforge.net/projects/winidentd/

This is a small, simpleIdentd server for windows platforms. It runs on win 95,98,2000 and NT without changes. The current relese is geared for Novell networks in that it expects the novell client to be available and will return the user context when aske