Программное создание, изменение и удаление/блокирование пользователей

Добрый день, подскажите пожалуйста есть ли возможность программно создавать, изменять и удалять/блокировать пользователей.
А именно у нас отдельная кадровая система на предприятии и информация о сотрудниках хранится в сторонней системе, считая, что у нас развернуто Active Directory то сотрудники авторизуется в систему под своим логином и паролем. (кадровая система является первостепенной, т.е. пользователей Active Directory создают по информации из неё, т.е. сначала в кадровой системе и только потом уже в Active Directory)
Задача, такая чтобы в ручном режиме не добавлять пользователей, не актуализировать их, нужно чтобы это неким процессом делалалось, допустим один раз в 2 часа.

Вопрос, можно ли программно создать пользователя, через некое API, после которого данный пользователь мог по сквозному авторизоваться в системе через LDAP.
Причём создать пользователя нужно так, чтобы уже определенные поля также сразу заполнить (ФИО, почтовый ящик, телефон и т.п.)

 

Добрый день. Краткий ответ, все действия можно по обработке пользователей можно сделать программно, готовых примеров в базе знаний я не нашел, тут нужно будет разбираться с кодом самостоятельно.
Я такую задачу ранее уже решал, поэтому приведу пример как можно реализовать данную задачу.
В идеале реализовать кадровые процессы в ELMA: прием нового сотрудника на работу, увольнение сотрудника и перевод сотрудника на другую должность. Тогда у вас создание и удаление учетных записей и в кадровой и AD и в ELMA будет происходить синхронно, все необходимые работы будут выполнены и все данные будут заполнены.
Замечу, что помимо создания самих учетных записей (или записей о сотруднике), вам нужно будет так же решать вопрос назначения пользователя на должность и включения его в группы, такую задачу, как правило в автоматическом режиме решить не получается. Поясню почему. Орг. структура в ELMA и AD устроена по разному: в ELMA у сотрудника есть должность (или должности), как отдельный объект, которая подчиняется какой-то другой должности и по иерархии может быть включена в какой-то отдел. В AD должность это просто строка, а непосредственный руководитель это ссылка на другого пользователя (а не ссылка на другую должность, как в ELMA), подразделение в AD это отдельный объект, который вложен в другое подразделение, и оно напрямую никак не связано с должностями, кроме того пользователь может быть включен только в одно подразделение. А в кадровой системе должности могут хранится в другой структуре. Такое несовпадение подходов, как правило требует, чтобы должности как минимум перепроверялись вручную, или же полностью создавались вручную. Кроме того, в ELMA орг. структура имеет графическую схему (как схема процесса), которую требуется моделировать вручную в дизайнере (автоматически возможно, но получится очень кривая схема). Таким образом я рекомендую вопрос синхронизации орг. структуры, выполнять в полуавтоматическом режиме в вышеуказанных процессах, если все необходимые должности есть, то можно выполнять назначение сотрудника автоматически с проверкой результатов ответственным сотрудником, если же должность новая, то выполнять их создание вручную в ELMA, AD и кадровой системе.
Второй момент это включение пользователей в группы, которые влияют на права доступа. Как правило группы в ELMA и AD не совпадают, поэтому включение пользователей (или в случае элмы должностей), нужно проводить в ручном режиме: отдельно в AD, отдельно в ELMA. Выполнять это рекомендую так же в ходе вышеуказанных процессов.
Ну и последнее собственно синхронизация данных между 3 системами, если вдруг что-то меняется. То есть это синхронизация, когда во всех 3 системах уже заведены пользователи, и требуется только актуализировать данные: например изменился номер телефона или email. Это уже резонно проводить с помощью процесса запускаемого по таймеру (я бы рекомендовал раз в день это делать, чаще обычно смысла нет). Для этого процесса потребуется соотнесение пользователей, для этого рекомендую использовать логин пользователя в AD. В ELMA он уже будет присутствовать в профиле пользователя, т.к. пользователи будут импортироваться, а вот в кадровой системе нужно завести поле с логином пользователя. Потом в этом автоматическом процессе синхронизации нужно определить, какая система будет являться первоисточником данных, то есть в какую систему изначально вводятся актуальные данные. По вашему описанию, это скорее всего будет кадровая система. Соответственно, нужно процесс синхронизации строить следующим образом: запускается процесс в ELMA по расписанию, ELMA получает актуальные изменения из кадровой системы, сверяет с данными о пользователях у себя и при необходимости обновляет, потом запрашивает профиль из AD и смотрит были ли там изменения и так же при необходимости обновляет. Рекомендую все правки сохранять в специальный лог в процессе, чтобы потом можно было разобраться, если что-то пойдет не так. Весь процесс должен отрабатывать автоматически без участия пользователя.
Надеюсь мои рекомендации были полезны, если будут вопросы обращайтесь - смогу вам все пояснить, т.к. есть опыт решения такой задачи.

 

