> > Сначала нескромный вопрос - а что разработчиками(или суппортом) на
сообщения
> > об ошибках/недочетах уже не принято отвечать?? На свой вопрос о неполной
> > реализации LDAP в CGP(функция ldap_compare_s не поддерживается) мне так
> > никто не ответил. Ну что же, попробую пожаловаться теперь на другое:
>
> Просто пока ответить нечего. Вы приводите в качестве примера кусок
исходника
> apache. То есть нам надо сначала разобраться что "там имелось в виду"
> разработчиками apache.
Во-первых, большое спасибо за ответ. Было бы приятно и удобно, если бы разработчики/суппорт просто сообщили о том, что "сообщение об ошибке получено - будем смотреть". А получилось - "Ау!!! А в ответ тишина.". Во-вторых, был приведен фрагмент исходника модуля к апачу с функцией ldap_compare_s, и фрагмент лога CGP, где он выдает сообщение на вызов именно этой функции(я проверял несколько раз - ошибка на вызове этой функции). Там происходит сравнение полученого из LDAP DN с построенным DN на основании введенных пользователем данными и данными из конфига. Вроде не ошибся.
> По существу вопроса могу лишь сказать, что в реализации LDAP есть проблемы
и
> они будут постепенно решаться.
ОК. будем ждать.
> > А вот теперь ошибка(IMHO): если мы отключаем эккаунт( Allow to Use =
No), то
> > логин к LDAP по второму DN не проходит(что есть правильно), а вот по
первому
> > DN все отлично подключается(что ни есть правильно - ведь учетная запись
> > отключена) и авторизация к разным службам через коммунигейтовский LDAP
идет
> > лесом :(.
>
> Какое решение предлагаете Вы?
>
1. например в случае выставления опции "Allow to Use = No"(а какие еще есть
опции, определяющие право пользователя на использование своего эккаунта?)
устанавливать в Directory/Main.data пароль = "". А в момент установки опции
"Allow to Use=Yes" опять устанавливать его.
2. процедуру аутенификации в LDAP предварить внутренней функцией,
проверяющей состояние почтового эккаунта, и если он запрещен, то и в логине
к LDAP тоже отказывать. Тогда не нужно мудрить со
сбросом/восстановлением/реплицированием паролей в LDAP. Минус - если у
эккаунта установлена внешняя аутенификация, то это удлинит время логина к
LDAP. Но IMHO плюсов больше чем минусов, а то какой смысл в "Allow to Use"
если при этом пользователь получает доступ к своему эккаунту через LDAP.
> Для успешной аутентикации по LDAPнеобходимо наличие соответствующей записи
и
> атрибута userpassword в ней. Вы запрещаете почтовому серверу использовать
> внутренние для этого сервера пароли - какое отношение это имеет к
директории
> LDAP, где этот сервер хранит _реплику_ _некоторых_ атрибутов аккаунта?
Даже в
> случае directory-based доменов, разрешение или запрещение в _CGPro_
> использования любого из трех (хоть всех) способов аутентикации приведет
> только к изменению соответствующих атрибутах записи. Сама запись и атрибут
> userPassword останутся. Аутентикация к серверу LDAP будет возможна.
Плохо :(
С уважением, Сергей.
##################################################################Вы получили это сообщение потому, что подписаны на список рассылки <CGatePro@mx.ru>.
Чтобы отписаться, отправьте сообщение на адрес <CGatePro-off@mx.ru> Чтобы переключиться в режим дайджеста - mailto:<CGatePro-digest@mx.ru> Чтобы переключиться в индексный режим - mailto:<CGatePro-index@mx.ru>Для административных запросов адрес <CGatePro-request@mx.ru> Получено Tue Sep 18 07:19:34 2001
Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:12:22 MSK