www.nsoft-s.com

Здравствуйте, подскажите, есть ли в MyChat автоматическая синхронизация пользователей состоящей в определенной группе в Active Directory?

Добрый день. Нет, мы такого ещё не делали. Импорт и синхронизация пользователей есть, но только по команде администратора, автоматически это не работает, потому что не очень понятно, как правильно синхронизировать данные.

Предложите свой вариант, обсудим.

И мне надо :-)
В Openfire можно настроить группу конкретную которую затаскивать все время.
Например делаем в АД группу MyChatUsers, прописываем ее в настройках MyChat
И все пользователи этой группа (в том числе и появляющиеся) автоматом затаскиваются с правами минимальными или настраиваемыми...
Тогда можно было просто пользователя добавил в группу и он уже получил доступ к чату.
Или, пока, хотя бы скрипт запуска синхронизации с какими-то параметрами ( группа и т.д.) что бы запускать раз в сутки и затаскивать новых.

Думаем над этим, но пока что такого нет.

Я правильно понял, что сейчас нет возможности автоматической синхронизации с AD (изменение свойств уже зарегистрированных пользователей при изменении их в AD и добавление новых пользователей), сейчас это можно делать только вручную?
Есть кнопка Синхронизация в подменю, локальный домен прописан вида mydomain.local , установлены флажки:

Синхронизация пользователей

Сформировать общий список контактов на основе структуры домена (OU)

Сформировать должности на основе данных из домена

Этот сервис должен работать или еще нет?

Ещё нет. Мы на пути к этому. Пока синхронизация только по пинку со стороны администратора в админке MyChat Server.

Коллеги, вопрос критически важный, т.к. в крупной компании совершенно не хочется тратить ресурсы на "пинание чего либо админом", у нас в день добавляется и удаляется по десятку пользователей и логично, что уж коль есть синхронизация с AD она должна быть автоматической.

Еще есть необходимость иметь возможность настройки этой самой синхронизации, например: частота синхронизации, автоматическое удаление или блокировка пользователей mychat при аналогичных действиях в AD, возможность прописать шаблон отбора пользователей и групп из AD (например как в openfire для групп: ldap.groupSearchFilter (objectClass=group)(cn=*Openfire*)). Наличие конфигурируемого фильтра очень актуально, т.к. те, кто использует Microsoft Exchange Server, как правило, уже имеют структуру(там отдельное OU и далее всё рулится группами, у вас я вообще не нашел возможности формировать список на основе групп) в AD по которой строится иерархическая адресная книга для Outlook и очень удобно было бы иметь возможность её использовать и для построения списка групп и контактов в клиенте ...

Т.е. при включении синхронизации с AD берем за аксиому парадигму, что дальше пользователями и группами будут рулить из AD (добавлять, удалять, менять пароли(т.к. они имеют обыкновение устаревать в соответствии с политиками безопасности и пользователи сами их меняют при входе в windows))

Добрый день, уважаемые разработчики.

Подскажите, в данном направлении уже что-то было сделано? Есть какое-то решение? У нас информация о пользователях меняется довольно часто в связи с некоторой текучкой в паре отделов и вручную каждый раз апдейтить инфу стало не камильфо :-)

Если пока ничего готового нет, то рассматриваю 3 варианта. Прошу подсказать, какой из них более адекватен:
1) обновление через Integration API. Я скриптом по расписанию запрашиваю с сервера МС зареганных пользователей, и по циклу беру инфу о пользователе в АД и JSON'ом обновляю его

2) скриптом MSL со стороны сервера МС устанавливаю соединение с АД, получаю список пользователей на сервере МС и также по циклу запрашиваю инфу о пользователе из АД и изменяю ее на сервере МС, если она отличается

3) сейчас будет трэш...я делаю все то же самое, но с базой сервера МС напрямую.

В готовящейся версии сделали LDAP-фильтры, но автоматической синхронизации ещё не делали. В MyChat Integration API функций специальных для работы с доменом нету, как вы хотите это делать?

