(Vladimir A. Butenko) пишет:
> Реально в Directory ничего крутого нет - это то же самое хранилище
> файлов, как и файл сервер, только файлы маленькие и кривые (записи), а
> файловая система - убогая и тоже кривая (дерево записей, с ее
> RDN-ами), где именем файла является одно из данных файла. Плюс еще в
> некоторых реализациях (типа OpenLDAP) нельзя директории
> переименовавать, если они не пусты.
>
> Директори имела бы смысл, если бы а) был более-менее разумный стандарт
> на формат хранимых записей - это то, что они "схемой" назвали. Реально
> у всех схемы разные, всё надо молотком и напильником прикручивать.
> б) структура директорий (layout) была бы стандартизирована - а в этом
> ВООБЩЕ никакого стандарта нету.
>
> Поэтому задача интеграции двух приложений "использующих Directory"
> ничем не проще (а порой - сложнее), чем задача интеграции приложений,
> которые что-то пишут в какие-то файлы.
>
> Результат - есть более-менее стандартный способ хранения, скажем,
> паролей и Real Name в записях - вот если пара приложений использует
> пароли, то их можно "сынтегрировать". Но дальше - полная труха. То
> есть - интегрировать-то, конечно, можно - но никакого
> удовольствия-удобства от этого нету.
>
> Еще раз - директори - это ничего более, чем кривая примитивная
> файловая система. Директори-based Домены - это домены, файлы сеттингов
> которых может править каждый, кому не лень. Какой от этого эффект
> может получиться - сами понимаете. Плюсов там никаких нет.
>
> А вот если есть приложения, которым просто надо какие-то атрибуты
> аккаунтов считывать, и даже менять - то CGatePro вполне это
> предоставляет, причем убирая главный недостаток LDAP - "файловость".
> То есть если использовать CGatePro LDAP в режиме "LDAP Provisioning",
> то изменение какого-то атрибута через LDAP приводит не просто к
> модификации "файла" (записи) - с тем же успехом Вы могли бы просто
> изменить файл account.settings, а к тому, что изменное данное реально
> меняется (то есть как будто Вы этот атрибут поменяли через CLI).
>
> Это решает проблему интеграции "большого" приложения (типа CGatePro),
> которое оперирует с об"ектами, фиг знает где расположенными и как
> работающими, с "маленькими", которым просто надо периодически считать
> какие-то атрибуты какого-то об"екта, но не надо их кэшировать.
> Проблему интеграции двух "больших" приложений оно не решает - там уже
> надо не LDAP использовать а настоящие протоколы синхроницации (которых
> нету, и которые надо будет придумывать).
>
> Так что Directory-Based Domains - штука, РЕАЛЬНО мало чем хорошая, что
> бы ни пели всякие апологеты LDAP и Directory, они только создают
> проблемы (произвольного изменения данных "за спиной"), не давая
> никаких (известных мне) преимуществ.
Так полная интеграция мне и не нужна. Пусть CGP хранит все свои
настройки и настройки пользоваетелей в локальных файлах, а не в
директории. Просто на предприятии используется openldap для хранения
учетных записей и авторизации пользователей в других службах (почта,
веб-прокси, самба, ftp, базы данных и так далее). Здоровое желание -
использовать эти же записи для авторизации почты. То есть хотелось бы,
чтобы CGP брал только атрибуты cn и userPassword из OpenLDAP. И я задал
вопрос, можно ли это сделать без скриптов. Сейчас я использую просто
скрипт на perl (External Authentication) для поиска и авторизации
пользователей в OpenLDAP.
Кстати еще такой вопрос.
CGP работает на FreeBSD. Если использовать Server OS Integration и
включить Enable OS Password, то будет ли работать такая авторизация,
если пользователи на FreeBSD заведены из LDAP с помощью nsswitch (с
локальными пользователями это работает, с nsswitch не пробовал, потому
что для этого нужно проапгрейдиться до версии 5.1) ?
-- С уважением, Харун Д.Л., ЧИПСПолучено Sun Nov 02 09:08:36 2003
Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:12:48 MSK