Squid eDir

[Иван Левшин aka Ivan L.]

Качайте отсюда -> http://www.novell.chel.ru/Project/Squid_NW_Auth/Download/squid_clienttrust.tar.gz - 9.7 Mb

[Александр Читалкин]

Хотел бы поинтересоваться - для реализации необходимого функционала модифицировался сам сквид, или к нему дописывались модули, не затрагивая исходники сервера?

[Андрей Тр. aka RH]

Где-то в начале см. сообщение PavelK - там упоминается "пропатченный Сквид", плюс кратко описана схема работы всего этого.

А мы у себя поставили и пробуем PaperCut NG - хорошо себя зарекомендовавший продукт, сейчас его портируют на Линукс. Аутентификация по ЛДАП настраивается как обычно для Сквида ( или другого прокси ), PCNG синхронизирует свою базу пользователей по ЛДАП.

[Александр Читалкин]

Спасибо Так я, собственно, и подумал. Просто еще ранее было что-то сказано про auth_helpers, но принцип работы этого механизма несколько нестыкуется с описанным функционалом системы.

[Иван Левшин aka Ivan L.]

Где-то в начале см. сообщение PavelK - там упоминается "пропатченный Сквид", плюс кратко описана схема работы всего этого.

А мы у себя поставили и пробуем PaperCut NG - хорошо себя зарекомендовавший продукт, сейчас его портируют на Линукс. Аутентификация по ЛДАП настраивается как обычно для Сквида ( или другого прокси ), PCNG синхронизирует свою базу пользователей по ЛДАП.

Он действительно что-то патчил - что мне не нравится. По известным причинам. Предложенное решение - надо посмотреть. Сейчас вроде как занимается "выращиванием" своего демона в отдельное решение, которое позволяет сквид не трогать. За ссылку - как всегда, спасибо

[Андрей Тр. aka RH]

Иван, для PCNG на Линуксе есть Quick Start Guide http://papercut.biz/pcng/netcontrol/man ... linux.html , Мануал - http://papercut.biz/pcng/netcontrol/manual/index.html ( пропускаешь все, что связано с печатью - просто у них контроль печати и Интернета совмещен в одном модуле ).

Про настройку хелпера для Сквида, в частности, тут : http://papercut.biz/pcng/netcontrol/man ... -squid-acl

Скачай триал ( 40-дневный ) и посмотри, у меня на установку и настройку всего ( включая правку конфигов Сквида ) ушло где-то с полчаса.

[Александр Читалкин]

Как обстоит дело у pcng с SSO? Хелпер-хелпером, он может попросить аутентификацию хоть у чего - edir, openldap, mysql, неважно, и таких способов и приемов много. Но ведь схема аутентификации между клиентом и прокси все равно останется либо ntlm (тогда ссо будет работать только в IE) либо basic (окошко логона). Даже если мы напишем новую, собственную, схему - браузеры ее не поймут. Как это решается в pcng и решается ли вообще?

[Андрей Тр. aka RH]

Не совсем понял, что в данном случае означает SSO. При выходе в Инет аутентификация выполняется же Сквидом ( или другим прокси ), и PCNG в этом никак не участвует. Другое дело, что пользователь может также залогиниться в саму PCNG посмотреть свой баланс и пр. - если ему это не запретить. Тогда PCNG также будет выполнять аутентификацию по LDAP ( или каким-то другим способом - как настроишь ). Я пока внимательно не изучал дополнительные возможности PCNG в этом плане, хотя разработчики стараются сделать их продукт максимально гибким.

Some large networks, particularly those found at established universities, may have custom
user directory and authentication services not directly supported by PaperCut NG. To
support these networks, administrators can use scripting and other technologies to build a
new custom User Directory Information Provider.
PaperCut NG works by handing off user, group and user authentication tasks to a separate
program/process. The external process must accept a set of commands as command-line
arguments and return the answer in a tab delimited prescribed format on standard out.
More information on the format can be found in Section 14.5, “Custom User Directory Information
Providers”. The source code for the standard PaperCut NG supplied User Directory
Information Provider are also supplied as part of the installation, and these may prove
to be a good example. The source code is provided in:
~/server/bin/linux-i686/src/
~/server/bin/linux-i686/sambauserdir
~/server/bin/linux-i686/authsamba
Organizations wishing to build a custom User Directory Information Provider are encouraged
to contact the PaperCut NG development team. They will be more than happy to assist.