3) сейчас будет трэш...я делаю все то же самое, но с базой сервера МС напрямую.

Расскажите подробнее.

3) сейчас будет трэш...я делаю все то же самое, но с базой сервера МС напрямую.

Расскажите подробнее.

Беру делфи, создаю консольное приложение (для простоты, хотя в более тяжелом случае можно было бы и сервис замутить), кидаю на DataModule компоненты FireDAC для работы с SQLite и ActiveDirectory, далее логика простая:
1) через FDConnection коннектимся к базе сервера МС, через FDQuery делаем выборку таблицы 'users' с необходимыми полями (в моем случае это организация, ФИО, должность, отдел, все виды телефонов, день рождения)
2) через OLEDB коннектимся к AD и выбираем все объекты с типом 'user'
3) старт транзакции на FDConnection
4) цикл по пользователям из FDQuery с фильтром по OLEDB-Query по полю DisplayName (это, опять же, для моего случая, т.к. корректность ведения этого поля кадровиками в нашей ИС я контролю жестко и уверен в нем на 100%). Сверяю данные по обозначенным выше полям, если что-то отличается - вношу правки либо через FDQuery.Edit, либо через FDConnection.ExecSQL(запрос на апдейт)
5) коммит транзакции на FDConnection

если не возникнет проблем с блокировками, то, думается мне, что для меня будет проще именно этот вариант )) тем более, что для реализации первых двух вариантов самую малость не хватает функционала :-)

Проблема возникнет, потому что MyChat Server держит базу данных в монопольном режиме специально, чтобы не было проблем со сторонними попытками подключения.

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

Я рекомендую вам дождаться нормальной синхронизации, которую сделаем мы.

Проблема возникнет, потому что MyChat Server держит базу данных в монопольном режиме специально, чтобы не было проблем со сторонними попытками подключения.

пичалька (((

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

ну почему же плохой...таблица с пользователями - такой же Query-компонент, умеющий делать фильтрацию, которая не вызывает дополнительных запросов к серверу (в данном случае к AD). У меня источник информации о пользователях во всех системах один - наша ИС, в которой кадровики ведут учет. Оттуда инфа уже разлетается по остальным системам - AD, почта, MyChat и прочие. Соответственно, в каждой из них пользователь с определенным ФИО весьма достоверно соотновится с аналогичным в другой системе. Вероятны исключения в виде полностью совпадающего ФИО у двух и более людей, но по причине малой вероятности данного случая я его не учитываю.
Что касается новых пользователей, то учитывая ограниченное кол-во лицензий MyChat, автоматически их создавать не хочу, да и не все они сидят в чате по причине отсутствия таковой необходимости (например, работники склада).
Насчет удалять - спорный момент, в AD я их не удаляю, а отключаю и переношу в отдельное OU, аналогично можно бы и с учетками в MC поступать. Но это опять же мой случай, а не универсальный вариант. Как тут ублажить абсолютно всех - сложно сказать :-)
Исходя из вышесказанного, моё желание простое - просто иметь актуальную инфу о существующих пользователях домена, тем более что в домене и всех прочих сервисах, за исключением МС, она всегда актуальна.

Я рекомендую вам дождаться нормальной синхронизации, которую сделаем мы.

Алексей, не поймите неправильно, я понимаю пул Ваших задач и их сложность, но что-то мне уже невтерпёж :-)

Всё понимаем. Имейте терпение, сэр

буду ждать с нетерпением :-)

P.S: (рац.предложение) а почему бы просто не дать пользователям инструменты в виде REST-api по работе с объектами в БД? Создание, модификация, удаление с помощью привычных многим REST-запросов, классический api-backend. И пусть бы каждый делал и пилил, как ему удобно и кажется правильным

вдруг кому будет интересно, в качестве временного решения сделал так

Теперь можно спокойно ждать решения от разработчиков