Комментарии 44
может в BSDельники?
Смешно пишите, «несколько затрудняет общение».
У 99% клиентов стоит аська в воплощении QIP, у 99% партнёров точно такая же ситуация по их клиентам.
У 99% клиентов стоит аська в воплощении QIP, у 99% партнёров точно такая же ситуация по их клиентам.
Ну, во-первых, это действительно было написано с иронией. Во-вторых, речь идёт не о клиентах или партнёрах, а именно о том, о ком там написано — о сотрудниках. С остальными, по роду работы, я общаюсь редко и мало.
Далеко не всем нужно общаться с клиентами. Конечно в отделе маркетинга от ICQ отказаться не получится, но, скажем, разработчикам она и даром не нужна: общаться нужно в основном с сотрудниками фирмы, либо с партнёрами, на которых (в отличие от клиентов) влиять можно и нужно.
А кто мешает включить ICQ транспорт на сервере?
Автору спасибо!
Мы долго выбирали, какую «болтушку» поставить на работе.
Выбрали джабер по многим причинам.
Самое главное, что есть открытый сервер.
Ну и с клиентами проблем нет.
Но вот до настройки ldap не доходили руки.
А это ведь на самом деле очень сильно облегчит, а вернее сведет к 0 затраты на заведение пользователей.
После выходных попробуем ваши инструкции.
Спасибо.
Мы долго выбирали, какую «болтушку» поставить на работе.
Выбрали джабер по многим причинам.
Самое главное, что есть открытый сервер.
Ну и с клиентами проблем нет.
Но вот до настройки ldap не доходили руки.
А это ведь на самом деле очень сильно облегчит, а вернее сведет к 0 затраты на заведение пользователей.
После выходных попробуем ваши инструкции.
Спасибо.
вот в таких статьях неплохо было бы объяснять попутно, что такое LDAP, я в Википедию полез, а там «облегчённый протокол доступа к каталогам» — не понятно.
и ещё замечание, это прямо так критично, что FreeBSD, а не Linux? мне кажется по Linux это тоже прокатит.
и ещё замечание, это прямо так критично, что FreeBSD, а не Linux? мне кажется по Linux это тоже прокатит.
Нельзя объять необъятное. Тут всё просто, если Вы не знаете, что такое LDAP — значит он Вам не нужен, и Вы счастливый человек. Ставите {auth_method, internal}, подключаете mod_register и вот, в общем-то всё. Для личной связи у меня так сервер и настроен. Заморочки с LDAP — это только для работы.
Разница между FreeBSD и Linux большей частью в путях. Если не ошибаюсь, линуксовая конфигурация лежит в /etc/ejabberd, а не в /usr/local/etc/jabberd и т. д. У меня в репозитариях Debian он есть, да лень ставить, чтобы проверить.
Разница между FreeBSD и Linux большей частью в путях. Если не ошибаюсь, линуксовая конфигурация лежит в /etc/ejabberd, а не в /usr/local/etc/jabberd и т. д. У меня в репозитариях Debian он есть, да лень ставить, чтобы проверить.
ключевые слова — Active Directory, домен-контроллер.
Если вы не знаете что такое LDAP, то вам эта статья не нужна. Когда узнаете — вернётесь.
Jabber наше всё, уже давно и наверное надолго!!! Автор большой молодец, спасибо.
А про ДНС зону не забыли?
_jabber._tcp.company.ru. 3600 IN SRV 5 0 5269 company.ru.
_xmpp-server._tcp.company.ru. 3600 IN SRV 5 0 5269 company.ru.
_xmpp-client._tcp.company.ru. 3600 IN SRV 5 0 5222 company.ru.
да и это нелишне
jabber.company.ru. 3600 IN CNAME company.ru.
icq.company.ru. 3600 IN CNAME company.ru.
_jabber._tcp.company.ru. 3600 IN SRV 5 0 5269 company.ru.
_xmpp-server._tcp.company.ru. 3600 IN SRV 5 0 5269 company.ru.
_xmpp-client._tcp.company.ru. 3600 IN SRV 5 0 5222 company.ru.
да и это нелишне
jabber.company.ru. 3600 IN CNAME company.ru.
icq.company.ru. 3600 IN CNAME company.ru.
Впрочем это вроде как не нужно если «локальная» корпоративная система строится
Не объясните, как смысл в этих записях? Сейчас у меня работают два ejabberd на разных серверах и доменах, прекрасно ладят и друг с другом и с внешним миром.
Подозреваю, что отсутствие этих записей нивелируется (по крайней мере частично) командой:
Подозреваю, что отсутствие этих записей нивелируется (по крайней мере частично) командой:
% If SRV lookup fails, then port 5269 is used to communicate with remote server
{outgoing_s2s_port, 5269}.
А shared roster через LDAP не настраивали? Я пару часов ковырял mod_shared_roster_ldap — подружить его с OpenLDAP'ом так и не смог. Буду на следующей неделе ещё пробовать…
Настраивал. И даже написал на Хабре: habrahabr.ru/blogs/im/44174/
С Active Directory оно дружит?
И какой клиент наиболее удобен для пользования обычными юзерами, привыкшими к ICQ? Желательно, конфигурируемый и с одним из стандартных installer'ов (для удалённой установки)?
И какой клиент наиболее удобен для пользования обычными юзерами, привыкшими к ICQ? Желательно, конфигурируемый и с одним из стандартных installer'ов (для удалённой установки)?
В свое время настраивал сие творение на винде для любителей IM. «Allow plaintext login» — зарубил мои надежды на использование джабера в организации. Бонус: самая большая запарка при подключении к мастдайному AD — это указать правильную точку входа в дерево для юзеров AD.
Никак не могу настроить на своём сервере авторизацию ejabberd через Communigate LDAP. Подключение под логином-паролем к серверу LDAP происходит нормально, но при подключении пользователя и проверке пароля выходит ошибка:
А проверка пароля вручную следующим образом проходит нормально:
При проверке вручную выяснилось что для Communigate нужно указывать логин как «user@domain.com» а не «uid=murz,cn=domain.com». Т.е. вот так работает:
А вот так уже не хочет:
Кто-нибудь знает, можно ли настроить в ejabberd чтобы он передавал логин при авторизации пользователя как user@domain.com, а не uid=user,cn=domain.com?
15:59:10.251 4 LDAP-000262([127.0.0.1]) BINDing as 'uid=murz,cn=domain.ru'
15:59:10.251 1 LDAP-000262([127.0.0.1]) BIND failed. Error Code=incorrect passwordА проверка пароля вручную следующим образом проходит нормально:
16:04:10.251 4 LDAP-000267([127.0.0.1]) BINDing as 'murz@domain.com'
16:04:10.251 2 LDAP-000267([127.0.0.1]) 'murz@domain.com' connected from [127.0.0.1]:45116При проверке вручную выяснилось что для Communigate нужно указывать логин как «user@domain.com» а не «uid=murz,cn=domain.com». Т.е. вот так работает:
$ldapsearch -w secret -x -D murz@domain.com -b "cn=domain.com" "(uid=murz)"
Searched succesfully!А вот так уже не хочет:
$ldapsearch -w secret -x -D uid=murz,cn=domain.com -b "cn=domain.com"
"(uid=murz)"
ldap_bind: Invalid credentials (49)
additional info: incorrect passwordКто-нибудь знает, можно ли настроить в ejabberd чтобы он передавал логин при авторизации пользователя как user@domain.com, а не uid=user,cn=domain.com?
Попробуйте поколдовать с параметром ldap_uids
www.process-one.net/docs/ejabberd/guide_en.html#htoc32
www.process-one.net/docs/ejabberd/guide_en.html#htoc32
Я уже ковырялся с этим параметром, но, к сожалению, это особо не помогло.
Пользователя ejabberd находит нормально, а вот когда проверяет пароль — ejabberd, насколько я понял, пытается подключиться к LDAP под логином-паролем пользователя, а это у него как раз и не проходит.
Настройки следующие:
В логе LDAP-сервера Communigate при подключении пишется следующее:
При старте:
Т.е. сам ejabberd нормально подключился под юзером из конфига «murz@domain.ru» и вошел. Т.е. всё нормально. Дальше он ждёт подключений юзеров.
Далее при подключении юзера user54@domain.ru:
Пароль указывается верный. Но при подключении имя пользователя идёт уже не как «user54@domain.ru», а как «uid=user54,cn=domain.ru». Но Communigate LDAP такой формат логина понимать не хочет и выдает ошибку что неправильный пароль.
То же самое и при попытках подключения с консоли:
А при несуществующем юзере — другая ошибка:
Пользователя ejabberd находит нормально, а вот когда проверяет пароль — ejabberd, насколько я понял, пытается подключиться к LDAP под логином-паролем пользователя, а это у него как раз и не проходит.
Настройки следующие:
{auth_method, ldap}.
{ldap_servers, ["localhost"]}.
{ldap_uids, [{"uid"}]}.
{ldap_base, "cn=domain.ru"}.
{ldap_rootdn, "murz@domain.ru"}.
{ldap_password, "secret"}.В логе LDAP-сервера Communigate при подключении пишется следующее:
При старте:
16:14:22.226 3 LDAP-000285([127.0.0.1]) got connection on [127.0.0.1]:389(Error Code=unassigned local network address) from [127.0.0.1]:53895
LDAP-000285([127.0.0.1]) BINDing as 'murz@domain.ru'
16:14:22.226 2 LDAP-000285([127.0.0.1]) 'murz@domain.ru' connected from [127.0.0.1]:53895
16:14:22.226 4 LDAP-000285([127.0.0.1]) Logged in as uid=murz,cn=domain.ru. authType=0Т.е. сам ejabberd нормально подключился под юзером из конфига «murz@domain.ru» и вошел. Т.е. всё нормально. Дальше он ждёт подключений юзеров.
Далее при подключении юзера user54@domain.ru:
16:16:51.999 3 LDAP-000288([127.0.0.1]) got connection on [127.0.0.1]:389(Error Code=unassigned local network address) from [127.0.0.1]:54283
16:16:51.999 4 LDAP-000288([127.0.0.1]) BINDing as 'uid=user54,cn=domain.ru'
16:16:52.000 1 LDAP-000288([127.0.0.1]) BIND failed. Error Code=incorrect password
16:16:52.001 3 LDAP-000288([127.0.0.1]) request reading failed. Error Code=connection closed by peer
16:16:52.001 4 LDAP-000288([127.0.0.1]) closing connection
16:16:52.001 4 LDAP-000288([127.0.0.1]) releasing stream Пароль указывается верный. Но при подключении имя пользователя идёт уже не как «user54@domain.ru», а как «uid=user54,cn=domain.ru». Но Communigate LDAP такой формат логина понимать не хочет и выдает ошибку что неправильный пароль.
То же самое и при попытках подключения с консоли:
$ ldapsearch -W -x -D uid=user54,cn=domain.ru -b "cn=domain.ru" "(uid=user54)"
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
additional info: incorrect password$ ldapsearch -W -x -D user54@domain.ru -b "cn=domain.ru" "(uid=user54)"
Enter LDAP Password:
# extended LDIF
[...нормальная выдача результата поиска...]А при несуществующем юзере — другая ошибка:
$ ldapsearch -W -x -D uid=user55,cn=domain.ru -b "cn=domain.ru" "(uid=user55)"
ldap_bind: Invalid credentials (49)
additional info: directory record with the specified DN is not foundА что если так?
{ldap_uids, [{"uid", "%u@domain.ru"}]}.
{ldap_base, ""}.
Так не помогает. С такими настройками ещё и юзера не находит:
Для того чтобы заработало нужно чтобы при поиске юзера он искал в базе по uid=user54,cn=domain.ru, а авторизовался после успешного поиска — по user54@domain.ru
Написал вчера в Communigate запрос — можно ли сменить тип авторизации LDAP — пока молчат.
12:35:32.880 4 LDAP-000311([127.0.0.1]) searching(sub) ''
12:35:32.880 4 LDAP-000311([127.0.0.1]) searching where (uid=user54@domain.ru)
12:35:32.880 4 LDAP-000311([127.0.0.1]) searching for ALL
12:35:32.933 2 LDAP-000311([127.0.0.1]) search finishedДля того чтобы заработало нужно чтобы при поиске юзера он искал в базе по uid=user54,cn=domain.ru, а авторизовался после успешного поиска — по user54@domain.ru
Написал вчера в Communigate запрос — можно ли сменить тип авторизации LDAP — пока молчат.
Тогда может применить внешнюю программу аутентификации? Я у нас так и сделал. Позже, наверное, внесём изменения в схему LDAP и перейдём на стандартные средства, но пока и так неплохо работает.
Добился-таки от Communigate ответа!
Нужно было поставить галку «дублировать пароли пользователя в базе LDAP» чтобы авторизация такого типа заработала.
Теперь другая засада — не могу подружить с gmail — никак не пойму в чем проблема :( Сообщения внутри сервера ходят, а с пользователями gmail — нет — ни авторизация ни сообщения не доходят вообще.
Нужно было поставить галку «дублировать пароли пользователя в базе LDAP» чтобы авторизация такого типа заработала.
Теперь другая засада — не могу подружить с gmail — никак не пойму в чем проблема :( Сообщения внутри сервера ходят, а с пользователями gmail — нет — ни авторизация ни сообщения не доходят вообще.
Это, скорее всего, проблема в коммуникации с другими серверами при помощи SRV.
В данный момент как раз пытаюсь победить подобное.
Для начала:
проверьте свои SRV записи _xmpp-server._tcp и _xmpp-client._tcp
Посмотрите логи на предмет установления S2S соединения с гуглем.
В данный момент как раз пытаюсь победить подобное.
Для начала:
проверьте свои SRV записи _xmpp-server._tcp и _xmpp-client._tcp
Посмотрите логи на предмет установления S2S соединения с гуглем.
Уже победил прописав SRV-записи, надо было просто подождать пока DNS-кеш у гугла обновит инфу о моём домене.
Работает всё нормально, осталась только небольшая проблема:
У меня стоит транспорт pyicqt, если его добавляешь через gmail.com-аккаунт, то при коннекте транспорт каждый раз требует авторизации. Но работает нормально если подтвердишь и если отвергнешь её. Только автоматом при выходе в онлайн не подключается и надоедает сообщениями об авторизации ;( Где искать причину этого — затрудняюсь что-то придумать ;(
Работает всё нормально, осталась только небольшая проблема:
У меня стоит транспорт pyicqt, если его добавляешь через gmail.com-аккаунт, то при коннекте транспорт каждый раз требует авторизации. Но работает нормально если подтвердишь и если отвергнешь её. Только автоматом при выходе в онлайн не подключается и надоедает сообщениями об авторизации ;( Где искать причину этого — затрудняюсь что-то придумать ;(
транспорт значит свой стоит?
думаю, стоит покопаться в районе acl у ejabberd
По этой же причине и не подключается автоматом, раз авторизацию требует.
думаю, стоит покопаться в районе acl у ejabberd
По этой же причине и не подключается автоматом, раз авторизацию требует.
Да, завернул аську через gmail — уж очень удобен поиск в истории разговоров у gmail через вёб-интерфейс, даже с сотового можно найти кто что в аську скидывал если приспичит.
Пробовал чужие сервисы, но все они нестабильные — то отваливаются, то меняют хост. В результате приходится весь контакт-лист переавторизовывать, старые удалять, а нормального редактора контактов так и не нашёл, beta.unclassified.de/projekte/jru-php/ с gmail перестал работать а рабочей замены не нашёл, чтобы можно было массово контакты редактировать. А также цепочка истории теряется из-за изменения хоста гейта.
Да и вообще — свой сервис всё же ближе к телу ;)
По acl добавил себя в группу админов, чтобы все права были: {acl, admin, {user, «murz», «gmail.com»}}.
Не помогло.
Добавил {{s2s_host, «gmail.com»}, allow}.
Тоже не помогло.
Проверил обычное добавление пользователей — работает.
Т.е. в аккаунте murz@gmail.com добавляю murz@j-im.ru — авторизация приходит, подтверждаю, всё хорошо.
Может быть от pyicqt не приходит запрос что подтверждаю авторизацию? хотя ничего такого в настройках там не нашёл.
Какие ещё настройки acl могут влиять на авторизацию?
Пробовал чужие сервисы, но все они нестабильные — то отваливаются, то меняют хост. В результате приходится весь контакт-лист переавторизовывать, старые удалять, а нормального редактора контактов так и не нашёл, beta.unclassified.de/projekte/jru-php/ с gmail перестал работать а рабочей замены не нашёл, чтобы можно было массово контакты редактировать. А также цепочка истории теряется из-за изменения хоста гейта.
Да и вообще — свой сервис всё же ближе к телу ;)
По acl добавил себя в группу админов, чтобы все права были: {acl, admin, {user, «murz», «gmail.com»}}.
Не помогло.
Добавил {{s2s_host, «gmail.com»}, allow}.
Тоже не помогло.
Проверил обычное добавление пользователей — работает.
Т.е. в аккаунте murz@gmail.com добавляю murz@j-im.ru — авторизация приходит, подтверждаю, всё хорошо.
Может быть от pyicqt не приходит запрос что подтверждаю авторизацию? хотя ничего такого в настройках там не нашёл.
Какие ещё настройки acl могут влиять на авторизацию?
В локальном аккаунте гейт нормально добавляется, авторизуется, выходит автоматом в онлайн. С другим сервисом (например icq.gelf.no-ip.com) этот же gmail-аккаунт нормально работал, авторизовал один раз и потом автоматом подключалось всё. Т.е. причина получается всё же в настройках pyicqt или ejabberd.
сейчас, к сожалению, не могу покопаться в своем сервере. вечером посмотрю.
а так, навскидку:
1. subscription стоит both после авторизации?
2. стоит выставить логи в дебаг у ejabberd и у PyIcq, почитать что пишут.
Получается так, что jid icq.что-там-у-вас.com не сохраняет статус подписки почему-то.
а так, навскидку:
1. subscription стоит both после авторизации?
2. стоит выставить логи в дебаг у ejabberd и у PyIcq, почитать что пишут.
Получается так, что jid icq.что-там-у-вас.com не сохраняет статус подписки почему-то.
Выставил дебаг-логи у ejabberd и у pyicqt,
пока не выйду в онлайн — в логах pyicqt и ejabberd вообще ничего не пишется, даже когда в клиенте нажимаю кнопку «авторизовать».
В pyicqt вообще тишина пока в онлайн аськи не вылезешь, а в ejabberd — запросы статуса асечных аккаунтов, но самого гейта icq.mydomain.ru вообще не упоминается.
При коннекте у шлюза Subscription: none
После того как авторизацию сделал — тоже
Subscription: none
пока не выйду в онлайн — в логах pyicqt и ejabberd вообще ничего не пишется, даже когда в клиенте нажимаю кнопку «авторизовать».
В pyicqt вообще тишина пока в онлайн аськи не вылезешь, а в ejabberd — запросы статуса асечных аккаунтов, но самого гейта icq.mydomain.ru вообще не упоминается.
При коннекте у шлюза Subscription: none
После того как авторизацию сделал — тоже
Subscription: none
Галка эта находится на странице host.ru:8010/Master/Domains/DomainsDirectory.html
Copy into Account records:
Passwords
Copy into Account records:
Passwords
И возможно ещё придётся поиграться с ldap_base.
Какие у Вас настройки в ejabberd?
Какие у Вас настройки в ejabberd?
в свое время ставил jabber с интеграцией в ldap (eDir), выбор пал на openfire, с работу уже ушел, но вроде все работает ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ejabberd с авторизацией через LDAP