Comments 31
Жесть.
А что, 1С не поддерживает ActiveDirectory? Можно было обмениваться данными напрямую через LDAP минуя все эти файлы, сценарии оболочки.
А что, 1С не поддерживает ActiveDirectory? Можно было обмениваться данными напрямую через LDAP минуя все эти файлы, сценарии оболочки.
Ты говоришь вполне логичные вещи и это именно то о чем я подумал в первую очередь, но данная идея была отметена в сторону в последствии.
Я не спорю можно и ежа скрестить со слоном, но я не программист 1С и в связи с этим не очень знаю что она может и мне было проще написать такой обработчик на powershell так как файлы уже выгружались еще до моего прихода в компанию, и я не нашел ни одной статьи где бы освещалась работа 1С с AD.
Да и мне кажется получилось бы значительно больше строк текста и тяжелее было бы что то добавить чем в этот скрипт.
Я не спорю можно и ежа скрестить со слоном, но я не программист 1С и в связи с этим не очень знаю что она может и мне было проще написать такой обработчик на powershell так как файлы уже выгружались еще до моего прихода в компанию, и я не нашел ни одной статьи где бы освещалась работа 1С с AD.
Да и мне кажется получилось бы значительно больше строк текста и тяжелее было бы что то добавить чем в этот скрипт.
1С может работать со всем, что имеет COM интерфейс.
1С поддерживает COM, соответственно всё можно сделать, но для этого процесс 1С должен иметь соответствующие привилегии в AD, что не всегда правильно по безопасности. Ну и учесть, что для изменения логики надо изменять код, останавливать работу пользователей. Скрипт всегда проще править ))
А что будет, если в 1С нажать кнопку "Отмена проведения"? :)
Ввиду не однозначности равенства пользователя домена и 1С, считаю, что начинать нужно от печки. То есть в начале создать учётную запись в AD, потом распространять её по программам учёта (техники, ресурсов и пр.), в том числе и 1С.
Теперь проверка логики: «В нашей компании после заведения пользователя в 1C создается CSV файл с данными» и «Прием на работу». То есть вы создаёте пользователя 1С до приёма на работу? И начальник службы безопасности знает об этом?
я не программист 1С
И не надо, сделайте внешнюю обработку и воспользуйтесь в ней старой доброй LanManager share functions for Windows NT interface unit
Теперь проверка логики: «В нашей компании после заведения пользователя в 1C создается CSV файл с данными» и «Прием на работу». То есть вы создаёте пользователя 1С до приёма на работу? И начальник службы безопасности знает об этом?
я не программист 1С
И не надо, сделайте внешнюю обработку и воспользуйтесь в ней старой доброй LanManager share functions for Windows NT interface unit
По поводу логики я немного не верно написал, файл создается после приема на работу. "Прием на работу" это тэг для определения действия над пользователем.
Вы немного не поняли. В данном случае речь идет не об учетной записи пользователя в 1С, а о приказах о приеме на работу и увольнении. В 1С ведется кадровый учет, так что это и есть "печка".
Выяснять, что первичней учётная запись AD или 1С — всё равно, что решать были-ли первым курица или яйцо. Для меня AD является основанием для настройки прикладных программ (в том числе 1С), поэтому — первично. Учётная запись AD создаётся или удаляется при визировании обходного листа сотрудника (как при приёме, так и увольнении). Я думаю, что указанный выше скрипт — итог перегруженности момента создания учётной записи AD (я создаю её с настройками по-умолчанию, дальнейшие изменения, после приказа, по служебным запискам начальников — распределение ресурсов).
Основанием для создания учетной записи в AD является наличие приказа о приеме на работу в кадровой учетной системе.
Основанием для отключения — выход в декрет, неявка на работу (когда кадры начинают ставить пропуски), увольнение, в некоторых случаях отпуск.
Обходной листок не гарантия отключения учетной записи, остается человеческий фактор. Нужна автоматизация.
Основанием для отключения — выход в декрет, неявка на работу (когда кадры начинают ставить пропуски), увольнение, в некоторых случаях отпуск.
Обходной листок не гарантия отключения учетной записи, остается человеческий фактор. Нужна автоматизация.
То есть предполагается, что зона ответственности системного администратора передаётся учётчице из отдела кадров? Вопрос риторический. Дайте адрес электронной почты службы внутренней безопасности.
Вы либо меня не поняли, либо у Вас извращенная логика.
Достоверность информации о том, работает человек или нет — это проблема управления по работе с персоналом, а не аккаунт администраторов. Учетная кадровая система является первоисточником, тут без вариантов.
Актуальность учетных записей Active Directory это работа и проблема аккаунт администратора, выгрузка информации из учетной системы и синхронизация с AD это единственный путь обеспечения оперативности актуализации этих учетных данных. Автоматизация при контроле со стороны аккаунт админа это устранение бОльшей части рисков связанных с человеческим фактором.
И если в организации в одном офисе до 150-200 человек местный сисадмин может знать каждую сволочь в лицо и быть в курсе, что кто то увольняется, то при бОльших количествах пользователей, куче обслуживаемых организаций и множестве офисов по всему региону отследить визуально смены должностей и увольнения просто не реально. Только автоматизация.
А что до безопасников, то они хотят, что бы доступ в сеть и её ресурсам имели только сотрудники организации, либо сторонние сотрудники по их согласованию. В общем то это их требование, прописанное в стандарте по ИБ.
Все остальные методы надуманны.
зыю
Злонамеренное создание в кадровой системе кадровиком сотрудника, что бы на него создали учетную запись — это не проблема аккаунт админа, это проблема специалистов по внутренней безопасности.
Достоверность информации о том, работает человек или нет — это проблема управления по работе с персоналом, а не аккаунт администраторов. Учетная кадровая система является первоисточником, тут без вариантов.
Актуальность учетных записей Active Directory это работа и проблема аккаунт администратора, выгрузка информации из учетной системы и синхронизация с AD это единственный путь обеспечения оперативности актуализации этих учетных данных. Автоматизация при контроле со стороны аккаунт админа это устранение бОльшей части рисков связанных с человеческим фактором.
И если в организации в одном офисе до 150-200 человек местный сисадмин может знать каждую сволочь в лицо и быть в курсе, что кто то увольняется, то при бОльших количествах пользователей, куче обслуживаемых организаций и множестве офисов по всему региону отследить визуально смены должностей и увольнения просто не реально. Только автоматизация.
А что до безопасников, то они хотят, что бы доступ в сеть и её ресурсам имели только сотрудники организации, либо сторонние сотрудники по их согласованию. В общем то это их требование, прописанное в стандарте по ИБ.
Все остальные методы надуманны.
зыю
Злонамеренное создание в кадровой системе кадровиком сотрудника, что бы на него создали учетную запись — это не проблема аккаунт админа, это проблема специалистов по внутренней безопасности.
У вас не верная логика, насчет безопасности, есть серьезные промышленные решения identity manager, и у них у всех инициатором создания учетных записей является HR система, а AD выступает одной из многих систем где автоматически создается учетная запись, на основании ее появления в кадровой системе. И эту логику не я придумал, а производители систем безопасности бизнес класса.
Ну что ж, все с чего то начинали. У нас тоже сначала были файлики, потом перешли на sql. Гораздо удобнее.
Что на мой взгляд явный минусы:
Есть стандартная команда import-csv. Она сильно упрощает жизнь.
Зачем парсить текст на наличие стоки? Вы уже договорились что вам будут выгружать csv — договоритесь о кодах дейстрия и введите поле action (типа 1 — прием, 2 — изменение, 3 — увальнение). И тогда не нужно будет делать 3 файла.
Нет функционала смены ФИО. Наверное у вас маленькая компания, или женщин мало.
Не понятно как вы реализовываете ключи для работы с учетками. У нас это сделано через код физлица 1С-кого.
Есть ошибки в имени домена (оставлены спецсимволы)
Такие скрипты уже встречались 2 или 3 раза на хабре не так давно, и не очень понятно чем отни отличаются.
Что на мой взгляд явный минусы:
Есть стандартная команда import-csv. Она сильно упрощает жизнь.
Зачем парсить текст на наличие стоки? Вы уже договорились что вам будут выгружать csv — договоритесь о кодах дейстрия и введите поле action (типа 1 — прием, 2 — изменение, 3 — увальнение). И тогда не нужно будет делать 3 файла.
Нет функционала смены ФИО. Наверное у вас маленькая компания, или женщин мало.
Не понятно как вы реализовываете ключи для работы с учетками. У нас это сделано через код физлица 1С-кого.
Есть ошибки в имени домена (оставлены спецсимволы)
Такие скрипты уже встречались 2 или 3 раза на хабре не так давно, и не очень понятно чем отни отличаются.
Подобных скриптов на хабре да и в интернете лично я не нашел. get-content ни чем не хуже import-csv. Парсится весь файл не на наличие строки и для того что бы получить данные для обработки, так как если файл пуст то ничего и не произойдет. Файл имеет имя сегодняшнего числа и в него дописываются все кадровые изменения сделанные сегодня, если изменение предпологается в будущем то 1С создает файл с нужной датой и он скриптом обработается в тот день когда указанно по дате. Поле action и есть первое поле.
В данной задаче Get-Content однозначно хуже. Давайте смотреть на примере вашего файла
Использование import-csv
То есть практически весь скрипт — это один ForEach + функции (да и те можно не делать)
А теперь сравните с вашим вариантом. Вы заменяете одну команду на 21 (6 на split 3 раза и еще 3 раза вы читаете файл (один и тот же кстати сказать))
Так же у вас нет обязательных проверок на то, что вы получаете. К примеру, SamAccountName не может быть более 20 символов — в скрипте это не учтено.
Я вовсе не пытаюсь сказать что ваш скрипт плох, нет. Просто судя по всему вы никогда не задавались вопросом оптимизации и производительности и в вашем случае этим можно пренебречь. Но раз уж вы решились выложить это на всеобщее обозрение — будьте готовы к критике.
Использование import-csv
ForEach ($User in (import-csv -path import.csv -declimer ";"))
{
Switch ($user."document type")
{
"прием на работу"
{
какое-либо действие
}
"перемещение"
{
какое-либо действие
}
"увольнение"
{
какое-либо действие
}
}
}То есть практически весь скрипт — это один ForEach + функции (да и те можно не делать)
А теперь сравните с вашим вариантом. Вы заменяете одну команду на 21 (6 на split 3 раза и еще 3 раза вы читаете файл (один и тот же кстати сказать))
Так же у вас нет обязательных проверок на то, что вы получаете. К примеру, SamAccountName не может быть более 20 символов — в скрипте это не учтено.
Я вовсе не пытаюсь сказать что ваш скрипт плох, нет. Просто судя по всему вы никогда не задавались вопросом оптимизации и производительности и в вашем случае этим можно пренебречь. Но раз уж вы решились выложить это на всеобщее обозрение — будьте готовы к критике.
Спасибо за комментарий. Вы кстати где то ошиблись в своей конструкции import csv не имеет параметра -declimer.
Плюс к этому ваша конструкция выдаст ошибку если одновременно на одно действие будет два пользователя. (к примеру два приема на работу)
Плюс к этому ваша конструкция выдаст ошибку если одновременно на одно действие будет два пользователя. (к примеру два приема на работу)
Такое случиться только в одном случае — если будет попытка принять одного и того же человека 2 раза. Но это ошибка не скрипта.
Спасибо за комментарий. Вы кстати где то ошиблись в своей конструкции import csv не имеет параметра -declimer.
Писал по памяти, ошибся. Правильный параметр — Delimiter ";" — он указывает какой символ является разделителем.
Подобных скриптов на хабре да и в интернете лично я не нашел.
Ну как минимум аналогичная задача рассматривалась тут. Правда в более глобальном масштабе.
а зачем вы делаете несколько раз Get-ADUser -Identity $usrcopyfrom, если можно получить сразу все необходимые свойства в переменную и уже из нее забирать, например:
$usrprop= Get-ADUser -Identity $usrcopyfrom -Properties DistinguishedName,...,company
$company=$usrprop.company
$usrprop= Get-ADUser -Identity $usrcopyfrom -Properties DistinguishedName,...,company
$company=$usrprop.company
три года назад с этого и начинали. Если интересно, могу показать во что это вылилось спустя какое то время :)
Sign up to leave a comment.
Автоматизация кадровых изменений на PowerShell