Ууух как много букв =) Спасибо за ответ, но я немного перефразирую свой вопрос, а именно

Представьте пожалуйста, что есть чистая только что установленная Elma, ещё нет ни одного пользователя кроме admin, и оргструктура абсолютно пустая, но сразу сделана одна настройка это настройке LDAP сервера, и уже можно по идее спокойно импортировать пользователей из AD, однако мы этого не делаем, мы вообще не хотим их импортировать, т.к. будем считать что AD у нас это не как источник информации о пользователях, их должности, отдела и т.п., даже представим себе что AD это просто как инструмент авторизации в Elma через Windows. (более того - представьте что в AD у пользователя в его аттрибутах указан только логин, другими словами я не хочу из AD тащить информацию о сотруднике, AD это только инструмент сквозной авторизации в Elma через Windows авторизацию)

Далее, где то в нашей Интранет сети есть какое то отдельно покупное решение, которое обеспечивает функционал кадров, и сразу отмечу что мы не можем уйти от него и это как бы железо-бетонно. Так вот это решение может дать мне пускай в виде WebAPI, пускай неким представлением в своей базе данным, не суть, в итоге она мне может выдать массив информации о сотрудниках предприятия, типа такого:
(хм, в редакторе есть всё, а вставки таблицы нет :/ )
представьте что это таблица:
ЛОГИН;EMAIL;ФАМИЛИЯ;ИМЯ;ОТЧЕСТВО;ТАБЕЛЬНЫЙ НОМЕР(500% уникальный!!!, хотя логин тоже 500%);ДОЛЖНОСТЬ;НАЗВАНИЕ ПОДРАЗДЕЛЕНИЯ;ID ПОДРАЗДЕЛЕНИЯ;НАЗВАНИЕ БЮРО;ID БЮРО
Т.е. грубо говоря информация о сотруднике примерно из 10 полей (необходимый минимум полей так сказать)
И сотрудников таких 5000 штук.

ЗАДАЧА: Нужно сделать на постоянной основе синхронизацию кадров из сторонней системы.
Т.е. как я это вижу, некий процесс который запускается с какой то периодичностью, сначала достаёт эти данные сразу всем, т.е. некий массив к себе.
Далее он начинает циклом бежать по нему, сначала он достаёт информацию о ID подразделении, и ищет её в оргструктуре ELMA (каким то образом по уникальному ID) если он таковой не находит то он её создаёт и сразу заносит её название, если он её находит то смотрит сходится или нет её название, хотя можно даже не проверять дешевле будет наверное сразу проапдейдить (ну не суть)
Далее аналогично он по ID ищет на имение бюро, а бюро это получается на языке Elma тоже объект оргструктуры, только одно дочерний другого объекта, и всё также если он его не находит, то создаёт при этом помещая его в до этого созданный/обновленный верний объект оргструктуры, если же он находит его то также просто апдейдит заголовок.

Таким образом это как бы первый шаг который я вижу, и по идее он уже должен построить оргструктуры подразделений, считая что она у нас 2ух уровневая в принципе и глубже не бывает (по крайней мере в кадрах нет такой глубины) то она будет примерно следующая

ОТДЕЛ 1
-БЮРО 1.1
-БЮРО 1.2
-БЮРО 1.3
ОТДЕЛ 2
-БЮРО 2.1
ОТДЕЛ 3
-БЮРО 3.1
-БЮРО 3.2
...

