Comments 24
github.com/raandree/NTFSSecurity
Чтобы не вызывать cacls.exe, icacls.exe и темболее xcacls.vbs.
Чтобы не вызывать cacls.exe, icacls.exe и темболее xcacls.vbs.
Автоматизация пользователей отличное решение. На это и нужен ИТ, чтобы приказ-юзер-профиль-все права по должности — развертывание всех приложений. И то же при увольнении.
Полностью согласен.
Было бы ещё интересно увидеть вариацию блокировки уч.записи по письму из outlook.
И вопрос не совсем в кассу но всё же, есть ли какое либо управление пакетом офисных приложений microsoft office с помощью powershell?
Было бы ещё интересно увидеть вариацию блокировки уч.записи по письму из outlook.
И вопрос не совсем в кассу но всё же, есть ли какое либо управление пакетом офисных приложений microsoft office с помощью powershell?
Какого рода управление вам нужно?
А блокировать по письму можно хоть обработчиком почтовым (на сервере ловить нужно письмо от нужного отправителя с нужным содержимым и выполнять скрипт) или макросом в аутлуке…
А блокировать по письму можно хоть обработчиком почтовым (на сервере ловить нужно письмо от нужного отправителя с нужным содержимым и выполнять скрипт) или макросом в аутлуке…
Первый вариант хорошо работает когда есть доступ к почтовому серверу :)
Управление да все которое есть, там к примеру поставить автоответ или же сделать полный архив почтового ящика.
Смотрите в api, благо у аутлука оно довольно богато. Тут примеров например есть msdn.microsoft.com/en-us/magazine/dn189202.aspx
А тут описание msdn.microsoft.com/en-us/VBA/Outlook-VBA/articles/object-model-outlook-vba-reference
Обычно конечно автоответы и архивы делаются на стороне сервера… :)
А тут описание msdn.microsoft.com/en-us/VBA/Outlook-VBA/articles/object-model-outlook-vba-reference
Обычно конечно автоответы и архивы делаются на стороне сервера… :)
А дальше?
Девушка вышла замуж и поменяла фамилию. Необходима изменить уч.запись и все ресурсы на новую фамилию, но что бы все осталось как было.
Девушка вышла замуж и поменяла фамилию. Необходима изменить уч.запись и все ресурсы на новую фамилию, но что бы все осталось как было.
Ну можно простой скрипт написать на изменение данных для старой учётки.
Плюс смена имён сетевых ресурсов, переименование почты, уч. записей в 1с, терминальные профили и т.п.
Достаточно удобно если все привязано к уч.записи AD. Если системы имеют локальные уч. записи. Это ещё то веселье по автоматизации в крупной компании. Самое забавное если девушка сама уже не помнит куда её предоставлялся доступ.
В итоге, перенастроив все на новое имя, узнаешь, что девушка уходит в декретный отпуск.
И на её место приходит новый сотрудник — девушка. И все начинается заново.
Достаточно удобно если все привязано к уч.записи AD. Если системы имеют локальные уч. записи. Это ещё то веселье по автоматизации в крупной компании. Самое забавное если девушка сама уже не помнит куда её предоставлялся доступ.
В итоге, перенастроив все на новое имя, узнаешь, что девушка уходит в декретный отпуск.
И на её место приходит новый сотрудник — девушка. И все начинается заново.
Переимновать учётку?
Как человек который пилит на Powershell в данный момент комплексное решение по синхронизации данных из учетной системы в AD могу сказать, что статья хорошая, но проблема синхронизации AD с учетной системой не раскрывается в статье от слова совсем. Непосредственно создать пользователя, раздать права, доступы и домашние папки это наименьшая из проблем этой автоматизации.
Основные головняки синхронизации:
ФИО сотрудников может совпадать и это могут быть разные люди.
ФИО сотрудников может совпадать и это может быть совмещение.
При полной выгрузке сотрудников из учетной системы каждый сотрудник может там встречаться от одного до n'оного количества раз, потому что новый табельный номер выдается при смене вида собственности организации, сотрудник мог увольняться и возвращаться в организацию, мог перемещаться по должностям и отделам внутри организации.
Новая политика создания логинов может ничего не знать про уже существующие логины и почтовые ящики.
Кадровики ошибаются в написании ФИО. Кадровики могут писать ФИО в том числе и заглавными. У людей может не быть отчества, или отчество может быть двойным…… как и фамилия. А еще сотрудников все могут знать под одним именем, а в кадровой системе у них может быть сходное но фактически другое имя. Наименование отдела или должности сотрудника может превышать длину полей атрибутов Department и Title. Заталкивать табельный номер сотрудника в employeId идея не лучшая, там длина всего 16 байт.
Есть чисто организационные проблемы: Сотрудники могут числится в одной организации, но в AD должны светить от другой компании.
И это еще без учета контроля административных и сервисных учетных записей и УЗ внешних компаний подрядчиков.
И да, для того что бы разгрести все это и не утонуть в ифах, нужны ДКА.
Парни, эта речка реальной автоматизацией синхронизации только выглядит не глубокой.
Основные головняки синхронизации:
ФИО сотрудников может совпадать и это могут быть разные люди.
ФИО сотрудников может совпадать и это может быть совмещение.
При полной выгрузке сотрудников из учетной системы каждый сотрудник может там встречаться от одного до n'оного количества раз, потому что новый табельный номер выдается при смене вида собственности организации, сотрудник мог увольняться и возвращаться в организацию, мог перемещаться по должностям и отделам внутри организации.
Новая политика создания логинов может ничего не знать про уже существующие логины и почтовые ящики.
Кадровики ошибаются в написании ФИО. Кадровики могут писать ФИО в том числе и заглавными. У людей может не быть отчества, или отчество может быть двойным…… как и фамилия. А еще сотрудников все могут знать под одним именем, а в кадровой системе у них может быть сходное но фактически другое имя. Наименование отдела или должности сотрудника может превышать длину полей атрибутов Department и Title. Заталкивать табельный номер сотрудника в employeId идея не лучшая, там длина всего 16 байт.
Есть чисто организационные проблемы: Сотрудники могут числится в одной организации, но в AD должны светить от другой компании.
И это еще без учета контроля административных и сервисных учетных записей и УЗ внешних компаний подрядчиков.
И да, для того что бы разгрести все это и не утонуть в ифах, нужны ДКА.
Парни, эта речка реальной автоматизацией синхронизации только выглядит не глубокой.
Так то оно так конечно, но добавить в скрипт что если такой логин уже есть добавить отчество, или же вообще заставить админа самому логин придумать.А если кто то увольняется само собой не надо удалять учётку просто отключаешь её и в комментарий уволен(а).
Лелаембизнес-процесс утверждения после проверки в отделе кадров. Проверили, все ок? Подписали, утвердили. Грубо пришел Вася в ИТ за ноутом, анкету открыл админ, спросил он, да? :) ОК верифиед. И т.д. так по каждому вопросу.
Когда компания более 20 человек, то тут действительно на 500-1000 работниках начинают взлетать интересности.
Кстати, с учетом политической обстановки вот сижу подумываю на никсах реализацию подобную под наш продукт строительный.
В общем тема горячая, надо обсуждать.
Когда компания более 20 человек, то тут действительно на 500-1000 работниках начинают взлетать интересности.
Кстати, с учетом политической обстановки вот сижу подумываю на никсах реализацию подобную под наш продукт строительный.
В общем тема горячая, надо обсуждать.
а вы не привязывайтесь к табельному номеру. создайте уникальный идентификатор сотрудника, который будет присваиваться всем штаным и нештатным ресурсам, будет сквозным для всех юрлиц, и не будет меняться при приеме/увольнении/переходе/повторном приеме. А к нему уже и привязывайте аккаунты.
Ну хорошо, будь по Вашему.
У меня по штатке три новых сотрудника, и у всех трех полное совпадение по ФИО. Они трудоустроены в один день. При проверке выясняется что у меня уже есть два разных подтвержденных сотрудника полностью совпадающих по ФИО. Итого по штатке пять сотрудников полностью совпадающих по ФИО, но с разными табельными номерами и должностями.
Как без участия аккаунт админа и специалиста кадровой службы понять сколько учетных записей в итоге должно быть?
У меня по штатке три новых сотрудника, и у всех трех полное совпадение по ФИО. Они трудоустроены в один день. При проверке выясняется что у меня уже есть два разных подтвержденных сотрудника полностью совпадающих по ФИО. Итого по штатке пять сотрудников полностью совпадающих по ФИО, но с разными табельными номерами и должностями.
Как без участия аккаунт админа и специалиста кадровой службы понять сколько учетных записей в итоге должно быть?
Я же говорю, HR система при приеме присваивает им уникальный номер. Каждому. Сквозной. Уникальность гарантируется как ручной проверкой, так и, например, использованием последних цифр номера паспорта (как вариант). Далее у вас появляется отчет/выгрузка, в которой видны идентификаторы, ФИО, табельные. И дублей нет.
а может использовать сразу SID? :)
В случае с 1С — это изменения в типовой конфигурации. Такие изменения приводят к снятии конфигурации с поддержки. Добавим к этому гремучую разношерстность организаций размером от мала до велика, включая версионность и тем что иногда даже не известно, кто обслуживает ЗуП. Все чего удается добиться, это стандартизованная выгрузка информации по всем сотрудникам с их статусами.
Но это все фигня, поскольку, связка табельного и именования организации уже обеспечит ту самую, пока я не понял зачем, сквозную уникальность. Но это не решает проблемы с пятью полными ФИОшниками, а в разрезе нескольких организаций это даже обостряет проблему, поскольку один человек может работать в нескольких организациях одновременно, и эти организации могут быть в одном домене AD.
Но это все фигня, поскольку, связка табельного и именования организации уже обеспечит ту самую, пока я не понял зачем, сквозную уникальность. Но это не решает проблемы с пятью полными ФИОшниками, а в разрезе нескольких организаций это даже обостряет проблему, поскольку один человек может работать в нескольких организациях одновременно, и эти организации могут быть в одном домене AD.
Sign up to leave a comment.
Как перестать быть демиургом и поручить создание сущностей PowerShell