Как я понимаю, ваш вопрос про SSO относится ко взаимодействию браузера со Сквидом.

[Андрей Тр. aka RH]

Не, не может же все быть так просто ..

Seamless Authentication with the Squid Proxy

http://www.novell.com/coolsolutions/feature/17777.html

[Иван Левшин aka Ivan L.]

Не, не может же все быть так просто ..

Seamless Authentication with the Squid Proxy

http://www.novell.com/coolsolutions/feature/17777.html

Не все так просто

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

If a user has logged into eDirectory using the Novell client, the Network Address attribute of the user object in eDirectory [b]should be[/b] populated with the user's IP address

Вот это самое should be меня и настораживает. Как сейчас - не знаю, а раньше этот самый адрес там либо старый был, либо вообще не populated. Из-за чего и городили городушку с демоном SSO.

[Александр Читалкин]

По ссылке:
Second Method: In the event that the IP address attribute of the user is not populated (which happens very rarely and is always the result of a broken Novell client), the Squid proxy will fall back to standard username/password authentication.
Утверждают, что адрес этот быть там должен. А если его там нет, то аутентификация будет стандартной basic, что не так страшно.

О безопасности ClientTrust - помниться, в свое время приходилось поспорить с особо убежденными: http://archive.cert.uni-stuttgart.de/ar ... 00097.html
Как видим из описания, и исходников клиенттраста для линукса на сурсфорже, протокол действительно простейший. Ничего не стоит продвинутому пользователю с познаниями в программировании взять этот сурс, переделать и собрать в MSVS, заставив всегда отдавать реквизиты привилегированного пользователя независимо от того, кто реально сейчас подключен. Или, как предлагает автор, поставить редирект на его машину.

И вообще, по поводу безопасности подобных "ключиков". Разумно будет поставить задачу так, чтобы программа-ключик была самодостаточна, не содержала в своем теле никакой salt (соли), заранее зашитых паролей и алгоритмов (которые можно выдрать), сертификатов и ключей (которые можно украсть). Также, она должна быть пригодна для запуска на любой машине (например, из логин-скрипта). В этом случае, обеспечить безопасную аутентификацию будет весьма сложно. Потому что все, что передается в сети в открытом виде - можно прослушать. Прослушать, значит расковырять протокол. Расковырять протокол - значит написать вышеозначенную программу-подделку.
Разумеется, разумно было бы трафик предварительно пошифровать. Не для того, чтобы скрыть его содержимое (в программах типа clienttrust ценности оно само по себе не представляет), но превратить в такую нечитабельную форму, которую прочитать мог бы только сервер, а сгенерить только "правильный" клиент. Как бы "подписать" это сообщение. И на основе успеха или неудачи этой операции делать вывод об успешной аутентификации. Чтобы этого достичь, шифровать трафик все равно надо каким-то ключем (ксор в расчет не берем ), притом таким, который нигде на храниться, кроме как в голове пользователя и каталоге. Это может быть только пароль. Даже для всех самых "навороченных" алгоритмов типа кербероса в качестве "затравки" для хендшейка он все равно используется. Потому что при фиксированном алгоритме шифрования с общим для всех ключем все старания сходят на нет - достаточно лишь его узнать и написать такую же модернизированную программу-подделку.
В итоге, все упирается в то, что правильными, а не полу-хакерскими, путями получить пароль текущего пользователя windows никак не выйдет. А значит, и все эти клиент-трасты представляются вещью субъективно-надежной, могущей вызвать споры, но никак не безопасной.

[Андрей Тр. aka RH]

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

If a user has logged into eDirectory using the Novell client, the Network Address attribute of the user object in eDirectory [b]should be[/b] populated with the user's IP address

Вот это самое should be меня и настораживает. Как сейчас - не знаю, а раньше этот самый адрес там либо старый был, либо вообще не populated. Из-за чего и городили городушку с демоном SSO.

