squid + NDS (не вопрос, а просьба о помощи)

[iNot]

Господа, я прочитал статью http://www.osp.ru/lan/2003/03/022.htm и хотел сделать эту связку, НО, столкнулся с проблемой. Я настраиваю сквид, он работает без авторизации. После этого я делаю как написано в статье, сквид спрашивает авторизацию, я ее прохожу, и на этом все заканчивается. Т.е. интернета я так и не вижу. Если есть у кого-то возможность мне помочь, я был бы очень благодарен. можно по асе 6001882.

[Михаил Григорьев]

Господа, я прочитал статью http://www.osp.ru/lan/2003/03/022.htm и хотел сделать эту связку, НО, столкнулся с проблемой. Я настраиваю сквид, он работает без авторизации. После этого я делаю как написано в статье, сквид спрашивает авторизацию, я ее прохожу, и на этом все заканчивается. Т.е. интернета я так и не вижу. Если есть у кого-то возможность мне помочь, я был бы очень благодарен. можно по асе 6001882.

Читаем здесь

Самый верхний мой пост

[iNot]

В итоге все заработало, теперь вопрос такой, как сделать чтобы авторизация происходила во всем дереве а не только в одном контексте...

Т.е.

Tree=Digital-air
|- Context = CON1
|- Context = CON2

Вот если настроить только на один из контекстов , то все работает на ура, вопрос как настроить на все дерево????

Еще есть идея. Сразу скажу немоя.

====

Написать свою программку-"разветвитель",
которая, в свою очередь, обращается сначала к одному хелперу, а при
получении от него "ERR" - к другому (и сама возвращает "OK" либо "ERR" по
мере надобности) - для программиста дело нехитрое. В первом приближении
можно даже без Си обойтись простым скриптом на Shell/Perl/чем-то
аналогичном. Либо можно в исходниках squid_ldap_auth покопаться (там
всего-то один файл) - сделать так, чтобы он сам "ERR" возвращал только
после отлупа от обоих

=====

Может делал кто-то что-то поддобное заделитесь пож...

[iNot]

Вопрос такой, а если юзеры есть с одинаковыми логинами... Но в разных контекстах, как быть? Потому что по умолчанию берется тот юзер у которого контекст выше....

[Музалёв Николай]

Вариант РАЗ:
- развести пользоватьелей по именам. Что несколько неудобно и рушит понятие контейнер, но это самый простой путь.
Вариант ДВА:
- авторизоваться в сквиде не по CN, а по др. полю. Мы у себя исползуем поле Given Name , в которое при регистрации пользователя заносим строку [имя.контекст] . Поскольку наши издавна приучены помнить свой контекст (он по назв. отделов), то проблем с пользователями нет. Пришлось произвести минимальное перемапирование переменных NDS->LDAP . Если поле Given Name занято под др. хозяйственные нужды, то приписать новый строковый атрибут классу USER с помощью SCHEMAXa.
IMHO

[iNot]

Вариант РАЗ:
- развести пользоватьелей по именам. Что несколько неудобно и рушит понятие контейнер, но это самый простой путь.
Вариант ДВА:
- авторизоваться в сквиде не по CN, а по др. полю. Мы у себя исползуем поле Given Name , в которое при регистрации пользователя заносим строку [имя.контекст] . Поскольку наши издавна приучены помнить свой контекст (он по назв. отделов), то проблем с пользователями нет. Пришлось произвести минимальное перемапирование переменных NDS->LDAP . Если поле Given Name занято под др. хозяйственные нужды, то приписать новый строковый атрибут классу USER с помощью SCHEMAXa.
IMHO

Видимо первый пункт мой... Но я нашел более 50 совпадений... Сложно будет блин

[skoltogyan]

Те, кто используют и те, кто собирается использовать, прочитав Выше уазанные коллегами ссылки - спрашиваю у ВАС:
Знаете-ли Вы что
1. используется при этом пароль пользователя из NDS ?

2. От станции пользователя (из броузера) к Вашему Прокси (Squid) пароль и имя идут практически открытыми. ?


Если я не прав - поправте меня.

Если знаете как сделать так, что-бы от Станции Пользователя к Проксt пароль и имя передавались по ssl - может расскажите ?

[iNot]

Те, кто используют и те, кто собирается использовать, прочитав Выше уазанные коллегами ссылки - спрашиваю у ВАС:
Знаете-ли Вы что
1. используется при этом пароль пользователя из NDS ?

2. От станции пользователя (из броузера) к Вашему Прокси (Squid) пароль и имя идут практически открытыми. ?


