none
Отключения учетных записей пользователей в AD на время отпуска RRS feed

Все ответы

  • Оптимальный вариант, это привязать ADDS к СКУД и не париться.
    25 января 2016 г. 7:27
  • Есть необходимость автоматизировать процесс отключения учетных записей пользователей в AD на время отпуска.

    Что означает "автоматизировать"? Компьютеры телепатией не владеют. Откуда сервер знает, какой пользователь и когда уходит в отпуск?

    Отключение учетной записи - в первую очередь административная и только во вторую - техническая процедура. Оформление отпуска включает в себя подписание большого количества бумажек самыми разными людьми. Что есть "автоматизация" в данном контекте? Нужно дать права конкретному человеку на отключение учетной записи? Или что-то иное? В общем, сформулируйте конкретную техническую задачу, которую вы хотите решить.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    25 января 2016 г. 7:58
  • Самое простое что приходит в голову, это положить на сетевую шару *.csv с данными по человеку и датам отпуска, как вариант заставить кадровиком обновлять релевантно этот файлик. Согласно ему уже повесить в шедулер на доменконтроллере скрипт который читает этот файл периодично и лочит кого надо согласно содержанию
    25 января 2016 г. 8:28
  • Самое простое что приходит в голову, это положить на сетевую шару *.csv с данными по человеку и датам отпуска, как вариант заставить кадровиком обновлять релевантно этот файлик. Согласно ему уже повесить в шедулер на доменконтроллере скрипт который читает этот файл периодично и лочит кого надо согласно содержанию
    Боюсь спросить, если это самое простое, что тогда сложное? :-)
    25 января 2016 г. 8:42
  • Ну вот как раз дружить с БД СКУД или не дай бог 1С это имхо сложнее
    25 января 2016 г. 8:46
  • СКУД и даже 1С есть далеко не везде. Но и вариант с CSV-файлом плох. Вы в нем как пользователей хотите идентифицировать? По фамилии? Как быть с однофамильцами (иногда даже с полными тезками)? По логину? Откуда кадровик его знает? Его и владелец-то не всегда знает - а если еще и ошибется, случайно или намеренно? Заставлять кадровика этот логин в AD искать? Так если ему на машину поставить ADUC или ADAC, так почему бы там же сразу и не отключать найденную учетку?..

    В общем, пока автор четко не сформулировал свои хотелки, обсуждать задачу, в общем, бессмысленно.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    25 января 2016 г. 8:59
  • Ну вот как раз дружить с БД СКУД или не дай бог 1С это имхо сложнее

    Но тут хотябы есть готовые решения+у тебя появляется реальный фактор (присутствие на раб. месте) исходя из которого можно блочить учетку или не блочить. 

    Я вообще не понимаю, зачем этим заниматься, если честно. Если бы автор сказал в чем конечная цель, нам было бы проще.

    25 января 2016 г. 9:04
  • Самое простое что приходит в голову, это положить на сетевую шару *.csv с данными по человеку и датам отпуска, как вариант заставить кадровиком обновлять релевантно этот файлик. Согласно ему уже повесить в шедулер на доменконтроллере скрипт который читает этот файл периодично и лочит кого надо согласно содержанию
    А потом нужно и не забыть разблокировать, такими же средствами, например, проверять текущую дату и сравнивать с датой выхода из отпуска и если совпадает, то разблокировать. А кадровик не думаю что посмотрит с энтузиазмом на такую затею. Правильно сказали "заставить". :)

    //Vadim

    25 января 2016 г. 9:26
  • В нашей компании около 1700 сотрудников, по требованию Отдела Информационной Безопасности ежедневно Отдел кадров скидывает список в формате excell  с сотрудниками ушедшими в отпуск на определенный период. Блокировка учетных записей не занимает много времени, вот запомнить когда и кто выходит с отпуска сложновато, приходится ежедневно пролистывать список. Задача: заблокировать учетную запись на заданный период. Спасибо))
    25 января 2016 г. 10:10
  • Ну вот как я говорил =) Конвертите его в csv и гогоу в PowerShell =) Курить Disable-ADAccount в купе с Set-ADAccountExpiration
    • Изменено NTLose 25 января 2016 г. 10:17
    25 января 2016 г. 10:13
  • а делегировать блокировку\разблокировку безопасникам или кадрам аще никак?
    25 января 2016 г. 10:20
  • Нет ни как, в ИБ ни хватка кадров, а в ОК женщины работают)))
    25 января 2016 г. 10:56
  •  Блокировка учетных записей не занимает много времени, вот запомнить когда и кто выходит с отпуска сложновато, приходится ежедневно пролистывать список. Задача: заблокировать учетную запись на заданный период. Спасибо))

    Судя по вашему описанию, у вас есть задача не ЗАблокировать, а РАЗблокировать учетную запись в нужный день, то есть прямо противоположная поставленной изначально.

    В этом случае могу только присоединиться к другим коллегам: отключайте руками и формируйте в служебной директории CSV-файл с логинами, которые должны быть разблокированы в конкретный день. Затем раз в сутки запускайте планировщиком скрипт PS, который будет брать список логинов из файла и разблокировать их. Для простоты можете давать файлу имя, совпадающее с датой разблокировки, в этом случае скрипт будет несложным. Что-то типа такого:

    Import-CSV ((get-date -format d)+".csv") | ForEach-Object {Enable-ADAccount -identity $_.Login}

    Файл должен иметь имя вида "dd.mm.yyyy", иметь в первой строке слово "Login", в последующих - по одному логину на строке.

    В принципе, блокировать можно тем же скриптом (заменить Enable-ADAccount на Disable-AACoount), но руками будет проще.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging


    25 января 2016 г. 10:57
  • Есть необходимость автоматизировать процесс отключения учетных записей пользователей в AD на время отпуска.

    Хотел бы заметить, что тогда пользователи не смогут пользоваться некоторыми корпоративными ресурсами, например почтой. Я конечно понимаю, что отпуск и все дела, но иногда бывает нужно обратится к коллегам по важному вопросу именно в виде электронного письма.
    Чем ИБ аргументирует своё требование?
    25 января 2016 г. 11:09
    Модератор
  • Тут надо иметь конкретный пример файла, логина там никакого не будет подозреваю. Буду имена по-русски, а значит нужно все перебивать в Unicode и наверняка парсить формат даты ибо это тоже лотерея. Если бы автор выложил условный образец эксельки и чуть более уточненное техзадание, то было бы гораздо легче 
    25 января 2016 г. 11:22
  • Вопрос хороший, обязательно его задам завтра на планерки))). Сейчас стоит Mdaemon 6, он сам себе с АД не связан. В ближайшем будущем планируется развернуть MS Exchange 2010. Лицензия есть, но по не понятным причинам предыдущий админ его не поднял. Спасибо)
    25 января 2016 г. 11:23
  • http://download.files.namba.net/files/77683591

    25 января 2016 г. 11:34
  • Нет ни как, в ИБ ни хватка кадров, а в ОК женщины работают)))

    ну дык, проблемы негров..

    А с ОК что - простенькая хта с вбсным скриптом на поиск акаунтов в ад и галочка поставиль галочка убраль и оно само насяльника... от вас только грамотно делегирование настроить..

    25 января 2016 г. 12:01
  • вот запомнить когда и кто выходит с отпуска сложновато, приходится ежедневно пролистывать список

    Для этого у нас был создан общий календарь с использованием Exchange 2010. Когда сотрудник уходит в отпуск, то сотрудник отдела кадров назначает ему "Встречу", а в копию ставит общий календарь. Тема - отпуск, длительность встречи = длительность отпуска. Каждый мог подключить календарь и видеть подобную информацию о всех отпусках (а так же если сотрудник на больничном, в командировке и т.п.):

    25 января 2016 г. 12:18
    Модератор
  • Файлик конечно через попу сделан, умереть такое парсить =/ Период отпуска от балды и во всех трех случаях по разному забит с точки зрения формата и пробелов/тире 
    25 января 2016 г. 12:37
  • как вариант, можно установить срок блокировки учетной записи 14 дней(через GPO) но вот что делать если ты на другой срок в отпуск уходишь)) А вообще, для таких вещей есть FIM.
    25 января 2016 г. 13:00
  • Будет ФИО. Логина не будет, но для администратора найти его самостоятельно не проблема, я думаю. ;)

    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    25 января 2016 г. 13:12