Иван, тогда ИМХО проще написать какой-то скрипт ( подозреваю, что очень простой ), который бы при логине пользователя заполнял нужный атрибут. Понятно, что в предложенном методе есть дырки, и что особо продвинутый пользователь, вероятно, сможет прикинуться кем-то еще (?) .. надо будет подумать на эту тему. Но и этот скриптик, с другой стороны, мог бы обновлять атрибут регулярно, пока пользователеь залогинен.

Или вообще брать адрес не из атрибута пользователя, а из коннекта данного пользователя на каком-то сервере .. из таблицы коннектов, такое ведь возможно. Кстати, именно по такому принципу у нас обсчитывает печать PCounter для пользователей с Маков - т.к. там нет возможности получить их новелловское имя от клиента - вот он и смотрит в таблице, кто в данный залогинен с того адреса, откуда пришло задание на печать.

Option 1. PCounter will lookup the users IP address in the connection table of the server and then charge the appropriate logged in user.

[Иван Левшин aka Ivan L.]

Андрей Тр. aka RH - если это действительно проще - отчего тогда новель городил к БМ клиенттраст? Подозреваю - чтобы однозначно и надежно идентифицировать пользователя Вот и мы своего клиента делали примерно так же. А подобные скрипты - во-первых, ИМХО, загрузят сервер без толку, во-вторых - действительно повышают риск спуфинга.

[Константин Ошмян]

Позвольте вставить и свои "пять копеек".

По ссылке:
Second Method: In the event that the IP address attribute of the user is not populated (which happens very rarely and is always the result of a broken Novell client), the Squid proxy will fall back to standard username/password authentication.
Утверждают, что адрес этот быть там должен. А если его там нет, то аутентификация будет стандартной basic, что не так страшно.

Вот именно это-то - как раз очень страшно. По крайней мере, для нас - неприемлемо категорически, поскольку при Basic-аутентификации пара имя/пароль пересылаются по сети (от браузера до прокси-сервера) безо всякого шифрования, да ещё и в каждом запросе. Если это те же самые имя/пароль, с которыми пользователь входит в сеть, то подслушивание данной информации кем-то с помощью сниффера - просто вопрос времени, о безопасности тут говорить просто невозможно.

О безопасности ClientTrust - помниться, в свое время приходилось поспорить с особо убежденными: http://archive.cert.uni-stuttgart.de/ar ... 00097.html
Как видим из описания, и исходников клиенттраста для линукса на сурсфорже, протокол действительно простейший. Ничего не стоит продвинутому пользователю с познаниями в программировании взять этот сурс, переделать и собрать в MSVS, заставив всегда отдавать реквизиты привилегированного пользователя независимо от того, кто реально сейчас подключен. Или, как предлагает автор, поставить редирект на его машину.

А вот с этими утверждениями хотелось бы поспорить уже мне.

Во-первых, пройдясь по данной ссылке, я не нашёл следов "спора с особо убеждёнными": там по данной теме одно-единственное сообщение, на которое никто так и не ответил.

Во-вторых, принцип действия ClientTrust-а там изложен неточно (заинтересованных могу отослать, например, к TID10023517). Да, он действительно работает по 3024-му порту UDP и отвечает на запросы Border-а, обращаясь для этого к новелловскому клиенту32; однако остальное - неверно. Бордер в запросе к ClientTrust-у передаёт имя своего сервера и дерева, а также контекст сервера; ClientTrust же проверяет (через Client32), есть ли у пользователя подключение к этому дереву вообще и серверу в частности. При необходимости/возможности (подключение к дереву - есть, к серверу - нет) - делается Unlicensed-подключение серверу. А вот назад КлиентТрастом пересылается отнюдь не "currently logged in user's fully-qualified userid" (как утверждает автор указанного сообщения), а всего лишь номер соединения к серверу (если оно есть либо его удалось установить). Всё остальное - уже забота Бордера: по номеру коннекшна к серверу, на котором он крутится, определить этот самый "user's fully-qualified userid"; а заодно - проверить, к той же ли станции он относится. Протокол действительно очень простой, но "хакать" клиента при этом - бесполезно, т.к. значительная часть работы по идентификации пользователя возлагается именно на сервер. Ну и недостатки протокола тоже понятны - необходимость в новелловском клиенте (для создания NCP-соединения к серверу) и неподдержка многопользовательских систем (типа упомянутых терминал-серверов).