Если я не прав - поправте меня.

Если знаете как сделать так, что-бы от Станции Пользователя к Проксt пароль и имя передавались по ssl - может расскажите ?

1. Да

2. Во втором посте в этой теме есть линк, там это обсуждается.

[skoltogyan]

Я спрашивал НЕ О ОБСУЖДЕНИИ, а о РЕШИЛ_ЛИ КТО РЕАЛЬНО, как настроить что-бы от станции к Броузеру шло при этом в закрытом виде

(я не спрашиваю про подняти pptp vpn от станции к серверу,получению IP для именно этого юзера и далее прокся делает для этого IP, что надо ).

[iNot]

Я спрашивал НЕ О ОБСУЖДЕНИИ, а о РЕШИЛ_ЛИ КТО РЕАЛЬНО, как настроить что-бы от станции к Броузеру шло при этом в закрытом виде

(я не спрашиваю про подняти pptp vpn от станции к серверу,получению IP для именно этого юзера и далее прокся делает для этого IP, что надо ).

А ты читал? Ты почитай... Вообще ldap_auth поддерживает TLS,
-Z TLS encrypt the LDAP connection, requires LDAP version 3

ПОчему бы не попробовать.. Я чесно говоря не пробовал. Пароль и так передается не в открыдом виде, а передается вроде только хэш. Мне этого вполне достаточно....

[skoltogyan]

Спрашивал о и говорил о том, Что ОТ СТАНЦИИ ПОЛЬЗОВАТЕЛЯ к ПРОКСИ СЕРВЕРУ имя и пароль идут в открытом виде..


НЕ ГОВОРИЛ НИ СЛОВА О ТОМ, КАК ОТ ПРОКСИ К LDAP серверу идет соединение. Там настраивается по secure .

[Михаил Григорьев]

Принцип такой (как мне видится)

От пользователя (Рабочая станция) имя и пароль (подчёркиваю что пароль, а не какой либо хэш) летят к серверу с squid в открытом виде.

Как это поправить в случае использования squid_ldap_auth:
1. VPN соединение с этим сервером.

Есть конечно вариант использования Digest или NTLM, но следует учитывать, что Digest поддерживает и IE и Мозила, а вот NTLM только IE. В чём тут заковыка, а в том что непонятно умеют ли (есть ли) Digest хелперы которые с LDAP работают.
Вобщем читаем тут про ето дело.

Далее...

Хелпер squid (squid_ldap_auth) идет на LDAP сервер
Как идет:
1. Либо нешифрованное соединение
2. Шифрованное соединение SSL/TLS c LDAP сервером
3. Шифрованное соединение (организуем тунель между LDAP клиентом и сервером)

В случае нешифрованного соединения есть двойная опасность, во-первых передается нешифрованный пароль пользователя, а во-вторых пароль пользователя с правами которого мы биндимся в LDAP серверу. Вы скажите что можно биндится с правами анонима, НО увы... аноним в NW по умолчанию не может смотреть у групп аттрибут securityequals

Самое хороше решение это соединение с LDAP сервером с использованием SSL/TLS. Про него кстате читаем в моей статье

Если SLDAP не нравится, то можно организовать тунель с помощью левой программы, типа stunnel, но по мне это не есть маразм. Зачем пудрить мозги м левым софтом если есть способы попроще.

[Михаил Григорьев]

ООО....
В 3-й версии сквида есть хелпер для ldap + digest, я только что качнул, по идее его можно прикрутить к 2.5 версии...

Ща прикрутим.... Надеюсь что прикручу.... )))

[skoltogyan]

В том и круть BM, что он предоставил решение, как от станции к ПРОКСЕ передавать имя и пароль в закрытом виде.

Использование ПРОСТО связки squid+edir - плохо.

Подымать VPN от станиции к sQUID - тогда уже надо делать не аутетификацию в squid по ldap к едир, а:

Подымать РАДИУС и предоставлять конкретному пользователю по предоставлению паролдя, его личный IP.. а squid же на базе IP будет давать доступ..
Только это уже СОВСЕМ други проблемы /вопросы.. и там уж СОВСЕМ НЕНУЖНО сращивать squid+ldap(edir)

[Михаил Григорьев]

Подымать РАДИУС и предоставлять конкретному пользователю по предоставлению паролдя, его личный IP.. а squid же на базе IP будет давать доступ..
Только это уже СОВСЕМ други проблемы /вопросы.. и там уж СОВСЕМ НЕНУЖНО сращивать squid+ldap(edir)

Легко...