Считаем что пол дела сделано.

Второй шаг это импорт пользователей уже
И здесь всё аналогично - только за ID считаем либо ЛОГИН либо ТАБЕЛЬНЫЙ (они уникальны всегда), и создаём это уже не огрструктуре а пространстве пользователей.
ЕДИНСТВЕННОЕ

 

... ЕДИНСТВЕННОЕ
что нужно пользователей программно создавать так, чтобы они имели связь с учетной записью из AD
т.е. например если кадровая системе мне выдала строку с логином strelkovandreyvalerievich и ELMA программно создала такого пользователя в системе, то данный пользователей зайдя на веб-клиент (который успешно настроен по сквозной авторизации) авторизовал бы его пустил как раз под тем программно созданным пользователем

 

В целом, предложенное мною выше решение вам хорошо подойдет.
Сейчас поясню по-порядку:
1. Интеграция с AD. пользователей вам в любом случае нужно будет создавать методом импорта из AD, чтобы была возможность сквозной авторизации. Это не означает, что вся информация о пользователе должна затягиваться из AD, от AD вам нужен только логин и фамилия с именем. Все остальное вы можете вытягивать из вашей кадровой системы, но создавать самого пользователя в ELMA, нужно методом импорта из AD, чтобы установилась связь между учеткой в AD и ELMA. Потом уже все остальные данные можно тянуть из кадровой системы (должность, табельный номер если нужно, телефоны, адреса отчества и т.д.). Это означает, что перед тем как создать пользователя в ELMA, нужно его сначала создать в AD.
2. Про орг. структуру. Как я писал выше, импортировать и программно создавать в ELMA орг. структуру - не очень хорошая идея. Дело в том, что в ELMA орг. структура графическая и представлена в виде схемы, соответственно вам для автоматической отрисовки орг.структуры нужно определить координаты всех ее элементов (отделов и должностей), компьютерным способом это решается очень плохо, поэтому я рекомендую вам орг.структру нарисовать вручную в дизайнере ELMA. Да, придется день максимум 2 потратить, но это будет лучше чем писать сложный алгоритм автоматического построения диаграммы орг.структуры. Кроме того, часто в процессе работы приходится немного отклоняться от орг.структуры, которая у вас определена штатным расписанием, т.к. вы ELMA орг.структура влияет на права и роли в процессах, а штатное расписание это формальный документ, который поменять значительно сложнее, поэтому официально и реально, хоть немного, но отличаются на практике. Поддерживать ее, так же будет не очень сложно и быстро, если у вас будут хорошо выстроены процессы. Я реализовывал такое решение в компании на 3000 пользователей и мы остановились именно на таком решении. Так же в ручном режиме поддерживались подразделения в AD.
3. Я бы разделил вашу задачу на 2: 1) Первичное наполнение пользователей 2) Разработка решения по поддержанию актуальности состояния пользователей в 3 ваших системах (кадровой, AD и ELMA). В первой части вам нужно будет создать орг.структуру в дизайнере в ELMA, затем нужно будет разработать сценарий, который разово возьмет данные из кадровой системы, по указанным логинам импортирует учетные записи из AD, а потом заполнит недостающие поля в импортированных учетных записях из кадровой системы. Замечу, что в ELMA нет стандартных способов расширить объект орг.структуры, поэтому вам нужно будет либо указать id подразделения в описании к элементу орг.структуры в ELMA, либо создавать названия элементов орг. структуры в ELMA полностью совпадающими с названием в кадровой системе (это возможно при условии, что у вас названия должностей, отделов и бюро уникальны). Так при импорте пользователей можно будет найти нужный элемент орг. структуры в ELMA и привязаться к нему. Вторая часть - это собственно кадровые процессы, в ходе которых будет построен процесс заведения пользователя во всех системах, что возможно делать программно, а остальное возлагать уже на сотрудников в процессе. Например процесс приема на работу мог бы выглядеть примерно так: Создается запрос на устройство такого то пользователя, и в ELMA вводятся все данные о нем, затем сотруднику кадрового отдела поступает задача завести его в кадровой системе (либо завести его программно через API вашей кадровой системы, если она это позволяет), затем поступает задача системному администратору завести учетную запись в AD (так же это можно сделать программно, у AD есть API через который пользователей можно создавать программно и на системного администратора поставить только задачу проверить и включить пользователя в необходимые группы, указать подразделение), после чего ELMA автоматически импортирует пользователя из AD, из кадровой системы подтягивает данные о сотруднике, если в ELMA уже есть требуемая должность, то автоматически присвоить ее, если ее нет, то далее администратору ELMA приходит задача добавить нужную должность в орг.структуру в ELMA, и указать ее вручную в задаче по процессу, так же ему может потребоваться выдать еще дополнительные права новому сотруднику внутри ELMA. Если упрощенно то процесс найма сотрудника может выглядеть так, но конечно его можно расширить добавив туда ознакомление с регламентами, инструктажи, обустройство рабочего места и так далее. В общем такой процесс может существенно улучшить работу с сотрудниками особенно на ваших масштабах.
Никакой доработки на стороне вашей кадровой системы или AD не потребуется, это все реализуется через процессы в ELMA.
Букв опять получилось много, старался писать более понятно

 

