Только бездушье губит нас, лечат любовь и ласка.
Ещё раз о "пользе" коммерческого проприетарного софта. На протяжении многих месяцев через службу техподдержки переписываюсь с представителями компании stalker.com - разработчика почтового сервера CommuniGatePro, но складывается впечатление, что бьюсь головой о глухую стену. Вот, например, небольшая выдержка из нашей высокосодержательной беседы:
ВОПРОС:
Скажите, а почему LDAP-сервер, встроенный в CommuniGate, хранит пароли в каком-то загадочном виде, который ни одному другому приложению просто непонятен? Ведь есть же общепринятый формат, в котором хранят пароли абсолютно все LDAP-серверы: <regexp>^({ID}b64HASH|[^{].+)$</regexp>, где ID указывает на используемый в данном поле метод шифрования, а b64HASH - шифрованный и конвертенный в BASE64 пароль. Я правильно понимаю, что в userPassword используется совершенно иной формат шифрованного пароля для того, чтобы одни и те же почтовые учётные записи в LDAP не могли полноценно использовать другие приложения, о причудах CommuniGate ничегошеньки не ведающие?
Очень жаль, но получается, что сейчас строить полноценные Directory Based Domain'ы, использующие существующие справочники (каталоги) предприятия, если и можно, то никак не на OpenLDAP (чего стоит только трабла с ldap_add: Naming violation (64)\nadditional info: naming attribute 'ТАКОЙ-ТО' is not present in entry) и с массой досадных НО, из которых в первую голову следует назвать неработоспособность списков рассылки, при том, что группы, как ни странно, работают, и сильно смущающая любого адекватного администратора необходимость хранения паролей открытым текстом (а в противном случае кроме CGP эти учётки для авторизации никто использовать не сможет).
Это когда-нибудь изменится или нормальная поддержка серверов каталогов может быь где угодно, в каком угодно софте, но только не в CommuniGate?
ОТВЕТ:
А зачем его читать? Если надо авторизоваться, то есть стандарный для
LDAP метод BIND. Его и надо использовать. А смотреть в этот атрибут - не
надо.
ВОПРОС:
Дмитрий, по-моему здесь всё очень просто: метод BIND для той абракадабры, которую CGP пишет в userPassword, может работать лишь в одном единственном случае: при использовании того примитивного и мало с чем совместимого LDAP-сервера, что встроен в CGP.
При создании же DBD на Remote Unit (а это как минимум логичнее создания его в каком-то загадочном сервере каталогов с недокументированными функциями и возможностями) никакой BIND работать не будет, потому что ни один из распространённых серверов LDAP не ведает о существовании A-Crypt и U-Crypt в том виде, в котором их представляет CommuniGate.
Я уж не говорю о том, что приложений, которые именно читают пароль из СК, а не пытаются биндиться, тоже немало (пример: Courier IMAP).
ОТВЕТ:
Используйте в CGPro возможности внешней аутентификации, если так
необхожимо все держать на внешнем LDAP сервере.
Привязывать значения атрибутов к процессу аутентификации - практика
порочная. Стандартами содержимое атрибута userPassword не оговаривается.
RFC2256 Section 5.36:
5.36. userPassword
( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
1.3.6.1.4.1.1466.115.121.1.40 - это octet string. Все.
Вы еще в Майкрософт на Active Directory пожалуйтесь. Это на счет
"абсолютно все", "общепринятый", "абракадабры" и проч.
No comments...
ВОПРОС:
Скажите, а почему LDAP-сервер, встроенный в CommuniGate, хранит пароли в каком-то загадочном виде, который ни одному другому приложению просто непонятен? Ведь есть же общепринятый формат, в котором хранят пароли абсолютно все LDAP-серверы: <regexp>^({ID}b64HASH|[^{].+)$</regexp>, где ID указывает на используемый в данном поле метод шифрования, а b64HASH - шифрованный и конвертенный в BASE64 пароль. Я правильно понимаю, что в userPassword используется совершенно иной формат шифрованного пароля для того, чтобы одни и те же почтовые учётные записи в LDAP не могли полноценно использовать другие приложения, о причудах CommuniGate ничегошеньки не ведающие?
Очень жаль, но получается, что сейчас строить полноценные Directory Based Domain'ы, использующие существующие справочники (каталоги) предприятия, если и можно, то никак не на OpenLDAP (чего стоит только трабла с ldap_add: Naming violation (64)\nadditional info: naming attribute 'ТАКОЙ-ТО' is not present in entry) и с массой досадных НО, из которых в первую голову следует назвать неработоспособность списков рассылки, при том, что группы, как ни странно, работают, и сильно смущающая любого адекватного администратора необходимость хранения паролей открытым текстом (а в противном случае кроме CGP эти учётки для авторизации никто использовать не сможет).
Это когда-нибудь изменится или нормальная поддержка серверов каталогов может быь где угодно, в каком угодно софте, но только не в CommuniGate?
ОТВЕТ:
А зачем его читать? Если надо авторизоваться, то есть стандарный для
LDAP метод BIND. Его и надо использовать. А смотреть в этот атрибут - не
надо.
ВОПРОС:
Дмитрий, по-моему здесь всё очень просто: метод BIND для той абракадабры, которую CGP пишет в userPassword, может работать лишь в одном единственном случае: при использовании того примитивного и мало с чем совместимого LDAP-сервера, что встроен в CGP.
При создании же DBD на Remote Unit (а это как минимум логичнее создания его в каком-то загадочном сервере каталогов с недокументированными функциями и возможностями) никакой BIND работать не будет, потому что ни один из распространённых серверов LDAP не ведает о существовании A-Crypt и U-Crypt в том виде, в котором их представляет CommuniGate.
Я уж не говорю о том, что приложений, которые именно читают пароль из СК, а не пытаются биндиться, тоже немало (пример: Courier IMAP).
ОТВЕТ:
Используйте в CGPro возможности внешней аутентификации, если так
необхожимо все держать на внешнем LDAP сервере.
Привязывать значения атрибутов к процессу аутентификации - практика
порочная. Стандартами содержимое атрибута userPassword не оговаривается.
RFC2256 Section 5.36:
5.36. userPassword
( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
1.3.6.1.4.1.1466.115.121.1.40 - это octet string. Все.
Вы еще в Майкрософт на Active Directory пожалуйтесь. Это на счет
"абсолютно все", "общепринятый", "абракадабры" и проч.
No comments...
-
-
24.10.2007 в 14:28-
-
24.10.2007 в 20:14Ведь ввёл же кто-то крылатое выражение "Клиент ВСЕГДА прав"!
-
-
24.10.2007 в 20:20Администрировать монстра всепожирающего Oracle, которого даже небольшие компании предпочитают использовать исключительно в качестве микроскопа для забивания гвоздей - пожалуйста. А представить структуру организации в виде иерархического дерева и развешать на этом дереве листочки, т.е. головы сотрудников, все считают архисложным и архиконтрпродуктивным занятием.
Вот хоть убейте, а не пойму никогда, почему легче разместить на запись Васи в таблице Сотрудники десять тысяч ссылок из смежных таблиц, нежели заполнить десять тысяч аттрибутов объекта "Вася" в каталоге?