Предложите свой вариант, обсудим.
Чат со мной
В Openfire можно настроить группу конкретную которую затаскивать все время.
Например делаем в АД группу MyChatUsers, прописываем ее в настройках MyChat
И все пользователи этой группа (в том числе и появляющиеся) автоматом затаскиваются с правами минимальными или настраиваемыми...
Тогда можно было просто пользователя добавил в группу и он уже получил доступ к чату.
Или, пока, хотя бы скрипт запуска синхронизации с какими-то параметрами ( группа и т.д.) что бы запускать раз в сутки и затаскивать новых.
Чат со мной
Есть кнопка Синхронизация в подменю, локальный домен прописан вида mydomain.local , установлены флажки:
Этот сервис должен работать или еще нет?
Чат со мной
Еще есть необходимость иметь возможность настройки этой самой синхронизации, например: частота синхронизации, автоматическое удаление или блокировка пользователей 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) сейчас будет трэш...я делаю все то же самое, но с базой сервера МС напрямую.
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
если не возникнет проблем с блокировками, то, думается мне, что для меня будет проще именно этот вариант )) тем более, что для реализации первых двух вариантов самую малость не хватает функционала :-)
Насчёт синхронизации по DisplayName — это не лучший вариант, вам нужно будет перелопачивать всех пользователей каждый раз (а нужно только тех, кто реально изменился), опять же, куча вариантов при частичном изменении данных, блокировании пользователей, появлению новых людей в домене и т.п.
Я рекомендую вам дождаться нормальной синхронизации, которую сделаем мы.
Чат со мной
Проблема возникнет, потому что MyChat Server держит базу данных в монопольном режиме специально, чтобы не было проблем со сторонними попытками подключения.
пичалька (((
Насчёт синхронизации по DisplayName — это не лучший вариант, вам нужно будет перелопачивать всех пользователей каждый раз (а нужно только тех, кто реально изменился), опять же, куча вариантов при частичном изменении данных, блокировании пользователей, появлению новых людей в домене и т.п.
ну почему же плохой...таблица с пользователями - такой же Query-компонент, умеющий делать фильтрацию, которая не вызывает дополнительных запросов к серверу (в данном случае к AD). У меня источник информации о пользователях во всех системах один - наша ИС, в которой кадровики ведут учет. Оттуда инфа уже разлетается по остальным системам - AD, почта, MyChat и прочие. Соответственно, в каждой из них пользователь с определенным ФИО весьма достоверно соотновится с аналогичным в другой системе. Вероятны исключения в виде полностью совпадающего ФИО у двух и более людей, но по причине малой вероятности данного случая я его не учитываю.
Что касается новых пользователей, то учитывая ограниченное кол-во лицензий MyChat, автоматически их создавать не хочу, да и не все они сидят в чате по причине отсутствия таковой необходимости (например, работники склада).
Насчет удалять - спорный момент, в AD я их не удаляю, а отключаю и переношу в отдельное OU, аналогично можно бы и с учетками в MC поступать. Но это опять же мой случай, а не универсальный вариант. Как тут ублажить абсолютно всех - сложно сказать :-)
Исходя из вышесказанного, моё желание простое - просто иметь актуальную инфу о существующих пользователях домена, тем более что в домене и всех прочих сервисах, за исключением МС, она всегда актуальна.
Я рекомендую вам дождаться нормальной синхронизации, которую сделаем мы.
Алексей, не поймите неправильно, я понимаю пул Ваших задач и их сложность, но что-то мне уже невтерпёж :-)
Чат со мной
P.S: (рац.предложение) а почему бы просто не дать пользователям инструменты в виде REST-api по работе с объектами в БД? Создание, модификация, удаление с помощью привычных многим REST-запросов, классический api-backend. И пусть бы каждый делал и пилил, как ему удобно и кажется правильным
Теперь можно спокойно ждать решения от разработчиков