В-третьих, Александр, а где находятся упомянутые "исходники клиенттраста для линукса на сурсфорже" (это уже не спор - просто интересуюсь) ?

[Александр Читалкин]

По-поводу basic. Прошу извинить, действительно так, и полностью согласен с Константином. Проще и надежнее просто давать deny на такие запросы, чем позволять аутентифицироваться по basic.

Насчет спора - речь не о посте выщеуказанного человека с секуритифокус.

По поводу ClientTrust и его "однозначной надежности", которой, подозреваю, там нет и никогда не было, как и у всех аналогов. Смотрим линуксовый сурс такого аналога этой программы для аутентификации на бордере. Извините заранее за объем поста.
В этой программе имеются несколько массивов, буферов для приема|передачи сообщений. Первое, ncpbuf[10]. Байт 1 в этом массиве установлен в 8, остальное инициализируется нулями. Вторая структура, msg, - буфер для приема. Программа ждет запроса от бордера, после чего тело запроса записывается в msg. После приема запроса происходит следующая операция:

ncpbuf[2]=msg[12];
ctuid[0]=ncpbuf[6]=msg[4];
ctuid[1]=ncpbuf[7]=msg[5];
ctuid[2]=ncpbuf[8]=msg[6];
ctuid[3]=ncpbuf[9]=msg[7];

Здесь видно, что то, что мы приняли в 4,5,6,7 байты буфера, переписывается в выходной буфер ncpbuf с некоторым смещением, и то же самое записывается в массив ctuid. 0,1,2,3 байты буфера записываются в массив cthead. Далее, то что оказалось в cthead, сравнивается с заранее заполненным массивом ctheadreq (это позволяет идентифицировать пакет как заголовок запроса), и если сравнение успешно, выполняется операция, которая копирует содержимое ctuid (а значит, и msg) в еще один выходной буфер, msgout. Далее выполняется команда ncp_open_mount. В зависимости от ее возвратного значения (NULL или !NULL, Connection Exists или Connection Doesn't Exist) остальные байты msgout заполняются либо кодом 34, либо 51. После всех этих операций мы имеем msgout, в байты 4,5,6,7 которого записано то, что мы приняли ранее от бордера в виде запроса(ctuid), и некий массив симолов в байтах 0-3, со значениями либо 34, либо 51 в зависимости от результата работы команды ncp_open_mount.
Далее, буфер msgout просто посылается бордеру в ответ без каких либо модификаций. Если буфер отправлен успешно и ранее вызванный ncp_open_mount возвратил NULL (Connection Exists), посылается еще один пакет командой NWRequestSimple, только уже в качестве данных для отправки служит ncpbuf, содержимое которого еще проще - все тот же ctuid + байт №12 из приемного буфера msg.
Что мы имеем? А имеем мы сервер, который отправляет (uid), но делает его через соединение как udp, так и ncp, которое устанавливается с уже существующим хэндлом текущего подключения к прокси-серверу. Возможно, таким образом и определяется связка ip<->user, сверяясь с таблицей handle<->user на сервере, если хэндл глобальный и храниться. А может и нет.
Ознакомиться с исходниками и самой программой-демоном можно здесь: http://sourceforge.net/projects/cl4others/

Все эти демоны и клиенты-ключи остаюся делом весьма рискованным, и использовать их, имхо, крайне неразумно. Тот вариант, что был опубликован на сайте novell в вышеуказанной ссылке, выглядит заметно интереснее. Перл, действительно, сервер сильно перегрузит из-за особенностей его работы, но если писать модуль аутентификации на си, проблем быть не должно, тем более что вызывается он только тогда, когда эта атунтификация нужна, а потом выгружается.

Андрею: таблица этих подключений netware-специфичная вещь? А если в сети нет серверов netware, а скажем, только OES - каким образом можно определить соответствие loggeduser<->ip?