Алексей спасибо за подробный ответ.
Я Вас понял, однако в этом есть одна небольшая грусть (про импорт пользователей), а именно, судя по вашему описанию,
так или иначе получается, что админом нужно каждый раз отслеживать появления на предприятии новых пользователей в AD, для того чтобы потом заходить в раздел Импорт из AD и искать его, отмечать галочкой и нажимать импортировать.
Т.е. под моим понятием синхронизации имелось ввиду что процесс будет запущен по некому расписанию, и он полностью будет автоматизирован и не требующий к себе внимания со стороны разработчиков, появился новая учётка в AD он её создал, и новый пользователь зайдя уже автоматически по сквозной авторизации будет пущен на главную страницу (т.е. админы даже знать про это не будут и не будут участия принимать)

Единственное что я теперь думаю по вашим словам, что похоже когда идёт импорт из AD, только разница между локально созданным пользователем и импортированным состоит не в каком то одном поле, типа 1/0 (т.е. типа локальный/active directory). Я так вижу, что если всё таки пробовать делать синхронизацию как мне же хочется, то похоже нужно импортируя пользователя как то отлавливать как изменений произошли вообще в целом в базе после этого, дабы понять закономерности таблиц и полей юзеров и других объектов как то связанных с ними, чтобы в итоге вывод показать, за счёт каких полей и происходит вот это некая связь пользователя и ad.

 

Не совсем правильно вы меня поняли.
Вы можете сделать процесс запускающийся по расписанию, который сможет смотреть новых пользователей и импортировать их сам программно без участия пользователя. Импортировать можно программно. Но для этого у вас в уже AD должна быть заведена учетная запись пользователя. Если я правильно понимаю ваш алгоритм, то у вас создается запись о сотруднике первой в вашей кадровой системе. Потом нужно завести учетку в AD. Это можно сделать программно, если у вас есть доступ по API к кадровой системе и есть алгоритм по которому можно автоматически создать учетку в AD в нужном подразделении. Опять же нужно включить пользователя в нужные группы прав в AD, об этом как правило в кадровых системах нет информации и вам в любом случае придется вручную заходит администратором и настраивать эту учетную запись. Затем что касается импорта учетной записи из AD в ELMA, тут так же можно программно импортировать, но опять же настроить права в ELMA, назначить должность по данным из AD как правило невозможно, потому что ни в AD ни в кадровой системе нет специфических прав для ELMA, ее орг.структуры и групп. Поэтому в любом случае нужно будет донастроить пользователя уже внутри самой ELMA. Удобнее всего такое решение сделать с помощью процесса, когда какой-то ответственный будет дополнять необходимую информацию в каждой системе.

 

Добрый день.
Можете подсказать как все же программно импортировать пользователй из LDAP.
Я, к сожалению, так и не смог найти такую возможность в документации.